Interesting problem with global objects

Well,

This one is strange, because it is the "correct intended behavior", but I seem to think otherwise.

Okay. So here is what:

• Lets say I have two layouts, and one object created in layout1 and set as "global"
• The second layout (layout2) also has an instance of this object. But game play requires this instance to be destroyed.

Now if I loop back (using "system:go to layout") on layout2, I would expect the object to not exist (since it was set to global, and was destroyed by gameplay), so this is okay, and expected.

But what if i use "system:reset global variables" along with "system:go to layout", I would expect even global instances of objects to be reset, basically resetting the complete layout with the initial object instances, and positions. But of course, I believe reset global variables, only works on variables.

We should probably have a "reset layout objects" action. I know this could be tricky, and have side effects, because you don't want this to work on certain objects. Probably this behavior should be an added "reset layout" rather than "reset objects" action. But I hope I make my point clear? Tricky one this. But. Would really help.

Consider a game like angry birds, with lots of layouts, (levels), you do not want to instance your usual gameplay elements (such as effects, birds, and what not) on every layout. You would create a template layout, push all common stuff in there, make it global, and simply use instances of these if flexibility is required. And then when you restart your layout, you want the initial instances to be recreated. Hope the example makes my question clear. :)

Note that this sort of stems from the limitation where an instance of an object is required on a layout before you create it dynamically. I notice that a message says this will be fixed in future revisions.

I think if that's fixed, its going to make this whole N levels design much less complicated. (and super clean)

Oh wait,

You dont have to set objects as global on a template layout....

Hmm seems you guys thought of everything! My bad. That's "clean" enough.

No changes required!

The problem is not so interesting after all. :D

What's a template layout?

I'm interested in this too - especially spawning things dynamically and not having to hide an instance of everything off the edge of the screen.

All objects are accessible from every layout without needing to be global.

This will be about the 20th time I've explained this. <img src="smileys/smiley19.gif" border="0" align="middle" />

Global means the object will be in all layouts, and will save it's state from one layout to the next.

Therefore its is a better idea to create an event sheet include, where you can create, destroy, etc anything you like, any time you like, and place that, or those event sheets in the layouts where you need to do something to those objects. <img src="smileys/smiley17.gif" border="0" align="middle" />

JohnnySix:

A template layout.

Well, since c2 requires you create an instance of an object before you create something for the first time, it makes sense to have a template layout (which is never used in game) and dump all your objects into that one layout. Apparently all c2 needs is an instance somewhere in the game, to know the objects default properties.

This way you do not have to recreate this first instance in all your subsequent layouts. Making things cleaner.

Interesting. I thought an instance of the object had to appear in every layout where you planned to create/spawn it, but you are right. It only has to appear in one layout and can be used by all others.

Now that I think about it, I recall what you are calling a template layout referred to as an "object bank" in Construct Classic--probably in scidave's Mikey's Adventure tutorial. Don't know why I didn't make the connection despite Newt's numerous explanations.