I think my proposed solutions would be straightforward and provide a good quality of life. I'm an experienced JS coder myself, and I can see this scaling to thousands of lines of code with hundreds of objects and working OK. Perhaps we should wait until people actually write a lot of JS code and see how it works out.
I'm not sure how the editor would even be involved in either case? Wouldn't that just get in the way? Do you want to type in an init() function somewhere else, for example? That just seems to separate out your code and make everything harder to find, which seems to be an anti-feature to me...
1. Use an init() method that sets up the object like you want
2. The approach I just described of using a common base class can do that
Both are straightforward, no?
The way function parameters now work is far better. The problem with completely dynamic calls is there is no way to know which parameters should be added. Function mapping solves the problem of calling by a string while still being able to pass along known parameters. Normally completely dynamic function calls are not necessary - if you restructure your functions to work with the new system, they may well be much cleaner and easier to understand afterwards.
(Maybe we should take this to the forum, these comment threads are getting pretty deep...)
Also I haven't used GameMaker or Unity much, but I don't think it's too helpful to refer to them - either the language is significantly different to JavaScript, or the way the editor works is significantly different to Construct, or maybe even they have poorly designed features which they're stuck with for backwards-compatibility reasons, and it wouldn't be sensible to copy that. So I think it's worth designing (and explaining) everything from scratch, although that can be informed by how it works in other tools.
I don't see why the approach used in the Ghost Shooter code demo wouldn't work for a large project. You can sub-class as many kinds of object as you like.
You can also use a deeper class heirarchy to avoid code duplication. This is just normal use of JavaScript classes. For example you could have custom MonsterEnemyInstance and ZombieEnemyInstance classes, both of which derive from a custom EnemyInstance class, which derives from Construct's IWorldInstance. Now you can do things like write a single EnemyInstance.die() method, and it can be used with both MonsterEnemyInstance and ZombieEnemyInstance. So as far as I can tell this appears suitably scalable to large projects without code duplication.
I don't know what you mean by that - can you explain exactly what that would do, how it would work, and what benefits it would offer the way it works with subclassing?
You can already just add the behaviors to the objects and use them instead of code. The point of the example was to use 100% code and no events or behaviors.
See Subclassing instances for how this works in r152.
As has been the case for some time, no new features will be developed for Construct 2.
Please report bugs to the bug tracker following all the guidelines or they won't be investigated.
It's a way of using your own custom class deriving from WorldInstance. So you can add all your own custom properties and functions, and still do everything WorldInstance does.
Ah, I think this can be done with subclassing. No need for separate scripts for that.
How does attaching a script to an object change how it's run or change what kind of code you can use? This doesn't appear to have been explained, and there is nothing like it in the JavaScript language itself. I'm pretty wary about diverging too far from how JavaScript normally works, because one of our key goals is to help people learn skills they can re-use elsewhere.
Yes, you can already do that using the Project Bar. When you select an object type in the Project Bar, it selects all its instances in an open Layout View. Then you can delete those instances from the layout.
Member since 21 May, 2007
The official blog for all things Construct and Scirra run by our employees!
Wider technology issues from Ashley's perspective.