I know about that issue, haven't gotten around to fixing it 👌
Try again now
Ah shoot, my bad, will fix thanks
I'm not sure we're on the same page concerning that whole JS thing.
Construct just introduced JS in the editor with the aim to eventually allow them to replace event sheets entirely. Aka making games entirely in JS.
My code is nothing final and only served as an example to what I meant in the proposal. I am asking to allow users to write their own classes and link them to C3 instances to write said code that would replace event sheets more effectively.
I don't want to write my own engine, far from it. I want the engine to extensible.
That would let Construct call js functions every tick, unless you meant call them from event sheets in which case, that would be "replacing event sheets entirely".
That is because the system action doesn't take an expression, but an instance variable, so we must use one.
Sure, ask any question you have.
Well, if I want to write all of the game in JS, I need to be able to run some code on each frame.
Filling in code templates would work yeah.
In that regard, you could just fill in a hidden template for the runOnStartup to avoid the trouble of having to chose the right function, and to avoid the case where the user messes with it.
But yeah what I'm asking for is just quality of life stuff, and a set of conventions, far from a rewrite of the engine.
Though one thing that does bug me is that if we do have a way to "add a script to an object through the editor" it would be nice to be able to add multiple ones and that does require a bit more work.
I wanna try writing what I mean into JS and send the file to you as I'm sure it would be much clearer.
If you mean the z elevation, you can also do that :)
Just be sure not to set it to values too big or you might have an unwanted perspective effect (or maybe it is wanted and in that case it's great)
I totally agree with you on that point. We'd need to see people actually write JS code and hundreds of lines before being sure of anything.
Well it'd be hard for the editor to get more in the way than "used for everything on layouts and basically anything that is not immediately code"
One example of how the editor could be useful would be:
Instead of doing
runOnStartup(async runtime =>
{
runtime.objects.Player.setInstanceClass(PlayerInstance);
runtime.setEventListener("tick", PlayerInstance.Tick)
}
Just add a button on the object properties tab and add the PlayerInstance class script to it.
Same button could be used to generate a new script file that would automatically write the basis for a subclass from the right class instead of having to guess or look at the docs.
Having to write the code somewhere else would indeed be counterproductive
Basically, if I wanna start writing a game entirely in JS, I dont want to have to write the stuff that will make my life easy later on. That's the main point I wanted to make.
The other point is that once there is a unified way of doing stuff it becomes much easier to write a standalone script that can be integrated anywhere and work almost plug and play, which is a huge plus for the community and for education
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 :/.
Member since 3 Aug, 2015
Sometimes I do some cool stuff in Construct. Sometimes I like to talk about it.