Plan for Josh Williams
by Josh Williams · 02/11/2005 (1:57 am) · 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
#82
Bitmap = Image on File that can contain single or multiple frames. T2D doesn't render Bitmaps! The bitmap format can be any format currently supported by T3D.
imageMap = A definition that points to a Bitmap and has parameters that tells T2D if it contains single or multiple frames and how those multiple frames are defined. Therefore an imageMap defines Frames.
Frame = A single region of a bitmap as defined by an imageMap.
animation = A definition that points to imageMap Frames.
Okay then...
Yes; you can set the sprites size to anything you require although its size isn't the size on the screen as this depends on the camera. The sprite size has nothing to do with the size of the underlying imagery.
Yes, the bitmaps can be large. imageMaps can only use bitmaps that are supported by the underlying hardware, not software. Modern cards have at least 2K and quite often 4K support although you'll be limiting your market to only people with cutting-edge cards. The absolute minimum we support is (0.25K - 256) support. It's up to you to decide the break-off point really, T2D doesn't currently make the decision for you. At some point, you'll want to use chunkMaps which are similar to imageMaps but split-up the underlying bitmap into a manageble minimum-spec (256) sized textures.
Yes; Sprites are made up of individual frames, not bitmaps. Remember, with T2D, you define an imageMap to acquire frames from your bitmaps and then either render frames from your imageMap or play animations which define frames from imageMaps.
Essentially, T2D has imageMaps/animations which mean you tell objects about them, not the underlying imagery. This means that your code isn't full of bitmap specific stuff like filenames and sizes etc.
T2D currently doesn't have any video support therefore there's no convention of compression (see frames above). That's not to say there won't ever be or that someone in the community won't add it. Hell, why not?
Hope this helps.
- Melv.
02/20/2005 (6:29 pm)
@Philip: Maybe we need to come to a common terminology here otherwise we'll get confused.....Bitmap = Image on File that can contain single or multiple frames. T2D doesn't render Bitmaps! The bitmap format can be any format currently supported by T3D.
imageMap = A definition that points to a Bitmap and has parameters that tells T2D if it contains single or multiple frames and how those multiple frames are defined. Therefore an imageMap defines Frames.
Frame = A single region of a bitmap as defined by an imageMap.
animation = A definition that points to imageMap Frames.
Okay then...
Yes; you can set the sprites size to anything you require although its size isn't the size on the screen as this depends on the camera. The sprite size has nothing to do with the size of the underlying imagery.
Yes, the bitmaps can be large. imageMaps can only use bitmaps that are supported by the underlying hardware, not software. Modern cards have at least 2K and quite often 4K support although you'll be limiting your market to only people with cutting-edge cards. The absolute minimum we support is (0.25K - 256) support. It's up to you to decide the break-off point really, T2D doesn't currently make the decision for you. At some point, you'll want to use chunkMaps which are similar to imageMaps but split-up the underlying bitmap into a manageble minimum-spec (256) sized textures.
Yes; Sprites are made up of individual frames, not bitmaps. Remember, with T2D, you define an imageMap to acquire frames from your bitmaps and then either render frames from your imageMap or play animations which define frames from imageMaps.
Essentially, T2D has imageMaps/animations which mean you tell objects about them, not the underlying imagery. This means that your code isn't full of bitmap specific stuff like filenames and sizes etc.
T2D currently doesn't have any video support therefore there's no convention of compression (see frames above). That's not to say there won't ever be or that someone in the community won't add it. Hell, why not?
Hope this helps.
- Melv.
#83
I am guessing that you would create a detailed image in Photoshop (or render an image out of XSI) and then define in software what the "frames" are going to be, i.e. a data structure that contains different framing parameters, like a "zoom" (series of frames centered on a set of coordinates that get larger or smaller) or "pan" (i.e. side scrolling). Is this what you mean? What about a sequence of something changing over time, like a person standing up? Is that possible? Would such a sequence be "derived from" a single bitmap or a series of bitmaps?
Thanks for your quick responses and patience...
Philip
02/20/2005 (7:56 pm)
@Melv: Thank you very much for your explanation. I obviously need to deepen my knowledge of the subject matter as I do not completely understand what you are saying. Rather than burden you with my novice questions right now, I'll go away and do that. Just a couple of questions that will help point me in the right direction:I am guessing that you would create a detailed image in Photoshop (or render an image out of XSI) and then define in software what the "frames" are going to be, i.e. a data structure that contains different framing parameters, like a "zoom" (series of frames centered on a set of coordinates that get larger or smaller) or "pan" (i.e. side scrolling). Is this what you mean? What about a sequence of something changing over time, like a person standing up? Is that possible? Would such a sequence be "derived from" a single bitmap or a series of bitmaps?
Thanks for your quick responses and patience...
Philip
#84
MegaMan Sprites
Click on Classic Megaman and then on Robot Masters. See how the bitmap is a collection of all the animations? You would load this bitmap into the Torque game engine like you would load any bitmap. Then, you would reference it as an imageMap. It would have the number of frames and references to their placement within the file itself. Then you could run through the animations.
By abstracting it, you can have a number of instances of the different sprites running around and doing different things while using a single (or multiple) bitmap file.
Setting Zoom would depend on constraints. Are you simply zooming a single image or does the detail need to change. If it needs to change, then you'll need to set up a constraint so that when image A gets zoomed to a certain size, image B will be loaded for detail (and zooming can continue or stop, etc).
For a scrolling level, it's usually more memory friendly to create a series of tile images to load. Most games on the Nintendo GameBoy make heavy use of tiled graphics. You can, however, load detailed images as well to use as backgrounds. A number of Melv's early demos showed this in action.
I'm sure I explained it badly, but I tried. If you have any questions or if I've really messed things up, just ask.
02/20/2005 (9:37 pm)
I just realized that I've never explained this before. I think one of the best ways to explain it would be to look at an existing sprite collection.MegaMan Sprites
Click on Classic Megaman and then on Robot Masters. See how the bitmap is a collection of all the animations? You would load this bitmap into the Torque game engine like you would load any bitmap. Then, you would reference it as an imageMap. It would have the number of frames and references to their placement within the file itself. Then you could run through the animations.
By abstracting it, you can have a number of instances of the different sprites running around and doing different things while using a single (or multiple) bitmap file.
Setting Zoom would depend on constraints. Are you simply zooming a single image or does the detail need to change. If it needs to change, then you'll need to set up a constraint so that when image A gets zoomed to a certain size, image B will be loaded for detail (and zooming can continue or stop, etc).
For a scrolling level, it's usually more memory friendly to create a series of tile images to load. Most games on the Nintendo GameBoy make heavy use of tiled graphics. You can, however, load detailed images as well to use as backgrounds. A number of Melv's early demos showed this in action.
I'm sure I explained it badly, but I tried. If you have any questions or if I've really messed things up, just ask.
#85
Philip
02/20/2005 (9:51 pm)
Ah, I get it!!!! A picture indeed is worth a thousand words. And I see the advantages of doing it this way. You explained it perfectly. Thanks so much. Philip
#86
@Philip: Glad this helped. :)
- Melv.
02/20/2005 (10:49 pm)
@David: Thank you very much for that great explanation. :)@Philip: Glad this helped. :)
- Melv.
#87
I know you don't answer marketing questions, but I would like to say to whoever controls the licensing issues that - aside from the engine capabilities - TGE's excellent licensing structure was the reason I originally purchased Torque. I hope that T2D follows the same structure.
Terry
02/22/2005 (7:00 am)
@Melv: We've talked briefly in another thread about T2D. Just wanted to add my "Yo" to the list. The posting of Josh's very informative .plans, as well as your input, are helpful in letting us know what we can expect from T2D soon and in the coming months. It also allows us to start pre-designing some of our ideas based on the capabilities of the product. As developers, we know you'd rather be coding than taking time to give us this information and answer questions. Thanks again to you and Josh for taking that time.I know you don't answer marketing questions, but I would like to say to whoever controls the licensing issues that - aside from the engine capabilities - TGE's excellent licensing structure was the reason I originally purchased Torque. I hope that T2D follows the same structure.
Terry
#88
what about a 2d fighting game to the degree of street fighter 2 with crazy particle effects?
02/23/2005 (10:11 pm)
quick dumb question....can a game like the old school x-men arcade (2 screen side scroller) be easily achieved with a higher quality of images (bitmaps) with this new engine?what about a 2d fighting game to the degree of street fighter 2 with crazy particle effects?
#89
Did I say unlimited there a few times or what?
- Melv.
Unlimited.
02/23/2005 (10:38 pm)
@Kenny: Yes and Yes. T2D can handle unlimited windows viewing unlimited and completely independant scenes. In-fact you can have unlimited windows all view the same scene from different positions/zooms.Did I say unlimited there a few times or what?
- Melv.
Unlimited.
#90
Just an idea on the deformable terrain for a Worms-like game, not sure if it'd be workable.
Create your map using 1x1 tiles, and set their passabilityas appropriate when the explosion hits the tile.
Like I said, don't know if it's workable or not, but it's an idea.
02/25/2005 (9:34 pm)
@ManuelJust an idea on the deformable terrain for a Worms-like game, not sure if it'd be workable.
Create your map using 1x1 tiles, and set their passabilityas appropriate when the explosion hits the tile.
Like I said, don't know if it's workable or not, but it's an idea.
Community Manager David Montgomery-Blake