It's not that they're not straightforward or that they're impossible. It's about quality of life and ease of development.
My whole point is based around making it easy to do, edit and expand on. Since there is a whole editor that can already be used to change the way event sheets opperate (by changing instance variables, behavior params or just object/plugin params) why not have something similar for scripts?
Having an init function that sets up the associated subclass for an object, or assigning vars manually through scripts that pick instances one by one, possibly by UID to get different outcomes etc.
All of that is of course possible. It's just a bunch of unnecessary steps that could be made integrated to the editor/ made visually/ automatically written.
Sure I'm not saying to copy them, as you said. I just think that it would be wise to see what they can do that might be cool and then design from scratch with it in mind
You taught me lots about multiplayer and though I do respect your work on zorder for strawberry punch I don't think we used a similar technique.
Still I don't take credit for the method myself, I doubt that either of us invented z ordering systems.
And thanks :)
Well here are two issues I can kinda think of at the moment:
1- What if you want to instantiate two ghosts but with different data. Different speeds, or different sizes etc all of that being defined from the layout.
2- What if you want to write something that can apply to more than just a Sprite, like a CameraObject script where every instance that has this class associated to it can control the camera a bit, by offsetting it or by fully taking control.
There are things that cant entirely be done only using subclassing just like things can't all be done by paralelizing features (like how families are used with one "solid" family, one "health" family etc).
The way Unity does it allows to have the best of both worlds. That's kind of what I mean.
Anyway, if all of that doesn't really make sense to you, then I'm really sorry, I will try my best to make it clearer once I write some code. But to be honest, the only way to really understand what I mean by all of that is to use Game Maker, Unity and Construct and write large-ish projects using them, which I know you guys don't really have time to do :/.
Anyway, the idea is to have a unified way to write js scripts that can better fit larger projects, which are the ones that will probably make most use out of the js feature.
That's the main benefit: Being able to easily write JS code that can be extended and modified at ease without having to preface it with tons of utility functions and an additionnal layer.
How it would work: Sadly I cant really go into more details than what I say in the blog post. I will try to write something using the available features and send a c3p file once I have something that's closer to what I envisionned using the newly available features but it's still gonna be limited compared to what you guys could actually do.
Well the simple answer is:
Right now it's technically possible to make games using JS only. However the things you did for Ghost Shooter will not work for a much bigger project. Anything that will have more than 10 concurrent systems working together will be very hard to organise to work with.
I would love to actually write something that would represent what I mean, but I'd need to properly design (and possibly code) it for it to be crystal clear. And even then, since I have only a limited understanding of the inner workings of the engine and that I cant access the engine code, you will very probably find flaws to what I can give you.
That is pretty cool indeed, that's enough to write some kind of workflow of my own. However I still think it would be pretty cool to see an integrated workflow to the editor in order to make development easier when using JS only.
I don't want to tick a js object, i want to tick a class instance that has been associated with a C3 instance.
That's interesting, how would it work exactly?
Is it already possible in r151?
Edit: nvm I just got what you meant. But that's already what I kinda do in the article, except I don't have access to the WorldInstance class so I made my own and get WorldInstance later. I didn't mean to make it possible, I meant to make it integrated in the editor and have a better workflow for it
What do you mean?
It doesnt change how it's run at all because the script is only a class getting defined. What it would do however would be to link an instance of that class to said object.
If code were to be put outside the class it would just run on startup like any other script. The script also only needs to be ran once to define the class and not on every object it's linked to. It's really just replacing the need to write the one line of JS in event I wrote
instance.Rotate = new Rotate(instance, data, runtime)
Thanks for tagging me. That's super weird, I wonder what he's trying to achieve :/.
Will the async actions be documented in the SDK? That's very useful IMO, great feature!
I'm guessing it would need to setup a new action tag, and then the actions become promises, and we need to return a promise instead of a value?
Great! I will try to make use of this feature as soon as possible.
Member since 3 Aug, 2015
Sometimes I do some cool stuff in Construct. Sometimes I like to talk about it.