Plan for Josh Williams
by Josh Williams · 02/10/2005 (5:57 pm) · 90 comments
Alright, here it is! First, my sincere apologies for the delay with this .plan... it's really cool that some of you have been looking forward to it, and I wish I could've found time to get it done right away. For as long as this .plan is, it didn't take too long to actually write, it was just hard to find the time to do it. There's been lots of actual work to do on T2D (let alone other cool projects!), so it was tough to justify taking time away to write this up. Finally got some time over the weekend though, and just got time to go back and edit / clean this monster up. Anyway, I hope some people find this thing interesting. Got some good feedback on the last .plan, so I figured I'd try to do the same here... only more! ;)
In the last .plan, I went over T2D's core classes, describing what T2D objects are capable of and how they're structured. Many people actually seemed interested to hear about all these nitty-gritty details. The geek factor around here is way too high to be healthy. Which is why I like this place so much.
So, let's dig in again. This time around, we'll take a look at T2D's core systems. Only now, I'm going to out-geek all of you. ;) In fact, this .plan has so much detail, I've had to create breakout sections in the discussions of collision detection and physics. Those topics contain some blocked sections, like this...
Also, some of the breakout sections are *really* long. One in the physics section weighs in at 6 pages long. But, rather than having all that text on this page and forcing folks who don't want to read it scroll-through everything, I've created separate little landing pages for that content, and I just link to the pages from within the block sections below. Also, this .plan was too big for the site to handle, literally-- it puked when I tried to post this behemoth. (Take that Davis Ray Sickmon! ;)
Okay, before getting started, let me give everyone a quick update on T2D's development status. Here in the last couple weeks of development (hint!), we've been pushing really hard, and making great progress. Melv is incredible, and I've been putting in some long (but fun!) hours over here too.
First thing to report is that T2D beta testing is going extremely well. Our ace team of beta testers never fails to hunt down even the tiniest bugs. Check it out:
That's Melv's baby daughter Jess, pounding away on T2D, and I'm happy to report that we passed the drool-plus-random-key-smashing test with flying colors!
GG Associates have been hammering on T2D for a while now too, and it's going great. I'd particularly like to thank Dan MacDonald and Anthony Rosenbaum for their thorough testing and detailed feedback. You guys rock.
On the development front, we're just about to finish the final release candidate build of T2D! It's been through five beta builds already, including 3 major revisions, so we're confident this puppy is ready to go. From here it's just finishing up documentation, demos, merging in some of the excellent work Pat has done, adding some better GUIs, and then doing the final installer packaging, etc. In addition, Melv is doing some new editor work, described below. All in all, the release candidate will be out almost immediately! Of course, confident as we are, we still need to put this last release candidate through testing, so don't expect T2D in your hands right away or anything. Trying to be really careful and give it a lot of testing love. But, it's obviously not very far away now. :)
The biggest development update to talk about is that we've decided to do our own simple tile editor for the Early Adopter release, instead of just doing .fmp / Mappy support. Mappy importing is still planned at some point, but after a looooong conversation and debate on the subject that lasted until 6 or 7am for me a few nights ago, Melv and I decided that the best thing would be to do our own little editor. Mappy is great, but no engine I'm aware of has as powerful a tile system as T2D. As such, Mappy just wasn't designed to support such a flexible system, and can't take full advantage of it. Doing a Mappy importer and working around the limitations seemed pretty simple on our first look, and it still isn't going to be too awfully hard, but we decided at this point time would be better spent working on our own stuff. If we're going to burn much dev time on this task, we'd rather produce something that will let people take advantage of T2D's tile system to a fuller extent. Melv is cranking away on the tile editor probably as I type right now, and it's one of the last things to go in this final (hopefully) release candidate build.
Well, that's where things stand at the moment. Very exciting! I hope appetites are whetted. Now, let's dig into T2D's core systems, as promised. The structure is similar to the last .plan, but we're describing systems instead of classes here. We'll cover the collision, physics, layer and group, mount, object picking, world limit, camera, scenegraph, and window systems, as well as discuss briefly the systems T2D inherits from TGE itself.
Okay ready? Collision is first-up, then physics. These first two topics are complicated, but very important, so get ready for long reads in these sections. :)
Collision
T2D's collision system underwent a pretty interesting development cycle, a brief history of which is in one of the breakout sections below. We want T2D to be, far and away, the best 2D engine around when it's fully complete (after the Early Adopter period is over). We know that the collision system T2D provides will be crucial in achieving that goal, and we want indie developers to have the best collision system around at their disposal. As such, after much thought, research, and discussion Melv and I set some very aggressive goals for T2D's collision system. We wanted to:
So how does this whole system work? Let's take a look.
Object collision settings:
As described in the last .plan, all script-instantiable T2D classes are derived from fxSceneObject2D, and this class defines the default collision system. Part of this definition allows objects to specify a collision polygon. Collision polys can either be regular n-gons, or custom convex shapes. This means that you can define tight-fitted custom polygons for your sprites, which makes it possible to create nicely accurate collision systems. Also, the collision polys are sized along with the object, so you don't have to worry about adjusting them.
In addition, objects can be configured to "send" and "receive" collisions. When an object sends collisions, it means that it's capable of causing collisions on other objects. Receiving collisions means that an object can be affected by collisions.
In the majority of T2D games, most objects will no doubt be configured to both send and receive collisions, just as in the real-world. But we've made it possible to easily turn off either of these capabilities for any object. So, you can create objects which can cause collisions in other objects, but are themselves immune to being affected by collisions (maybe bullets would have this profile. Tiles have this profile in T2D by default). Or, you can create objects which don't cause collisions themselves, but can be affected by colliding with other objects (feathers?). Or create objects that do neither and are exempted from the collision system altogether. Note as well that these settings can be dynamically twiddled, so you can switch on or off an object's ability to send or receive collisions at any time.
Objects can also be assigned to layers, and to groups, and these layers and groups can be used in collision detection. For example, you might assign a player's avatar and their bullets to a specific layer and group. Likewise, you might assign all enemies and their fire to the same layer, in a different group. Then, you can set collision layer and group collision masks on the player and enemies-- for the player, you might turn on collisions with its own layer, but turn off collisions with its own group (meaning that the player can't harm himself with his own projectiles), and turn on collisions for the enemy group. For enemies, you might do exactly the same, but perhaps turn on collisions with their own group as well, so that enemies can shoot each other. If you were making a multiplayer game (in the near future ;), you might turn off friendly fire by assigning players on the same team and their projectile fire to the same group, and turning off their collision with the team's group.
Besides offering fine-grained control over the kinds of collisions you want different objects to have, this layer and group system also allows you to speed up collision detection. No matter how optimized the code (and T2D's collision code is nicely optimized, again, Melv is an animal), collision detection is an expensive operation. This can especially be true when you're dealing with accurate swept-polygon collision (more info below), as T2D does. So, by specifying that an object should only collide with particular layers and groups, you can reduce the collision search space substantially, speeding up the entire process.
Finally, objects can be configured with a script collision callback function. In this way, players can over-ride or add to the default collision detection and response system. By default, the collision callback is passed the time of collision, up to two contact points, collision normals, and a custom string field which can be used to extend the callback info on the cheap. :) One obvious use of this system would be to generate explosions at the points of contact between two objects. Or, your collision script might implement its own custom physics processing system... maybe you want some of your objects to actually deform upon collision. You could modify your sprites, perhaps amongst some pre-set collection of deformation frames, and their collision polygons in this callback.
All in all, this puts a lot of power and flexibility in the user's hands. Objects can be very precisely configured for various collision behaviors, and the system itself is very easy to extend or over-ride, even just in script. It's a very powerful and flexible collision specification system, but it only takes a few lines of script to get set-up. Also, these settings can be declared in datablocks, so you can create prototype datablocks for collision settings and share them across many objects, making it even quicker and easier to get the collision set-up.
So, those are the collision configuration options. Now, let's see how collisions are detected and processed.
Collision Detection:
Like most collision systems, Torque 2D detects collisions in two phases. The first is a broad-phase, early-out collision test, which narrows the list of potential collisions. The second is a nitty-gritty collision test which returns accurate collision information both for when objects overlap, and for when they are disjoint but collide in forward-time. We'll look at both of these systems in more detail.
First, broad-phase, early-out collision is very common in collision detection schemes, as most of you no doubt already know. The goal is to very quickly determine objects that will definitely not collide with each other, so that you don't have to check these objects against each other in the next, much more expensive narrow-phase of exact object-object collision detection.
T2D's scenegraph sorts objects into "bins", which are just regular space divisions. Its broad-phase collision check compares objects in the same bin against axis-aligned bounding-boxes (AABBs) to determine whether the two objects might collide. This technique is very common, and it's tough to beat in 2D.
Once T2D is done deciding what objects definitely will not collide with each other, it has a much smaller (hopefully) list of objects which might possibly collide with each other. As stated above, T2D is capable of performing swept-polygon collision detection, which Melv and I agreed on using after much research, discussion, and debate (see the development history breakout below... this particular decision took 20+ pages of dialogue between Melv and I. :). This system is capable of detecting both overlapping objects, and disjoint objects which collide in forward-time. It is very robust, and is designed to fit perfectly with the upcoming networking changes we'll be making (see another aside below, on networked collision detection, for more info on why this is true).
Swept-volume collision detection is an active area of current research, so I guess you could say that T2D is right on the cutting-edge here. ;) We aren't doing anything too hyper-fancy (like leveraging GPU-acceleration for the sweep calcs), but the swept system we've got is pretty nice.
And you know what one of the best things about the whole system is? Despite the fact that Melv was working to get all this stuff implemented absolutely as quickly as possible, all of this code is very clean and very well commented. Even though this all involves complicated, math-heavy algorithms, you can actually read the code and understand it without even needing a piece of scratch paper.
The other cool thing about all this code is that it's fast. Yet, it's easy to use and extend. Imagine that, complicated chunks of code that are still clean, easy to extend, easy to interface with, and fast. I love Melv. :)
Alright, we now have a pretty good understanding of how T2D's collision detection system works. It meets all the goals we set for it, including being highly configurable. It's capable of handling lots and lots of objects at once, yet returns accurate collisions against detailed collision polys, thanks both to the two-phase systems used and the speed of the actual code Melv wrote. And, it's got a headstart on networking.
For those of you who weren't already familiar with the subjects, I hope the asides on collision detection were somewhat interesting. Now, let's move on and look at T2D's collision response system, and its implementation of rigid-body physics.
Physics
Okay, we've looked at collision detection in T2D, so let's look at the other side of the coin: collision response.
T2D defines a totally customizable and overridable collision response system. The basic tenant was to first assume that individual developers will want the ability to create their own collision response schemes, either in C++, or in script. So, we tried to design the physics so that customization or replacement would be as simple as possible. For developers that don't want to implement their own collision response system though, we planned out a robust default system. T2D's default collision response system utilizes an impressive rigid-body physics model, which any object can plug into. And again, developers have the ability to leverage the default rigid body dynamics system to meet their own needs, by extending and customizing the default behavior (even just with scripts, using T2D's collision callback).
Before we go into more detail about implementing custom collision response, let's take a detailed look at T2D's default system. For all the talk above about how cool it is that T2D makes it easy for you to define your own collision response systems, or to extend the default system, I think one of the very best features of T2D now is its default rigid body physics capabilities. It feels great that all kinds of 3D engines this year are bragging about their rigid body physics... and here is T2D, starting to catch up with 'em, in one less dimension. ;)
Rigid-Body Dynamics in T2D:
Torque 2D's rigid body dynamics simulation models all the standard bells and whistles, including inertia, linear velocity, angular velocity, friction, restitution, relaxation, and damping, and has an easy method for applying impulse-forces and torque. If you aren't a pro with rigid body physics, check out the breakout section below for an overview of rigid body dynamics in general, and their simulation in games in particular. If you are already a pro (or just don't care to read all the junk in the breakout), skip over and continue on to read more about T2D's physics system.
Torque 2D's rigid-body system simulates Newtonian physics. Below is another breakout very briefly defining the physics terms used to describe T2D's simulation capabilities.
Configuring objects for use in T2D's rigid-body dynamics is very simple. You just need to enable automatic collision response for the object (see below), and set-up the object's physics parameters. These parameters include friction, restitution, relaxation, damping, density, and a force scaling factor. The parameter naming is obvious: the first four are the coefficients used to model the object's physics properties (see definitions above), density is used to calculate the object's mass based on the area of its collision poly, and force scaling is used, as you might expect, to lessen or heighten the net force applied to the object at any time.
Note as well that T2D once again leverages datablocks to make the process of setting up physics properties as simple and quick as possible for developers. T2D defines the fxCollsionMaterialDatablock, which contains the six parameters above. Multiple objects can share the same datablock, so using collision material datablocks can be a real development time-saver.
There are additional physics parameters which can be used. For instance, objects can be configured with maximum and minimum linear and angular velocities. They can also be affected by an individual, constant gravitation force, or be set-up to automatically rotate at a given pace. These additional parameters are part of the core fxSceneObject2D definition, and the corresponding datablock can be used to set-up these properties too.
Customizing physics:
So, T2D's default collision response system is pretty darn impressive. But, you're not forced to use it. Similarly to how collisions work, any object in T2D can have its ability to send or receive updates to/from the default physics system turned on or off. For more information on "sending" and "receiving" collision-related information in T2D, see the discussion on the subject in the collision detection section above.
For a T2D object which you want to be fully a part of the default physics simulation, you'd enable both sending and receiving of physics. For an object which you didn't want to part of the physics simulation at all, you'd disable both. If you wanted an object to be able to cause automated physical reactions in other objects, but not be affected by default physics itself, you'd enable the ability to send physics, and disable the ability to receive. You'd do the opposite if you wanted an object which could react to other objects using the default physics system, but that wouldn't initiate default physical responses with other objects itself.
In this way, you can completely (or partially) detach any object from T2D's default physics system. You are then totally free to implement your own collision response system, in C++ or even just in script. Or, you could customize the existing system, again, either in C++, or in script.
Should also note that the ability to turn default physics off is independent of whether collision detection on an object is enabled or disabled (though they are obviously related... turning off collision sending and receiving but turning on physics won't get you far).
All in all, besides having a great built-in physics simulation, T2D makes it easy for you to develop your own collision response / physics, if you so choose!
And that's a quick look at T2D's collision response! Pretty nitty-gritty details on how the physics system itself works can be found on the page linked in that aside. Now, with collision detection and response out of the way, all the hugely-long and boring sections of this .plan are done with. There are lots of other nice T2D systems to discuss, but they don't require very long-winded explanations.
Mounting
Torque 2D allows you to mount objects to other objects. A "mount" is an attachment between two objects. When you mount one object to another, the two objects can automatically move around together (more information on how mounted movement can be controlled below).
Now, any object can be mounted to any other object in T2D. As Melv mentioned in my last .plan, that means that you could even mount a tile layer to a particle. :) This is pretty cool, especially once you start considering all the neat stuff you can do with mounts.
It's really fast setting up mounts and you can have multiple objects attached to another. And any of those mounted objects can have one or more objects mounted to them. And those secondarily mounted objects can have other objects attached to them. And so on. :) So, it's easy to create long chains and big webs of mounted objects.
Besides that, you can mount objects to any point on another object. So, mounted objects need not be attached at the center of an object, and mounted objects needn't be spaced out evenly around their parent's perimeter or anything.
In addition, you can specify whether a mount should be rigid (such that the mounted object always stays the same distance from its parent), or use mount forces. With a mount force, you can dictate that a mounted object should move with its parent after the specified force is being exerted on the mount connection. When the parent object moves, a mounted object with a mount force will lag behind the parent's movement, catching up if/when the parent comes to rest.
For example, you can create a long chain of mounted objects, each with a mount force defined. Then, you can the parent object, move it horizontally and start shaking it up and down. If you've got your mount forces configured correctly, you'll see the chain begin to "slither" like a snake, with each object in the chain eventually moving sideways, and bouncing up and down. You can change the mount forces at any time too, so you could easily make parts of the chain whip quickly into position next to their parents, or stretch further behind. Or, if you'd had the same long chain of mounted objects and had specified that each mount be rigid, when the parent object started moving, the whole chain would move simultaneously. It'd be a straight line of objects, following the parent's movement exactly.
And that's not all... you can also do fancy mount rotations. For example, you can tell a mounted object to adhere to its parent's rotation, so that when the parent rotates, the mounted object will too (and rotations are controlled in the same way, via rigid or force-based connections). Or, you could tell the mounted object not to follow the parent's rotation, so that the parent object might be spinning away, but the mounted object isn't affected at all. Or, you can rotate the mount itself. In this scenario, the parent object might not be rotating, and the mounted object might not be rotating itself either, but the mounted object's position would be rotating about the parent object (so the mounted object is orbiting the parent). Neat! You can even set-up automatic rates of rotation for all these things.
Well the possibilities are endless here. In no time, you could set-up a boss with a bunch of mounted shields rotating around him that the player has to blast off or shoot between. Note as well that you can assign mounted objects to different collision groups, so it'd be easy even to do stuff like have a "fire shield", "ice shield", "water shield", etc that you had to hit with particular kinds of weapons.
I don't know... I'm just not a good game designer, but there's obviously tons of cool stuff you can do with this system. There are lots of creative people around here, so I'm sure you're already brewing up neat gameplay ideas that could take advantage this functionality. Also, mounted objects + physics = fun, believe me. :) This is another neat little system that T2D provides out of the box, and it makes it easy to pull off all kinds of fun pieces of gameplay.
Oh, almost forgot... there is also a "link" system in T2D. Link nodes / points can be set-up exactly like mount points, however links don't imply a relationship with another object. Rather, links can be used to track a specific point on an object. Say you have a spaceship with a big rotating gun... you could set-up a link point on the tip of the gun, and use it to spawn a projectile from the correct spot at any time. Very handy.
Layers and Groups
We've already discussed layers and groups a little in the collision detection section. But layers and groups are useful for more than just customizing and speeding up collision detection.
Objects can be assigned to layers, and you can specify that layers be sorted for rendering. In fact, the sort order for layers can be changed at will, and objects can be re-assigned to different layers at any time. Also, objects on the same layer can be assigned intra-layer z-ordering, and this ordering can be changed at any time. In this way, T2D gives you very fine-grained control over the z-ordering and rendering of your objects,
Unlike many 2D APIs / libraries, T2D doesn't limit you to using a small number of rendering layers. So, T2D makes it easy, for example, to set-up very nice-looking parallaxed backgrounds with lots and lots of layers.
And groups are a handy tool all around. You can use groups not only as a nice way to set-up collidable collections, but to help keep track of and manipulate logical classes of objects.
Object picking
There are many utilities in T2D that were put in to help developers handle common game problems. One thing that comes up a lot in games is object picking. Sometimes, you want players to be able to click on particular objects and select them. Or, if you were making a 2D RTS, you'd want to be able to let your players click-drag a box around units and select them all.
These are common object picking problems, and T2D has a nice picking interface. There are routines to pick objects that intersect with a point (mouse click), line, or area within the world. Picking is basically a collision detection test, and Torque 2D performs accurate picking against object collision polygons. This also means that it's easy to specify that a pick should only return objects in certain layers or groups. Again, if you were making an RTS, you might have a player's units in a group, so it'd be easy to pick just the player's units.
Also, it's possible to have custom pick functions. Tile maps, for example, have a special pick function which can return the logical tile(s) that intersect with a pick query.
This is just one example of the neat utilities T2D provides. Again, the goal throughout T2D's development has been "hey, let's make it easy for people to make 2D games!" So, we've tried to provide a bunch of stuff like this. Credit to Melv for caring so much about indie developers and wanting to put in the time and effort it takes to create all these functions, even though they're not the most fun things to implement.
World limits
The term "world limit" is a bit of a bad descriptor for what this particular system actually does. "World limits" in T2D are used to define the region in which a particular object can move around. Probably a better term would be "movement regions" or some such.
Regardless, world limits are a nice little feature of T2D. They allow you to set, on a per-object basis, the rectilinear area in which an object can exist in.
The world limit system is turned off by default-- T2D objects don't have world limits unless you explicitly turn them on for it-- because using world limits has a (small) performance penalty. Of course, performance was extremely important to us during T2D's design and development, so world limits were turned off by default.
When world limits are on though, you can do several neat things. Besides defining a valid area for an object to exist and move around in, you can also utilize various built-in world-limit collision-responses. By calling the setWorldLimit(...) method, you can specify what kind of response the object should have when it collides with a world limit.
The first world limit collision mode is "null", which tells T2D not to do anything special to the object when it collides with its world limit. Next is "rigid", which tells T2D to use the normal rigid-body dynamics system to handle world limit collision. Next is "bounce", which will bounce the object back from the world limit by perfectly reflecting the angle of incidence and maintaining the object's incoming speed. Next, "clamp" zeroes the object's perpendicular velocity component (colliding against a side wall of the world limit will result in the x component of the object's velocity being zeroed immediately). "Sticky" results in the object coming to rest against the world limit edge it hit. And "kill" results in the object being deleted once it reaches a world limit.
As with all collisions in T2D, world limit contacts are detected accurately against an object's collision poly.
Scenegraph
Torque 2D is a scenegraph-driven framework. (I'm assuming anyone who's read this far into the overview is already familiar with scenegraphs. If you're not, there are many good descriptions available online.)
We've already indirectly discussed many aspects of T2D's scenegraph in the sections on collision detection, physics, and layers here, and I won't re-tread. T2D's scenegraph uses a bin system to divide space and store locality information for scene objects. As per usual, this information is used to cull and optimize rendering, collision detection, etc. The scenegraph provides a great interface for initializing, querying and updating the scene, and you'll see many examples of how it can be used below.
The scenegraph is used to run the overall game simulation, and can be used to specify scenegraph-wide simulation parameters. For example, with one simple call to a scenegraph's setConstantForce(...) method, you can apply a global force to all objects in the scene which adhere to the default physics system. One obvious use for this functionality is to set-up (or modify) gravity for a scene. You can also pause the scene time at any moment, and resume it whenever you like.
The camera system in T2D is really flexible. You can set windows to cover a given area of the scene with a specific zoom level, and you can zoom, rotate, and pan the view any time. Also, you can give the view window a target position or area and have it move there smoothly over time from its current position. From there, you can undo / revert the view's move, returning to the old position. In fact, the last 64 view target calls are stored in T2D, so you can revert / undo up to 64 view moves. There are lots of cool possibilities with this system, and with just a little extension, you could define a nice easy interface for creating complex camera paths and scenes.
Man, so many other features. Check it out:
-Camera Mounts: the view window can be mounted to any object, and the mount can work identically to any other mount. So, you can make the camera follow an object (like the player avatar) with a rigid or force-based connection.
-Special effects: effects like camera shaking are easy. In fact, camera shakes are implemented specifically out of the box, and you can specify a shake period and intensity, as in Torque's own default camera. This is great for stuff like providing feedback when a player gets hit.
-Multiple scenes, multiple views! You can have multiple scenegraphs running at the same time, and multiple windows on any scenegraph. So, you can have multiple separate scenes, and/or multiple views of the same scene. (Nintendo DS, anyone? ;)
-Render filtering: You can dynamically filter what kinds of objects should be rendered at any given time.
-Scene saving a loading! The entire scene state can be serialized and saved at any time. Likewise, saved scene data can be loaded, and simulation can pick up right where it left off. Or, you can load a scene, pause time, and re-set any properties of the scene or its objects that you like.
Finally, the scenegraph is capable of detailed debug and performance reporting. You'll see in some forthcoming screenshots how nifty this system is. The collision poly, oriented-bounding box, and axis-aligned bounding box for all scene objects can be visualized at any time. And you can turn on automatic reports for all kinds of information, including: the total object count in the scene, the current FPS, the number of objects which are potentially going to be rendered (those which haven't been culled from the current view), the number of potential collisions, the number of current collision contact points, the percentage of objects currently colliding with each other, and the time it took to process physics for the current frame, amongst other information. Of course, you can also customize the debug and performance queries to provide whatever other information you'd like to have. These reporting tools are very helpful when it comes to debugging and optimizing a game!
The T2D scenegraph is really slick, and just having a hardware-accelerated, scenegraph-driven 2D engine is impressive in and of itself. Between this and the preceding sections on collision detection, physics, and layers, you should have a pretty good feel for what T2D's scenegraph is capable of. The scenegraph is basically the central system of T2D, which is saying a lot, considering all that T2D can do. So, it would take many pages to fully describe all of what the scenegraph can do and how it all works. Suffice it to say, the scenegraph + the base fxSceneObject2D class form the very core of Torque 2D, and the two provide an extremely powerful basis to build from, as I hope has been indicated by the discussion so far.
Torque integration
Torque 2D, of course, integrates with the overall Torque platform. Specifically, T2D takes advantage of Torque's cross-platform support, GUI system, scripting, and sound.
That's a lot of stuff to cover, but I assume folks here are familiar with these already, so I won't go into detail about them. But, one of T2D's biggest advantages overall is that it is built on all these great core Torque technologies. Just because it's built on Torque, T2D almost automatically becomes one of the only cross-platform 2D engines, and with Torque's system, it's set-up to go to even more platforms. It also gets to use a full-fledged scripting language and powerful console command processing capabilities. T2D gets a great GUI system for free (which is undergoing a major overhaul here at the office, btw, you'll see Ben and the rest of us talking about that more in the future), and the GUI editor to go along with it. Also, T2D gets to use Torque's audio functionality, so it has good sound support.
Just taking those things right there... even if T2D had just a normal rendering system, physics, etc, it'd still be one of the best engines around. Now, it's just insane. :)
Quick note: you've no doubt noticed that networking isn't part of the list of Torque technologies which T2D takes advantage of. That's true, for now. For the Early Adopter release, we've implemented a temporary networking solution. Essentially, you can use CommandToServer() and CommandToClient() calls to do many kinds of networked games. For example, T2D ships with an example networked multiplayer checkers game.
However, full-on, Torque-style networking isn't a part of T2D just yet. It will be very soon after the initial Early Adopter release though, and that'll be another outstanding system T2D gets to leverage for free.
The reason we didn't include full networking in this initial release is that we didn't want T2D objects to take on the overhead associated with deriving from Torque's GameBase class. For T2D, we'll be splitting out tick processing (similar to the work Pat has done recently) and implementing networking from there. That said, all of T2D's systems have been designed with networking in mind. Collision and physics are the stickiest things to get networked, and Melv and I were extremely mindful of the need to network those systems in the future when we were designing them.
Getting networking in won't be a difficult task, but we wanted to get T2D out into people's hands as soon as possible. It's already an outstanding solution for most games. Even people who have fast-paced multiplayer games in mind can pick up T2D now and begin learning to use it, knowing full-well that robust, highest-quality networking support as is standard with the Torque platform is on the way.
And with that, we've covered each of T2D's major core systems. Woo!
Of course, it's also important to note that you'll be able to get the full C++ source code for T2D (details on how you get it will be announced very soon). The code is all structured to be as clean to read and understand as possible, and one of the main design goals for the entire T2D architecture was to make it easy to customize and extend.
In addition, T2D ships with about 100 pages of detailed documentation (and that's not counting source-code comments). This documentation includes a tutorial in which a small game is built from the ground up, a detailed technical overview (a stripped-down and cleaned-up version of these .plans), and an object reference. So, you'll be covered when you start learning how to use and/or customize this sweet 2D engine. :)
Okay, thanks to everyone for reading. It was fun writing this .plan and I'm sorry it took me longer to get started on it than I hoped. But, I guess the upside there is that I was able to get lots done on T2D in the mean time! Hopefully some of you found this an interesting read.
Catch you all around, and watch this space for more T2D info in the very near future! Launch sequence starting in...
In the last .plan, I went over T2D's core classes, describing what T2D objects are capable of and how they're structured. Many people actually seemed interested to hear about all these nitty-gritty details. The geek factor around here is way too high to be healthy. Which is why I like this place so much.
So, let's dig in again. This time around, we'll take a look at T2D's core systems. Only now, I'm going to out-geek all of you. ;) In fact, this .plan has so much detail, I've had to create breakout sections in the discussions of collision detection and physics. Those topics contain some blocked sections, like this...
Quote:These sections can safely be skipped without breaking the main thread of this .plan. These breakouts contain asides, explanations of the reasoning for why certain design decisions were made, and other discussions that might be interesting, but aren't necessary to the main technical overview. I thought some people would find them interesting, but want to make it easy for anybody who's not interested to skip 'em.
Hello, I am a block section containing unnecessary but potentially interesting detail on certain aspects of T2D's sub-systems, or general asides on relevant but tangential topics.
Also, some of the breakout sections are *really* long. One in the physics section weighs in at 6 pages long. But, rather than having all that text on this page and forcing folks who don't want to read it scroll-through everything, I've created separate little landing pages for that content, and I just link to the pages from within the block sections below. Also, this .plan was too big for the site to handle, literally-- it puked when I tried to post this behemoth. (Take that Davis Ray Sickmon! ;)
Okay, before getting started, let me give everyone a quick update on T2D's development status. Here in the last couple weeks of development (hint!), we've been pushing really hard, and making great progress. Melv is incredible, and I've been putting in some long (but fun!) hours over here too.
First thing to report is that T2D beta testing is going extremely well. Our ace team of beta testers never fails to hunt down even the tiniest bugs. Check it out:
That's Melv's baby daughter Jess, pounding away on T2D, and I'm happy to report that we passed the drool-plus-random-key-smashing test with flying colors!
GG Associates have been hammering on T2D for a while now too, and it's going great. I'd particularly like to thank Dan MacDonald and Anthony Rosenbaum for their thorough testing and detailed feedback. You guys rock.
On the development front, we're just about to finish the final release candidate build of T2D! It's been through five beta builds already, including 3 major revisions, so we're confident this puppy is ready to go. From here it's just finishing up documentation, demos, merging in some of the excellent work Pat has done, adding some better GUIs, and then doing the final installer packaging, etc. In addition, Melv is doing some new editor work, described below. All in all, the release candidate will be out almost immediately! Of course, confident as we are, we still need to put this last release candidate through testing, so don't expect T2D in your hands right away or anything. Trying to be really careful and give it a lot of testing love. But, it's obviously not very far away now. :)
The biggest development update to talk about is that we've decided to do our own simple tile editor for the Early Adopter release, instead of just doing .fmp / Mappy support. Mappy importing is still planned at some point, but after a looooong conversation and debate on the subject that lasted until 6 or 7am for me a few nights ago, Melv and I decided that the best thing would be to do our own little editor. Mappy is great, but no engine I'm aware of has as powerful a tile system as T2D. As such, Mappy just wasn't designed to support such a flexible system, and can't take full advantage of it. Doing a Mappy importer and working around the limitations seemed pretty simple on our first look, and it still isn't going to be too awfully hard, but we decided at this point time would be better spent working on our own stuff. If we're going to burn much dev time on this task, we'd rather produce something that will let people take advantage of T2D's tile system to a fuller extent. Melv is cranking away on the tile editor probably as I type right now, and it's one of the last things to go in this final (hopefully) release candidate build.
Well, that's where things stand at the moment. Very exciting! I hope appetites are whetted. Now, let's dig into T2D's core systems, as promised. The structure is similar to the last .plan, but we're describing systems instead of classes here. We'll cover the collision, physics, layer and group, mount, object picking, world limit, camera, scenegraph, and window systems, as well as discuss briefly the systems T2D inherits from TGE itself.
Okay ready? Collision is first-up, then physics. These first two topics are complicated, but very important, so get ready for long reads in these sections. :)
Collision
T2D's collision system underwent a pretty interesting development cycle, a brief history of which is in one of the breakout sections below. We want T2D to be, far and away, the best 2D engine around when it's fully complete (after the Early Adopter period is over). We know that the collision system T2D provides will be crucial in achieving that goal, and we want indie developers to have the best collision system around at their disposal. As such, after much thought, research, and discussion Melv and I set some very aggressive goals for T2D's collision system. We wanted to:
- Allow detailed collision polygons to be specified for objects and accurately collide them
- Let users enable or disable individual objects' ability to cause or be affected by collisions
- Easily restrict collisions between particular groups of objects
- Return rich collision information
- Make it possible for people to customize the system, even with scripting only
- Easily hook-up to custom collision response systems
- Use the same system for tile-maps and normal scene objects
- Handle hundreds of objects in a scene at once
- Create a network-ready collision scheme
- Do it all in a very easy to configure manner, so that anyone can use T2D with little hassle
So how does this whole system work? Let's take a look.
Object collision settings:
As described in the last .plan, all script-instantiable T2D classes are derived from fxSceneObject2D, and this class defines the default collision system. Part of this definition allows objects to specify a collision polygon. Collision polys can either be regular n-gons, or custom convex shapes. This means that you can define tight-fitted custom polygons for your sprites, which makes it possible to create nicely accurate collision systems. Also, the collision polys are sized along with the object, so you don't have to worry about adjusting them.
In addition, objects can be configured to "send" and "receive" collisions. When an object sends collisions, it means that it's capable of causing collisions on other objects. Receiving collisions means that an object can be affected by collisions.
Quote:Aside: Sending and receiving collisions, what?
------------------------------------------
To make this more clear... objects in the real world of course both send and receive collisionswhen you and your buddy stand at opposite ends of the room, run at each other, and smack together (because you are smart and you find this activity enjoyable), you both send a collision to the other and receive a collision from the other. Your skull sends a collision to your buddy's, and your buddy's skull receives your collision. And vice versa.
Torque itself has a similar concept of active and passive colliders, but it doesn't define a clean interface regarding it.
In the majority of T2D games, most objects will no doubt be configured to both send and receive collisions, just as in the real-world. But we've made it possible to easily turn off either of these capabilities for any object. So, you can create objects which can cause collisions in other objects, but are themselves immune to being affected by collisions (maybe bullets would have this profile. Tiles have this profile in T2D by default). Or, you can create objects which don't cause collisions themselves, but can be affected by colliding with other objects (feathers?). Or create objects that do neither and are exempted from the collision system altogether. Note as well that these settings can be dynamically twiddled, so you can switch on or off an object's ability to send or receive collisions at any time.
Objects can also be assigned to layers, and to groups, and these layers and groups can be used in collision detection. For example, you might assign a player's avatar and their bullets to a specific layer and group. Likewise, you might assign all enemies and their fire to the same layer, in a different group. Then, you can set collision layer and group collision masks on the player and enemies-- for the player, you might turn on collisions with its own layer, but turn off collisions with its own group (meaning that the player can't harm himself with his own projectiles), and turn on collisions for the enemy group. For enemies, you might do exactly the same, but perhaps turn on collisions with their own group as well, so that enemies can shoot each other. If you were making a multiplayer game (in the near future ;), you might turn off friendly fire by assigning players on the same team and their projectile fire to the same group, and turning off their collision with the team's group.
Besides offering fine-grained control over the kinds of collisions you want different objects to have, this layer and group system also allows you to speed up collision detection. No matter how optimized the code (and T2D's collision code is nicely optimized, again, Melv is an animal), collision detection is an expensive operation. This can especially be true when you're dealing with accurate swept-polygon collision (more info below), as T2D does. So, by specifying that an object should only collide with particular layers and groups, you can reduce the collision search space substantially, speeding up the entire process.
Finally, objects can be configured with a script collision callback function. In this way, players can over-ride or add to the default collision detection and response system. By default, the collision callback is passed the time of collision, up to two contact points, collision normals, and a custom string field which can be used to extend the callback info on the cheap. :) One obvious use of this system would be to generate explosions at the points of contact between two objects. Or, your collision script might implement its own custom physics processing system... maybe you want some of your objects to actually deform upon collision. You could modify your sprites, perhaps amongst some pre-set collection of deformation frames, and their collision polygons in this callback.
All in all, this puts a lot of power and flexibility in the user's hands. Objects can be very precisely configured for various collision behaviors, and the system itself is very easy to extend or over-ride, even just in script. It's a very powerful and flexible collision specification system, but it only takes a few lines of script to get set-up. Also, these settings can be declared in datablocks, so you can create prototype datablocks for collision settings and share them across many objects, making it even quicker and easier to get the collision set-up.
So, those are the collision configuration options. Now, let's see how collisions are detected and processed.
Collision Detection:
Like most collision systems, Torque 2D detects collisions in two phases. The first is a broad-phase, early-out collision test, which narrows the list of potential collisions. The second is a nitty-gritty collision test which returns accurate collision information both for when objects overlap, and for when they are disjoint but collide in forward-time. We'll look at both of these systems in more detail.
First, broad-phase, early-out collision is very common in collision detection schemes, as most of you no doubt already know. The goal is to very quickly determine objects that will definitely not collide with each other, so that you don't have to check these objects against each other in the next, much more expensive narrow-phase of exact object-object collision detection.
T2D's scenegraph sorts objects into "bins", which are just regular space divisions. Its broad-phase collision check compares objects in the same bin against axis-aligned bounding-boxes (AABBs) to determine whether the two objects might collide. This technique is very common, and it's tough to beat in 2D.
Quote:Aside: Broad-phase CD information:
---------------------------------------------------------
One can use a large variety of techniques in broad-phase collision checks. Some of the best information and resources on the subject can be found here, here, and in the book Real-Time Rendering. Most recent research in this area is specifically targeted at handling 3D collision detection with highly complex objects. In these scenarios, AABB checks are not usually optimal, and the most recent research is generally hostile toward using AABB checks in the broad phase. But, Melv is smarter than all these fool academics. ;) In all seriousness though, 2D game scenes are generally quite well-suited for using AABB in early-out, broad-phase collision pass.
Once T2D is done deciding what objects definitely will not collide with each other, it has a much smaller (hopefully) list of objects which might possibly collide with each other. As stated above, T2D is capable of performing swept-polygon collision detection, which Melv and I agreed on using after much research, discussion, and debate (see the development history breakout below... this particular decision took 20+ pages of dialogue between Melv and I. :). This system is capable of detecting both overlapping objects, and disjoint objects which collide in forward-time. It is very robust, and is designed to fit perfectly with the upcoming networking changes we'll be making (see another aside below, on networked collision detection, for more info on why this is true).
Swept-volume collision detection is an active area of current research, so I guess you could say that T2D is right on the cutting-edge here. ;) We aren't doing anything too hyper-fancy (like leveraging GPU-acceleration for the sweep calcs), but the swept system we've got is pretty nice.
And you know what one of the best things about the whole system is? Despite the fact that Melv was working to get all this stuff implemented absolutely as quickly as possible, all of this code is very clean and very well commented. Even though this all involves complicated, math-heavy algorithms, you can actually read the code and understand it without even needing a piece of scratch paper.
The other cool thing about all this code is that it's fast. Yet, it's easy to use and extend. Imagine that, complicated chunks of code that are still clean, easy to extend, easy to interface with, and fast. I love Melv. :)
Quote:Aside: Collision detection schemes
--------------------------------------------------------
Collision detection is a well-established field of study, but it's still researched very actively, in both academic and private fields like game development, CAD, CGI, robotics, and others. For anyone interested, here's a quick aside on collision detection. The goal of this discussion isn't to offer a detailed tutorial on collision detection algorithms (this .plan is getting long enough already). Rather, I hope to give a feel for how some common collision schemes work, so you can see a context for T2D's collision detection, if you aren't already familiar with these algorithms.
... Read more! ... this one is about 1.5 pages long, so it's broken out separately. Very briefly talks about the usual kinds of narrow-phase collision detection schemes: feature-oriented (Linn-Canny), simplex-oriented (GJK), and methods more appropriate for dealing with less strenuous CD constraints.
Quote:Aside: Network-ready collision detection:
---------------------------------------------------------------
What's so hard about networked collision detection anyway? If you haven't thought about it much yet, read this quick aside and see why preparing for the inevitable move to networked simulation was so important for T2D.
... Read more!... this one is about 1.5 pages long as well, so it's broken also out separately. Offers a high-level overview of the problems associated with network simulation in general and as applied to collision detection in particular.
Quote:Aside: A brief development history of T2D's collision detection system
------------------------------------------------------------------------------------
See how we got where we are today. Torque 2D originally had a very simplistic collision detection system, which Melv created just as a temporary placeholder. It used simple bounding box checks for collision detection and checked only for overlaps, in discrete time (see the aside above for a simple discussion on why this doesn't work too well in general, and especially not in networked games).
... Read more!... Another 1.5 pager, also broken out. Get the inside scoop!
Alright, we now have a pretty good understanding of how T2D's collision detection system works. It meets all the goals we set for it, including being highly configurable. It's capable of handling lots and lots of objects at once, yet returns accurate collisions against detailed collision polys, thanks both to the two-phase systems used and the speed of the actual code Melv wrote. And, it's got a headstart on networking.
For those of you who weren't already familiar with the subjects, I hope the asides on collision detection were somewhat interesting. Now, let's move on and look at T2D's collision response system, and its implementation of rigid-body physics.
Physics
Okay, we've looked at collision detection in T2D, so let's look at the other side of the coin: collision response.
T2D defines a totally customizable and overridable collision response system. The basic tenant was to first assume that individual developers will want the ability to create their own collision response schemes, either in C++, or in script. So, we tried to design the physics so that customization or replacement would be as simple as possible. For developers that don't want to implement their own collision response system though, we planned out a robust default system. T2D's default collision response system utilizes an impressive rigid-body physics model, which any object can plug into. And again, developers have the ability to leverage the default rigid body dynamics system to meet their own needs, by extending and customizing the default behavior (even just with scripts, using T2D's collision callback).
Before we go into more detail about implementing custom collision response, let's take a detailed look at T2D's default system. For all the talk above about how cool it is that T2D makes it easy for you to define your own collision response systems, or to extend the default system, I think one of the very best features of T2D now is its default rigid body physics capabilities. It feels great that all kinds of 3D engines this year are bragging about their rigid body physics... and here is T2D, starting to catch up with 'em, in one less dimension. ;)
Rigid-Body Dynamics in T2D:
Torque 2D's rigid body dynamics simulation models all the standard bells and whistles, including inertia, linear velocity, angular velocity, friction, restitution, relaxation, and damping, and has an easy method for applying impulse-forces and torque. If you aren't a pro with rigid body physics, check out the breakout section below for an overview of rigid body dynamics in general, and their simulation in games in particular. If you are already a pro (or just don't care to read all the junk in the breakout), skip over and continue on to read more about T2D's physics system.
Quote:Aside: Rigid-body dynamics, real-time simulations, and Torque 2D:
---------------------------------------------------------------------------------------------------
This discussion offers a simple overview of the common algorithms used in real-time rigid-body dynamics simulations, and relates them to the physics system in Torque 2D.
...Read more!... this one is about 6 pages long, needed to break it out. Sub-sections:
Introduction
Methods of real-time rigid-body simulation
-Approaches for constraint and contact handling
-Integrators
Closing
References
Torque 2D's rigid-body system simulates Newtonian physics. Below is another breakout very briefly defining the physics terms used to describe T2D's simulation capabilities.
Quote:Aside: Brief definition of physics terms:
---------------------------------------------------------------
Here are quickie definitions of the terms used to describe T2D's simulation of Newtonian rigid body physics. (For physics buffs and sim nuts, I'm just using commonsensical definitions here, not scientifically or pedagogically satisfactory ones)
Linear velocity - The speed and direction an object is moving at
Angular velocity - The speed and direction an object is rotating at
Friction - Resistance to moving or rotating
Restitution - Bounciness
Relaxation - Returning to a balanced state after a disturbance
Damping - Loss of energy over time
Configuring objects for use in T2D's rigid-body dynamics is very simple. You just need to enable automatic collision response for the object (see below), and set-up the object's physics parameters. These parameters include friction, restitution, relaxation, damping, density, and a force scaling factor. The parameter naming is obvious: the first four are the coefficients used to model the object's physics properties (see definitions above), density is used to calculate the object's mass based on the area of its collision poly, and force scaling is used, as you might expect, to lessen or heighten the net force applied to the object at any time.
Note as well that T2D once again leverages datablocks to make the process of setting up physics properties as simple and quick as possible for developers. T2D defines the fxCollsionMaterialDatablock, which contains the six parameters above. Multiple objects can share the same datablock, so using collision material datablocks can be a real development time-saver.
There are additional physics parameters which can be used. For instance, objects can be configured with maximum and minimum linear and angular velocities. They can also be affected by an individual, constant gravitation force, or be set-up to automatically rotate at a given pace. These additional parameters are part of the core fxSceneObject2D definition, and the corresponding datablock can be used to set-up these properties too.
Customizing physics:
So, T2D's default collision response system is pretty darn impressive. But, you're not forced to use it. Similarly to how collisions work, any object in T2D can have its ability to send or receive updates to/from the default physics system turned on or off. For more information on "sending" and "receiving" collision-related information in T2D, see the discussion on the subject in the collision detection section above.
For a T2D object which you want to be fully a part of the default physics simulation, you'd enable both sending and receiving of physics. For an object which you didn't want to part of the physics simulation at all, you'd disable both. If you wanted an object to be able to cause automated physical reactions in other objects, but not be affected by default physics itself, you'd enable the ability to send physics, and disable the ability to receive. You'd do the opposite if you wanted an object which could react to other objects using the default physics system, but that wouldn't initiate default physical responses with other objects itself.
In this way, you can completely (or partially) detach any object from T2D's default physics system. You are then totally free to implement your own collision response system, in C++ or even just in script. Or, you could customize the existing system, again, either in C++, or in script.
Should also note that the ability to turn default physics off is independent of whether collision detection on an object is enabled or disabled (though they are obviously related... turning off collision sending and receiving but turning on physics won't get you far).
All in all, besides having a great built-in physics simulation, T2D makes it easy for you to develop your own collision response / physics, if you so choose!
And that's a quick look at T2D's collision response! Pretty nitty-gritty details on how the physics system itself works can be found on the page linked in that aside. Now, with collision detection and response out of the way, all the hugely-long and boring sections of this .plan are done with. There are lots of other nice T2D systems to discuss, but they don't require very long-winded explanations.
Mounting
Torque 2D allows you to mount objects to other objects. A "mount" is an attachment between two objects. When you mount one object to another, the two objects can automatically move around together (more information on how mounted movement can be controlled below).
Now, any object can be mounted to any other object in T2D. As Melv mentioned in my last .plan, that means that you could even mount a tile layer to a particle. :) This is pretty cool, especially once you start considering all the neat stuff you can do with mounts.
It's really fast setting up mounts and you can have multiple objects attached to another. And any of those mounted objects can have one or more objects mounted to them. And those secondarily mounted objects can have other objects attached to them. And so on. :) So, it's easy to create long chains and big webs of mounted objects.
Besides that, you can mount objects to any point on another object. So, mounted objects need not be attached at the center of an object, and mounted objects needn't be spaced out evenly around their parent's perimeter or anything.
In addition, you can specify whether a mount should be rigid (such that the mounted object always stays the same distance from its parent), or use mount forces. With a mount force, you can dictate that a mounted object should move with its parent after the specified force is being exerted on the mount connection. When the parent object moves, a mounted object with a mount force will lag behind the parent's movement, catching up if/when the parent comes to rest.
For example, you can create a long chain of mounted objects, each with a mount force defined. Then, you can the parent object, move it horizontally and start shaking it up and down. If you've got your mount forces configured correctly, you'll see the chain begin to "slither" like a snake, with each object in the chain eventually moving sideways, and bouncing up and down. You can change the mount forces at any time too, so you could easily make parts of the chain whip quickly into position next to their parents, or stretch further behind. Or, if you'd had the same long chain of mounted objects and had specified that each mount be rigid, when the parent object started moving, the whole chain would move simultaneously. It'd be a straight line of objects, following the parent's movement exactly.
And that's not all... you can also do fancy mount rotations. For example, you can tell a mounted object to adhere to its parent's rotation, so that when the parent rotates, the mounted object will too (and rotations are controlled in the same way, via rigid or force-based connections). Or, you could tell the mounted object not to follow the parent's rotation, so that the parent object might be spinning away, but the mounted object isn't affected at all. Or, you can rotate the mount itself. In this scenario, the parent object might not be rotating, and the mounted object might not be rotating itself either, but the mounted object's position would be rotating about the parent object (so the mounted object is orbiting the parent). Neat! You can even set-up automatic rates of rotation for all these things.
Well the possibilities are endless here. In no time, you could set-up a boss with a bunch of mounted shields rotating around him that the player has to blast off or shoot between. Note as well that you can assign mounted objects to different collision groups, so it'd be easy even to do stuff like have a "fire shield", "ice shield", "water shield", etc that you had to hit with particular kinds of weapons.
I don't know... I'm just not a good game designer, but there's obviously tons of cool stuff you can do with this system. There are lots of creative people around here, so I'm sure you're already brewing up neat gameplay ideas that could take advantage this functionality. Also, mounted objects + physics = fun, believe me. :) This is another neat little system that T2D provides out of the box, and it makes it easy to pull off all kinds of fun pieces of gameplay.
Oh, almost forgot... there is also a "link" system in T2D. Link nodes / points can be set-up exactly like mount points, however links don't imply a relationship with another object. Rather, links can be used to track a specific point on an object. Say you have a spaceship with a big rotating gun... you could set-up a link point on the tip of the gun, and use it to spawn a projectile from the correct spot at any time. Very handy.
Layers and Groups
We've already discussed layers and groups a little in the collision detection section. But layers and groups are useful for more than just customizing and speeding up collision detection.
Objects can be assigned to layers, and you can specify that layers be sorted for rendering. In fact, the sort order for layers can be changed at will, and objects can be re-assigned to different layers at any time. Also, objects on the same layer can be assigned intra-layer z-ordering, and this ordering can be changed at any time. In this way, T2D gives you very fine-grained control over the z-ordering and rendering of your objects,
Unlike many 2D APIs / libraries, T2D doesn't limit you to using a small number of rendering layers. So, T2D makes it easy, for example, to set-up very nice-looking parallaxed backgrounds with lots and lots of layers.
And groups are a handy tool all around. You can use groups not only as a nice way to set-up collidable collections, but to help keep track of and manipulate logical classes of objects.
Object picking
There are many utilities in T2D that were put in to help developers handle common game problems. One thing that comes up a lot in games is object picking. Sometimes, you want players to be able to click on particular objects and select them. Or, if you were making a 2D RTS, you'd want to be able to let your players click-drag a box around units and select them all.
These are common object picking problems, and T2D has a nice picking interface. There are routines to pick objects that intersect with a point (mouse click), line, or area within the world. Picking is basically a collision detection test, and Torque 2D performs accurate picking against object collision polygons. This also means that it's easy to specify that a pick should only return objects in certain layers or groups. Again, if you were making an RTS, you might have a player's units in a group, so it'd be easy to pick just the player's units.
Also, it's possible to have custom pick functions. Tile maps, for example, have a special pick function which can return the logical tile(s) that intersect with a pick query.
This is just one example of the neat utilities T2D provides. Again, the goal throughout T2D's development has been "hey, let's make it easy for people to make 2D games!" So, we've tried to provide a bunch of stuff like this. Credit to Melv for caring so much about indie developers and wanting to put in the time and effort it takes to create all these functions, even though they're not the most fun things to implement.
World limits
The term "world limit" is a bit of a bad descriptor for what this particular system actually does. "World limits" in T2D are used to define the region in which a particular object can move around. Probably a better term would be "movement regions" or some such.
Regardless, world limits are a nice little feature of T2D. They allow you to set, on a per-object basis, the rectilinear area in which an object can exist in.
The world limit system is turned off by default-- T2D objects don't have world limits unless you explicitly turn them on for it-- because using world limits has a (small) performance penalty. Of course, performance was extremely important to us during T2D's design and development, so world limits were turned off by default.
When world limits are on though, you can do several neat things. Besides defining a valid area for an object to exist and move around in, you can also utilize various built-in world-limit collision-responses. By calling the setWorldLimit(...) method, you can specify what kind of response the object should have when it collides with a world limit.
The first world limit collision mode is "null", which tells T2D not to do anything special to the object when it collides with its world limit. Next is "rigid", which tells T2D to use the normal rigid-body dynamics system to handle world limit collision. Next is "bounce", which will bounce the object back from the world limit by perfectly reflecting the angle of incidence and maintaining the object's incoming speed. Next, "clamp" zeroes the object's perpendicular velocity component (colliding against a side wall of the world limit will result in the x component of the object's velocity being zeroed immediately). "Sticky" results in the object coming to rest against the world limit edge it hit. And "kill" results in the object being deleted once it reaches a world limit.
As with all collisions in T2D, world limit contacts are detected accurately against an object's collision poly.
Scenegraph
Torque 2D is a scenegraph-driven framework. (I'm assuming anyone who's read this far into the overview is already familiar with scenegraphs. If you're not, there are many good descriptions available online.)
We've already indirectly discussed many aspects of T2D's scenegraph in the sections on collision detection, physics, and layers here, and I won't re-tread. T2D's scenegraph uses a bin system to divide space and store locality information for scene objects. As per usual, this information is used to cull and optimize rendering, collision detection, etc. The scenegraph provides a great interface for initializing, querying and updating the scene, and you'll see many examples of how it can be used below.
The scenegraph is used to run the overall game simulation, and can be used to specify scenegraph-wide simulation parameters. For example, with one simple call to a scenegraph's setConstantForce(...) method, you can apply a global force to all objects in the scene which adhere to the default physics system. One obvious use for this functionality is to set-up (or modify) gravity for a scene. You can also pause the scene time at any moment, and resume it whenever you like.
The camera system in T2D is really flexible. You can set windows to cover a given area of the scene with a specific zoom level, and you can zoom, rotate, and pan the view any time. Also, you can give the view window a target position or area and have it move there smoothly over time from its current position. From there, you can undo / revert the view's move, returning to the old position. In fact, the last 64 view target calls are stored in T2D, so you can revert / undo up to 64 view moves. There are lots of cool possibilities with this system, and with just a little extension, you could define a nice easy interface for creating complex camera paths and scenes.
Man, so many other features. Check it out:
-Camera Mounts: the view window can be mounted to any object, and the mount can work identically to any other mount. So, you can make the camera follow an object (like the player avatar) with a rigid or force-based connection.
-Special effects: effects like camera shaking are easy. In fact, camera shakes are implemented specifically out of the box, and you can specify a shake period and intensity, as in Torque's own default camera. This is great for stuff like providing feedback when a player gets hit.
-Multiple scenes, multiple views! You can have multiple scenegraphs running at the same time, and multiple windows on any scenegraph. So, you can have multiple separate scenes, and/or multiple views of the same scene. (Nintendo DS, anyone? ;)
-Render filtering: You can dynamically filter what kinds of objects should be rendered at any given time.
-Scene saving a loading! The entire scene state can be serialized and saved at any time. Likewise, saved scene data can be loaded, and simulation can pick up right where it left off. Or, you can load a scene, pause time, and re-set any properties of the scene or its objects that you like.
Finally, the scenegraph is capable of detailed debug and performance reporting. You'll see in some forthcoming screenshots how nifty this system is. The collision poly, oriented-bounding box, and axis-aligned bounding box for all scene objects can be visualized at any time. And you can turn on automatic reports for all kinds of information, including: the total object count in the scene, the current FPS, the number of objects which are potentially going to be rendered (those which haven't been culled from the current view), the number of potential collisions, the number of current collision contact points, the percentage of objects currently colliding with each other, and the time it took to process physics for the current frame, amongst other information. Of course, you can also customize the debug and performance queries to provide whatever other information you'd like to have. These reporting tools are very helpful when it comes to debugging and optimizing a game!
The T2D scenegraph is really slick, and just having a hardware-accelerated, scenegraph-driven 2D engine is impressive in and of itself. Between this and the preceding sections on collision detection, physics, and layers, you should have a pretty good feel for what T2D's scenegraph is capable of. The scenegraph is basically the central system of T2D, which is saying a lot, considering all that T2D can do. So, it would take many pages to fully describe all of what the scenegraph can do and how it all works. Suffice it to say, the scenegraph + the base fxSceneObject2D class form the very core of Torque 2D, and the two provide an extremely powerful basis to build from, as I hope has been indicated by the discussion so far.
Torque integration
Torque 2D, of course, integrates with the overall Torque platform. Specifically, T2D takes advantage of Torque's cross-platform support, GUI system, scripting, and sound.
That's a lot of stuff to cover, but I assume folks here are familiar with these already, so I won't go into detail about them. But, one of T2D's biggest advantages overall is that it is built on all these great core Torque technologies. Just because it's built on Torque, T2D almost automatically becomes one of the only cross-platform 2D engines, and with Torque's system, it's set-up to go to even more platforms. It also gets to use a full-fledged scripting language and powerful console command processing capabilities. T2D gets a great GUI system for free (which is undergoing a major overhaul here at the office, btw, you'll see Ben and the rest of us talking about that more in the future), and the GUI editor to go along with it. Also, T2D gets to use Torque's audio functionality, so it has good sound support.
Just taking those things right there... even if T2D had just a normal rendering system, physics, etc, it'd still be one of the best engines around. Now, it's just insane. :)
Quick note: you've no doubt noticed that networking isn't part of the list of Torque technologies which T2D takes advantage of. That's true, for now. For the Early Adopter release, we've implemented a temporary networking solution. Essentially, you can use CommandToServer() and CommandToClient() calls to do many kinds of networked games. For example, T2D ships with an example networked multiplayer checkers game.
However, full-on, Torque-style networking isn't a part of T2D just yet. It will be very soon after the initial Early Adopter release though, and that'll be another outstanding system T2D gets to leverage for free.
The reason we didn't include full networking in this initial release is that we didn't want T2D objects to take on the overhead associated with deriving from Torque's GameBase class. For T2D, we'll be splitting out tick processing (similar to the work Pat has done recently) and implementing networking from there. That said, all of T2D's systems have been designed with networking in mind. Collision and physics are the stickiest things to get networked, and Melv and I were extremely mindful of the need to network those systems in the future when we were designing them.
Getting networking in won't be a difficult task, but we wanted to get T2D out into people's hands as soon as possible. It's already an outstanding solution for most games. Even people who have fast-paced multiplayer games in mind can pick up T2D now and begin learning to use it, knowing full-well that robust, highest-quality networking support as is standard with the Torque platform is on the way.
And with that, we've covered each of T2D's major core systems. Woo!
Of course, it's also important to note that you'll be able to get the full C++ source code for T2D (details on how you get it will be announced very soon). The code is all structured to be as clean to read and understand as possible, and one of the main design goals for the entire T2D architecture was to make it easy to customize and extend.
In addition, T2D ships with about 100 pages of detailed documentation (and that's not counting source-code comments). This documentation includes a tutorial in which a small game is built from the ground up, a detailed technical overview (a stripped-down and cleaned-up version of these .plans), and an object reference. So, you'll be covered when you start learning how to use and/or customize this sweet 2D engine. :)
Okay, thanks to everyone for reading. It was fun writing this .plan and I'm sorry it took me longer to get started on it than I hoped. But, I guess the upside there is that I was able to get lots done on T2D in the mean time! Hopefully some of you found this an interesting read.
Catch you all around, and watch this space for more T2D info in the very near future! Launch sequence starting in...
About the author
#42
Both the collision system and the physics were designed with networking in mind, in-fact networking was one of the primary design goals. At this point, I really can't provide more than what Josh said although he may want to add a little more?
Articulated Body Support; I'm quite glad you brought this subject up. At the moment, T2D has the concept of mounting and there are lots of options for this system and whilst this doesn't strictly provide for constrained joints, it has been used to articulate body-parts in various demos. For instance, it's possible to add the head, arms and legs to your players body and move them independantly whilsts at the same time, have them mounted correct onto the body. You can move the body around, rotate it, flip it and all the body parts move with it. These mounts don't have constraints but it's actually a relatively easy matter to do so. To answer your question fully; joints have been discussed (and I'm not talking about the smoking variety here), and it'll definately be something that we'll look into. The consideration here will be how useful will they be for 90% of the games? I'm not making judgement here, it's just that we have to carefully consider performance as it's a game-engine not a simulation for simulations sake. With that said, I really do like the idea of being able to composite characters of constrained joints and so it will definately be a topic of conversation post EA1 release.
The idea of joints always makes me think that somebody should do a game similar to South-Park, perhaps "Flat-World", that has that characteristic flat animation style. :)
I can't speak as to the development plans for T3D and the physics unfortunately. Either Ben, Josh or perhaps Tim could answer that one. I will say that it wouldn't be a case of moving T2D physics into T3D. The algorithms, shortcuts, data-structures are noticably different (read that more complex) in 3D, as are the problems.
That's about the best info I can provide at this point. As Josh mentions, we've still got plenty of work to do on both the networking and the physics (hey, this is EA after all) and we're hoping to provide more and more power enabling much more varied gameplay dynamics, especially where the physics is concerned.
It's already proving to be an exciting year and I just can't wait to get this thing out the door and move onto phase #2.
As always, please don't hesitate sending me an email if you've got any non-marketting questions!
Thanks for all the YOs guys, keep them coming!
- Melv.
02/14/2005 (12:23 am)
Steve,Both the collision system and the physics were designed with networking in mind, in-fact networking was one of the primary design goals. At this point, I really can't provide more than what Josh said although he may want to add a little more?
Articulated Body Support; I'm quite glad you brought this subject up. At the moment, T2D has the concept of mounting and there are lots of options for this system and whilst this doesn't strictly provide for constrained joints, it has been used to articulate body-parts in various demos. For instance, it's possible to add the head, arms and legs to your players body and move them independantly whilsts at the same time, have them mounted correct onto the body. You can move the body around, rotate it, flip it and all the body parts move with it. These mounts don't have constraints but it's actually a relatively easy matter to do so. To answer your question fully; joints have been discussed (and I'm not talking about the smoking variety here), and it'll definately be something that we'll look into. The consideration here will be how useful will they be for 90% of the games? I'm not making judgement here, it's just that we have to carefully consider performance as it's a game-engine not a simulation for simulations sake. With that said, I really do like the idea of being able to composite characters of constrained joints and so it will definately be a topic of conversation post EA1 release.
The idea of joints always makes me think that somebody should do a game similar to South-Park, perhaps "Flat-World", that has that characteristic flat animation style. :)
I can't speak as to the development plans for T3D and the physics unfortunately. Either Ben, Josh or perhaps Tim could answer that one. I will say that it wouldn't be a case of moving T2D physics into T3D. The algorithms, shortcuts, data-structures are noticably different (read that more complex) in 3D, as are the problems.
That's about the best info I can provide at this point. As Josh mentions, we've still got plenty of work to do on both the networking and the physics (hey, this is EA after all) and we're hoping to provide more and more power enabling much more varied gameplay dynamics, especially where the physics is concerned.
It's already proving to be an exciting year and I just can't wait to get this thing out the door and move onto phase #2.
As always, please don't hesitate sending me an email if you've got any non-marketting questions!
Thanks for all the YOs guys, keep them coming!
- Melv.
#43
Steve, good questions! First, on getting these physics in TGE, it's not on any immediate task list. That's all I'll say for now. :) Also, just so you know Torque already has some cool physics functionality, as you'll see when you pick up a license. But, there is always cool stuff brewing here...
On articulated bodies, it would be very cool, and it'd be great fun to work on. Given the number of 2D games that might have use for them though, it's not a priority right now. Much more generally useful things to work for the time being, as I'm sure you can understand. This would be something I'd look for either as a community-generated resource, or maybe something Melv or I might do in spare time (ha.....)
On networked physics... getting accurate networked collision detection is the first major step for networked physics. From there, accurate collisions + client-side prediction and a deterministic physics system forms the bulk of what you need. We have done some work to ensure that these will be easy moves to make. But, there is still obviously a lot of work to get a really nice networked physics sim. So, all we'll fess up to for now is that, yes, some good prep work has been done, and this was important in our design decisions. We'll talk more about all this when we focus on full networking integration.
Good q's and thanks again for the compliment.
02/14/2005 (2:12 am)
Melv, thanks, sure I'll add a little. :)Steve, good questions! First, on getting these physics in TGE, it's not on any immediate task list. That's all I'll say for now. :) Also, just so you know Torque already has some cool physics functionality, as you'll see when you pick up a license. But, there is always cool stuff brewing here...
On articulated bodies, it would be very cool, and it'd be great fun to work on. Given the number of 2D games that might have use for them though, it's not a priority right now. Much more generally useful things to work for the time being, as I'm sure you can understand. This would be something I'd look for either as a community-generated resource, or maybe something Melv or I might do in spare time (ha.....)
On networked physics... getting accurate networked collision detection is the first major step for networked physics. From there, accurate collisions + client-side prediction and a deterministic physics system forms the bulk of what you need. We have done some work to ensure that these will be easy moves to make. But, there is still obviously a lot of work to get a really nice networked physics sim. So, all we'll fess up to for now is that, yes, some good prep work has been done, and this was important in our design decisions. We'll talk more about all this when we focus on full networking integration.
Good q's and thanks again for the compliment.
#45
02/14/2005 (8:41 am)
I don't just need a hit. I want to OD on T2D! 
#46
02/14/2005 (12:33 pm)
Will any reps from Garage Games be visiting the GDC in March? I would really like to see T2D in action. Thanks!
#47
02/14/2005 (12:40 pm)
We'll be at GDC, yep. :) We'll have our own booth and be in the ATI booths as well.
#49
02/14/2005 (4:42 pm)
Might've missed this somewhere else, but will T2D compile in VC6?
#50
02/14/2005 (5:06 pm)
valerie
#52
Sorry if this has been touched on but I'm guessing we'll have joystick support? Also, what about pathfinding? Will the tile mechanism allow for fairly easy access if I wanted to say, implement a depth-first or A* algorithm? Again, sorry if this has been previously noted.
02/15/2005 (9:43 am)
Melv, Josh:Sorry if this has been touched on but I'm guessing we'll have joystick support? Also, what about pathfinding? Will the tile mechanism allow for fairly easy access if I wanted to say, implement a depth-first or A* algorithm? Again, sorry if this has been previously noted.
#53
You've got full access to the tile-map database, it's not hidden behind some complex interface, both in the scripts and C++, there are well documented accessor functions to get to all the information you need to add any routines for your game. At the moment, you'll just have to take it on faith that it's real easy.
A nice thing that I've tried to maintain is that the script-functions have indentical names to the C++ class member function names so if you play with the scripts and call say "loadTileLayer()", you can go into the fxTileLayer2D class and call "bool loadTileLayer( const char* filename );".
The interface between scripts and C++ just got a lot easier. :)
- Melv.
02/15/2005 (10:26 am)
@Pete111: T2D gets its support from TGE so yes, joystick support. T2D, at the moment, provides all the basis functions such as sprites, tile-maps, scrollers, layering system, collisions, physics, mounting, so on and so forth. We don't provide the higher-level mechanisms that start to provide more specific game support yet. Putting aside the fact that T2D was designed so that it's easy to extend and generate your own custom 2D objects, adding stuff like an A* algorithm is easy.You've got full access to the tile-map database, it's not hidden behind some complex interface, both in the scripts and C++, there are well documented accessor functions to get to all the information you need to add any routines for your game. At the moment, you'll just have to take it on faith that it's real easy.
A nice thing that I've tried to maintain is that the script-functions have indentical names to the C++ class member function names so if you play with the scripts and call say "loadTileLayer()", you can go into the fxTileLayer2D class and call "bool loadTileLayer( const char* filename );".
The interface between scripts and C++ just got a lot easier. :)
- Melv.
#54
02/15/2005 (12:03 pm)
Sorry if this is a daft question, but will scriptable triggers and similar TGE constructs be available to the T2D system?
#55
I've received nearly a hundred or so emails in the last 3 weeks asking me similar questions. Probably 90% of the things asked for would take an evening, if that, to add. Triggers are definately in that class. This doesn't make the question invalid though, certainly not.
Without any changes and in script-alone, you could easily use an fxSceneObject2D to tell you when an object is in a specific 2D region though. The script-code would be around 7-lines. I know that all sorts of resources such as this will be made really quickly as T2D is so god damn easy to extend! Also, as Josh mentioned in his technical brief, we have the concept of "world-limits" which can be used to simply tell you when an object goes outside of them or have them control the object in several ways, including rigid-body dynamics. Oh man, I could talk all night about this and as Josh proved above, so could he! ;)
We've got a whole bucket load of stuff that'll be going into T2D shortly after release though. What we need to do now is release it, get lots of feedback from nice folks like you and see where we go from there. In the meantime, we'll be adding networking, more robust predictive physics, blah blah blah.
The communities reaction to T2D is going to be very important in its design.
- Melv.
02/15/2005 (12:20 pm)
@Jason: Non of the 3D specific 3D constructs will work or have any relevance to T2D. Again, we're currently at Early Adopter release so some of the higher-level constructs that you'd expect in 3D (which are not typically in 2D engines) are not in there but will be.I've received nearly a hundred or so emails in the last 3 weeks asking me similar questions. Probably 90% of the things asked for would take an evening, if that, to add. Triggers are definately in that class. This doesn't make the question invalid though, certainly not.
Without any changes and in script-alone, you could easily use an fxSceneObject2D to tell you when an object is in a specific 2D region though. The script-code would be around 7-lines. I know that all sorts of resources such as this will be made really quickly as T2D is so god damn easy to extend! Also, as Josh mentioned in his technical brief, we have the concept of "world-limits" which can be used to simply tell you when an object goes outside of them or have them control the object in several ways, including rigid-body dynamics. Oh man, I could talk all night about this and as Josh proved above, so could he! ;)
We've got a whole bucket load of stuff that'll be going into T2D shortly after release though. What we need to do now is release it, get lots of feedback from nice folks like you and see where we go from there. In the meantime, we'll be adding networking, more robust predictive physics, blah blah blah.
The communities reaction to T2D is going to be very important in its design.
- Melv.
#56
I'm sorry about that. I must have left this window open and when my daugther got on, felt she needed to post her name.
She's a quick one for 4 1/2. Considering that she can beat the 24th level(I think.The yellow one with the big circle in it) in the demo of marble blast.
I'll have to be more careful
02/16/2005 (2:23 am)
Melv,I'm sorry about that. I must have left this window open and when my daugther got on, felt she needed to post her name.
She's a quick one for 4 1/2. Considering that she can beat the 24th level(I think.The yellow one with the big circle in it) in the demo of marble blast.
I'll have to be more careful
#58
I'm dying to do a Metal Slug - like game, do you think guys that with the scrolling and big-image-partitioning stuff it would be "easy"? What about pixel-perfect collision between the static geometry and the characters? Is it possible to edit the bitmaps at run-time (thinking about deformable terrain :) )
02/16/2005 (7:21 am)
Torque2D just seems like the perfect tool for the 2D Game Developer. I'm dying to do a Metal Slug - like game, do you think guys that with the scrolling and big-image-partitioning stuff it would be "easy"? What about pixel-perfect collision between the static geometry and the characters? Is it possible to edit the bitmaps at run-time (thinking about deformable terrain :) )
#59
For large-scale image stuff, you'd definately want to use tile-maps and now that we've got a cool editor, you can do just that, especially as it's a realtime editor e.g. WYSIWYG.
We don't use pixel-perfect collision detection, we use swept polygon detection. Swept, pixel-perfect collision-detection and physics just isn't going to happen. ;)
- Melv.
02/16/2005 (7:27 am)
@Manuel: You could amend/generate the bitmaps at runtime *inside* the engine. This stuff isn't exposed to the scripts though. As you'd expect, most high-performance stuff like this would need to be done in C++ anyway.For large-scale image stuff, you'd definately want to use tile-maps and now that we've got a cool editor, you can do just that, especially as it's a realtime editor e.g. WYSIWYG.
We don't use pixel-perfect collision detection, we use swept polygon detection. Swept, pixel-perfect collision-detection and physics just isn't going to happen. ;)
- Melv.
#60
02/16/2005 (11:36 am)
And in case I don't need physics? Think about the terrain in worms, I talk about something like that. The physics used in a game of that kind (grenades and so on) can be faked with basic math (no need to complex physics).
Steve Oner
Josh- I'm sure you are busy and writing an academic paper is not at the top of your priority list. If you have more time and are willing to consider it in a few months, please get in touch.
I have questions on Torque2D which may be hard to answer:
Will Torque2D's physics be network ready? You mentioned that the collision system has been carefully prepared and that it's not 100% ready, but a big step toward network compatibility has been taken. Has the physics system been similarly prepared? Very difficult issues involved here so I'll be intrigued to hear your response.
Are there plans to add articulated body support?
Are there plans to move these physics to Torque itself?
I will not be upset if you aren't ready to provide detailed answers yet but I'd like to hear whatever you can say at this point. Thank you.