Here is a way to dynamically create instances

After doing research in the forums I see that it is a common question...

"How do I create an instance of an object dynamically (by text name) and then get a reference to that instance to use it?"

Normally in computer languages this can be done synchronously (create it and immediately use it).

However this can also be done asynchronously (start the creation now...and later it will be finished).

<strike><font color=yellow>

Construct 2 uses the asynchronous method.

This however causes complexity that seems out of place in Construct 2.

</font></strike>

<font color=green>In the tutorial there is an example of doing the same thing synchronously as well.</font>

Many people have struggled with how to get a handle on this.

Plugins have been created to try to help.

Here is a tutorial that contains a capx (https://www.scirra.com/tutorials/788/asynchronous-callback-object-creation) that shows a method to handle this with what is known in the software development world as "Callbacks".

It is implemented entirely with Construct 2 Personal / Business features.

The way it works is described in detailed comments in the capx. Basically you create an object by calling a function called "New" and pass it some parameters via Dictionary objects that includes the text name of the object type, the name of the Callback function you want called after the object has been created, and any parameters you want passed to the Callback function.

The Callback function gets the UID of the new object (as Function.Param(0)) and all the additional parameters you specified (as Function.Param(1)).

With this you can do a Family > Pick instance with UID or Pick an instance of the specific type and then just do all the actions you would have normally done.

Nice, make a tutorial! <img src="smileys/smiley3.gif" border="0" align="middle" />

Yes, it might get lost as a mere forum post.

Good idea you two...

Tutorial:

(https://www.scirra.com/tutorials/788/asynchronous-callback-object-creation)

I'm not sure I understand the necessity of this, since when you create a new instance of an object, it is automatically picked for the following actions within the same event. No need for a callback function to modify the new instance, it's available immediatly. Maybe I'm missing something, I'm a former software developper myself and I understand what a constructor is, but I don't see the point of making thing more complicated than they are when the point of construct is to make them simpler.

And if the name of the type you want to create is stored as a string of text in an Instance Variable or read in from JSON?

What you are talking about only works if you HARD CODE the type into the event... look through the forums and you will see many people asking how to do this exact thing.

well this is true, you cannot create an object dynamically by passing a string variable, and I agree it's too bad.

But in the end the solution you are offering is more or less hardcode too, it's a big SWITCH that handles each case (sprite 1, sprite 2, sprite 3 and so on). Yes you can now create new instance by just passing a string variable, as long as it's handled by your system. In order to introduce a new type of sprite, you still have to write the specific code for it, in two different places.

So in the end, it's pretty much the same as writting a constructor function for each sprite type, where in one place you create the instance and set its properties. Then you just call the right function when needed.

Instead, you added this asynchronous layer, which in my opinion is unecessary and only adds complexity.

It definitely is not the same thing. Instead of putting switches all over your code and writing the same code over and over with slight variations with this method you have a single switch which acts as the object table you would normally have made for you automatically when you compile your application.

To add a new type you copy and paste one of the other switch cases (2 lines) and change the type to the new type... that is it... you do not need to do anything specific to that type else where.

From then on you can refer to the instance via Family (like is shown in the capx) ... at that point you have decoupled your type from your code so you can start making abstraction layers and reusable functions.

I really cannot teach 30 years of coding in a forum post, but if you learn OOP programming and go through the experience of making a few large applications that you have to maintain, upgrade, and reuse code across project to avoid bugs and wasted time then you will see the benefits of decoupling your types from your logic... this is why in OOP languages like C++ and C# you have things like Interfaces and Inheritance trees... It is an old problem that professional software engineers deal with all the time... it is something that new developers that are just working on small project never have to consider... this is why I added the tutorial to the "advanced" category ... it is not for new developers or hobbyists.

Another point I would like to make for those interested is how nice the idea of Family feature is in Construct 2 once you have decoupled your type from your logic... This gives you the equivalent of "multiple inheritance" in the OOP world. Many languages do not support multiple inheritance, but get around that with the ability to define multiple interfaces on your class and the ability to inherit from one parent class.

You can have a single object type inherit from several different Families and then "cast" it from one family type to another to reuse the functionality that is available in each family. In the capx you can see an example of this where one of the objects inherits the flash behavior when it is treated as one kind of Family type and then is "cast" to the fade family type and is faded... all without knowing which specific sprite type was being referenced at that moment.

Lots of opportunity there for code reuse.

It's all probably very usefull, although it seems overcomplicated.

Just a small question though.

You state Construct2 has asynchronous callback, or something like that, but in a creation event when you use subevents automatically the just created instance is referenced, wouldn't that be called synchronous?

My understanding of how Construct2 creates objects (async vs sync) is largely based on this post (http://www.scirra.com/forum/wait-next-tick_topic65424.html).

You two bringing up the question (and after everything I have learn in the past few days) I decided to create a new test capx which seems to show that I can call a general purpose function that accepts a string and returns a UID and it can be immediately picked by a Family. So I am not sure what it is they were talking about in that post above.

Obviously this new capx is just a quick test I did so I am going to start using this new method that is SYNCHRONOUS and see if everything works correctly with it. If so I will change the tutorial (and this post) to not claim that objects are created asynchronously. Async method calls with callbacks (which is commonly used in JavaScript and other languages) is still useful so I will leave the tutorial either way and modify it to show the Sync method as well.

<img src="https://cwcdfw.bn1302.livefilestore.com/y2pHSSo_OgySsvNt1Qh0kj1_52XJaliqX9BcI_zWL_kUz-0XCwesVEZpwfVcevJlvwwbIaOP-fn87ZB_LjnlHMJ7k9sF0hoZ7q0XpuRNNv5Zz8/CreateSpriteByNameSync.JPG" border="0" />

LittleStain

I just converted my app (I wouldn't call it a game yet... more of a test to see how far I can push the Construct2 engine) so now I have a slicker version of the New function that does both Sync and Async and it all seems to be working well.

I wanted to point out one example of where in JavaScript in the past I have taken advantage of Async callbacks. I am a principal engineer at a large Internet company that has nothing to do with gaming so my experience is with a data analytics app, but still I did some JavaScript coding on it.

When you make remote calls back to a server such as with JQuery $.ajax calls they are actually async calls. The browser completes that call on a background thread and then does an async callback to a JavaScript function you provide when the Internet server has responded to your request.

You can certainly mix sync and async methods. However a growing trend in software engineering is building most functionality to be async. This allows future advancement like distributing computing across cores (with threads) or across machines. For example look at the technology from Microsoft called Rx (Reactive Extensions) which has a JavaScript version... Netflix made a Java version to run the code that puts together the lists of suggested videos they show you in their UI...

First let me say like many others here, I don't come from a programming background. Using Construct2 is the first time (apart from old fashioned html-website building) I tried to do anything with programming.

Construct2, has some asynchronous callbacks, the best examples I can think of now are Ajax and pathfinding. To make it easier for non-programmers like me, these have the "on data recieved" / "on path found" events attached to them.

The topic you linked to was started by Yann and he/she is a very capable programmer, so I'm sure the things described in it make sense, although it confuses me also.

I will have another look at your capx and tutorial and try to understand what kind of benefits there would be for me personally to create the events your way.

It's always interesting to see how someone with a different background tries to tackle issues, it always learns me a lot.