Plan for Josh Williams
by Josh Williams · 02/10/2005 (5:57 pm) · 90 comments
Alright, here it is! First, my sincere apologies for the delay with this .plan... it's really cool that some of you have been looking forward to it, and I wish I could've found time to get it done right away. For as long as this .plan is, it didn't take too long to actually write, it was just hard to find the time to do it. There's been lots of actual work to do on T2D (let alone other cool projects!), so it was tough to justify taking time away to write this up. Finally got some time over the weekend though, and just got time to go back and edit / clean this monster up. Anyway, I hope some people find this thing interesting. Got some good feedback on the last .plan, so I figured I'd try to do the same here... only more! ;)
In the last .plan, I went over T2D's core classes, describing what T2D objects are capable of and how they're structured. Many people actually seemed interested to hear about all these nitty-gritty details. The geek factor around here is way too high to be healthy. Which is why I like this place so much.
So, let's dig in again. This time around, we'll take a look at T2D's core systems. Only now, I'm going to out-geek all of you. ;) In fact, this .plan has so much detail, I've had to create breakout sections in the discussions of collision detection and physics. Those topics contain some blocked sections, like this...
Also, some of the breakout sections are *really* long. One in the physics section weighs in at 6 pages long. But, rather than having all that text on this page and forcing folks who don't want to read it scroll-through everything, I've created separate little landing pages for that content, and I just link to the pages from within the block sections below. Also, this .plan was too big for the site to handle, literally-- it puked when I tried to post this behemoth. (Take that Davis Ray Sickmon! ;)
Okay, before getting started, let me give everyone a quick update on T2D's development status. Here in the last couple weeks of development (hint!), we've been pushing really hard, and making great progress. Melv is incredible, and I've been putting in some long (but fun!) hours over here too.
First thing to report is that T2D beta testing is going extremely well. Our ace team of beta testers never fails to hunt down even the tiniest bugs. Check it out:
That's Melv's baby daughter Jess, pounding away on T2D, and I'm happy to report that we passed the drool-plus-random-key-smashing test with flying colors!
GG Associates have been hammering on T2D for a while now too, and it's going great. I'd particularly like to thank Dan MacDonald and Anthony Rosenbaum for their thorough testing and detailed feedback. You guys rock.
On the development front, we're just about to finish the final release candidate build of T2D! It's been through five beta builds already, including 3 major revisions, so we're confident this puppy is ready to go. From here it's just finishing up documentation, demos, merging in some of the excellent work Pat has done, adding some better GUIs, and then doing the final installer packaging, etc. In addition, Melv is doing some new editor work, described below. All in all, the release candidate will be out almost immediately! Of course, confident as we are, we still need to put this last release candidate through testing, so don't expect T2D in your hands right away or anything. Trying to be really careful and give it a lot of testing love. But, it's obviously not very far away now. :)
The biggest development update to talk about is that we've decided to do our own simple tile editor for the Early Adopter release, instead of just doing .fmp / Mappy support. Mappy importing is still planned at some point, but after a looooong conversation and debate on the subject that lasted until 6 or 7am for me a few nights ago, Melv and I decided that the best thing would be to do our own little editor. Mappy is great, but no engine I'm aware of has as powerful a tile system as T2D. As such, Mappy just wasn't designed to support such a flexible system, and can't take full advantage of it. Doing a Mappy importer and working around the limitations seemed pretty simple on our first look, and it still isn't going to be too awfully hard, but we decided at this point time would be better spent working on our own stuff. If we're going to burn much dev time on this task, we'd rather produce something that will let people take advantage of T2D's tile system to a fuller extent. Melv is cranking away on the tile editor probably as I type right now, and it's one of the last things to go in this final (hopefully) release candidate build.
Well, that's where things stand at the moment. Very exciting! I hope appetites are whetted. Now, let's dig into T2D's core systems, as promised. The structure is similar to the last .plan, but we're describing systems instead of classes here. We'll cover the collision, physics, layer and group, mount, object picking, world limit, camera, scenegraph, and window systems, as well as discuss briefly the systems T2D inherits from TGE itself.
Okay ready? Collision is first-up, then physics. These first two topics are complicated, but very important, so get ready for long reads in these sections. :)
Collision
T2D's collision system underwent a pretty interesting development cycle, a brief history of which is in one of the breakout sections below. We want T2D to be, far and away, the best 2D engine around when it's fully complete (after the Early Adopter period is over). We know that the collision system T2D provides will be crucial in achieving that goal, and we want indie developers to have the best collision system around at their disposal. As such, after much thought, research, and discussion Melv and I set some very aggressive goals for T2D's collision system. We wanted to:
So how does this whole system work? Let's take a look.
Object collision settings:
As described in the last .plan, all script-instantiable T2D classes are derived from fxSceneObject2D, and this class defines the default collision system. Part of this definition allows objects to specify a collision polygon. Collision polys can either be regular n-gons, or custom convex shapes. This means that you can define tight-fitted custom polygons for your sprites, which makes it possible to create nicely accurate collision systems. Also, the collision polys are sized along with the object, so you don't have to worry about adjusting them.
In addition, objects can be configured to "send" and "receive" collisions. When an object sends collisions, it means that it's capable of causing collisions on other objects. Receiving collisions means that an object can be affected by collisions.
In the majority of T2D games, most objects will no doubt be configured to both send and receive collisions, just as in the real-world. But we've made it possible to easily turn off either of these capabilities for any object. So, you can create objects which can cause collisions in other objects, but are themselves immune to being affected by collisions (maybe bullets would have this profile. Tiles have this profile in T2D by default). Or, you can create objects which don't cause collisions themselves, but can be affected by colliding with other objects (feathers?). Or create objects that do neither and are exempted from the collision system altogether. Note as well that these settings can be dynamically twiddled, so you can switch on or off an object's ability to send or receive collisions at any time.
Objects can also be assigned to layers, and to groups, and these layers and groups can be used in collision detection. For example, you might assign a player's avatar and their bullets to a specific layer and group. Likewise, you might assign all enemies and their fire to the same layer, in a different group. Then, you can set collision layer and group collision masks on the player and enemies-- for the player, you might turn on collisions with its own layer, but turn off collisions with its own group (meaning that the player can't harm himself with his own projectiles), and turn on collisions for the enemy group. For enemies, you might do exactly the same, but perhaps turn on collisions with their own group as well, so that enemies can shoot each other. If you were making a multiplayer game (in the near future ;), you might turn off friendly fire by assigning players on the same team and their projectile fire to the same group, and turning off their collision with the team's group.
Besides offering fine-grained control over the kinds of collisions you want different objects to have, this layer and group system also allows you to speed up collision detection. No matter how optimized the code (and T2D's collision code is nicely optimized, again, Melv is an animal), collision detection is an expensive operation. This can especially be true when you're dealing with accurate swept-polygon collision (more info below), as T2D does. So, by specifying that an object should only collide with particular layers and groups, you can reduce the collision search space substantially, speeding up the entire process.
Finally, objects can be configured with a script collision callback function. In this way, players can over-ride or add to the default collision detection and response system. By default, the collision callback is passed the time of collision, up to two contact points, collision normals, and a custom string field which can be used to extend the callback info on the cheap. :) One obvious use of this system would be to generate explosions at the points of contact between two objects. Or, your collision script might implement its own custom physics processing system... maybe you want some of your objects to actually deform upon collision. You could modify your sprites, perhaps amongst some pre-set collection of deformation frames, and their collision polygons in this callback.
All in all, this puts a lot of power and flexibility in the user's hands. Objects can be very precisely configured for various collision behaviors, and the system itself is very easy to extend or over-ride, even just in script. It's a very powerful and flexible collision specification system, but it only takes a few lines of script to get set-up. Also, these settings can be declared in datablocks, so you can create prototype datablocks for collision settings and share them across many objects, making it even quicker and easier to get the collision set-up.
So, those are the collision configuration options. Now, let's see how collisions are detected and processed.
Collision Detection:
Like most collision systems, Torque 2D detects collisions in two phases. The first is a broad-phase, early-out collision test, which narrows the list of potential collisions. The second is a nitty-gritty collision test which returns accurate collision information both for when objects overlap, and for when they are disjoint but collide in forward-time. We'll look at both of these systems in more detail.
First, broad-phase, early-out collision is very common in collision detection schemes, as most of you no doubt already know. The goal is to very quickly determine objects that will definitely not collide with each other, so that you don't have to check these objects against each other in the next, much more expensive narrow-phase of exact object-object collision detection.
T2D's scenegraph sorts objects into "bins", which are just regular space divisions. Its broad-phase collision check compares objects in the same bin against axis-aligned bounding-boxes (AABBs) to determine whether the two objects might collide. This technique is very common, and it's tough to beat in 2D.
Once T2D is done deciding what objects definitely will not collide with each other, it has a much smaller (hopefully) list of objects which might possibly collide with each other. As stated above, T2D is capable of performing swept-polygon collision detection, which Melv and I agreed on using after much research, discussion, and debate (see the development history breakout below... this particular decision took 20+ pages of dialogue between Melv and I. :). This system is capable of detecting both overlapping objects, and disjoint objects which collide in forward-time. It is very robust, and is designed to fit perfectly with the upcoming networking changes we'll be making (see another aside below, on networked collision detection, for more info on why this is true).
Swept-volume collision detection is an active area of current research, so I guess you could say that T2D is right on the cutting-edge here. ;) We aren't doing anything too hyper-fancy (like leveraging GPU-acceleration for the sweep calcs), but the swept system we've got is pretty nice.
And you know what one of the best things about the whole system is? Despite the fact that Melv was working to get all this stuff implemented absolutely as quickly as possible, all of this code is very clean and very well commented. Even though this all involves complicated, math-heavy algorithms, you can actually read the code and understand it without even needing a piece of scratch paper.
The other cool thing about all this code is that it's fast. Yet, it's easy to use and extend. Imagine that, complicated chunks of code that are still clean, easy to extend, easy to interface with, and fast. I love Melv. :)
Alright, we now have a pretty good understanding of how T2D's collision detection system works. It meets all the goals we set for it, including being highly configurable. It's capable of handling lots and lots of objects at once, yet returns accurate collisions against detailed collision polys, thanks both to the two-phase systems used and the speed of the actual code Melv wrote. And, it's got a headstart on networking.
For those of you who weren't already familiar with the subjects, I hope the asides on collision detection were somewhat interesting. Now, let's move on and look at T2D's collision response system, and its implementation of rigid-body physics.
Physics
Okay, we've looked at collision detection in T2D, so let's look at the other side of the coin: collision response.
T2D defines a totally customizable and overridable collision response system. The basic tenant was to first assume that individual developers will want the ability to create their own collision response schemes, either in C++, or in script. So, we tried to design the physics so that customization or replacement would be as simple as possible. For developers that don't want to implement their own collision response system though, we planned out a robust default system. T2D's default collision response system utilizes an impressive rigid-body physics model, which any object can plug into. And again, developers have the ability to leverage the default rigid body dynamics system to meet their own needs, by extending and customizing the default behavior (even just with scripts, using T2D's collision callback).
Before we go into more detail about implementing custom collision response, let's take a detailed look at T2D's default system. For all the talk above about how cool it is that T2D makes it easy for you to define your own collision response systems, or to extend the default system, I think one of the very best features of T2D now is its default rigid body physics capabilities. It feels great that all kinds of 3D engines this year are bragging about their rigid body physics... and here is T2D, starting to catch up with 'em, in one less dimension. ;)
Rigid-Body Dynamics in T2D:
Torque 2D's rigid body dynamics simulation models all the standard bells and whistles, including inertia, linear velocity, angular velocity, friction, restitution, relaxation, and damping, and has an easy method for applying impulse-forces and torque. If you aren't a pro with rigid body physics, check out the breakout section below for an overview of rigid body dynamics in general, and their simulation in games in particular. If you are already a pro (or just don't care to read all the junk in the breakout), skip over and continue on to read more about T2D's physics system.
Torque 2D's rigid-body system simulates Newtonian physics. Below is another breakout very briefly defining the physics terms used to describe T2D's simulation capabilities.
Configuring objects for use in T2D's rigid-body dynamics is very simple. You just need to enable automatic collision response for the object (see below), and set-up the object's physics parameters. These parameters include friction, restitution, relaxation, damping, density, and a force scaling factor. The parameter naming is obvious: the first four are the coefficients used to model the object's physics properties (see definitions above), density is used to calculate the object's mass based on the area of its collision poly, and force scaling is used, as you might expect, to lessen or heighten the net force applied to the object at any time.
Note as well that T2D once again leverages datablocks to make the process of setting up physics properties as simple and quick as possible for developers. T2D defines the fxCollsionMaterialDatablock, which contains the six parameters above. Multiple objects can share the same datablock, so using collision material datablocks can be a real development time-saver.
There are additional physics parameters which can be used. For instance, objects can be configured with maximum and minimum linear and angular velocities. They can also be affected by an individual, constant gravitation force, or be set-up to automatically rotate at a given pace. These additional parameters are part of the core fxSceneObject2D definition, and the corresponding datablock can be used to set-up these properties too.
Customizing physics:
So, T2D's default collision response system is pretty darn impressive. But, you're not forced to use it. Similarly to how collisions work, any object in T2D can have its ability to send or receive updates to/from the default physics system turned on or off. For more information on "sending" and "receiving" collision-related information in T2D, see the discussion on the subject in the collision detection section above.
For a T2D object which you want to be fully a part of the default physics simulation, you'd enable both sending and receiving of physics. For an object which you didn't want to part of the physics simulation at all, you'd disable both. If you wanted an object to be able to cause automated physical reactions in other objects, but not be affected by default physics itself, you'd enable the ability to send physics, and disable the ability to receive. You'd do the opposite if you wanted an object which could react to other objects using the default physics system, but that wouldn't initiate default physical responses with other objects itself.
In this way, you can completely (or partially) detach any object from T2D's default physics system. You are then totally free to implement your own collision response system, in C++ or even just in script. Or, you could customize the existing system, again, either in C++, or in script.
Should also note that the ability to turn default physics off is independent of whether collision detection on an object is enabled or disabled (though they are obviously related... turning off collision sending and receiving but turning on physics won't get you far).
All in all, besides having a great built-in physics simulation, T2D makes it easy for you to develop your own collision response / physics, if you so choose!
And that's a quick look at T2D's collision response! Pretty nitty-gritty details on how the physics system itself works can be found on the page linked in that aside. Now, with collision detection and response out of the way, all the hugely-long and boring sections of this .plan are done with. There are lots of other nice T2D systems to discuss, but they don't require very long-winded explanations.
Mounting
Torque 2D allows you to mount objects to other objects. A "mount" is an attachment between two objects. When you mount one object to another, the two objects can automatically move around together (more information on how mounted movement can be controlled below).
Now, any object can be mounted to any other object in T2D. As Melv mentioned in my last .plan, that means that you could even mount a tile layer to a particle. :) This is pretty cool, especially once you start considering all the neat stuff you can do with mounts.
It's really fast setting up mounts and you can have multiple objects attached to another. And any of those mounted objects can have one or more objects mounted to them. And those secondarily mounted objects can have other objects attached to them. And so on. :) So, it's easy to create long chains and big webs of mounted objects.
Besides that, you can mount objects to any point on another object. So, mounted objects need not be attached at the center of an object, and mounted objects needn't be spaced out evenly around their parent's perimeter or anything.
In addition, you can specify whether a mount should be rigid (such that the mounted object always stays the same distance from its parent), or use mount forces. With a mount force, you can dictate that a mounted object should move with its parent after the specified force is being exerted on the mount connection. When the parent object moves, a mounted object with a mount force will lag behind the parent's movement, catching up if/when the parent comes to rest.
For example, you can create a long chain of mounted objects, each with a mount force defined. Then, you can the parent object, move it horizontally and start shaking it up and down. If you've got your mount forces configured correctly, you'll see the chain begin to "slither" like a snake, with each object in the chain eventually moving sideways, and bouncing up and down. You can change the mount forces at any time too, so you could easily make parts of the chain whip quickly into position next to their parents, or stretch further behind. Or, if you'd had the same long chain of mounted objects and had specified that each mount be rigid, when the parent object started moving, the whole chain would move simultaneously. It'd be a straight line of objects, following the parent's movement exactly.
And that's not all... you can also do fancy mount rotations. For example, you can tell a mounted object to adhere to its parent's rotation, so that when the parent rotates, the mounted object will too (and rotations are controlled in the same way, via rigid or force-based connections). Or, you could tell the mounted object not to follow the parent's rotation, so that the parent object might be spinning away, but the mounted object isn't affected at all. Or, you can rotate the mount itself. In this scenario, the parent object might not be rotating, and the mounted object might not be rotating itself either, but the mounted object's position would be rotating about the parent object (so the mounted object is orbiting the parent). Neat! You can even set-up automatic rates of rotation for all these things.
Well the possibilities are endless here. In no time, you could set-up a boss with a bunch of mounted shields rotating around him that the player has to blast off or shoot between. Note as well that you can assign mounted objects to different collision groups, so it'd be easy even to do stuff like have a "fire shield", "ice shield", "water shield", etc that you had to hit with particular kinds of weapons.
I don't know... I'm just not a good game designer, but there's obviously tons of cool stuff you can do with this system. There are lots of creative people around here, so I'm sure you're already brewing up neat gameplay ideas that could take advantage this functionality. Also, mounted objects + physics = fun, believe me. :) This is another neat little system that T2D provides out of the box, and it makes it easy to pull off all kinds of fun pieces of gameplay.
Oh, almost forgot... there is also a "link" system in T2D. Link nodes / points can be set-up exactly like mount points, however links don't imply a relationship with another object. Rather, links can be used to track a specific point on an object. Say you have a spaceship with a big rotating gun... you could set-up a link point on the tip of the gun, and use it to spawn a projectile from the correct spot at any time. Very handy.
Layers and Groups
We've already discussed layers and groups a little in the collision detection section. But layers and groups are useful for more than just customizing and speeding up collision detection.
Objects can be assigned to layers, and you can specify that layers be sorted for rendering. In fact, the sort order for layers can be changed at will, and objects can be re-assigned to different layers at any time. Also, objects on the same layer can be assigned intra-layer z-ordering, and this ordering can be changed at any time. In this way, T2D gives you very fine-grained control over the z-ordering and rendering of your objects,
Unlike many 2D APIs / libraries, T2D doesn't limit you to using a small number of rendering layers. So, T2D makes it easy, for example, to set-up very nice-looking parallaxed backgrounds with lots and lots of layers.
And groups are a handy tool all around. You can use groups not only as a nice way to set-up collidable collections, but to help keep track of and manipulate logical classes of objects.
Object picking
There are many utilities in T2D that were put in to help developers handle common game problems. One thing that comes up a lot in games is object picking. Sometimes, you want players to be able to click on particular objects and select them. Or, if you were making a 2D RTS, you'd want to be able to let your players click-drag a box around units and select them all.
These are common object picking problems, and T2D has a nice picking interface. There are routines to pick objects that intersect with a point (mouse click), line, or area within the world. Picking is basically a collision detection test, and Torque 2D performs accurate picking against object collision polygons. This also means that it's easy to specify that a pick should only return objects in certain layers or groups. Again, if you were making an RTS, you might have a player's units in a group, so it'd be easy to pick just the player's units.
Also, it's possible to have custom pick functions. Tile maps, for example, have a special pick function which can return the logical tile(s) that intersect with a pick query.
This is just one example of the neat utilities T2D provides. Again, the goal throughout T2D's development has been "hey, let's make it easy for people to make 2D games!" So, we've tried to provide a bunch of stuff like this. Credit to Melv for caring so much about indie developers and wanting to put in the time and effort it takes to create all these functions, even though they're not the most fun things to implement.
World limits
The term "world limit" is a bit of a bad descriptor for what this particular system actually does. "World limits" in T2D are used to define the region in which a particular object can move around. Probably a better term would be "movement regions" or some such.
Regardless, world limits are a nice little feature of T2D. They allow you to set, on a per-object basis, the rectilinear area in which an object can exist in.
The world limit system is turned off by default-- T2D objects don't have world limits unless you explicitly turn them on for it-- because using world limits has a (small) performance penalty. Of course, performance was extremely important to us during T2D's design and development, so world limits were turned off by default.
When world limits are on though, you can do several neat things. Besides defining a valid area for an object to exist and move around in, you can also utilize various built-in world-limit collision-responses. By calling the setWorldLimit(...) method, you can specify what kind of response the object should have when it collides with a world limit.
The first world limit collision mode is "null", which tells T2D not to do anything special to the object when it collides with its world limit. Next is "rigid", which tells T2D to use the normal rigid-body dynamics system to handle world limit collision. Next is "bounce", which will bounce the object back from the world limit by perfectly reflecting the angle of incidence and maintaining the object's incoming speed. Next, "clamp" zeroes the object's perpendicular velocity component (colliding against a side wall of the world limit will result in the x component of the object's velocity being zeroed immediately). "Sticky" results in the object coming to rest against the world limit edge it hit. And "kill" results in the object being deleted once it reaches a world limit.
As with all collisions in T2D, world limit contacts are detected accurately against an object's collision poly.
Scenegraph
Torque 2D is a scenegraph-driven framework. (I'm assuming anyone who's read this far into the overview is already familiar with scenegraphs. If you're not, there are many good descriptions available online.)
We've already indirectly discussed many aspects of T2D's scenegraph in the sections on collision detection, physics, and layers here, and I won't re-tread. T2D's scenegraph uses a bin system to divide space and store locality information for scene objects. As per usual, this information is used to cull and optimize rendering, collision detection, etc. The scenegraph provides a great interface for initializing, querying and updating the scene, and you'll see many examples of how it can be used below.
The scenegraph is used to run the overall game simulation, and can be used to specify scenegraph-wide simulation parameters. For example, with one simple call to a scenegraph's setConstantForce(...) method, you can apply a global force to all objects in the scene which adhere to the default physics system. One obvious use for this functionality is to set-up (or modify) gravity for a scene. You can also pause the scene time at any moment, and resume it whenever you like.
The camera system in T2D is really flexible. You can set windows to cover a given area of the scene with a specific zoom level, and you can zoom, rotate, and pan the view any time. Also, you can give the view window a target position or area and have it move there smoothly over time from its current position. From there, you can undo / revert the view's move, returning to the old position. In fact, the last 64 view target calls are stored in T2D, so you can revert / undo up to 64 view moves. There are lots of cool possibilities with this system, and with just a little extension, you could define a nice easy interface for creating complex camera paths and scenes.
Man, so many other features. Check it out:
-Camera Mounts: the view window can be mounted to any object, and the mount can work identically to any other mount. So, you can make the camera follow an object (like the player avatar) with a rigid or force-based connection.
-Special effects: effects like camera shaking are easy. In fact, camera shakes are implemented specifically out of the box, and you can specify a shake period and intensity, as in Torque's own default camera. This is great for stuff like providing feedback when a player gets hit.
-Multiple scenes, multiple views! You can have multiple scenegraphs running at the same time, and multiple windows on any scenegraph. So, you can have multiple separate scenes, and/or multiple views of the same scene. (Nintendo DS, anyone? ;)
-Render filtering: You can dynamically filter what kinds of objects should be rendered at any given time.
-Scene saving a loading! The entire scene state can be serialized and saved at any time. Likewise, saved scene data can be loaded, and simulation can pick up right where it left off. Or, you can load a scene, pause time, and re-set any properties of the scene or its objects that you like.
Finally, the scenegraph is capable of detailed debug and performance reporting. You'll see in some forthcoming screenshots how nifty this system is. The collision poly, oriented-bounding box, and axis-aligned bounding box for all scene objects can be visualized at any time. And you can turn on automatic reports for all kinds of information, including: the total object count in the scene, the current FPS, the number of objects which are potentially going to be rendered (those which haven't been culled from the current view), the number of potential collisions, the number of current collision contact points, the percentage of objects currently colliding with each other, and the time it took to process physics for the current frame, amongst other information. Of course, you can also customize the debug and performance queries to provide whatever other information you'd like to have. These reporting tools are very helpful when it comes to debugging and optimizing a game!
The T2D scenegraph is really slick, and just having a hardware-accelerated, scenegraph-driven 2D engine is impressive in and of itself. Between this and the preceding sections on collision detection, physics, and layers, you should have a pretty good feel for what T2D's scenegraph is capable of. The scenegraph is basically the central system of T2D, which is saying a lot, considering all that T2D can do. So, it would take many pages to fully describe all of what the scenegraph can do and how it all works. Suffice it to say, the scenegraph + the base fxSceneObject2D class form the very core of Torque 2D, and the two provide an extremely powerful basis to build from, as I hope has been indicated by the discussion so far.
Torque integration
Torque 2D, of course, integrates with the overall Torque platform. Specifically, T2D takes advantage of Torque's cross-platform support, GUI system, scripting, and sound.
That's a lot of stuff to cover, but I assume folks here are familiar with these already, so I won't go into detail about them. But, one of T2D's biggest advantages overall is that it is built on all these great core Torque technologies. Just because it's built on Torque, T2D almost automatically becomes one of the only cross-platform 2D engines, and with Torque's system, it's set-up to go to even more platforms. It also gets to use a full-fledged scripting language and powerful console command processing capabilities. T2D gets a great GUI system for free (which is undergoing a major overhaul here at the office, btw, you'll see Ben and the rest of us talking about that more in the future), and the GUI editor to go along with it. Also, T2D gets to use Torque's audio functionality, so it has good sound support.
Just taking those things right there... even if T2D had just a normal rendering system, physics, etc, it'd still be one of the best engines around. Now, it's just insane. :)
Quick note: you've no doubt noticed that networking isn't part of the list of Torque technologies which T2D takes advantage of. That's true, for now. For the Early Adopter release, we've implemented a temporary networking solution. Essentially, you can use CommandToServer() and CommandToClient() calls to do many kinds of networked games. For example, T2D ships with an example networked multiplayer checkers game.
However, full-on, Torque-style networking isn't a part of T2D just yet. It will be very soon after the initial Early Adopter release though, and that'll be another outstanding system T2D gets to leverage for free.
The reason we didn't include full networking in this initial release is that we didn't want T2D objects to take on the overhead associated with deriving from Torque's GameBase class. For T2D, we'll be splitting out tick processing (similar to the work Pat has done recently) and implementing networking from there. That said, all of T2D's systems have been designed with networking in mind. Collision and physics are the stickiest things to get networked, and Melv and I were extremely mindful of the need to network those systems in the future when we were designing them.
Getting networking in won't be a difficult task, but we wanted to get T2D out into people's hands as soon as possible. It's already an outstanding solution for most games. Even people who have fast-paced multiplayer games in mind can pick up T2D now and begin learning to use it, knowing full-well that robust, highest-quality networking support as is standard with the Torque platform is on the way.
And with that, we've covered each of T2D's major core systems. Woo!
Of course, it's also important to note that you'll be able to get the full C++ source code for T2D (details on how you get it will be announced very soon). The code is all structured to be as clean to read and understand as possible, and one of the main design goals for the entire T2D architecture was to make it easy to customize and extend.
In addition, T2D ships with about 100 pages of detailed documentation (and that's not counting source-code comments). This documentation includes a tutorial in which a small game is built from the ground up, a detailed technical overview (a stripped-down and cleaned-up version of these .plans), and an object reference. So, you'll be covered when you start learning how to use and/or customize this sweet 2D engine. :)
Okay, thanks to everyone for reading. It was fun writing this .plan and I'm sorry it took me longer to get started on it than I hoped. But, I guess the upside there is that I was able to get lots done on T2D in the mean time! Hopefully some of you found this an interesting read.
Catch you all around, and watch this space for more T2D info in the very near future! Launch sequence starting in...
In the last .plan, I went over T2D's core classes, describing what T2D objects are capable of and how they're structured. Many people actually seemed interested to hear about all these nitty-gritty details. The geek factor around here is way too high to be healthy. Which is why I like this place so much.
So, let's dig in again. This time around, we'll take a look at T2D's core systems. Only now, I'm going to out-geek all of you. ;) In fact, this .plan has so much detail, I've had to create breakout sections in the discussions of collision detection and physics. Those topics contain some blocked sections, like this...
Quote:These sections can safely be skipped without breaking the main thread of this .plan. These breakouts contain asides, explanations of the reasoning for why certain design decisions were made, and other discussions that might be interesting, but aren't necessary to the main technical overview. I thought some people would find them interesting, but want to make it easy for anybody who's not interested to skip 'em.
Hello, I am a block section containing unnecessary but potentially interesting detail on certain aspects of T2D's sub-systems, or general asides on relevant but tangential topics.
Also, some of the breakout sections are *really* long. One in the physics section weighs in at 6 pages long. But, rather than having all that text on this page and forcing folks who don't want to read it scroll-through everything, I've created separate little landing pages for that content, and I just link to the pages from within the block sections below. Also, this .plan was too big for the site to handle, literally-- it puked when I tried to post this behemoth. (Take that Davis Ray Sickmon! ;)
Okay, before getting started, let me give everyone a quick update on T2D's development status. Here in the last couple weeks of development (hint!), we've been pushing really hard, and making great progress. Melv is incredible, and I've been putting in some long (but fun!) hours over here too.
First thing to report is that T2D beta testing is going extremely well. Our ace team of beta testers never fails to hunt down even the tiniest bugs. Check it out:
That's Melv's baby daughter Jess, pounding away on T2D, and I'm happy to report that we passed the drool-plus-random-key-smashing test with flying colors!
GG Associates have been hammering on T2D for a while now too, and it's going great. I'd particularly like to thank Dan MacDonald and Anthony Rosenbaum for their thorough testing and detailed feedback. You guys rock.
On the development front, we're just about to finish the final release candidate build of T2D! It's been through five beta builds already, including 3 major revisions, so we're confident this puppy is ready to go. From here it's just finishing up documentation, demos, merging in some of the excellent work Pat has done, adding some better GUIs, and then doing the final installer packaging, etc. In addition, Melv is doing some new editor work, described below. All in all, the release candidate will be out almost immediately! Of course, confident as we are, we still need to put this last release candidate through testing, so don't expect T2D in your hands right away or anything. Trying to be really careful and give it a lot of testing love. But, it's obviously not very far away now. :)
The biggest development update to talk about is that we've decided to do our own simple tile editor for the Early Adopter release, instead of just doing .fmp / Mappy support. Mappy importing is still planned at some point, but after a looooong conversation and debate on the subject that lasted until 6 or 7am for me a few nights ago, Melv and I decided that the best thing would be to do our own little editor. Mappy is great, but no engine I'm aware of has as powerful a tile system as T2D. As such, Mappy just wasn't designed to support such a flexible system, and can't take full advantage of it. Doing a Mappy importer and working around the limitations seemed pretty simple on our first look, and it still isn't going to be too awfully hard, but we decided at this point time would be better spent working on our own stuff. If we're going to burn much dev time on this task, we'd rather produce something that will let people take advantage of T2D's tile system to a fuller extent. Melv is cranking away on the tile editor probably as I type right now, and it's one of the last things to go in this final (hopefully) release candidate build.
Well, that's where things stand at the moment. Very exciting! I hope appetites are whetted. Now, let's dig into T2D's core systems, as promised. The structure is similar to the last .plan, but we're describing systems instead of classes here. We'll cover the collision, physics, layer and group, mount, object picking, world limit, camera, scenegraph, and window systems, as well as discuss briefly the systems T2D inherits from TGE itself.
Okay ready? Collision is first-up, then physics. These first two topics are complicated, but very important, so get ready for long reads in these sections. :)
Collision
T2D's collision system underwent a pretty interesting development cycle, a brief history of which is in one of the breakout sections below. We want T2D to be, far and away, the best 2D engine around when it's fully complete (after the Early Adopter period is over). We know that the collision system T2D provides will be crucial in achieving that goal, and we want indie developers to have the best collision system around at their disposal. As such, after much thought, research, and discussion Melv and I set some very aggressive goals for T2D's collision system. We wanted to:
- Allow detailed collision polygons to be specified for objects and accurately collide them
- Let users enable or disable individual objects' ability to cause or be affected by collisions
- Easily restrict collisions between particular groups of objects
- Return rich collision information
- Make it possible for people to customize the system, even with scripting only
- Easily hook-up to custom collision response systems
- Use the same system for tile-maps and normal scene objects
- Handle hundreds of objects in a scene at once
- Create a network-ready collision scheme
- Do it all in a very easy to configure manner, so that anyone can use T2D with little hassle
So how does this whole system work? Let's take a look.
Object collision settings:
As described in the last .plan, all script-instantiable T2D classes are derived from fxSceneObject2D, and this class defines the default collision system. Part of this definition allows objects to specify a collision polygon. Collision polys can either be regular n-gons, or custom convex shapes. This means that you can define tight-fitted custom polygons for your sprites, which makes it possible to create nicely accurate collision systems. Also, the collision polys are sized along with the object, so you don't have to worry about adjusting them.
In addition, objects can be configured to "send" and "receive" collisions. When an object sends collisions, it means that it's capable of causing collisions on other objects. Receiving collisions means that an object can be affected by collisions.
Quote:Aside: Sending and receiving collisions, what?
------------------------------------------
To make this more clear... objects in the real world of course both send and receive collisionswhen you and your buddy stand at opposite ends of the room, run at each other, and smack together (because you are smart and you find this activity enjoyable), you both send a collision to the other and receive a collision from the other. Your skull sends a collision to your buddy's, and your buddy's skull receives your collision. And vice versa.
Torque itself has a similar concept of active and passive colliders, but it doesn't define a clean interface regarding it.
In the majority of T2D games, most objects will no doubt be configured to both send and receive collisions, just as in the real-world. But we've made it possible to easily turn off either of these capabilities for any object. So, you can create objects which can cause collisions in other objects, but are themselves immune to being affected by collisions (maybe bullets would have this profile. Tiles have this profile in T2D by default). Or, you can create objects which don't cause collisions themselves, but can be affected by colliding with other objects (feathers?). Or create objects that do neither and are exempted from the collision system altogether. Note as well that these settings can be dynamically twiddled, so you can switch on or off an object's ability to send or receive collisions at any time.
Objects can also be assigned to layers, and to groups, and these layers and groups can be used in collision detection. For example, you might assign a player's avatar and their bullets to a specific layer and group. Likewise, you might assign all enemies and their fire to the same layer, in a different group. Then, you can set collision layer and group collision masks on the player and enemies-- for the player, you might turn on collisions with its own layer, but turn off collisions with its own group (meaning that the player can't harm himself with his own projectiles), and turn on collisions for the enemy group. For enemies, you might do exactly the same, but perhaps turn on collisions with their own group as well, so that enemies can shoot each other. If you were making a multiplayer game (in the near future ;), you might turn off friendly fire by assigning players on the same team and their projectile fire to the same group, and turning off their collision with the team's group.
Besides offering fine-grained control over the kinds of collisions you want different objects to have, this layer and group system also allows you to speed up collision detection. No matter how optimized the code (and T2D's collision code is nicely optimized, again, Melv is an animal), collision detection is an expensive operation. This can especially be true when you're dealing with accurate swept-polygon collision (more info below), as T2D does. So, by specifying that an object should only collide with particular layers and groups, you can reduce the collision search space substantially, speeding up the entire process.
Finally, objects can be configured with a script collision callback function. In this way, players can over-ride or add to the default collision detection and response system. By default, the collision callback is passed the time of collision, up to two contact points, collision normals, and a custom string field which can be used to extend the callback info on the cheap. :) One obvious use of this system would be to generate explosions at the points of contact between two objects. Or, your collision script might implement its own custom physics processing system... maybe you want some of your objects to actually deform upon collision. You could modify your sprites, perhaps amongst some pre-set collection of deformation frames, and their collision polygons in this callback.
All in all, this puts a lot of power and flexibility in the user's hands. Objects can be very precisely configured for various collision behaviors, and the system itself is very easy to extend or over-ride, even just in script. It's a very powerful and flexible collision specification system, but it only takes a few lines of script to get set-up. Also, these settings can be declared in datablocks, so you can create prototype datablocks for collision settings and share them across many objects, making it even quicker and easier to get the collision set-up.
So, those are the collision configuration options. Now, let's see how collisions are detected and processed.
Collision Detection:
Like most collision systems, Torque 2D detects collisions in two phases. The first is a broad-phase, early-out collision test, which narrows the list of potential collisions. The second is a nitty-gritty collision test which returns accurate collision information both for when objects overlap, and for when they are disjoint but collide in forward-time. We'll look at both of these systems in more detail.
First, broad-phase, early-out collision is very common in collision detection schemes, as most of you no doubt already know. The goal is to very quickly determine objects that will definitely not collide with each other, so that you don't have to check these objects against each other in the next, much more expensive narrow-phase of exact object-object collision detection.
T2D's scenegraph sorts objects into "bins", which are just regular space divisions. Its broad-phase collision check compares objects in the same bin against axis-aligned bounding-boxes (AABBs) to determine whether the two objects might collide. This technique is very common, and it's tough to beat in 2D.
Quote:Aside: Broad-phase CD information:
---------------------------------------------------------
One can use a large variety of techniques in broad-phase collision checks. Some of the best information and resources on the subject can be found here, here, and in the book Real-Time Rendering. Most recent research in this area is specifically targeted at handling 3D collision detection with highly complex objects. In these scenarios, AABB checks are not usually optimal, and the most recent research is generally hostile toward using AABB checks in the broad phase. But, Melv is smarter than all these fool academics. ;) In all seriousness though, 2D game scenes are generally quite well-suited for using AABB in early-out, broad-phase collision pass.
Once T2D is done deciding what objects definitely will not collide with each other, it has a much smaller (hopefully) list of objects which might possibly collide with each other. As stated above, T2D is capable of performing swept-polygon collision detection, which Melv and I agreed on using after much research, discussion, and debate (see the development history breakout below... this particular decision took 20+ pages of dialogue between Melv and I. :). This system is capable of detecting both overlapping objects, and disjoint objects which collide in forward-time. It is very robust, and is designed to fit perfectly with the upcoming networking changes we'll be making (see another aside below, on networked collision detection, for more info on why this is true).
Swept-volume collision detection is an active area of current research, so I guess you could say that T2D is right on the cutting-edge here. ;) We aren't doing anything too hyper-fancy (like leveraging GPU-acceleration for the sweep calcs), but the swept system we've got is pretty nice.
And you know what one of the best things about the whole system is? Despite the fact that Melv was working to get all this stuff implemented absolutely as quickly as possible, all of this code is very clean and very well commented. Even though this all involves complicated, math-heavy algorithms, you can actually read the code and understand it without even needing a piece of scratch paper.
The other cool thing about all this code is that it's fast. Yet, it's easy to use and extend. Imagine that, complicated chunks of code that are still clean, easy to extend, easy to interface with, and fast. I love Melv. :)
Quote:Aside: Collision detection schemes
--------------------------------------------------------
Collision detection is a well-established field of study, but it's still researched very actively, in both academic and private fields like game development, CAD, CGI, robotics, and others. For anyone interested, here's a quick aside on collision detection. The goal of this discussion isn't to offer a detailed tutorial on collision detection algorithms (this .plan is getting long enough already). Rather, I hope to give a feel for how some common collision schemes work, so you can see a context for T2D's collision detection, if you aren't already familiar with these algorithms.
... Read more! ... this one is about 1.5 pages long, so it's broken out separately. Very briefly talks about the usual kinds of narrow-phase collision detection schemes: feature-oriented (Linn-Canny), simplex-oriented (GJK), and methods more appropriate for dealing with less strenuous CD constraints.
Quote:Aside: Network-ready collision detection:
---------------------------------------------------------------
What's so hard about networked collision detection anyway? If you haven't thought about it much yet, read this quick aside and see why preparing for the inevitable move to networked simulation was so important for T2D.
... Read more!... this one is about 1.5 pages long as well, so it's broken also out separately. Offers a high-level overview of the problems associated with network simulation in general and as applied to collision detection in particular.
Quote:Aside: A brief development history of T2D's collision detection system
------------------------------------------------------------------------------------
See how we got where we are today. Torque 2D originally had a very simplistic collision detection system, which Melv created just as a temporary placeholder. It used simple bounding box checks for collision detection and checked only for overlaps, in discrete time (see the aside above for a simple discussion on why this doesn't work too well in general, and especially not in networked games).
... Read more!... Another 1.5 pager, also broken out. Get the inside scoop!
Alright, we now have a pretty good understanding of how T2D's collision detection system works. It meets all the goals we set for it, including being highly configurable. It's capable of handling lots and lots of objects at once, yet returns accurate collisions against detailed collision polys, thanks both to the two-phase systems used and the speed of the actual code Melv wrote. And, it's got a headstart on networking.
For those of you who weren't already familiar with the subjects, I hope the asides on collision detection were somewhat interesting. Now, let's move on and look at T2D's collision response system, and its implementation of rigid-body physics.
Physics
Okay, we've looked at collision detection in T2D, so let's look at the other side of the coin: collision response.
T2D defines a totally customizable and overridable collision response system. The basic tenant was to first assume that individual developers will want the ability to create their own collision response schemes, either in C++, or in script. So, we tried to design the physics so that customization or replacement would be as simple as possible. For developers that don't want to implement their own collision response system though, we planned out a robust default system. T2D's default collision response system utilizes an impressive rigid-body physics model, which any object can plug into. And again, developers have the ability to leverage the default rigid body dynamics system to meet their own needs, by extending and customizing the default behavior (even just with scripts, using T2D's collision callback).
Before we go into more detail about implementing custom collision response, let's take a detailed look at T2D's default system. For all the talk above about how cool it is that T2D makes it easy for you to define your own collision response systems, or to extend the default system, I think one of the very best features of T2D now is its default rigid body physics capabilities. It feels great that all kinds of 3D engines this year are bragging about their rigid body physics... and here is T2D, starting to catch up with 'em, in one less dimension. ;)
Rigid-Body Dynamics in T2D:
Torque 2D's rigid body dynamics simulation models all the standard bells and whistles, including inertia, linear velocity, angular velocity, friction, restitution, relaxation, and damping, and has an easy method for applying impulse-forces and torque. If you aren't a pro with rigid body physics, check out the breakout section below for an overview of rigid body dynamics in general, and their simulation in games in particular. If you are already a pro (or just don't care to read all the junk in the breakout), skip over and continue on to read more about T2D's physics system.
Quote:Aside: Rigid-body dynamics, real-time simulations, and Torque 2D:
---------------------------------------------------------------------------------------------------
This discussion offers a simple overview of the common algorithms used in real-time rigid-body dynamics simulations, and relates them to the physics system in Torque 2D.
...Read more!... this one is about 6 pages long, needed to break it out. Sub-sections:
Introduction
Methods of real-time rigid-body simulation
-Approaches for constraint and contact handling
-Integrators
Closing
References
Torque 2D's rigid-body system simulates Newtonian physics. Below is another breakout very briefly defining the physics terms used to describe T2D's simulation capabilities.
Quote:Aside: Brief definition of physics terms:
---------------------------------------------------------------
Here are quickie definitions of the terms used to describe T2D's simulation of Newtonian rigid body physics. (For physics buffs and sim nuts, I'm just using commonsensical definitions here, not scientifically or pedagogically satisfactory ones)
Linear velocity - The speed and direction an object is moving at
Angular velocity - The speed and direction an object is rotating at
Friction - Resistance to moving or rotating
Restitution - Bounciness
Relaxation - Returning to a balanced state after a disturbance
Damping - Loss of energy over time
Configuring objects for use in T2D's rigid-body dynamics is very simple. You just need to enable automatic collision response for the object (see below), and set-up the object's physics parameters. These parameters include friction, restitution, relaxation, damping, density, and a force scaling factor. The parameter naming is obvious: the first four are the coefficients used to model the object's physics properties (see definitions above), density is used to calculate the object's mass based on the area of its collision poly, and force scaling is used, as you might expect, to lessen or heighten the net force applied to the object at any time.
Note as well that T2D once again leverages datablocks to make the process of setting up physics properties as simple and quick as possible for developers. T2D defines the fxCollsionMaterialDatablock, which contains the six parameters above. Multiple objects can share the same datablock, so using collision material datablocks can be a real development time-saver.
There are additional physics parameters which can be used. For instance, objects can be configured with maximum and minimum linear and angular velocities. They can also be affected by an individual, constant gravitation force, or be set-up to automatically rotate at a given pace. These additional parameters are part of the core fxSceneObject2D definition, and the corresponding datablock can be used to set-up these properties too.
Customizing physics:
So, T2D's default collision response system is pretty darn impressive. But, you're not forced to use it. Similarly to how collisions work, any object in T2D can have its ability to send or receive updates to/from the default physics system turned on or off. For more information on "sending" and "receiving" collision-related information in T2D, see the discussion on the subject in the collision detection section above.
For a T2D object which you want to be fully a part of the default physics simulation, you'd enable both sending and receiving of physics. For an object which you didn't want to part of the physics simulation at all, you'd disable both. If you wanted an object to be able to cause automated physical reactions in other objects, but not be affected by default physics itself, you'd enable the ability to send physics, and disable the ability to receive. You'd do the opposite if you wanted an object which could react to other objects using the default physics system, but that wouldn't initiate default physical responses with other objects itself.
In this way, you can completely (or partially) detach any object from T2D's default physics system. You are then totally free to implement your own collision response system, in C++ or even just in script. Or, you could customize the existing system, again, either in C++, or in script.
Should also note that the ability to turn default physics off is independent of whether collision detection on an object is enabled or disabled (though they are obviously related... turning off collision sending and receiving but turning on physics won't get you far).
All in all, besides having a great built-in physics simulation, T2D makes it easy for you to develop your own collision response / physics, if you so choose!
And that's a quick look at T2D's collision response! Pretty nitty-gritty details on how the physics system itself works can be found on the page linked in that aside. Now, with collision detection and response out of the way, all the hugely-long and boring sections of this .plan are done with. There are lots of other nice T2D systems to discuss, but they don't require very long-winded explanations.
Mounting
Torque 2D allows you to mount objects to other objects. A "mount" is an attachment between two objects. When you mount one object to another, the two objects can automatically move around together (more information on how mounted movement can be controlled below).
Now, any object can be mounted to any other object in T2D. As Melv mentioned in my last .plan, that means that you could even mount a tile layer to a particle. :) This is pretty cool, especially once you start considering all the neat stuff you can do with mounts.
It's really fast setting up mounts and you can have multiple objects attached to another. And any of those mounted objects can have one or more objects mounted to them. And those secondarily mounted objects can have other objects attached to them. And so on. :) So, it's easy to create long chains and big webs of mounted objects.
Besides that, you can mount objects to any point on another object. So, mounted objects need not be attached at the center of an object, and mounted objects needn't be spaced out evenly around their parent's perimeter or anything.
In addition, you can specify whether a mount should be rigid (such that the mounted object always stays the same distance from its parent), or use mount forces. With a mount force, you can dictate that a mounted object should move with its parent after the specified force is being exerted on the mount connection. When the parent object moves, a mounted object with a mount force will lag behind the parent's movement, catching up if/when the parent comes to rest.
For example, you can create a long chain of mounted objects, each with a mount force defined. Then, you can the parent object, move it horizontally and start shaking it up and down. If you've got your mount forces configured correctly, you'll see the chain begin to "slither" like a snake, with each object in the chain eventually moving sideways, and bouncing up and down. You can change the mount forces at any time too, so you could easily make parts of the chain whip quickly into position next to their parents, or stretch further behind. Or, if you'd had the same long chain of mounted objects and had specified that each mount be rigid, when the parent object started moving, the whole chain would move simultaneously. It'd be a straight line of objects, following the parent's movement exactly.
And that's not all... you can also do fancy mount rotations. For example, you can tell a mounted object to adhere to its parent's rotation, so that when the parent rotates, the mounted object will too (and rotations are controlled in the same way, via rigid or force-based connections). Or, you could tell the mounted object not to follow the parent's rotation, so that the parent object might be spinning away, but the mounted object isn't affected at all. Or, you can rotate the mount itself. In this scenario, the parent object might not be rotating, and the mounted object might not be rotating itself either, but the mounted object's position would be rotating about the parent object (so the mounted object is orbiting the parent). Neat! You can even set-up automatic rates of rotation for all these things.
Well the possibilities are endless here. In no time, you could set-up a boss with a bunch of mounted shields rotating around him that the player has to blast off or shoot between. Note as well that you can assign mounted objects to different collision groups, so it'd be easy even to do stuff like have a "fire shield", "ice shield", "water shield", etc that you had to hit with particular kinds of weapons.
I don't know... I'm just not a good game designer, but there's obviously tons of cool stuff you can do with this system. There are lots of creative people around here, so I'm sure you're already brewing up neat gameplay ideas that could take advantage this functionality. Also, mounted objects + physics = fun, believe me. :) This is another neat little system that T2D provides out of the box, and it makes it easy to pull off all kinds of fun pieces of gameplay.
Oh, almost forgot... there is also a "link" system in T2D. Link nodes / points can be set-up exactly like mount points, however links don't imply a relationship with another object. Rather, links can be used to track a specific point on an object. Say you have a spaceship with a big rotating gun... you could set-up a link point on the tip of the gun, and use it to spawn a projectile from the correct spot at any time. Very handy.
Layers and Groups
We've already discussed layers and groups a little in the collision detection section. But layers and groups are useful for more than just customizing and speeding up collision detection.
Objects can be assigned to layers, and you can specify that layers be sorted for rendering. In fact, the sort order for layers can be changed at will, and objects can be re-assigned to different layers at any time. Also, objects on the same layer can be assigned intra-layer z-ordering, and this ordering can be changed at any time. In this way, T2D gives you very fine-grained control over the z-ordering and rendering of your objects,
Unlike many 2D APIs / libraries, T2D doesn't limit you to using a small number of rendering layers. So, T2D makes it easy, for example, to set-up very nice-looking parallaxed backgrounds with lots and lots of layers.
And groups are a handy tool all around. You can use groups not only as a nice way to set-up collidable collections, but to help keep track of and manipulate logical classes of objects.
Object picking
There are many utilities in T2D that were put in to help developers handle common game problems. One thing that comes up a lot in games is object picking. Sometimes, you want players to be able to click on particular objects and select them. Or, if you were making a 2D RTS, you'd want to be able to let your players click-drag a box around units and select them all.
These are common object picking problems, and T2D has a nice picking interface. There are routines to pick objects that intersect with a point (mouse click), line, or area within the world. Picking is basically a collision detection test, and Torque 2D performs accurate picking against object collision polygons. This also means that it's easy to specify that a pick should only return objects in certain layers or groups. Again, if you were making an RTS, you might have a player's units in a group, so it'd be easy to pick just the player's units.
Also, it's possible to have custom pick functions. Tile maps, for example, have a special pick function which can return the logical tile(s) that intersect with a pick query.
This is just one example of the neat utilities T2D provides. Again, the goal throughout T2D's development has been "hey, let's make it easy for people to make 2D games!" So, we've tried to provide a bunch of stuff like this. Credit to Melv for caring so much about indie developers and wanting to put in the time and effort it takes to create all these functions, even though they're not the most fun things to implement.
World limits
The term "world limit" is a bit of a bad descriptor for what this particular system actually does. "World limits" in T2D are used to define the region in which a particular object can move around. Probably a better term would be "movement regions" or some such.
Regardless, world limits are a nice little feature of T2D. They allow you to set, on a per-object basis, the rectilinear area in which an object can exist in.
The world limit system is turned off by default-- T2D objects don't have world limits unless you explicitly turn them on for it-- because using world limits has a (small) performance penalty. Of course, performance was extremely important to us during T2D's design and development, so world limits were turned off by default.
When world limits are on though, you can do several neat things. Besides defining a valid area for an object to exist and move around in, you can also utilize various built-in world-limit collision-responses. By calling the setWorldLimit(...) method, you can specify what kind of response the object should have when it collides with a world limit.
The first world limit collision mode is "null", which tells T2D not to do anything special to the object when it collides with its world limit. Next is "rigid", which tells T2D to use the normal rigid-body dynamics system to handle world limit collision. Next is "bounce", which will bounce the object back from the world limit by perfectly reflecting the angle of incidence and maintaining the object's incoming speed. Next, "clamp" zeroes the object's perpendicular velocity component (colliding against a side wall of the world limit will result in the x component of the object's velocity being zeroed immediately). "Sticky" results in the object coming to rest against the world limit edge it hit. And "kill" results in the object being deleted once it reaches a world limit.
As with all collisions in T2D, world limit contacts are detected accurately against an object's collision poly.
Scenegraph
Torque 2D is a scenegraph-driven framework. (I'm assuming anyone who's read this far into the overview is already familiar with scenegraphs. If you're not, there are many good descriptions available online.)
We've already indirectly discussed many aspects of T2D's scenegraph in the sections on collision detection, physics, and layers here, and I won't re-tread. T2D's scenegraph uses a bin system to divide space and store locality information for scene objects. As per usual, this information is used to cull and optimize rendering, collision detection, etc. The scenegraph provides a great interface for initializing, querying and updating the scene, and you'll see many examples of how it can be used below.
The scenegraph is used to run the overall game simulation, and can be used to specify scenegraph-wide simulation parameters. For example, with one simple call to a scenegraph's setConstantForce(...) method, you can apply a global force to all objects in the scene which adhere to the default physics system. One obvious use for this functionality is to set-up (or modify) gravity for a scene. You can also pause the scene time at any moment, and resume it whenever you like.
The camera system in T2D is really flexible. You can set windows to cover a given area of the scene with a specific zoom level, and you can zoom, rotate, and pan the view any time. Also, you can give the view window a target position or area and have it move there smoothly over time from its current position. From there, you can undo / revert the view's move, returning to the old position. In fact, the last 64 view target calls are stored in T2D, so you can revert / undo up to 64 view moves. There are lots of cool possibilities with this system, and with just a little extension, you could define a nice easy interface for creating complex camera paths and scenes.
Man, so many other features. Check it out:
-Camera Mounts: the view window can be mounted to any object, and the mount can work identically to any other mount. So, you can make the camera follow an object (like the player avatar) with a rigid or force-based connection.
-Special effects: effects like camera shaking are easy. In fact, camera shakes are implemented specifically out of the box, and you can specify a shake period and intensity, as in Torque's own default camera. This is great for stuff like providing feedback when a player gets hit.
-Multiple scenes, multiple views! You can have multiple scenegraphs running at the same time, and multiple windows on any scenegraph. So, you can have multiple separate scenes, and/or multiple views of the same scene. (Nintendo DS, anyone? ;)
-Render filtering: You can dynamically filter what kinds of objects should be rendered at any given time.
-Scene saving a loading! The entire scene state can be serialized and saved at any time. Likewise, saved scene data can be loaded, and simulation can pick up right where it left off. Or, you can load a scene, pause time, and re-set any properties of the scene or its objects that you like.
Finally, the scenegraph is capable of detailed debug and performance reporting. You'll see in some forthcoming screenshots how nifty this system is. The collision poly, oriented-bounding box, and axis-aligned bounding box for all scene objects can be visualized at any time. And you can turn on automatic reports for all kinds of information, including: the total object count in the scene, the current FPS, the number of objects which are potentially going to be rendered (those which haven't been culled from the current view), the number of potential collisions, the number of current collision contact points, the percentage of objects currently colliding with each other, and the time it took to process physics for the current frame, amongst other information. Of course, you can also customize the debug and performance queries to provide whatever other information you'd like to have. These reporting tools are very helpful when it comes to debugging and optimizing a game!
The T2D scenegraph is really slick, and just having a hardware-accelerated, scenegraph-driven 2D engine is impressive in and of itself. Between this and the preceding sections on collision detection, physics, and layers, you should have a pretty good feel for what T2D's scenegraph is capable of. The scenegraph is basically the central system of T2D, which is saying a lot, considering all that T2D can do. So, it would take many pages to fully describe all of what the scenegraph can do and how it all works. Suffice it to say, the scenegraph + the base fxSceneObject2D class form the very core of Torque 2D, and the two provide an extremely powerful basis to build from, as I hope has been indicated by the discussion so far.
Torque integration
Torque 2D, of course, integrates with the overall Torque platform. Specifically, T2D takes advantage of Torque's cross-platform support, GUI system, scripting, and sound.
That's a lot of stuff to cover, but I assume folks here are familiar with these already, so I won't go into detail about them. But, one of T2D's biggest advantages overall is that it is built on all these great core Torque technologies. Just because it's built on Torque, T2D almost automatically becomes one of the only cross-platform 2D engines, and with Torque's system, it's set-up to go to even more platforms. It also gets to use a full-fledged scripting language and powerful console command processing capabilities. T2D gets a great GUI system for free (which is undergoing a major overhaul here at the office, btw, you'll see Ben and the rest of us talking about that more in the future), and the GUI editor to go along with it. Also, T2D gets to use Torque's audio functionality, so it has good sound support.
Just taking those things right there... even if T2D had just a normal rendering system, physics, etc, it'd still be one of the best engines around. Now, it's just insane. :)
Quick note: you've no doubt noticed that networking isn't part of the list of Torque technologies which T2D takes advantage of. That's true, for now. For the Early Adopter release, we've implemented a temporary networking solution. Essentially, you can use CommandToServer() and CommandToClient() calls to do many kinds of networked games. For example, T2D ships with an example networked multiplayer checkers game.
However, full-on, Torque-style networking isn't a part of T2D just yet. It will be very soon after the initial Early Adopter release though, and that'll be another outstanding system T2D gets to leverage for free.
The reason we didn't include full networking in this initial release is that we didn't want T2D objects to take on the overhead associated with deriving from Torque's GameBase class. For T2D, we'll be splitting out tick processing (similar to the work Pat has done recently) and implementing networking from there. That said, all of T2D's systems have been designed with networking in mind. Collision and physics are the stickiest things to get networked, and Melv and I were extremely mindful of the need to network those systems in the future when we were designing them.
Getting networking in won't be a difficult task, but we wanted to get T2D out into people's hands as soon as possible. It's already an outstanding solution for most games. Even people who have fast-paced multiplayer games in mind can pick up T2D now and begin learning to use it, knowing full-well that robust, highest-quality networking support as is standard with the Torque platform is on the way.
And with that, we've covered each of T2D's major core systems. Woo!
Of course, it's also important to note that you'll be able to get the full C++ source code for T2D (details on how you get it will be announced very soon). The code is all structured to be as clean to read and understand as possible, and one of the main design goals for the entire T2D architecture was to make it easy to customize and extend.
In addition, T2D ships with about 100 pages of detailed documentation (and that's not counting source-code comments). This documentation includes a tutorial in which a small game is built from the ground up, a detailed technical overview (a stripped-down and cleaned-up version of these .plans), and an object reference. So, you'll be covered when you start learning how to use and/or customize this sweet 2D engine. :)
Okay, thanks to everyone for reading. It was fun writing this .plan and I'm sorry it took me longer to get started on it than I hoped. But, I guess the upside there is that I was able to get lots done on T2D in the mean time! Hopefully some of you found this an interesting read.
Catch you all around, and watch this space for more T2D info in the very near future! Launch sequence starting in...
About the author
#2
Collision and physics: dynamic collision shapes aren't a stock part of T2D, but you could fake it. Gish uses a particle and spring system for Gish's character, and you could do something similar in T2D. Easiest way to do it would be to do a bit of custom work to add springs, but you might be able to set up a web of fource-mounted objects that behaved the way you wanted. Would depend on the exact feel you're going for. Also, Alex (from Chronic Logic) and I talked some at IGC, and IIRC he said he offered to contribute their spring stuff to Torque (may have been the beer talking though).
In any case, all kinds of cool physics-based gameplay is possible with T2D.
Btw, did anybody catch Alex's postmortem on Gish? Haven't been keeping up with the forums very well lately, so don't know if it was posted yet, but that is a good read.
Graphics: Zooming / rotating, etc looks great. If you want to be able to zoom way in on an object, you'll want to use a large graphic for it (either on a big texture or use the texture chunking system).
And yep, really easy to have multiple windows, windows-within-windows, split-screen!
GUI: I haven't looked at the flash resource much yet. But if it just renders swfs to a GUI control and it behaves well, it'd be possible to tie an invisible sceneobject in t2d to the external GUI control and set-up an interface to communicate/update between the two.
Client/server: full networking isn't in yet, so it definitely has a simpler set-up than Torque right now. When we do introduce full networking, we want to make sure that it's in a manner that's very, very easy for people to understand. So, we'll be doing some work to make it easier to understand from an outsider's perspective than the current TGE set-up.
Thanks for the questions. :)
02/10/2005 (7:03 pm)
Josh to answer your questions:Collision and physics: dynamic collision shapes aren't a stock part of T2D, but you could fake it. Gish uses a particle and spring system for Gish's character, and you could do something similar in T2D. Easiest way to do it would be to do a bit of custom work to add springs, but you might be able to set up a web of fource-mounted objects that behaved the way you wanted. Would depend on the exact feel you're going for. Also, Alex (from Chronic Logic) and I talked some at IGC, and IIRC he said he offered to contribute their spring stuff to Torque (may have been the beer talking though).
In any case, all kinds of cool physics-based gameplay is possible with T2D.
Btw, did anybody catch Alex's postmortem on Gish? Haven't been keeping up with the forums very well lately, so don't know if it was posted yet, but that is a good read.
Graphics: Zooming / rotating, etc looks great. If you want to be able to zoom way in on an object, you'll want to use a large graphic for it (either on a big texture or use the texture chunking system).
And yep, really easy to have multiple windows, windows-within-windows, split-screen!
GUI: I haven't looked at the flash resource much yet. But if it just renders swfs to a GUI control and it behaves well, it'd be possible to tie an invisible sceneobject in t2d to the external GUI control and set-up an interface to communicate/update between the two.
Client/server: full networking isn't in yet, so it definitely has a simpler set-up than Torque right now. When we do introduce full networking, we want to make sure that it's in a manner that's very, very easy for people to understand. So, we'll be doing some work to make it easier to understand from an outsider's perspective than the current TGE set-up.
Thanks for the questions. :)
#3
02/10/2005 (7:04 pm)
I was reading this josh and I couldn't read fast enough. I was begging for one of those matrix style downloads where you can absorb all the information at once! Still this is the .plan that keeps on giving. I've read a few of the breakouts and they keep going forever and ever withi never ending links to tocuments. For a guy like me who's addicted to information this is the .plan to end all .plans. So much good stuff here Josh I can't begin to comment, only that T2D has already taken over the world, the world just hasn't realized it yet :) 
#4
T2D is looking awesome. There is so much stuff I want to buy!!!
02/10/2005 (7:50 pm)
Ahh I was wondering where this plan went. I witnessed it puke from my side earlier today. I clicked and just got a blank screen then after a while the plan disappeared. T2D is looking awesome. There is so much stuff I want to buy!!!
#5
Thanks for putting this up. I'm gonna print it up now. All 12 pages of T2D goodness!
02/10/2005 (8:18 pm)
Josh, Thanks for putting this up. I'm gonna print it up now. All 12 pages of T2D goodness!
#6
Btw, these .plans are only so long because they'll be adapted for use in the documentation (after I scrub my fanboyism, the personal histories / remarks, clean up the language, etc)
02/10/2005 (9:09 pm)
Sweet Charlie. If you just want an idea of everything you can do, then you just need these 12 pages, yep. If you want all the nitty-gritty detail, then don't forget the 8 or 9 extra pages from the asides ;) (rigid body sims and T2D and collision detection schemes and T2D are the ones that contain details about T2D's underbelly)Btw, these .plans are only so long because they'll be adapted for use in the documentation (after I scrub my fanboyism, the personal histories / remarks, clean up the language, etc)
#7
02/10/2005 (11:02 pm)
Well, if you ever get burnt from programming, I think you should pick up some PR work. I'll add the other files to my print que now!
#8
Ok, I admit I didn't bring any casual reading material with me on this trip, but I only read through the Physics section, but I'll come back to this one.
I can't stop talking T2D ... I'm at Desktop Summit and we're finding such a felt hunger for a place that normal humans can get started making games - although I might not point them at Josh's .plans as he kinda does geek out a bit even for the linux types. Everyone asks how old do you have to be to use T2D (for sons/daughters, grandsons and nephews). The second most common question (especially for anyone familiar with TGE) is can you have 2D games work inside a 3D game in Torque - it just seems the imagination is sparked by the fact we're using so much common tech that the idea of combining play mechanics, high quality mini games and retro games within games a natural path for most peoples minds to go.
When I mention our built in physics model I always get does it have, "the standard bells and whistles"?
I think I'll have to push Josh to create an english to geek translation as a glossary to his docs - for those who don't enjoy a fluentcy with game geek speak.
Melv/Josh I have to say it is an inspiration to work with two people who are as passionate and driven to create such a high quality technology, it almost makes me want to learn to make the games I dream up... if I just wasn't playing this great build and indie game industry RPG/RTS game.
My Tag for T2D: "The game industries closest held secret is out, the 'most fun game is making games' - T2D Make it fun... Make it fast."
02/10/2005 (11:14 pm)
I really think Jess's picture should be on the credits screen she really was an invaluable part of the team. Ok, I admit I didn't bring any casual reading material with me on this trip, but I only read through the Physics section, but I'll come back to this one.
I can't stop talking T2D ... I'm at Desktop Summit and we're finding such a felt hunger for a place that normal humans can get started making games - although I might not point them at Josh's .plans as he kinda does geek out a bit even for the linux types. Everyone asks how old do you have to be to use T2D (for sons/daughters, grandsons and nephews). The second most common question (especially for anyone familiar with TGE) is can you have 2D games work inside a 3D game in Torque - it just seems the imagination is sparked by the fact we're using so much common tech that the idea of combining play mechanics, high quality mini games and retro games within games a natural path for most peoples minds to go.
When I mention our built in physics model I always get does it have, "the standard bells and whistles"?
Quote: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.
I think I'll have to push Josh to create an english to geek translation as a glossary to his docs - for those who don't enjoy a fluentcy with game geek speak.
Melv/Josh I have to say it is an inspiration to work with two people who are as passionate and driven to create such a high quality technology, it almost makes me want to learn to make the games I dream up... if I just wasn't playing this great build and indie game industry RPG/RTS game.
My Tag for T2D: "The game industries closest held secret is out, the 'most fun game is making games' - T2D Make it fun... Make it fast."
#9
Unlike other systems I've developed, T2D has been a pure pleasure to write. Seeing system after system start to work in close-harmony is such a buzz. Sure, there's been moments when I've left my keyboard before I smash it into little pieces but I've always come back, typically 10 mins later, and solved the issue quickly. To send stuff to the GG guys and see their reactions is a personal pleasure. I wish we had some videos of the T2D stuff being presented at these shows, I'm stuck here in my computer room and thus far, over almost 9 months of development, I've not seen T2D being shown to a single person!! How frustrating is that! The feedback from Jay and others is that people are very impressed.
Can't wait for T2D be out there and see images of simple games/demos being posted. I'm confident that they'll be out within a fews weeks of release; yes it's that easy to get lots of cool stuff up and running so why not.
I don't think any of us fully realise the potential of T2D. There's thousands of people out there who'll do stuff with it that'll simply knock our socks off and I just can't wait to see what talented people will do with it.........
- Melv.
02/11/2005 (12:50 am)
This sounds great .. where do I sign-up? ;)Unlike other systems I've developed, T2D has been a pure pleasure to write. Seeing system after system start to work in close-harmony is such a buzz. Sure, there's been moments when I've left my keyboard before I smash it into little pieces but I've always come back, typically 10 mins later, and solved the issue quickly. To send stuff to the GG guys and see their reactions is a personal pleasure. I wish we had some videos of the T2D stuff being presented at these shows, I'm stuck here in my computer room and thus far, over almost 9 months of development, I've not seen T2D being shown to a single person!! How frustrating is that! The feedback from Jay and others is that people are very impressed.
Can't wait for T2D be out there and see images of simple games/demos being posted. I'm confident that they'll be out within a fews weeks of release; yes it's that easy to get lots of cool stuff up and running so why not.
I don't think any of us fully realise the potential of T2D. There's thousands of people out there who'll do stuff with it that'll simply knock our socks off and I just can't wait to see what talented people will do with it.........
- Melv.
#10
If I have ever had any one big complaint about technology it is that it always has to be bigger and better. There was actually a time when a little bit of money, a good deal of determination and talent and a big desire could get you where you wanted to go.
Now, with over expensive software, cinematic and all the other eye candy, the market has ended up like so many others.
It is great for me to see that someone has taken the time to go back and make a once great thing even better.
I'm all about pushing the envelope. But not when it means giving up on the things that created that envelope to begin with. Now it's time to come back home to the root of it all and see what we as Indies can do.
I have no doubt that with this technology the little people can rise again.
That
02/11/2005 (1:08 am)
Melv and GG,If I have ever had any one big complaint about technology it is that it always has to be bigger and better. There was actually a time when a little bit of money, a good deal of determination and talent and a big desire could get you where you wanted to go.
Now, with over expensive software, cinematic and all the other eye candy, the market has ended up like so many others.
It is great for me to see that someone has taken the time to go back and make a once great thing even better.
I'm all about pushing the envelope. But not when it means giving up on the things that created that envelope to begin with. Now it's time to come back home to the root of it all and see what we as Indies can do.
I have no doubt that with this technology the little people can rise again.
That
#11
I've read various off-GG posts where people bring into question the "bulk" of T2D as it sits squarely on-top of the T3D engine and they state that it surely must be slow because of all this "bulk". Everyone is entitled to their opinion but slow, T2D is not! T2D consistently hits the maximum FPS that can currently be achieved in T3D (yes, there's a limit) and things are only going to get more optimised as time goes on. It's easy to talk about "bulk" and forget the powerful scripting language, completely cross-platform support (not limited to Win32, Mac, Linux), audio, GUI system etc. Josh hints at other work that's going on currently that will completely render this idea null and void.
Also, the basic script framework needed to get T2D up and running is tiny. You get a canvas and well, that's all you need. Sure, you wouldn't have the GUI editor but you would be able to create T2D windows, scenes and objects and have all the physics up and running no problem.
Of course I'm going to say this but for your money you do get alot of power at your fingertips. I would certainly buy it. You may not be interested in developing 2D games at all and just want to use T2D to suppliment T3D and we've ensured that you can do that, right out of the box.
It was mentioned above about using stuff like the new flash-render control alongside T2D. One thing to mention is that developing a custom 2D object in T2D is actually easier than developing a T3D GUI control, as you'd expect. The great thing about doing it this way is that T2D controls all the rendering and the (fxFlash2D) object inherits all the capabilities without you having to write any code for it to do so. You could have a flash control that the player can drag around and has rigid-body dynamics!!! Anything that's been done in a T3D GUI control can be moved over to T2D in a very short time period.
Once you get the idea of imageMaps and the scenewindow, you'll be generating stuff really quickly.
If anyone wants to ask any technical questions regarding T2D then please email me (I'll copy Josh) and I'd be happy to answer your questions. Please just don't ask me marketing questions!!!
- Melv
02/11/2005 (1:33 am)
@Charlie: Yes, we should not forget that we're here because of the people who developed 2D games which eventually became 3D games. I just hope that people see that what we've got here is a different animal. Prior to going into crunch-mode on T2D, I downloaded and played with lots of 2D 'engines', most of them libraries that offer low-level blitting capabilities and some basic encapsulation. I also looked at the gamemaker-style apps and some were quite impressive indeed and some not so.I've read various off-GG posts where people bring into question the "bulk" of T2D as it sits squarely on-top of the T3D engine and they state that it surely must be slow because of all this "bulk". Everyone is entitled to their opinion but slow, T2D is not! T2D consistently hits the maximum FPS that can currently be achieved in T3D (yes, there's a limit) and things are only going to get more optimised as time goes on. It's easy to talk about "bulk" and forget the powerful scripting language, completely cross-platform support (not limited to Win32, Mac, Linux), audio, GUI system etc. Josh hints at other work that's going on currently that will completely render this idea null and void.
Also, the basic script framework needed to get T2D up and running is tiny. You get a canvas and well, that's all you need. Sure, you wouldn't have the GUI editor but you would be able to create T2D windows, scenes and objects and have all the physics up and running no problem.
Of course I'm going to say this but for your money you do get alot of power at your fingertips. I would certainly buy it. You may not be interested in developing 2D games at all and just want to use T2D to suppliment T3D and we've ensured that you can do that, right out of the box.
It was mentioned above about using stuff like the new flash-render control alongside T2D. One thing to mention is that developing a custom 2D object in T2D is actually easier than developing a T3D GUI control, as you'd expect. The great thing about doing it this way is that T2D controls all the rendering and the (fxFlash2D) object inherits all the capabilities without you having to write any code for it to do so. You could have a flash control that the player can drag around and has rigid-body dynamics!!! Anything that's been done in a T3D GUI control can be moved over to T2D in a very short time period.
Once you get the idea of imageMaps and the scenewindow, you'll be generating stuff really quickly.
If anyone wants to ask any technical questions regarding T2D then please email me (I'll copy Josh) and I'd be happy to answer your questions. Please just don't ask me marketing questions!!!
- Melv
#12
02/11/2005 (1:34 am)
Quote:"The game industries closest held secret is out, the 'most fun game is making games'"Says us. And a good marketing pitch to sell something to us, but it's about as true as the Art Institute game design program's marketing pitch, "Actually, it *IS* all fun and games." I met this guy once, he was nuts for video games, had every console current and historical, spent every dime he had on games, bought a big screen TV just to play games, had stacks of video game magazines, had 4 X-boxes on a wireless network so that 16 people could play Halo at once on LAN parties at his house, worked at a video game store, was an absolute fanatic about video games. So I asked him, the next logical step is to make your own, right? He looked at me like I was nuts. Zero interest. Nope, his "big dream" was to own his own video game store. Similarly, I have a friend who's a professional ballet dancer. So I asked her, the next logical step is to one day choreograph, and make your own ballets, right? Again with the "you're crazy" look, she had zero interest in that, only dancing. Some people play, others create... some dance, others design... don't mean to split hairs here, but I thought I had a relevant and interesting comment. Do continue along the T2D trajectory :)
#13
Hello M.M I'll just pretend I read through all that ;o)
Your trainee programmer (or was that the boss sitting at the keyboard?), is looking very healthy and happy. You must treat your employees really well.
So release is imminent (damn now my spelling has gone south!). My 2D project is on hold until I can get my hands on T2D. I still want a pseudo 3D perspective with collision (think GBA FF tactics style of level design) so er hurry up will you....come on you have an extra pair of hands now :)
02/11/2005 (1:49 am)
@MelvHello M.M I'll just pretend I read through all that ;o)
Your trainee programmer (or was that the boss sitting at the keyboard?), is looking very healthy and happy. You must treat your employees really well.
So release is imminent (damn now my spelling has gone south!). My 2D project is on hold until I can get my hands on T2D. I still want a pseudo 3D perspective with collision (think GBA FF tactics style of level design) so er hurry up will you....come on you have an extra pair of hands now :)
#14
You mentioned perhaps doing a more detailed overview of RBD if anyone had interest in seeing it. I definitely do. You linked to Baraff's rb tutorial from siggr96 in the references. A writeup like yours, with detail similar to Baraff's tutorial, from a game programmer's perspective and more up to date than Baraff's would be very popular. Something just like what you have now but going into just enough detail to help people implement the algorithms on their own. Such works take much effort, but it would be helpful to anyone interested in game physics. If you'd like, I could help during the summer, as I know my professors would be happy to see a paper like this.
I will be buying Torque and Torque2D when its released. I've lurked here at GG for a long time, as you can see in my profile, and respect what the people in this community are trying to do. Time to get in on the fun, compliments to you and Melv and the rest of the team on Torque2D.
02/11/2005 (6:02 am)
Josh- I'm studying for a Masters in computer science, specializing in numerical methods and dynamics. Your linked overview of real-time rigid body dynamics is one of the best summaries I've seen. It takes real knowledge to do comprehensive but understandable overviews and as Feynman said, you don't know a subject unless you can explain it simply to others. Would you mind if I link to that page or quote parts of it (with credit)? You mentioned perhaps doing a more detailed overview of RBD if anyone had interest in seeing it. I definitely do. You linked to Baraff's rb tutorial from siggr96 in the references. A writeup like yours, with detail similar to Baraff's tutorial, from a game programmer's perspective and more up to date than Baraff's would be very popular. Something just like what you have now but going into just enough detail to help people implement the algorithms on their own. Such works take much effort, but it would be helpful to anyone interested in game physics. If you'd like, I could help during the summer, as I know my professors would be happy to see a paper like this.
I will be buying Torque and Torque2D when its released. I've lurked here at GG for a long time, as you can see in my profile, and respect what the people in this community are trying to do. Time to get in on the fun, compliments to you and Melv and the rest of the team on Torque2D.
#15
02/11/2005 (10:54 am)
@Steve - Wow! a legacy lurker, makes a marketing guy wonder how many lurkers have been around since March 2001 and haven't ever posted... Welcome to the land of posting - next we'll have you blogging.
#16
Well, you never know, it might work.
- Melv.
02/11/2005 (11:04 am)
Okay, I know it's a crude method but if you've got nothing to say here but you've actually read this and T2D has you even slightly excited then please just post "yo!".Well, you never know, it might work.
- Melv.
#17
To say T2D has got me slightly excited would be a massive understatement! I have played around with making games since college and have always hit stumbling blocks that seem to get in the way of the creative process. I have spent so much time trying to put together solid game engines in either DirectX, OpenGL and SDL that would have been preferably spent on making actual games!
I must admit that one of the main reasons that I finally bought a TGE licence is so that I could get my hands on an EA version of T2D as soon as possible! I have been devouring every scrap of info I can find on this engine and believe that the potential of it is quite simply outstanding.
Much kudos to Melv, Josh and all the guys that have helped to produce what could be a major stumbling block to passing my Computing degree later this summer!
All that remains now is to perhaps hope for a hint of the release date? ;-)
- Dave
02/11/2005 (11:25 am)
Hi guys,To say T2D has got me slightly excited would be a massive understatement! I have played around with making games since college and have always hit stumbling blocks that seem to get in the way of the creative process. I have spent so much time trying to put together solid game engines in either DirectX, OpenGL and SDL that would have been preferably spent on making actual games!
I must admit that one of the main reasons that I finally bought a TGE licence is so that I could get my hands on an EA version of T2D as soon as possible! I have been devouring every scrap of info I can find on this engine and believe that the potential of it is quite simply outstanding.
Much kudos to Melv, Josh and all the guys that have helped to produce what could be a major stumbling block to passing my Computing degree later this summer!
All that remains now is to perhaps hope for a hint of the release date? ;-)
- Dave
#18
I WANT T2D NOW!
02/11/2005 (11:53 am)
I'm just amazed that I saw a reference to pedagogy in there! I'd been waiting to see this post all day since I saw the broken blank post earlier yesterday!I WANT T2D NOW!
#19
02/11/2005 (12:07 pm)
uhh...YO BABY!
#20
Besides, I grew up when 2d was king, and it'd be fun to try to out-do Miyamoto (emphasis on TRY)
02/11/2005 (12:15 pm)
I to want T2D now :) I've got a bag full of ideas that I've never used that would be perfect for this new engine, and after watching the video showing the particle system, I'm sure there are others being cooked up somewhere in my subconsious.Besides, I grew up when 2d was king, and it'd be fun to try to out-do Miyamoto (emphasis on TRY)
Torque Owner Joshua Dallman
Default Studio Name
love the T2D keys on that keyboard :)
collision question, and this may be so basic you're taking it for granted: dynamic collision shapes? ie Gish tar blob.
physics: this is the part of T2D I'm most excited about. Gish showed me just how "to the next level" physics can take otherwise simple NES-like games. amazing possibilities here, can't WAIT to see what indies come up with.
scenegraph: for rotating and zooming, how does that look with raster graphics? can you do multiple windows easily, like a window-within-a-window (security cam) or split-screen multiplayer?
torque integration: gui integration: does this mean with the new flash resource, we can use flash graphics and animation in T2D guis? how about flash graphics as in-game sprites/etc.? is T2D highly seperated in terms of client/server code the way TGE is (in terms of how you program your game, even if it's single player)?
very excited about this stuff... a T2D game may very well be my 3rd title.