Mich's Wish List

#41 Don't use behaviours ever. If we mean config datablocks then we use those all the time.

#42 @Scott - Are you saying you don't use behaviors, or are you suggesting people to not use behaviors? Btw, I was referring to config datablocks.

#43 Sorry Mich, I was say I don't use behaviours at all. I prefer to encapsulate attributes in config blocks and behaviour using classes and sub-classes.

#44 @Mich - super excited for 2D Tuesdays

#45 Wow @Mich,

Your wishlist is great! That's the kind of knowledge from a tech lead that makes me warm and fuzzy. It's a great list filled with things to attract hobbyists and pros alike, and it has most everything on my mind as well!

If I would change anything listed, it is the emphasis on physics, as others have stated. It's important but it's not THE important of all time.

Call me short-sighted but there are only so many flinging birds, incredible machines, and animal drops that can be made IMHO. Atleast, as @Conor pointed out so eloquently, there are 10x more non-physics games out there (and making tons of money, too).

So, if that box2d s*it is clogging the system, I'd do a run around and get some of this other stuff out!

And if I would add anything to the list... well I'll make a new post for that. :)

#46 @Charlie - You and Conor do have valid points about not all games needing the same physics responses used in games like Angry Birds. However, an implementation of Box 2D is going to give you a whole lot more for free. I talked about that in my recent post in the Box 2D thread. When you are implementing a new physics system into a hierarchy like we have in iT2D/T2D, you are going to touch a lot of classes and sub-systems. This is a great opportunity to perform a lot of cleanup and generally improve the engine.

Implementing Box 2D physics to make a game like Angry Birds is not why it was on my wish list. The list of "freebies" you get with a proper implementation cascades:

- Remove unnecessary code
- Rename classes to be more fitting
- Update source documentation
- Remove some bloat
- Switch scene management to something more cleaner

#47 @Mich, it's not obvious to me how your list of cascading features is tied to a physics library (cleaner scene management?), but we'll see...

#48 Here is my personal addendum to your list @Mich. It's in my nature to collect ideas on improving tools, so don't be mad. :P

TorqueScript modernizations

• undefined variable warnings - I waste 20% of my time chasing down bugs by echo()'ing until I find I mispelled a variable name. There. I admitted it. (note: I found an out-of-date flag to set this, but it will wreak havoc on your log file due to lots of builder-based errors)
• Actionscript-like improvements to TorqueScript - always backwards compatible of course. more like actionscript, which means more organized (public, static, class) and faster where possible

Modular engine

• C++ modules - how cool would it be to release a new TexturePacker reader for Torque as a C++ "plugin", ready for all to use? how about a new "editor" in the builder as a plugin? now we're cooking with gas! (P.S. sharing "code snippets" on the forum is depressing)

game projects

• remove "resource.db" files - images and other resources should just work when placed in the appropriate dirs. if I drag an image into the images dir (or a script into the gamescripts dir) it just works. for the image, it defaults to "FULL" mode. If I click it in the builder and set it to cell mode, then a file is kept alongside the image with that metadata.
• TorqueScript modules (improved) - I'd like people to be able to pop Twillex.cs into a directory and just have it work and be automatically initialized and stuff. (note: there is some kind of mod system, but I don't follow it.)
• smaller default game footprint - it would be nice if most of the "common" code ran from the app directory (and was included at final build), so that I could make a new project that was almost empty instead of 400 files like now ... imagine the benefit for sharing demos.

GUI improvements

• It's the little things, like selecting all the text when you click on an entry field. Or, my favorite Flash GUI feature, a way to adjust a numbered value just by clicking and moving the mouse. Oh, and remember the size and position of my editor when I start, please. :P
• the day I can run the game *in the editor* and even adjust it GUI'ly while it plays is the day that no other engine need bother to exist.

object templates (my personal favorite)

you know how you can make a scene object, in the editor, meant to be a template, set it up with size and image, behaviors and world limits, etc? you can then set it off-screen and clone it for each run-time character? I'd like this to be more natural, so that I can save these templates to be used for any scene, change them in the editor, and so forth. (the "persist" feature isn't quite it.) this would be similar to how particle effects or tile maps can be saved and re-used.

