What would you like to see addressed in Torque 2D?

#121 It has been awhile since I have posted. But I spent many months in the early TGB releases working with the engine and it looks like this new code base will address many of the issues we faced adopting TGB early, I wanted to throw a few of my own comments in the bucket..

1. GUI system overhaul I've seen mentioned already makes much sense to me. The core of how that gets implemented I'm not as concerned about as long as it has the ability to do scene type animations and reuse of scene objects easily, think mini maps, loading screens magic with proper callbacks in place, particle effects on gui control clicks.

2. I would kill for a simple fully integrated isometric implementation, maybe GG should put Neo on the payroll for a few months :-) While its possible today with TGB, integration of not just tilemaps, but behaviors, pathfinding, etc could all use some core level love to do right. Maybe accomplishing this with the 2d/3d capabilities might be easy in the new concept.

3. The particle system (which already kicks butt) , I would prefer to see tied to the behavior system a little more closely, where behaviors could drive the dynamic portions of the particle effects and interaction with other objects, it might already be able to do this, but I havent used recent tgb versions. Being able to reuse the same type of effects easily over multiple particles would reduce implementation time, and drive consistency.

4. Media overhauls and pipeline help. The core issues mentioned with image animation loading, video playback , sound looping, etc. Native support for more media types would be nice.

5. Include a Default Garage Game Scene for how you want your required license splash screen to show, dont make me build one :-)

6. include "tons" more predefined behaviors

7. Closer integration with Torsion, or inclusion of.(I heard its mentioned).

8. A solid implementation on linux (I know.. but its on my list)

9. A robust Game Server on linux regardless of 8.

10. My most important one. Many application platforms adopt a modular type system for plugging in core functionality. I would think something like this would allow custom engine development to advance rapidly and safely, and ability to build core integrations without breaking the core. For instance. The "engine" itself is just a module itself. If I wanted to override the engine behavior, my code would be compiled into a module that I would choose to include in my project, or the physics engine, particle engine, etc. As well as allowing non engine owners the ability to put their own compiled functionality into scope to some degree if you would allow inclusion of a linked library to be scoped.
This would allow for third party add ons to be easy to integrated, as well as securing the safety of the core engine allowing updates without code merger lower in the core, or the ability to just package those parts of the engine being used. The TorqueScript scripting engine itself could be a module, that could be replaced with LUA by someone so desiring to hack out the parser / lexer for that. Asking for alot I realize. Just a hopeful developer looking to be lazy..

#122 Since I load this and the "Torque 2D Development Series" blog post every day to see if there's any updates, I keep thinking about what I do want to see in Torque 2D. Networking was a big thing for me, as the networking I wrote to do my TGB multiplayer tetris game took quite a bit of effort in reading TGE docs and looking at the C++ source, and going through piles of TGB common code to learn things.

So adding support for real-time networking right out of the box was great. But really, the number one thing that bothers me about TGB is all of the code in the "common" folder that TGB sorta uses some of. None of the "common" code is actually documented as far as I can tell, because it's not really part of the engine. There are also some functions in the engine that aren't documented at all, either though.

When I was writing that tetris game, getting things like the options GUI working, savable preferences, and several other little things working, was *so hard* to find out. It's not documented, and some of the code seemed flat out broken. I'm pretty sure a ton of it was just copied straight from TGE and left to rot.

At some point, a few years ago, I had my movemaps showing up in the options dialog perfectly. I updated to the latest version of TGB, and somehow it was completely broken. Some functions I was calling were just non-existent. I don't know where they went. I search aaaalllll over the documentation for TGB and TGE... nothing. So now the latest version of the game has no configurable controls. I don't want to go digging around through a ton of that "common" code and more of the C++ engine to figure out how the heck it's supposed to work.

I'm also really not a big fan of TorqueScript. It's too quirky for my tastes, but I doubt that's going anywhere.

As far as the features of the TGB-specifc API itself, I was fairly pleased. The editor certainly needs a lot of usability improvement, but it already does a lot of things right.


I'm just a casual user of TGB. The only game I finished was that multiplayer tetris game I wrote for a weekend contest (which I won). I'm sure most everyone who really uses it has figured out the division of labor between the engine, the common code, and their own, and what pieces are in what state after being left over from TGE, which would make the whole process a lot clearer, but from my mostly first-time perspective, it's a real headache to work with compared to other frameworks.


One month until GDC...

#123 Okay catching up was insane... whew!

1. Don't lose torque script please keep that as a scripting layer. I've spent over three years forcing myself to learn the language and writing countless new methods to make programming and rapid prototyping a breeze. I'd lose my mind without incorporating my gameMethods.cs into every TGB project I created(mainly because they wouldn't even work anymore).

