by date
Plan for Josh Williams
Plan for Josh Williams
| Name: | Josh Williams |  |
|---|---|---|
| Date Posted: | Feb 11, 2005 | |
| Rating: |  4.7 out of 5 | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: |  or Subscribe with  . | |
| Profile Page: | View profile page for Josh Williams |
Blog post
Torque 2D informal technical overview .plans, pt 2. All the nitty-gritty on T2D's core systems.
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...
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.
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:
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.
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.
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...
Recent Blog Posts
| List: | 09/18/07 - News is out! 08/18/06 - Torque X-- why we're doing it. 02/26/05 - Plan for Josh Williams 02/22/05 - Plan for Josh Williams 02/11/05 - Plan for Josh Williams 02/01/05 - Plan for Josh Williams 01/12/05 - Plan for Josh Williams 12/20/04 - Plan for Josh Williams |
|---|
Submit your own resources!| Joshua Dallman (Feb 11, 2005 at 02:05 GMT) |
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.
Edited on Feb 11, 2005 02:26 GMT
| Josh Williams (Feb 11, 2005 at 03:03 GMT) |
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. :)
Edited on Feb 11, 2005 06:07 GMT
| Dan MacDonald (Feb 11, 2005 at 03:04 GMT) |
| Michael Cozzolino (Feb 11, 2005 at 03:50 GMT) |
T2D is looking awesome. There is so much stuff I want to buy!!!
| Charlie Malbaurn (Feb 11, 2005 at 04:18 GMT) |
Thanks for putting this up. I'm gonna print it up now. All 12 pages of T2D goodness!
| Josh Williams (Feb 11, 2005 at 05:09 GMT) |
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)
Edited on Feb 11, 2005 05:15 GMT
| Charlie Malbaurn (Feb 11, 2005 at 07:02 GMT) |
| Jay Moore (Feb 11, 2005 at 07:14 GMT) Resource Rating: 5 |
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."
| Melv May (Feb 11, 2005 at 08:50 GMT) |
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.
| Charlie Malbaurn (Feb 11, 2005 at 09:08 GMT) |
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
| Melv May (Feb 11, 2005 at 09:33 GMT) |
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
| Joshua Dallman (Feb 11, 2005 at 09:34 GMT) |
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 :)
| Peter Dwyer (Feb 11, 2005 at 09:49 GMT) |
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 :)
| Steve Oner (Feb 11, 2005 at 14:02 GMT) |
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.
Edited on Feb 11, 2005 14:46 GMT
| Jay Moore (Feb 11, 2005 at 18:54 GMT) Resource Rating: 5 |
| Melv May (Feb 11, 2005 at 19:04 GMT) |
Well, you never know, it might work.
- Melv.
| David Roberts (Feb 11, 2005 at 19:25 GMT) Resource Rating: 5 |
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
| David Blake (Feb 11, 2005 at 19:53 GMT) Resource Rating: 5 |
I WANT T2D NOW!
| Stephen Zepp (Feb 11, 2005 at 20:07 GMT) Resource Rating: 5 |
| Joshua Spencer (Feb 11, 2005 at 20:15 GMT) |
Besides, I grew up when 2d was king, and it'd be fun to try to out-do Miyamoto (emphasis on TRY)
Edited on Feb 11, 2005 20:20 GMT
| Matthew Langley (Feb 11, 2005 at 21:07 GMT) Resource Rating: 5 |
{
echo("YO!");
}
I'm far too hyped up about T2D... I simply can't wait lol... you got us all on the edge of our seats...
btw a wonderful read Josh...
| Edward F. Maurina III (Feb 11, 2005 at 21:34 GMT) Resource Rating: 5 |
Quite an impressive effort to date. I am very much looking forward to adding this to my kit. Congrats Melv and Josh. Keep up the good work.
EdM|EGTGE
Edited on Feb 11, 2005 21:36 GMT
| Mark McCoy (Feb 12, 2005 at 00:09 GMT) |
| J. Alan Atherton (Feb 12, 2005 at 00:38 GMT) |
| Josh Williams (Feb 12, 2005 at 00:39 GMT) |
| Phil Shenk (Feb 12, 2005 at 07:04 GMT) |
| Darryl Bartlett (Feb 12, 2005 at 09:28 GMT) |
Cheers and good luck.
| Josh Williams (Feb 12, 2005 at 10:47 GMT) |
Steve, woops, didn't mean to ignore your post! Welcome out of the land of lurkers. The big ball of fire in the sky is called the "sun", it won't hurt you unless you look directly at it. Thanks for the kind words about the rigid body write-up. I actually wasn't very happy with it... wanted to go into *lots* more detail, but it wasn't appropriate for this .plan. Personally, I'd love to do a more detailed write-up like you suggest. And it's great to hear that you thought this base would be so good to build from. Thanks. Realistically, pains me to say it, but I won't have time to do anything like this soon. Perhaps in the summer, and I appreciate your offer to help there... I'll be in touch if there's time! :)
And great to hear that you're interested in T2D and will be picking that and Torque up... look forward to seeing some cool stuff from ya. Catch you around the site, I hope.
| Gabor Forrai (Feb 12, 2005 at 16:24 GMT) |
| nibbuls (Feb 12, 2005 at 17:36 GMT) Resource Rating: 5 |
| Jason McIntosh (Feb 12, 2005 at 21:55 GMT) |
| Matthew Langley (Feb 13, 2005 at 05:45 GMT) Resource Rating: 5 |
| Melv May (Feb 13, 2005 at 09:54 GMT) |
Hmmmm, T2D merchandise! T2D T-Shirts, mugs and pens ... "I do it retro", "T2D for me", "I live in a reduced dimension", "T2D swallowed the red pill" etc...
- Melv.
| Paul Dana (Feb 13, 2005 at 15:57 GMT) |
| Jay Moore (Feb 13, 2005 at 19:30 GMT) Resource Rating: 5 |
@Paul - I think the poundage record for .plans was held by Davis in the past, but with all of Josh's linked in content I don't think we've seen a heavier text based .plan (although I think he could have used more pictures for us marketing types).
| Martin "Founder" Hoover (Feb 13, 2005 at 21:30 GMT) |
| Matt Harpold (Feb 13, 2005 at 21:36 GMT) |
(Although Josh's plan is still good to reread a few more times)
| Adam (Feb 14, 2005 at 00:32 GMT) |
| Manuel F. Lara (Feb 14, 2005 at 05:25 GMT) Resource Rating: 5 |
| Corey Martin (Feb 14, 2005 at 07:22 GMT) Resource Rating: 5 |
| Steve Oner (Feb 14, 2005 at 07:35 GMT) |
Josh- I'm sure you are busy and writing an academic paper is not at the top of your priority list. If you have more time and are willing to consider it in a few months, please get in touch.
I have questions on Torque2D which may be hard to answer:
Will Torque2D's physics be network ready? You mentioned that the collision system has been carefully prepared and that it's not 100% ready, but a big step toward network compatibility has been taken. Has the physics system been similarly prepared? Very difficult issues involved here so I'll be intrigued to hear your response.
Are there plans to add articulated body support?
Are there plans to move these physics to Torque itself?
I will not be upset if you aren't ready to provide detailed answers yet but I'd like to hear whatever you can say at this point. Thank you.
| Melv May (Feb 14, 2005 at 08:23 GMT) |
Both the collision system and the physics were designed with networking in mind, in-fact networking was one of the primary design goals. At this point, I really can't provide more than what Josh said although he may want to add a little more?
Articulated Body Support; I'm quite glad you brought this subject up. At the moment, T2D has the concept of mounting and there are lots of options for this system and whilst this doesn't strictly provide for constrained joints, it has been used to articulate body-parts in various demos. For instance, it's possible to add the head, arms and legs to your players body and move them independantly whilsts at the same time, have them mounted correct onto the body. You can move the body around, rotate it, flip it and all the body parts move with it. These mounts don't have constraints but it's actually a relatively easy matter to do so. To answer your question fully; joints have been discussed (and I'm not talking about the smoking variety here), and it'll definately be something that we'll look into. The consideration here will be how useful will they be for 90% of the games? I'm not making judgement here, it's just that we have to carefully consider performance as it's a game-engine not a simulation for simulations sake. With that said, I really do like the idea of being able to composite characters of constrained joints and so it will definately be a topic of conversation post EA1 release.
The idea of joints always makes me think that somebody should do a game similar to South-Park, perhaps "Flat-World", that has that characteristic flat animation style. :)
I can't speak as to the development plans for T3D and the physics unfortunately. Either Ben, Josh or perhaps Tim could answer that one. I will say that it wouldn't be a case of moving T2D physics into T3D. The algorithms, shortcuts, data-structures are noticably different (read that more complex) in 3D, as are the problems.
That's about the best info I can provide at this point. As Josh mentions, we've still got plenty of work to do on both the networking and the physics (hey, this is EA after all) and we're hoping to provide more and more power enabling much more varied gameplay dynamics, especially where the physics is concerned.
It's already proving to be an exciting year and I just can't wait to get this thing out the door and move onto phase #2.
As always, please don't hesitate sending me an email if you've got any non-marketting questions!
Thanks for all the YOs guys, keep them coming!
- Melv.
Edited on Feb 14, 2005 08:24 GMT
| Josh Williams (Feb 14, 2005 at 10:12 GMT) |
Steve, good questions! First, on getting these physics in TGE, it's not on any immediate task list. That's all I'll say for now. :) Also, just so you know Torque already has some cool physics functionality, as you'll see when you pick up a license. But, there is always cool stuff brewing here...
On articulated bodies, it would be very cool, and it'd be great fun to work on. Given the number of 2D games that might have use for them though, it's not a priority right now. Much more generally useful things to work for the time being, as I'm sure you can understand. This would be something I'd look for either as a community-generated resource, or maybe something Melv or I might do in spare time (ha.....)
On networked physics... getting accurate networked collision detection is the first major step for networked physics. From there, accurate collisions + client-side prediction and a deterministic physics system forms the bulk of what you need. We have done some work to ensure that these will be easy moves to make. But, there is still obviously a lot of work to get a really nice networked physics sim. So, all we'll fess up to for now is that, yes, some good prep work has been done, and this was important in our design decisions. We'll talk more about all this when we focus on full networking integration.
Good q's and thanks again for the compliment.
| Melv May (Feb 14, 2005 at 10:33 GMT) |
- Melv.
| David Blake (Feb 14, 2005 at 16:41 GMT) Resource Rating: 5 |
| Pete111 (Feb 14, 2005 at 20:33 GMT) |
| Josh Williams (Feb 14, 2005 at 20:40 GMT) |
Edited on Feb 14, 2005 23:32 GMT
| Pete111 (Feb 14, 2005 at 21:38 GMT) |
| Matt Harpold (Feb 15, 2005 at 00:42 GMT) |
| Charlie Malbaurn (Feb 15, 2005 at 01:06 GMT) |
| Melv May (Feb 15, 2005 at 08:13 GMT) |
@Charlie: ?
| Pete111 (Feb 15, 2005 at 17:43 GMT) |
Sorry if this has been touched on but I'm guessing we'll have joystick support? Also, what about pathfinding? Will the tile mechanism allow for fairly easy access if I wanted to say, implement a depth-first or A* algorithm? Again, sorry if this has been previously noted.
| Melv May (Feb 15, 2005 at 18:26 GMT) |
You've got full access to the tile-map database, it's not hidden behind some complex interface, both in the scripts and C++, there are well documented accessor functions to get to all the information you need to add any routines for your game. At the moment, you'll just have to take it on faith that it's real easy.
A nice thing that I've tried to maintain is that the script-functions have indentical names to the C++ class member function names so if you play with the scripts and call say "loadTileLayer()", you can go into the fxTileLayer2D class and call "bool loadTileLayer( const char* filename );".
The interface between scripts and C++ just got a lot easier. :)
- Melv.
| Jason McIntosh (Feb 15, 2005 at 20:03 GMT) |
| Melv May (Feb 15, 2005 at 20:20 GMT) |
I've received nearly a hundred or so emails in the last 3 weeks asking me similar questions. Probably 90% of the things asked for would take an evening, if that, to add. Triggers are definately in that class. This doesn't make the question invalid though, certainly not.
Without any changes and in script-alone, you could easily use an fxSceneObject2D to tell you when an object is in a specific 2D region though. The script-code would be around 7-lines. I know that all sorts of resources such as this will be made really quickly as T2D is so god damn easy to extend! Also, as Josh mentioned in his technical brief, we have the concept of "world-limits" which can be used to simply tell you when an object goes outside of them or have them control the object in several ways, including rigid-body dynamics. Oh man, I could talk all night about this and as Josh proved above, so could he! ;)
We've got a whole bucket load of stuff that'll be going into T2D shortly after release though. What we need to do now is release it, get lots of feedback from nice folks like you and see where we go from there. In the meantime, we'll be adding networking, more robust predictive physics, blah blah blah.
The communities reaction to T2D is going to be very important in its design.
- Melv.
Edited on Feb 15, 2005 20:21 GMT
| Charlie Malbaurn (Feb 16, 2005 at 10:23 GMT) |
I'm sorry about that. I must have left this window open and when my daugther got on, felt she needed to post her name.
She's a quick one for 4 1/2. Considering that she can beat the 24th level(I think.The yellow one with the big circle in it) in the demo of marble blast.
I'll have to be more careful
Edited on Feb 16, 2005 10:26 GMT
| Melv May (Feb 16, 2005 at 10:35 GMT) |
- Melv.
| Manuel F. Lara (Feb 16, 2005 at 15:21 GMT) Resource Rating: 5 |
I'm dying to do a Metal Slug - like game, do you think guys that with the scrolling and big-image-partitioning stuff it would be "easy"? What about pixel-perfect collision between the static geometry and the characters? Is it possible to edit the bitmaps at run-time (thinking about deformable terrain :) )
| Melv May (Feb 16, 2005 at 15:27 GMT) |
For large-scale image stuff, you'd definately want to use tile-maps and now that we've got a cool editor, you can do just that, especially as it's a realtime editor e.g. WYSIWYG.
We don't use pixel-perfect collision detection, we use swept polygon detection. Swept, pixel-perfect collision-detection and physics just isn't going to happen. ;)
- Melv.
| Manuel F. Lara (Feb 16, 2005 at 19:36 GMT) Resource Rating: 5 |
| Melv May (Feb 16, 2005 at 20:11 GMT) |
T2D doesn't force you into doing things a specific way. There's always an alternative, including extending any of the stock T2D objects and adding your own rendering, collisions, physics, whatever.
T2D has "simple" physics with "basic" math if you need it. It's also got "complex" physics with "complex" math but either way, it only takes a call or two to access both. You can set the linear velocity of an object and it moves. No need to play with impulses or have collision detection feeding into the physics system. It's all off by default. No impact, nada.
BTW: The physics in T2D is faked, it ain't real. ;)
Certain game types, Worms being a good example, that evolve around a single piece of tech like the deformable landscape will always involve custom stuff. There's just no way to cast a net big enough to cover these game types generically although we're holding at own at the moment, even at EA1.
This cool?
- Melv.
Edited on Feb 16, 2005 20:15 GMT
| Manuel F. Lara (Feb 16, 2005 at 20:31 GMT) Resource Rating: 5 |
| Melv May (Feb 16, 2005 at 20:38 GMT) |
- Melv.
| Manuel F. Lara (Feb 16, 2005 at 21:31 GMT) Resource Rating: 5 |
Then tell us once and for all when we'll be able to enjoy playing with T2D!! just kidding..
No really, tell us.
| Melv May (Feb 16, 2005 at 22:17 GMT) |
You won't believe me but it's harder for me at this point than it is for you. I'm itching to get T2D out but we're just clearing up the final details before we announce. Really want to release ASAP. I'm working every evening to finish these details and Josh is working until 4-5am most days, seriously! I know you could use it now as it is but there's a certain standard to the package that has to be met, after all it is a product and people expect value for money and boy are they going to get it and I'm sure you will feel the same very soon.
- Melv.
Edited on Feb 17, 2005 17:11 GMT
| Drew -Gaiiden- Sikora (Feb 17, 2005 at 06:56 GMT) |
Man, I was struck speechless when I received the press release for the DesktopSummit article (over at GameDev.net). Then my breath was taken away when I came here and read almost entirely (skimmed most of the asides in this .plan, but that's all I skimmed) through both of Josh's .plans. I'm still not quite fully recovered!!!!
You guys got yourselves an awesome product here. Melv, Josh, I bow before you. My company has been in deadlock since I stopped working on my own 2D engine, since I couldn't find a suitable (2D) engine out there to meet my needs. Now with T2D we can finally make our games! You guys are a godsend.
Being a GG lurker myself (tho not quite as long as Steve), it's great to finally be able to become active in the community and support a product worth uhm... supporting!! Yea! :)
I knew my faith was properly placed, which is why I've worn my GG hat everyday since I swiped it back in '03 at the GDC (Dunno if you remember that, Jeff :P)
What else can I say? GG Rox0rs!
(Looking forward to seeing you all at GDC too btw!)
Edited on Feb 17, 2005 07:26 GMT
| Alan "DaFalcon" Carr (Feb 17, 2005 at 08:44 GMT) |
I've been lurking nearly as long as Steve [with a few comments here and there now and then], and I've read through both .plans and all the asides and found it all extremely interesting. My programming background is virtually nil (BASIC in elementary school, Hypercard in Junior High, HTML and some VB in High School, a couple semesters of Pascal and C in college before changing focus) but most of this still made a great deal of sense to me. I've actually read it from a game design angle as someone who is an extreme believer in the potential for amazing 2D games with today's technology, and this is really exciting stuff (as you know, of course)!!
I keep picturing the project I've recently been involved in (Midnight Mansion, a 2D game for the Mac) built with an engine like this. And yes, I'm definitely drooling!
| Matthew Langley (Feb 17, 2005 at 17:07 GMT) Resource Rating: 5 |
Quote:
You won't believe me but it's harder for me at this point then it is for you.
lol I bet... having the thing we all want and only being able to tell us more about it (which just makes us want it more) but not being able to give it to us or give us a definate date/time... lol probably close to torture ehh...
definately appreciate all the work you guys have put into this. Will be worth the wait once we get our hands on it.
| Melv May (Feb 17, 2005 at 17:13 GMT) |
- Melv.
| Pete111 (Feb 17, 2005 at 17:47 GMT) |
| Melv May (Feb 17, 2005 at 18:05 GMT) |
T2D doesn't currently have the ability to paint individual pixels as it's not widely used for making games, even retro ones. It would be relatively easy to generate an object that would allow you to do these basic paint operations on it, probably take a couple of hours to setup.
- Melv.
Edited on Feb 17, 2005 18:33 GMT
| Matthew Langley (Feb 17, 2005 at 18:13 GMT) Resource Rating: 5 |
| Pete111 (Feb 17, 2005 at 22:09 GMT) |
| Melv May (Feb 17, 2005 at 22:48 GMT) |
- Melv.
| David Blake (Feb 17, 2005 at 23:18 GMT) Resource Rating: 5 |
Of course, running a model through a DSQ animation and capturing frames from the camera in the ShowTool Pro could be an excellent 2D gaming tool as well. Kind of like a Poser add-on, but using TGE.
EDIT: A few too many words for the sentence to make ANY sense. Plus another little idea I had on content creation combining T2D with T3D.
Edited on Feb 17, 2005 23:21 GMT
| Matthew Langley (Feb 18, 2005 at 20:43 GMT) Resource Rating: 5 |
@David: That would be a very usefull applicaiton of it...
or even texture editing, bitmap (for guis) editing... would be great for rpg games, allowing people to create truly customizable armor and items with logos, etc on them, later when multiplayer gets implemented this could create some interesting things... lol ok maybe its more of a viable idea for someone to create a resource for (down the road) than I thought
| Philip Shaddock (Feb 20, 2005 at 00:19 GMT) |
Philip
| Matthew Langley (Feb 20, 2005 at 04:17 GMT) Resource Rating: 5 |
| Joe Bird (Feb 20, 2005 at 09:41 GMT) Resource Rating: 5 |
| Philip Shaddock (Feb 20, 2005 at 17:50 GMT) |
Thanks,
Philip
| David Blake (Feb 20, 2005 at 18:20 GMT) Resource Rating: 5 |
| Melv May (Feb 20, 2005 at 18:29 GMT) |
Bitmap = Image on File that can contain single or multiple frames. T2D doesn't render Bitmaps! The bitmap format can be any format currently supported by T3D.
imageMap = A definition that points to a Bitmap and has parameters that tells T2D if it contains single or multiple frames and how those multiple frames are defined. Therefore an imageMap defines Frames.
Frame = A single region of a bitmap as defined by an imageMap.
animation = A definition that points to imageMap Frames.
Okay then...
Yes; you can set the sprites size to anything you require although its size isn't the size on the screen as this depends on the camera. The sprite size has nothing to do with the size of the underlying imagery.
Yes, the bitmaps can be large. imageMaps can only use bitmaps that are supported by the underlying hardware, not software. Modern cards have at least 2K and quite often 4K support although you'll be limiting your market to only people with cutting-edge cards. The absolute minimum we support is (0.25K - 256) support. It's up to you to decide the break-off point really, T2D doesn't currently make the decision for you. At some point, you'll want to use chunkMaps which are similar to imageMaps but split-up the underlying bitmap into a manageble minimum-spec (256) sized textures.
Yes; Sprites are made up of individual frames, not bitmaps. Remember, with T2D, you define an imageMap to acquire frames from your bitmaps and then either render frames from your imageMap or play animations which define frames from imageMaps.
Essentially, T2D has imageMaps/animations which mean you tell objects about them, not the underlying imagery. This means that your code isn't full of bitmap specific stuff like filenames and sizes etc.
T2D currently doesn't have any video support therefore there's no convention of compression (see frames above). That's not to say there won't ever be or that someone in the community won't add it. Hell, why not?
Hope this helps.
- Melv.
Edited on Feb 20, 2005 18:32 GMT
| Philip Shaddock (Feb 20, 2005 at 19:56 GMT) |
I am guessing that you would create a detailed image in Photoshop (or render an image out of XSI) and then define in software what the "frames" are going to be, i.e. a data structure that contains different framing parameters, like a "zoom" (series of frames centered on a set of coordinates that get larger or smaller) or "pan" (i.e. side scrolling). Is this what you mean? What about a sequence of something changing over time, like a person standing up? Is that possible? Would such a sequence be "derived from" a single bitmap or a series of bitmaps?
Thanks for your quick responses and patience...
Philip
| David Blake (Feb 20, 2005 at 21:37 GMT) Resource Rating: 5 |
MegaMan Sprites
Click on Classic Megaman and then on Robot Masters. See how the bitmap is a collection of all the animations? You would load this bitmap into the Torque game engine like you would load any bitmap. Then, you would reference it as an imageMap. It would have the number of frames and references to their placement within the file itself. Then you could run through the animations.
By abstracting it, you can have a number of instances of the different sprites running around and doing different things while using a single (or multiple) bitmap file.
Setting Zoom would depend on constraints. Are you simply zooming a single image or does the detail need to change. If it needs to change, then you'll need to set up a constraint so that when image A gets zoomed to a certain size, image B will be loaded for detail (and zooming can continue or stop, etc).
For a scrolling level, it's usually more memory friendly to create a series of tile images to load. Most games on the Nintendo GameBoy make heavy use of tiled graphics. You can, however, load detailed images as well to use as backgrounds. A number of Melv's early demos showed this in action.
I'm sure I explained it badly, but I tried. If you have any questions or if I've really messed things up, just ask.
| Philip Shaddock (Feb 20, 2005 at 21:51 GMT) |
Philip
| Melv May (Feb 20, 2005 at 22:49 GMT) |
@Philip: Glad this helped. :)
- Melv.
| Terry (Feb 22, 2005 at 07:00 GMT) Resource Rating: 5 |
I know you don't answer marketing questions, but I would like to say to whoever controls the licensing issues that - aside from the engine capabilities - TGE's excellent licensing structure was the reason I originally purchased Torque. I hope that T2D follows the same structure.
Terry
| Kenny Carvalho (Feb 23, 2005 at 22:11 GMT) |
what about a 2d fighting game to the degree of street fighter 2 with crazy particle effects?
| Melv May (Feb 23, 2005 at 22:38 GMT) |
Did I say unlimited there a few times or what?
- Melv.
Unlimited.
Edited on Feb 23, 2005 22:39 GMT
| Theo Brinkman (Feb 25, 2005 at 21:34 GMT) |
Just an idea on the deformable terrain for a Worms-like game, not sure if it'd be workable.
Create your map using 1x1 tiles, and set their passabilityas appropriate when the explosion hits the tile.
Like I said, don't know if it's workable or not, but it's an idea.
You must be a member and be logged in to either append comments or rate this resource.
