Object constructor question(s)

Object-oriented programming utilizes "constructors" which at its basic level allow the programmer to instantiate a bunch of member (instance) variables upon creating the object.

Correct me if I'm wrong, but it appears Construct 2 doesn't have that built in.

For this simple example where we just set the position and scale of Ball on creation, are these the current alternatives:

Make the constructor simply just an On created trigger:

<img src="http://cannedessence.com/construct2screens/constructor1.png" border="0" />

Problem: you can't elegantly send values to the constructor. This would be desired if the place where you create the object has contextual information from some other picked object, etc.

OR

Make a function as a constructor replacement, and this is where it gets confusing to me:

<img src="http://cannedessence.com/construct2screens/constructor2.png" border="0" />

Why does this work? Notice the second action in the Create_Ball function. Shouldn't this pick all instances of Ball, since the event doesn't pick any instances of Ball? Somehow it picks the most recently created Ball, which works here. However, it doesn't seem right, so I don't want to rely on it.

I can't put an On Created trigger inside the function definition because they are both triggers.

Is there something I'm missing about this?

Thanks!

Make a function as a constructor replacement, and this is where it gets confusing to me:

<img src="http://cannedessence.com/construct2screens/constructor2.png" border="0" />

Why does this work? Notice the second action in the Create_Ball function. Shouldn't this pick all instances of Ball, since the event doesn't pick any instances of Ball? Somehow it picks the most recently created Ball, which works here. However, it doesn't seem right, so I don't want to rely on it.

I can't put an On Created trigger inside the function definition because they are both triggers.

Is there something I'm missing about this?

Thanks!

The create action picks the created instance, so you are only referring to that instance. So you could get rid both the function and on created, then do this:

create ball

set ball scale to 2

It would work just as well :) But yea, it's not really ideal to my workflow at some times either.

Ashley specifically set out to create an event-based system so that non-programmers would be able to create games more easily.

The system is 'as it is' and I for one would not want it to become more programmer-based. The idea is you learn the system that is available, and not expect something to work as you think it should.

There are already plenty of systems out there that cater for the more programmer-minded individual.

Honestly as far as game logic goes, the need to perform some operation on all instances after the creation of one instance happens much less than the need to do something to the specific object instance when it is created.

You can have it both ways. 'Create object' or 'Spawn object' pick the instance, so you can initialise just that object in a constructor-like way. If you *do* want to do something to *all* instances after creating another instance (which sounds unusual but is possible), just put 'pick all' in a subevent and then you can affect all instances from there.

That answers my questions, thank you all!

newt

No, I agree that referencing the instance you just created is more common than referencing all instances of the just-created instance. I prefer that functionality (it makes my second example constructor work =P). I just found it fishy that it worked, because as far as I knew, no action (just events) picked instances. I was just afraid that it was incidentally picking the most recent instance because it happened to be at the "top" of the SOL or something.

Good to know the create object action also picks the instance.

zenox98

I agree with the essence of what you are saying: Construct 2 is designed to be accessible to non-programmers, shirking away lots of the scary syntax, boilerplate, etc, of code. However, there are reasons for why object-oriented languages were designed the way they were, it wasn't just job security.

Being able to clean up the on layout start event by logically grouping events into functions is smart. Notice how the Ghost Shooter example start layout event is a bit unruly? Having a constructor function to handle instantiating an object and its properties is good organization, not "programmer-minded."

That's the kind of stuff you see in the popular thread about best event practices in Construct 2: scirra.com/forum/programming-best-and-worst-practices_topic63136.html

You can have it both ways. 'Create object' or 'Spawn object' pick the instance, so you can initialise just that object in a constructor-like way. If you *do* want to do something to *all* instances after creating another instance (which sounds unusual but is possible), just put 'pick all' in a subevent and then you can affect all instances from there.

This should probably make it into the manual (in the section where System Create Object is described)