process

smaller/quicker releases - I'm sorry but i had to say it, again. the amount of pressure off the team would be huge if small things made it into releases every month. sure there is also a giant iT2D 2.0 coming with box2d, but until then...

#49 @Charlie -

Quote:It's not obvious to me how your list of cascading features is tied to a physics library

Ok, well I'll cover that in my 2D Tuesday discussions, but here is a list of some changes:

• All world units are now physical units i.e. the meter.
• Objects to "real world" equivalents, not pixels
• Y axis has been inverted. +Y is now "UP", -Y is "DOWN".
• "Rotation" is now referred to as "Angle".
• Positive angle gives anti-clockwise rotation whereas negative angle gives clockwise rotation.
• t2dVector now uses fields of "x" and "y" rather than "mX" and "mY".
• t2dSceneGraph has been renamed to be t2dScene.
• The old "setGraphGroup" & "getGraphGroup" calls are replaced by "setSceneGroup" and "getSceneGroup".
• The old "setLayer" & "getLayer" calls are replaced by "setSceneLayer" and "getSceneLayer".
• Nearly all of the collision control methods and fields have been removed, only a few remain so it's much easier to use.
• The collision callback occurs on the "t2dScene" namespace now, not the "t2dSceneObject".
• The "mounting" feature has been removed. This is completely subsumed by the use of "Joints"
• The joint API exists on the "t2dScene" namespace, not the "t2dSceneObject" one.
• A lot of API documentation exists inside the C++ code.
• The C++ now separates "ConsoleMethod" for types into their own header files i.e. "t2dSceneObject_ScriptBinding.h"
• The TorqueScript method names are identical to the C++ method names.
• There is now an extremely detailed Debug-Drawing and metrics display available.
• I have tried to maintain compatibility for all binary-save files. It should be able to load older files and convert that data into the new format appropriately.

Some of those are going to make for good porting instructions, while others are almost completely unrelated to physics. For example, moving ConsoleMethods to their own _ScriptBinding.h has dramatically reduced the bloat of individual source files. t2dSceneObject.cc used to be 11,037 lines. Now it is 4,745.

For something simpler, like t2dSceneGraph being changed to t2dScene, think of how well that flows with what is usually associated to it. A t2dSceneWindow will contain a t2dScene, which holds t2dSceneObjects. Small change with great results.

#50 @Mich,

Assuming that a scene object is pretty darn similar still, I imagine a person can get their code up and ported in a couple of days. I'm in!

I'm curious about the collision being in the scene. It makes sense, but I always liked that collisions were more sophisticated in Torque than they are in Flash and other frameworks, so I hope it is still pretty sophisticated. The one thing I always wanted was that only the "sender" of a collision received the callback (unless both objects are set to send a collision to each other).

Finally, I hope I can turn the advanced physics "off" since I don't use them (except linear velocity) and all physics are expensive. I kinda like the Unity3D model (from reading about it only) where you add/remove physics from a game object, instead of having it intimately tied in. Then you could "attach" torque legacy physics, box2d, or just basic linear motion to your object and pay, in cpu, only for what you need. Or maybe, if I am reading between the lines correctly, attach the physics to a "scene" (instead of a scene object) now, and have the scene apply forces to the objects like the real world does.

Well cool. I guess you are getting pretty close, though you can't say. :P

#51

Quote: Or maybe, if I am reading between the lines correctly, attach the physics to a "scene" (instead of a scene object) now, and have the scene apply forces to the objects like the real world does.

That's closest to the pin. Objects are manipulated based on the forces applied to them. You can apply constraints, such as friction, density, and joints, to control their reactions. Simple stuff like linear velocity is cheap and you will not notice any problems. I posted screenshots in another thread showing how we had thousands of things on screen moving all at once with extremely high FPS.

Bah, I'm giving away all the good stuff for 2D Tuesdays. I'll save the rest of the details for those blogs.

#52 Oh this is sounding really good! I always felt like box2d takes over simple designs with its series of joints, multi-bodies, motors, and protrusions. If I don't need 'em, I don't want to deal with 'em. It sounds like y'all may be onto a more intuitive way to express these constraints!

#53 Well here we go: First 2D Tuesday Entry