2. I know people may bark at this but please don't make the engine a drop in your assets and you have a game game engine. I love that TGB empowers it's users that seek to learn it. Plus many company's thrive off of simplifying the process for those who seek instant gratification and it also keeps the community involved with the lets help each other overcome the obstacles.

3. Documentation more of it would be great. Here's a possible solution though. Give the community incentive to make more user generated documentation. Maybe a badge system with rank or a documentation contributer monthly swag raffle. Every body wants documentation and we all overcome hurdles so if the incentive is given the documentation will boom. That solution also creates a problem. Quality Documentation? Incorporate a user based vote system, a employee based vote system, and a times visited counter. By measuring all three areas you decrease the cheat and ballot stuffing factor and you get a better view of what the community wants

4. Animation I love the slider based timeline animation system ideas. I would love to see more capability to effect the individual frames of an animation. So we can incorporate sounds and different collision shapes as well. I prototyped a fighting game engine that became very tedious. I had to create sceneObjects on the fly to generate multiple hit boxes and create my own time management system. Such a pain. Being able to effect individual animations frames in code and in the editor would of greatly helped

5. With that said I'd like to see the ability to apply multiple collision polys on a static sprite or animation frame. This would solve the concave issue. At the moment I have to use multiple sceneObjects.

6. It been said but better asset management. is a must my fighting game prototype flooded the editor like you wouldn't believe and it only had four fighters. Minor asset manipulation would be great like masking, blending, deformation, lighting, texture mapping, and so on so forth(That was by no means minor, huh? lol).

7. The prefab idea is cool, make sure there a good management editor tool as well and being able to apply all those not so minor manipulation stated in request 6 to the group would be cool too.

8. camera effects such as rotate, deformation, warping, concave, convex, fish eye. Being able to do these effects in a specific area or radius would be even more cool. Time warp grenades here we go!

9. that brings in the next idea. better time management all we got is $timeScale. I want to effect individual objects, the whole world, rewind, fast forward. Maybe it's already possible but I'm just not there yet but if it isn't it would be cool.

10. The ability to apply control statements above the behavior level so we can make conditional behaviors inline with behaviors with conditions. It'll allow us to keep the behaviors even lighter and more powerful.

11. More support for drawing shapes. There barely any support for t2dShapeVector the documentation is lacking and I'm in the middle of creating this cool system but I need to draw these shape in code and just have to figure it out. The TDN just skipped this section. BTW making circles is impossible at least paths have a painstaking process that makes it possible. I should be able to enter a radius or diameter and voila

12. More advanced math functions Majority of my methods are math calculations for grid based math There should be a method for all grid based math calculations.

13 last but not least easier audio and audio manipulation. things like audio range and scale of increase or decrease in a specific area. This can be programmed but editor support would be nice. and a nice little visual circle showing the radius of the sound and or even the rate of fall of would be great. Audio effect would be awesome as well like in editor compression, reverb, delay, phaser, distortion, and etc. Now my characters could sound awesome when they travel from a padded room to a steel room clanking swords together instead of me adding tons of sound files that I preprocessed in another sound editor.

14. A remote job working on T2D would be awesome as well. Since I was making big requests why not throw the icing on this 13 layer cake.

Anyway I love torque and all the support, the community and whatever else I'm neglecting to mention. Keep up the good work.

#124 Some sort of collision ray casting would be nice. I'd love to be able to cast a ray out from a point at a certain angle and return the coordinates of the collision and the object it collided with. This should be a method of t2dSceneObject. It would be the basis for many more advanced calculations allowing users to create some powerful functions and methods.

#125 @Glenn: You already have that in TGB, they are in the t2dSceneGraph.

pickPoint
pickLine
pickRect
pickRadius

For sure you get this and more in T2D though.

#126 Thanks Melv I was looking for this to be in t2dSceneObject for some reason. but it makes sense now. Thanks got some research to do!

#127 no problema and thanks for your list of request. You wouldn't want #14, thats' my job. You wouldn't want my job. ;)

#128 Holy cow, I've got a ridiculous idea.

Could we get the possibility for "Scenegraph recording". I would love to have the ability to experiment with saved films, and one way I could see it working is since the scenegraph (or whatever ends up being the environmental context for T2D) is modified by script, either through player input or some other interaction, those modifications could be logged and subsequently played back. This way, without having to completely simulate the script running the game, the scene graph just plays back what happened to it.

Technically, this could be game agnostic.

Howsabout that for a ridiculous idea.

Thanks!

#129 You're talking about a journal which is already part of the core engine I believe.

