Pure code objects in level builder?
by Jason McIntosh · in Torque Game Builder · 06/23/2006 (8:20 am) · 1 replies
I haven't had time to really dig into using the editor much yet, so maybe I need more time to discover features, but here's an observation and a request.
Is there a way to place a "pure code" object into the level? That is, a script object which has no T2D class associated with it? If not, my request is to please add this capability. [Thinking about it now, is this possible? I might have gone insane recently. Maybe it could be a hook to a myClass::initialize( %this, %levelPosition ) call?]
The reason is that right now the editor works by connecting a visual representation (scene object) with your code. This is backwards to me. I don't build classes that are based on the physics or sprites. I build classes that are based on the behavior of the objects they are for and attach visual and physics representation to that as distinct and separate entities so that they can be managed and controlled with great freedom. So the T2D scene objects become "embedded" (composited/aggregated) into the code object as references.
As an example, the player object in any game should not be the sprite with some code added. The visual representation is only a part of the behavior, and basing the entire structure of the object around that creates limitations and clutters the code. That's ok for a tutorial demo, but a game of any sophistication and complexity will break fast using that kind of construction.
If I was able to place script objects with no scene object into levels, I could avoid those issues. My pure code object would then initialize its own assets such as sprites and particle effects. Sure, that's an "old skool" way now, but it's also much better for large projects. As it is, I don't think I will be able to use the level editor very much, which is a shame because it looks great, and I don't look forward to building my own tools when this one exists. :)
I'm also not clear about how you can manage objects if you can't embed references in your script objects (ie, your namespace/class code). For instance, if I mount a particle effect to a sprite, link that to a namespace, how will the namespace be able to manage that linked particle effect? Where does the reference come from when I want to turn it on/off or delete it? Maybe I'll find those answers in the tutorials. :)
Thanks for reading. Some of this is me thinking "out loud," so please correct me where I'm wrong in regard to the capabilities of the wonderful looking TGB editor. I don't want to confuse anyone.
Is there a way to place a "pure code" object into the level? That is, a script object which has no T2D class associated with it? If not, my request is to please add this capability. [Thinking about it now, is this possible? I might have gone insane recently. Maybe it could be a hook to a myClass::initialize( %this, %levelPosition ) call?]
The reason is that right now the editor works by connecting a visual representation (scene object) with your code. This is backwards to me. I don't build classes that are based on the physics or sprites. I build classes that are based on the behavior of the objects they are for and attach visual and physics representation to that as distinct and separate entities so that they can be managed and controlled with great freedom. So the T2D scene objects become "embedded" (composited/aggregated) into the code object as references.
As an example, the player object in any game should not be the sprite with some code added. The visual representation is only a part of the behavior, and basing the entire structure of the object around that creates limitations and clutters the code. That's ok for a tutorial demo, but a game of any sophistication and complexity will break fast using that kind of construction.
If I was able to place script objects with no scene object into levels, I could avoid those issues. My pure code object would then initialize its own assets such as sprites and particle effects. Sure, that's an "old skool" way now, but it's also much better for large projects. As it is, I don't think I will be able to use the level editor very much, which is a shame because it looks great, and I don't look forward to building my own tools when this one exists. :)
I'm also not clear about how you can manage objects if you can't embed references in your script objects (ie, your namespace/class code). For instance, if I mount a particle effect to a sprite, link that to a namespace, how will the namespace be able to manage that linked particle effect? Where does the reference come from when I want to turn it on/off or delete it? Maybe I'll find those answers in the tutorials. :)
Thanks for reading. Some of this is me thinking "out loud," so please correct me where I'm wrong in regard to the capabilities of the wonderful looking TGB editor. I don't want to confuse anyone.
About the author
Torque 3D Owner Stephen Zepp
Or even easier for what you want your workflow to be: name your objects uniquely--that's their "direct reference". Use the onLevelLoaded callback to do whatever procedural work you want per level.
Long Answer (long for you!): it's honestly just a mind shift for you to make (or not make, completely your choice), but the basic method of using the level builder for things like player objects is simply that--a method. It's actually more designed for utilizing your finished classes and their visual representations for actually building levels--many 2D games are made up of dozens/hundreds of levels, and procedurally/programmatically creating that many levels is a chore, especially since code writers don't necessarily make the best level creators.