#130 haha wow, I've never seen that before! It's always awesome to think something amazing is not available to find out that it actually already is :-)

#131 Not sure how well it actually worked in TGB but I do appreciate you reminding me. Stick it on the TODO pile. ;)

#132 I really like what I'm seeing so far in T2D but here are some more suggestions:

-Other people have stated it, but I would also like to have some kind of ability to animate sub-sets of the "2D Model".
It would be nice if you could animate sensors and kinematic bodies including turning them "on" and "off" as part of the animation.
This may not seem all that essential, but if you use this type of technique with a small team with a low budget you can usually produce better animations that take up less memory than if you use "traditional" animation techniques. Additionally, if you can animate sensors and kinematic bodies you can use that to create some very interesting gameplay situations.

-Mario-esque moving platforms supported by the engine.
Given that the most popular implementation I've seen from people using Box2D is to maintain a list of bodies touching a platform and update those bodies' velocity each frame, it would be nice if the engine handled this. I would prefer having the official source code handle this rather than adding it in script or by having users modify the source code after T2D is released.

-Support for COLLADA files for 3D meshes and animations.

-Official support for .dds files.
(Was this ever added to the official source code of TGB? I haven't used the engine in a couple of years.)

-Live updating of assets.

#133

Quote:Given that the most popular implementation I've seen from people using Box2D is to maintain a list of bodies touching a platform and update those bodies' velocity each frame, it would be nice if the engine handled this.

Not sure what you mean here, Bodies don't touch anything, collision-shapes do.

Quote:Support for COLLADA files for 3D meshes and animations.

I hate to break it to you but this is a 2D engine. ;)

You'll definately like the animation system in T2D! In terms of image-support you'll get what comes with T3D.

#134

Quote:Not sure what you mean here, Bodies don't touch anything, collision-shapes do.

Sorry, I'm getting my Box2D and T2D terminology mixed up here. I meant to use the Box2D definition of a "body" rather than the T2D definition. So each platform has a list of "b2Body" instances that are touching the platform. Every frame the velocity of each of these "b2Body" instances will have its velocity updated so that it will kind of "stick" to the platform like in a mario game.

Quote:I hate to break it to you but this is a 2D engine. ;)

I meant support for 3D meshes and animations in a similar fashion to how TGB had support for them except that T2D would import COLLADA files instead of .dts files.

Quote:You'll definately like the animation system in T2D! In terms of image-support you'll get what comes with T3D.

That is great. I can't wait to see what you guys have come up with.

#135 The T2D and Box2D terminology is the same. A T2D Body is a Box2D Body. Also, T2D supports static, dynamic & kinematics bodies. Again, Bodies don't "touch" anything so they can't touch platforms. Only Collision-Shapes can which are attached to bodies.

Nevertheless I do see what you're asking.

#136 Sorry about the confusion.

I was also thinking that the ability to draw a 2D mesh along a curve path could potentially be very useful for creating winding roads as well as effects like in this video:www.youtube.com/watch?v=Vvr1vW5m_v0
If curve control points could be attached to bodies you could potentially have very nice looking simulated ropes or maybe even hair on a character.

Additionally, it would be nice to be able to generate a 2D mesh from a closed curve path and to apply a texture to the mesh. This is very useful for generating large amounts of organic looking terrain with a low memory footprint. If performing the conversion from curve path to 2d mesh were fast enough to do while a game was running and you could attach control points to bodies, you could visually represent those jelly blobs from the R&D video with a continuous mesh instead of a large number of discreet objects.

#137 For those who wanted to use control statements on behaviors it is possible in TGB since behaviors can be added and removed to and from a object in script. I pursued the theory that if it can be done in the level builder it it can be done in script. shoud be something like $player.addBehavior(shipMovement); Found the methods digging through the documentation and thought I'd share.

#138 Better Vector Support, specifically the ability to import .svg files into torque as either image polygons and collision polygons.

I think it's been said before, but I'm not sure: Drawing routines for paths, I have an idea for a game where a glowing path can guide you through the level if you get lost. This sort of thing isn't possible in TGB without messing with the source, at least I haven't figured out how to do it.

#139 I just wanted to point out how I excited I am to see what T2D has to offer at GDC!!!

#140 @David, before you get too excited, make sure you read the blog on resetting our sites. We aren't showing a lot this year and the majority of the Torque 2D guys are back in Las Vegas working hard. We decided it was best to keep them "heads down" on development while the rest of us put on the show.

We will have Steven Garcia on site to answer as many questions as he can. I'm afraid; however, if you were setting your sites on Torque 2D for this year's GDC, you might be underwhelmed.