by date
Plan for Josh Williams
Plan for Josh Williams
| Name: | Josh Williams |  |
|---|---|---|
| Date Posted: | Feb 01, 2005 | |
| Rating: |  5.0 out of 5 | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: |  or Subscribe with  . | |
| Profile Page: | View profile page for Josh Williams |
Blog post
Exposing the seedy underbelly of T2D
In this .plan, I'm taking a first-pass at a technical overview for T2D. I'm hoping there are some crazy fools out there like me who can't seem to get enough details about cool technologies like T2D. So, hopefully somebody will find this (long and boring) .plan interesting (despite it's long and boring nature). (Update: this .plan covers T2D's core classes, read the next .plan to read about it's core systems![/url]
I'm sure this .plan won't answer all your questions about T2D, but it should end up being a nice overview. I promised to do something like this in my last .plan, so here we go!
To start off, for most of us here, all I really need to say about T2D is that it's developed by Melv May. :) For anyone that knows the guy, it is immediately possible to conclude with a high degree of confidence that T2D must, technically speaking, friggin rock. Melv has been working on T2D like a madman, and it is a quality product of outstanding engineering.
All told, T2D represents about 9 months of dedicated, impassioned work on Melv's part, and by us here at GG for the past 6 months or so. I know how much thought and effort has been poured into T2D, because I've been right there for most of the ride. I've already got great memories of late-night chats with Melv where we approached every design decision from a hundred angles, trying to make sure we'd end up with the best 2D game engine out there.
I'm very proud of Torque 2D. I think every day we get closer to achieving our goal for this engine, and by the end of this year, I do expect T2D will be far and away the best 2D game engine around. I love being a part of its creation.
Even at this point, as we push to finalize T2D for its Early Adopter release, the engine already has numerous advantages over other 2D engines. It'll be very exciting to see what the early adopters do with all this power, especially as the year goes on and we add easy to use editors and more core technology.
Okay, if I were reading this .plan right now, I'd be skimming ahead to get to the juicy parts, so let's just have at. :)
Below, you'll find a pretty detailed technical write-up on T2D's core feature set. It's long, and it's dry, so most people will probably just want to skip or skim this one. But for those of you out there like me who love reading this kind of stuff... enjoy!
T2D Technical Overview
Overview
Torque2D is a platform for 2D game development, built on top of the Torque Game Engine. This means T2D gets to leverage Torque's scripting, sound, platform, GUI, and other core systems. T2D implements its own scenegraph-driven, hardware-accelerated 2D rendering and game world systems.
In addition to the systems provided by TGE's core, Torque 2D's custom systems include everything you want in a 2D engine: sprites, tiles, particles, collision, physics, advanced camera capabilities, object mounting, parallax scrolling, rendering layering, object picking, and more. Each system is designed for power, ease of use, performance, and to be as readily customizable and extendable as possible. Scene saving and loading, multiple viewports, debug rendering and easy to visualize performance statistics, along with about 100 pages of tutorial and reference documentation round out the package, with many time-saving editors on the way.
Let's look at the primary classes T2D defines:
Core object fxSceneObject2D
T2D defines a base class from which every other major class is derived, the fxSceneObject2D. fxSceneObject2D provides:
Each of these capabilities and systems will be described in more detail later. First, we'll cover the fxSceneObject2D subclasses.
Sprites fxStaticSprite2D, fxChunkedSprite2D, fxAnimatedSprite2D
T2D has a very impressive sprite system. Sprite rendering in T2D is ultra-fast and sprites, like all T2D objects, can be scaled and rotated in graphics hardware. Sprites are divided into two main kinds: those with complex animation capabilities, and those without.
fxStaticSprite2D
The fxStaticSprite2D is a general-purpose sprite, allowing you to place (and move) renderable shapes in your scene that don't require complex animation sequences. The "static" in the name refers to the animation frames, as opposed to the object's ability to move around in the scene. Static sprites are perfectly free to move about the scene, and their rendering frames can even be changed, but they don't have a powerful animation interface.
fxStaticSprite2D uses an "image map", defined as an fxImageMapDatablock2D, to identify it's graphics frames. More information on image maps can be found below, but the basic idea is that image maps are used to load a sheet of images for use by sprites (and scrollers, tiles, and particles).
fxStaticSprite2D objects can be moved around the scene, and can have full collision, physics, etc. Again, these objects, like all the core objects in T2D, derive from fxSceneObject2D which provides a very powerful base to build from.
Related to the fxStaticSprite2D is the fxChunkedSprite2D. These sprites are very similar to static sprites, but are better for handling very large imagery. In particular fxChunkedSprite2D uses the fxChunkedImageDatablock2D, which is capable of loading imagery from non-power-of-two textures. More information on the fxChunkedImageDatablock2D can be found in the appropriate sub-section below. Ultimately, this interface for loading imagery from non-power-of-two sources will be simplified even further, but for now, T2D makes it easy to load images from any source by using these chunked resource capabilities. The fxChunkedSprite2D is also capable of tiling sprite imagery across its surface, according to parameters you can set.
fxAnimatedSprite2D
The fxAnimatedSprite2D provides very powerful tools for creating, playing, and managing animated sprites. Animated sprites (and animated tiles and particles) rely on animation datablocks and animation controllers in order to play animations. In order to get a grasp of the fxAnimatedSprite2D, we must first examine these systems:
The fxAnimationDatablock2D datablock class can load frames from an image map and define an animation as a chain of frames. The animation datablock can then define the play time of the animation, and set whether the animation cycles, and even whether the animation should start playing with a random frame.
The fxAnimationController2D is a utility class used by fxAnimatedSprite2D (as well as by animated tiles and animated particles) to control and play animations.
The fxAnimationDatablock2D and fxAnimationController2D abstract the process of defining, setting up, playing, and manipulating animations. Since there are multiple kinds of animated objects in T2D, this is very convenient, as each animated class can utilize the same functionality. This encapsulation of behavior is also nice because it allows you to easily define your own custom animated classes by leveraging the functionality provided by the standard animation classes.
Now, with all the animation functionality provided by the animation datablocks and controllers, creating animated sprites is a fairly simple matter. fxAnimatedSprite2D::playAnimation(name) is used to play a particular animation, as defined and controlled by the sprite's animation controller. fxAnimatedSprite2D also defines a callback function, onAnimationEnd(), so you can perform some custom actions when an animation ends.
Note that static sprites have none of the animation overhead incurred by the fxAnimatedSprite2D. Thus, while all sprites could really be animated sprites with no animations defined or played, it was decided to create the specialized static sprite class, just for that added bit of specialization and efficiency. Structuring things this way also makes it easier for people to get a grip on sprites-- making it as simple as possible for people to set-up basic sprites, without worrying about any extra calls or functionality, is a good thing.
That's the overview of sprites in T2D. Sprites are pretty much the core of most any 2D game, so Melv was careful to treat 'em right, and we've all been careful about suggested modifications to these core classes.
Setting basic properties and loading images datablocks, and image maps
Torque2D makes heavy use of datablocks. (If you aren't familiar with Datablocks, I encourage you to read the scripting documentation here on the site). Every object in T2D has a datablock associated with it, which can be used to configure its initial or static properties.
Image maps
Image maps, or the fxImageMapDatablock2D, are some of the most important and most used datablocks in T2D. As described above, image maps can be used to load imagery from a sheet of frames. Image maps essentially read textures and then extract image frames from the texture. These image frames can be extracted in one of three ways: single frame, color-keyed, or celled.
Using single frame extraction will result in an entire texture being loaded as a single frame.
To use color-keyed extraction, the source image must be separated by lines of a particular color-- each image to be extracted must boxed-in by straight lines of this particular color, and the color must not be used anywhere else in the image. Often, people use pure black, pure green, or bright pink for this key color. When in color-keyed extraction mode, the image map reads the upper-left texel on a texture and sets that as the color-key. Note that this is the same system used to define image maps for GUI controls in standard TGE.
Celled extraction means that the source image is split into a regular grid of equally-sized cells, and that each cell should be loaded as a separate image frame. You specify the size of each grid, and the number of grids, and the image map can load any frame from the source texture.
Image maps, again, abstract and encapsulate the process of loading graphics frames from source imagery. This way, multiple objects can extract renderable frames from a source image without having to do the actual loading work themselves. This architecture also means that multiple objects (even of different types) can use the same image map to load their particular animations. This can end up saving texture memory usage, by decreasing the need to define redundant animation frames in separate textures. Once again, this functionality also makes it easy to define your own custom, renderable objects by utilizing the image map's frame loading functionality.
Besides the normal fxImageMapDatablock2D, there is also the fxChunkedImageDatablock2D, as mentioned above. This datablock is similar to the normal image map, but allows for loading from non-power-of-two sources. Again, the interface for handling non-power-of-two source imagery will be simplified soon after the initial Early Adopter release of T2D, but this system provides the baseline functionality needed to allow people to load from irregular sources.
Okay, now we've got some basic ideas about T2D down... we know a little about the high-level features provided to all T2D objects by the fxSceneObject2D, we know about T2D's sprite capabilities and animation system, and we have an understanding of T2D's architecture for loading images.
Next, we'll continue digging into each of the objects provided in T2D, and then we'll go over the major processing systems provided by default in T2D and the core fxSceneObject2D.
Scrolling backgrounds fxScroller2D
T2D provides a really simple way to get scrolling backgrounds in your game. There is a more powerful methodology for backgrounds in T2D, (..tile maps, which are discussed below) but the fxScroller2D provides a very simple, efficient way to use scrolling backgrounds.
fxScroller2D loads its image using the image map interface (and can only have one frame). This image is then scrolled, according to parameters set either in the fxScrollerDatablock2D, or by calling the setScrollMode(mode, dx, dy) method. Mode is a boolean parameter specifying whether the scroller should scroll or remain static, and dx and dy define the scrolling speed, in world units per second, to be used.
Regarding world units, T2D has a nice system for handling coordinates in your game world. Whether working with the game world itself, with background scrollers, tiles, sprites, or anything else, you don't need to worry about the actual pixel size of anything-- T2D does all the translation for you, and you can simply work in world coordinates. This kind of functionality is standard in 3D engines, but (surprisingly) some 2D engines out there don't provide this nice level of abstraction. Scrollers are one area where this consistent coordinate system is very useful.
Again, the main advantage of fxScroller2D objects is that they are very easy to set-up, and very performance-friendly. They can also be used to get parallax-scrolling up and running in no time. By defining multiple scrolling backgrounds, you can easily sort and assign them to different rendering layers (more info on this later), and assign different scrolling speeds. Thus, scrollers in the far background can scroll slowly, while those in the foreground scroll by rapidly. This creates the cool, pseudo-3D "parallax" scrolling effect common in many 2D games, and it's incredibly easy to get going with Torque 2D.
Tiles
I've looked very thoroughly at a lot of 2D engines out there, especially the major, well-known ones, and I am happy to say that T2D is well on it's way to having the most powerful and flexible tile system around. It took us quite a bit of wrestling to figure out the best way to handle tiles, lots of lunch discussions with Pat and Alex here at GG, and many more late night design sessions with Melv, but we finally ended up with an outstanding system. There's still more work to do on tiles, but the core system is in place, and I'm very happy with it. Let's check it out:
One impressive feature of T2D's tiles is their integration with the physics system. Objects can collide with tiles, and these collisions can generate full physics responses (on the objects). Given how powerful T2D's collision and physics system is, this is a very nice, and uniquely powerful, feature of the tiles. It was also a tough one to get in, let alone to make performant. After some long conversations about how to handle the tiles, Melv and I came up with an excellent plan for them, and Melv knocked the implementation out of the park. The tile interaction in T2D is really great (and we're not done yet ;)
Overall, there are three kinds of tiles in T2D: static, animated, and "active". Static and animated tiles are very similar to their sprite counterparts, and they use the same encapsulated sub-objects to manage their imagery and animations. The cool thing to note here is that T2D supports richly animated tiles, should you wish to use them! Not all 2D engines do. :)
Active tiles are a different animal. Active tiles define a skeleton which you can use to create tiles which actively affect the world. One example that's been talked about before is creating turrets as active tiles in your tilemap. This has some efficiency advantages versus creating a tile layer and associating a stand-alone turret object with it. There are lots of creative ways to take advantage of this functionality. We (probably) won't ship the Early Adopter version of T2D with a good example of an active tile, but soon afterward, we should produce some. Eventually, we both expect that there'll be libraries of active tiles out there people can use and customize.
Another neat feature of T2D's tile system is that each tile object can have an associated script which runs once the tile is displayed. Again, this is a cool little feature that allows you to more easily create really dynamic tiled environments.
T2D tilemaps can also be panned, in any direction (with a little bit of set-up work)
Object picking also works for tiles-- you can, for example, determine exactly what tile (if any) currently lies directly beneath a current screen or world-space point.
Those are some of the big features of T2D tiles. Now, here's how the system works in general:
T2D stores tiles, at the highest level, in a tile map-- fxTileMap2D. fxTileMap2D objects create, maintain, and destroy fxTileLayer2D objects, which in turn handle the virtual tile objects. fxTileMap2D can load and save maps from and to disk.
The fxTileLayer2D object is the meat of the tile system. Where the fxTileMap2D class provides some high-level loading and management routines, fxTileLayer2D actually does the dirty tile work. Tiles are simply defined as a grid in the tile layer, and the tile layer can control any individual tile, determining whether the tile is static, animated, or active, setting the tile's script callback, changing the tile, etc.
The tile map can set-up the tile layer's actual dimensions, and how many individual tiles it contains.
The tile layer has some convenient features: for example it has a layer clear, which will remove all the information on the layer's grid. Also, there are fine-grained animation controls on the tile layer, for example, you can force an animated tile to be "unique", which means it will use it's own instance of an animation controller, so as not to be affected by potential changes to a central controller (non-uniquely animated tiles are animated together, and save some memory overhead and cpu overhead, as they all rely on the same instance of an animation controller). Tile layers can also be panned, and can be set-up to for auto-panning at a fixed rate. Tile layers can be wrapped as well-- in fact, you can control wrapping behavior independently along both major axes.
Another important consequence of the tile layer's structure is that individual tiles can be deleted (cleared) and changed at any time. So getting some truly dynamic and active tile maps is easy in T2D, you're not simply confined to static backgrounds and collision imagery.
That's where things stand at the moment. We have even more plans for tiles in T2D, but we'll wait until after the Early Adopter release to go into them in more detail. One thing I will say now though is that we'll have support for non-rectilinear tiles as soon as possible. For now, we just wanted to get the core backbone of the tiling system up and running. We achieved much more than we originally set out to achieve with the tile system, I think. And with this infrastructure in place, adding in new tile types won't be very difficult.
Great. So, there's all this awesome tile support in T2D. But, how do you load tiles? It'd be a royal pain to have to set-up tile maps all by hand in script. Thus, T2D will ship with an FMP loader, meaning you can load tile sets created in the well-known (and cross-platform) Mappy tile editor. Then, you can take advantage of T2D-specific tile functionality via script setup. In the future, we'll either be creating our own tile editor, or extending an existing editor (perhaps Mappy).
Particles
Okay, I'm going fanboy mode here, I can't help it:
Particles are incredible in T2D. In my opinion, T2D has the most impressive real-time particle system in any engine. Once we get a finalized, user-friendly particle editor in, I know T2D owners are going to lose hours and hours of time just creating pretty particle effects. I love this system, and I have to give all props to Melv for coming up with it.
So, how's it work?
There are three layers to the particle system: effects, and emitters, and particles themselves. Effects contain an unlimited (virtually) collection of particle emitters, and control these emitters over time. Particle emitters spew particles in a fine-grain controllable, time-dependent manner. Particles themselves are like very lightweight, efficiently rendered animated sprites as they can utilize animation controllers to change their rendered frame over time.
fxParticleEffect2D
Particle effects are essentially a large collection of specific fields and particle emitter sub-objects which are used to define a particle effect. The effect's fields can be split into two groups: those which change over time, and those which are static.
Fields which change over time are controlled via a time-graph system, meaning that you specify time and key-value pairs for these fields. For each field, the effect will interpolate between the currently adjacent key-values, arriving at the proper values at the specified time.
For example, the quantity_scale is a time-dependent particle effect field. This field, like many effect fields, specifies a value by which to multiply the particle emission quantity specified in the effect's particle emitter objects themselves. Essentially, this provides particle effects the ability to override their sub-object emitters' settings, inducing effect-wide changes in emitters.
In this example, we might specify that we want all emitters that are a part of this effect to begin spewing particles faster and faster after two seconds, peaking at twice their normal rate after two more seconds, and then ramping down to their normal emission rate after another second. To do so, we'd specify time and key-value pairs for this field: (time, key-value) : (2.0, 1.0), (4.0, 2.0), (5.0, 1.0). In script, assume we have a whole particle effect set-up, then applying this change to the effect would work like so:
%exampleEffect.selectGraph("quantity_scale");
%exampleEffect.addDataKey(2.0, 1.0);
%exampleEffect.addDataKey(4.0, 2.0);
%exampleEffect.addDataKey(5.0, 1.0);
This tells the effect that we want it to ramp up all of its particle emitter's particle emission quantities to twice their normal rate between seconds two and four of the effect, and to be back to normal by the fifth second the effect plays.
An example of a non-time-dependent field is the effect's timeRepeat, which is accessed via getTimeRepeat() and setTimeRepeat(scale). This field affects the timescale of all emitters that are a part of the effect.
fxParticleEmitter2D
Emitters are actually very similar to effects, they utilize a similar system of fields, and whereas effects spawn emitters, emitters spawn particles. Emitters define a long list of fields which can be used to control particle emission behavior. These fields are also split into two groups: time-graph controlled, dynamic fields which are interpolated over an unlimited chain of time / key value pairs, and static flags which parameterize the emitter's general behavior.
Examples of dynamic emitter fields include particlelife_base and particlelife_variation. These two fields are used to determine the lifetime of each particle spawned by the emitter. The base component defines the default particle lifetime, while the variation component defines a range [-variation, variation] of deviance from the base value. This variation is randomly distributed, using a standard linear random generator.
Emitters use this base / variation concept for many of their dynamic fields. The particle emission quantity, particle size, particle speed, emission force, and other fields all use this dual base / variation time-graph controlled paradigm. Other fields don't use it, for example, visibility_life is time-graph controlled but has no variance. This field controls the length of time for which each particle is visible.
Now, all this leads to a very powerful, highly flexible particle effect system. But it'd be awfully nasty if you had to control it all via scripting. Luckily, T2D Early Adopter comes with a (very basic!) particle editor. This saves you from ever having to script any particle effects. The Early Adopter particle editor isn't at all the prettiest or most user-friendly tool ever made, but it is fully functional and you can do anything with it that you can in script.
Emitters efficiently handle particle spawning and control, keeping a particle pool handy to minimize memory allocs. Particle rendering is quite efficient as well, though there are still some important optimizations to make after the Early Adopter release.
Emitters also provide a rich interface for querying their current field values, and include debug rendering information.
What's more, particle effects can be saved to disk, for later re-use.
Very cool. And that's not all... like all of the standard objects in T2D, particle effects are derivatives of fxSceneObject2D. That means effects can be manipulated like any other object.. they can be moved, mounted, scaled, assigned to groups and layers, and even have physics interaction!
I don't think even Melv fully realizes how cool this system is. And if he does, then he's way the hell too humble about it. By all rights, he should be out screaming his head off about what a badass he is for creating it. :) In all honesty, I'd pay just for a real-time particle effects system like this. There are particle systems without as much power (let alone being real-time!) as this system out there that people pay pretty big bug bucks for, for use in film, scientific visualization, etc.
Once we have a polished particle editor, I bet all kinds of people will produce dazzling particle effects, and I'm sure we'll all while away hours just sitting around staring at them. Mmm.. shiny.
Note: the T2D reference documentation contains a complete list of every script-accessible field and method for particle effects and emitters, as it does for all objects in T2D.
Further Note: presently, T2D interpolates over time-graphs only linearly, but in the future other common interpolators will be implemented.
Scoop: just a couple weeks ago I was contacted by two experienced engineers who are interested in porting this particle system up to Torque (and TSE). So, no promises, but watch this space for more details. :)
With that, we've covered the basic objects found in Torque 2D. Between the core scene object, sprites, scrollers, tile maps, and particle effects, you have all you need to make every kind of 2D game.
I'm just realizing that this .plan is almost ten full pages long already. If I'm lucky, maybe two or three people out there actually read the whole thing. It's still not done yet, but it'd probably be best to split this technical overview up into two pieces. This .plan covered the core objects in the engine, so watch for Episode II: Attack of the Core Systems tomorrow! (Or very soon afterward, depending on how much sleep I'm willing to deprive myself of tonight). You can see the outline for tomorrow's .plan below. (Update: the next .plan is out :)
Thanks for reading. If you made it straight-through the whole thing, with its utter lack of pictures or funny personal anecdotes or really any redeeming qualities of any sort, hats off to you, friend. You are indeed a hardcore technophile. ... You pervert.
Collision
Physics
Layers and Groups
Mounting
Object picking
World limits
Camera
Scenegraph
Torque integration
C++ source available
Detailed documentation
(continued in the next .plan
I'm sure this .plan won't answer all your questions about T2D, but it should end up being a nice overview. I promised to do something like this in my last .plan, so here we go!
To start off, for most of us here, all I really need to say about T2D is that it's developed by Melv May. :) For anyone that knows the guy, it is immediately possible to conclude with a high degree of confidence that T2D must, technically speaking, friggin rock. Melv has been working on T2D like a madman, and it is a quality product of outstanding engineering.
All told, T2D represents about 9 months of dedicated, impassioned work on Melv's part, and by us here at GG for the past 6 months or so. I know how much thought and effort has been poured into T2D, because I've been right there for most of the ride. I've already got great memories of late-night chats with Melv where we approached every design decision from a hundred angles, trying to make sure we'd end up with the best 2D game engine out there.
I'm very proud of Torque 2D. I think every day we get closer to achieving our goal for this engine, and by the end of this year, I do expect T2D will be far and away the best 2D game engine around. I love being a part of its creation.
Even at this point, as we push to finalize T2D for its Early Adopter release, the engine already has numerous advantages over other 2D engines. It'll be very exciting to see what the early adopters do with all this power, especially as the year goes on and we add easy to use editors and more core technology.
Okay, if I were reading this .plan right now, I'd be skimming ahead to get to the juicy parts, so let's just have at. :)
Below, you'll find a pretty detailed technical write-up on T2D's core feature set. It's long, and it's dry, so most people will probably just want to skip or skim this one. But for those of you out there like me who love reading this kind of stuff... enjoy!
T2D Technical Overview
Overview
Torque2D is a platform for 2D game development, built on top of the Torque Game Engine. This means T2D gets to leverage Torque's scripting, sound, platform, GUI, and other core systems. T2D implements its own scenegraph-driven, hardware-accelerated 2D rendering and game world systems.
In addition to the systems provided by TGE's core, Torque 2D's custom systems include everything you want in a 2D engine: sprites, tiles, particles, collision, physics, advanced camera capabilities, object mounting, parallax scrolling, rendering layering, object picking, and more. Each system is designed for power, ease of use, performance, and to be as readily customizable and extendable as possible. Scene saving and loading, multiple viewports, debug rendering and easy to visualize performance statistics, along with about 100 pages of tutorial and reference documentation round out the package, with many time-saving editors on the way.
Let's look at the primary classes T2D defines:
Core object fxSceneObject2D
T2D defines a base class from which every other major class is derived, the fxSceneObject2D. fxSceneObject2D provides:
- Extendible, efficient swept-polygon collision detection
- Rigid-body physics
- Unlimited, hierarchical object mounting
- Assignment to rendering layers
- Object picking with points, lines, and areas
- Individual world-limit definition, clamping and collision response
- Object scaling, rotation, and automated / fixed rotation
- Object serialization
- Scriptable interface and callbacks
- Debug and performance reporting
- Customizability and extendability for simple creation of custom objects
Each of these capabilities and systems will be described in more detail later. First, we'll cover the fxSceneObject2D subclasses.
Sprites fxStaticSprite2D, fxChunkedSprite2D, fxAnimatedSprite2D
T2D has a very impressive sprite system. Sprite rendering in T2D is ultra-fast and sprites, like all T2D objects, can be scaled and rotated in graphics hardware. Sprites are divided into two main kinds: those with complex animation capabilities, and those without.
fxStaticSprite2D
The fxStaticSprite2D is a general-purpose sprite, allowing you to place (and move) renderable shapes in your scene that don't require complex animation sequences. The "static" in the name refers to the animation frames, as opposed to the object's ability to move around in the scene. Static sprites are perfectly free to move about the scene, and their rendering frames can even be changed, but they don't have a powerful animation interface.
fxStaticSprite2D uses an "image map", defined as an fxImageMapDatablock2D, to identify it's graphics frames. More information on image maps can be found below, but the basic idea is that image maps are used to load a sheet of images for use by sprites (and scrollers, tiles, and particles).
fxStaticSprite2D objects can be moved around the scene, and can have full collision, physics, etc. Again, these objects, like all the core objects in T2D, derive from fxSceneObject2D which provides a very powerful base to build from.
Related to the fxStaticSprite2D is the fxChunkedSprite2D. These sprites are very similar to static sprites, but are better for handling very large imagery. In particular fxChunkedSprite2D uses the fxChunkedImageDatablock2D, which is capable of loading imagery from non-power-of-two textures. More information on the fxChunkedImageDatablock2D can be found in the appropriate sub-section below. Ultimately, this interface for loading imagery from non-power-of-two sources will be simplified even further, but for now, T2D makes it easy to load images from any source by using these chunked resource capabilities. The fxChunkedSprite2D is also capable of tiling sprite imagery across its surface, according to parameters you can set.
fxAnimatedSprite2D
The fxAnimatedSprite2D provides very powerful tools for creating, playing, and managing animated sprites. Animated sprites (and animated tiles and particles) rely on animation datablocks and animation controllers in order to play animations. In order to get a grasp of the fxAnimatedSprite2D, we must first examine these systems:
The fxAnimationDatablock2D datablock class can load frames from an image map and define an animation as a chain of frames. The animation datablock can then define the play time of the animation, and set whether the animation cycles, and even whether the animation should start playing with a random frame.
The fxAnimationController2D is a utility class used by fxAnimatedSprite2D (as well as by animated tiles and animated particles) to control and play animations.
The fxAnimationDatablock2D and fxAnimationController2D abstract the process of defining, setting up, playing, and manipulating animations. Since there are multiple kinds of animated objects in T2D, this is very convenient, as each animated class can utilize the same functionality. This encapsulation of behavior is also nice because it allows you to easily define your own custom animated classes by leveraging the functionality provided by the standard animation classes.
Now, with all the animation functionality provided by the animation datablocks and controllers, creating animated sprites is a fairly simple matter. fxAnimatedSprite2D::playAnimation(name) is used to play a particular animation, as defined and controlled by the sprite's animation controller. fxAnimatedSprite2D also defines a callback function, onAnimationEnd(), so you can perform some custom actions when an animation ends.
Note that static sprites have none of the animation overhead incurred by the fxAnimatedSprite2D. Thus, while all sprites could really be animated sprites with no animations defined or played, it was decided to create the specialized static sprite class, just for that added bit of specialization and efficiency. Structuring things this way also makes it easier for people to get a grip on sprites-- making it as simple as possible for people to set-up basic sprites, without worrying about any extra calls or functionality, is a good thing.
That's the overview of sprites in T2D. Sprites are pretty much the core of most any 2D game, so Melv was careful to treat 'em right, and we've all been careful about suggested modifications to these core classes.
Setting basic properties and loading images datablocks, and image maps
Torque2D makes heavy use of datablocks. (If you aren't familiar with Datablocks, I encourage you to read the scripting documentation here on the site). Every object in T2D has a datablock associated with it, which can be used to configure its initial or static properties.
Image maps
Image maps, or the fxImageMapDatablock2D, are some of the most important and most used datablocks in T2D. As described above, image maps can be used to load imagery from a sheet of frames. Image maps essentially read textures and then extract image frames from the texture. These image frames can be extracted in one of three ways: single frame, color-keyed, or celled.
Using single frame extraction will result in an entire texture being loaded as a single frame.
To use color-keyed extraction, the source image must be separated by lines of a particular color-- each image to be extracted must boxed-in by straight lines of this particular color, and the color must not be used anywhere else in the image. Often, people use pure black, pure green, or bright pink for this key color. When in color-keyed extraction mode, the image map reads the upper-left texel on a texture and sets that as the color-key. Note that this is the same system used to define image maps for GUI controls in standard TGE.
Celled extraction means that the source image is split into a regular grid of equally-sized cells, and that each cell should be loaded as a separate image frame. You specify the size of each grid, and the number of grids, and the image map can load any frame from the source texture.
Image maps, again, abstract and encapsulate the process of loading graphics frames from source imagery. This way, multiple objects can extract renderable frames from a source image without having to do the actual loading work themselves. This architecture also means that multiple objects (even of different types) can use the same image map to load their particular animations. This can end up saving texture memory usage, by decreasing the need to define redundant animation frames in separate textures. Once again, this functionality also makes it easy to define your own custom, renderable objects by utilizing the image map's frame loading functionality.
Besides the normal fxImageMapDatablock2D, there is also the fxChunkedImageDatablock2D, as mentioned above. This datablock is similar to the normal image map, but allows for loading from non-power-of-two sources. Again, the interface for handling non-power-of-two source imagery will be simplified soon after the initial Early Adopter release of T2D, but this system provides the baseline functionality needed to allow people to load from irregular sources.
Okay, now we've got some basic ideas about T2D down... we know a little about the high-level features provided to all T2D objects by the fxSceneObject2D, we know about T2D's sprite capabilities and animation system, and we have an understanding of T2D's architecture for loading images.
Next, we'll continue digging into each of the objects provided in T2D, and then we'll go over the major processing systems provided by default in T2D and the core fxSceneObject2D.
Scrolling backgrounds fxScroller2D
T2D provides a really simple way to get scrolling backgrounds in your game. There is a more powerful methodology for backgrounds in T2D, (..tile maps, which are discussed below) but the fxScroller2D provides a very simple, efficient way to use scrolling backgrounds.
fxScroller2D loads its image using the image map interface (and can only have one frame). This image is then scrolled, according to parameters set either in the fxScrollerDatablock2D, or by calling the setScrollMode(mode, dx, dy) method. Mode is a boolean parameter specifying whether the scroller should scroll or remain static, and dx and dy define the scrolling speed, in world units per second, to be used.
Regarding world units, T2D has a nice system for handling coordinates in your game world. Whether working with the game world itself, with background scrollers, tiles, sprites, or anything else, you don't need to worry about the actual pixel size of anything-- T2D does all the translation for you, and you can simply work in world coordinates. This kind of functionality is standard in 3D engines, but (surprisingly) some 2D engines out there don't provide this nice level of abstraction. Scrollers are one area where this consistent coordinate system is very useful.
Again, the main advantage of fxScroller2D objects is that they are very easy to set-up, and very performance-friendly. They can also be used to get parallax-scrolling up and running in no time. By defining multiple scrolling backgrounds, you can easily sort and assign them to different rendering layers (more info on this later), and assign different scrolling speeds. Thus, scrollers in the far background can scroll slowly, while those in the foreground scroll by rapidly. This creates the cool, pseudo-3D "parallax" scrolling effect common in many 2D games, and it's incredibly easy to get going with Torque 2D.
Tiles
I've looked very thoroughly at a lot of 2D engines out there, especially the major, well-known ones, and I am happy to say that T2D is well on it's way to having the most powerful and flexible tile system around. It took us quite a bit of wrestling to figure out the best way to handle tiles, lots of lunch discussions with Pat and Alex here at GG, and many more late night design sessions with Melv, but we finally ended up with an outstanding system. There's still more work to do on tiles, but the core system is in place, and I'm very happy with it. Let's check it out:
One impressive feature of T2D's tiles is their integration with the physics system. Objects can collide with tiles, and these collisions can generate full physics responses (on the objects). Given how powerful T2D's collision and physics system is, this is a very nice, and uniquely powerful, feature of the tiles. It was also a tough one to get in, let alone to make performant. After some long conversations about how to handle the tiles, Melv and I came up with an excellent plan for them, and Melv knocked the implementation out of the park. The tile interaction in T2D is really great (and we're not done yet ;)
Overall, there are three kinds of tiles in T2D: static, animated, and "active". Static and animated tiles are very similar to their sprite counterparts, and they use the same encapsulated sub-objects to manage their imagery and animations. The cool thing to note here is that T2D supports richly animated tiles, should you wish to use them! Not all 2D engines do. :)
Active tiles are a different animal. Active tiles define a skeleton which you can use to create tiles which actively affect the world. One example that's been talked about before is creating turrets as active tiles in your tilemap. This has some efficiency advantages versus creating a tile layer and associating a stand-alone turret object with it. There are lots of creative ways to take advantage of this functionality. We (probably) won't ship the Early Adopter version of T2D with a good example of an active tile, but soon afterward, we should produce some. Eventually, we both expect that there'll be libraries of active tiles out there people can use and customize.
Another neat feature of T2D's tile system is that each tile object can have an associated script which runs once the tile is displayed. Again, this is a cool little feature that allows you to more easily create really dynamic tiled environments.
T2D tilemaps can also be panned, in any direction (with a little bit of set-up work)
Object picking also works for tiles-- you can, for example, determine exactly what tile (if any) currently lies directly beneath a current screen or world-space point.
Those are some of the big features of T2D tiles. Now, here's how the system works in general:
T2D stores tiles, at the highest level, in a tile map-- fxTileMap2D. fxTileMap2D objects create, maintain, and destroy fxTileLayer2D objects, which in turn handle the virtual tile objects. fxTileMap2D can load and save maps from and to disk.
The fxTileLayer2D object is the meat of the tile system. Where the fxTileMap2D class provides some high-level loading and management routines, fxTileLayer2D actually does the dirty tile work. Tiles are simply defined as a grid in the tile layer, and the tile layer can control any individual tile, determining whether the tile is static, animated, or active, setting the tile's script callback, changing the tile, etc.
The tile map can set-up the tile layer's actual dimensions, and how many individual tiles it contains.
The tile layer has some convenient features: for example it has a layer clear, which will remove all the information on the layer's grid. Also, there are fine-grained animation controls on the tile layer, for example, you can force an animated tile to be "unique", which means it will use it's own instance of an animation controller, so as not to be affected by potential changes to a central controller (non-uniquely animated tiles are animated together, and save some memory overhead and cpu overhead, as they all rely on the same instance of an animation controller). Tile layers can also be panned, and can be set-up to for auto-panning at a fixed rate. Tile layers can be wrapped as well-- in fact, you can control wrapping behavior independently along both major axes.
Another important consequence of the tile layer's structure is that individual tiles can be deleted (cleared) and changed at any time. So getting some truly dynamic and active tile maps is easy in T2D, you're not simply confined to static backgrounds and collision imagery.
That's where things stand at the moment. We have even more plans for tiles in T2D, but we'll wait until after the Early Adopter release to go into them in more detail. One thing I will say now though is that we'll have support for non-rectilinear tiles as soon as possible. For now, we just wanted to get the core backbone of the tiling system up and running. We achieved much more than we originally set out to achieve with the tile system, I think. And with this infrastructure in place, adding in new tile types won't be very difficult.
Great. So, there's all this awesome tile support in T2D. But, how do you load tiles? It'd be a royal pain to have to set-up tile maps all by hand in script. Thus, T2D will ship with an FMP loader, meaning you can load tile sets created in the well-known (and cross-platform) Mappy tile editor. Then, you can take advantage of T2D-specific tile functionality via script setup. In the future, we'll either be creating our own tile editor, or extending an existing editor (perhaps Mappy).
Particles
Okay, I'm going fanboy mode here, I can't help it:
Particles are incredible in T2D. In my opinion, T2D has the most impressive real-time particle system in any engine. Once we get a finalized, user-friendly particle editor in, I know T2D owners are going to lose hours and hours of time just creating pretty particle effects. I love this system, and I have to give all props to Melv for coming up with it.
So, how's it work?
There are three layers to the particle system: effects, and emitters, and particles themselves. Effects contain an unlimited (virtually) collection of particle emitters, and control these emitters over time. Particle emitters spew particles in a fine-grain controllable, time-dependent manner. Particles themselves are like very lightweight, efficiently rendered animated sprites as they can utilize animation controllers to change their rendered frame over time.
fxParticleEffect2D
Particle effects are essentially a large collection of specific fields and particle emitter sub-objects which are used to define a particle effect. The effect's fields can be split into two groups: those which change over time, and those which are static.
Fields which change over time are controlled via a time-graph system, meaning that you specify time and key-value pairs for these fields. For each field, the effect will interpolate between the currently adjacent key-values, arriving at the proper values at the specified time.
For example, the quantity_scale is a time-dependent particle effect field. This field, like many effect fields, specifies a value by which to multiply the particle emission quantity specified in the effect's particle emitter objects themselves. Essentially, this provides particle effects the ability to override their sub-object emitters' settings, inducing effect-wide changes in emitters.
In this example, we might specify that we want all emitters that are a part of this effect to begin spewing particles faster and faster after two seconds, peaking at twice their normal rate after two more seconds, and then ramping down to their normal emission rate after another second. To do so, we'd specify time and key-value pairs for this field: (time, key-value) : (2.0, 1.0), (4.0, 2.0), (5.0, 1.0). In script, assume we have a whole particle effect set-up, then applying this change to the effect would work like so:
%exampleEffect.selectGraph("quantity_scale");
%exampleEffect.addDataKey(2.0, 1.0);
%exampleEffect.addDataKey(4.0, 2.0);
%exampleEffect.addDataKey(5.0, 1.0);
This tells the effect that we want it to ramp up all of its particle emitter's particle emission quantities to twice their normal rate between seconds two and four of the effect, and to be back to normal by the fifth second the effect plays.
An example of a non-time-dependent field is the effect's timeRepeat, which is accessed via getTimeRepeat() and setTimeRepeat(scale). This field affects the timescale of all emitters that are a part of the effect.
fxParticleEmitter2D
Emitters are actually very similar to effects, they utilize a similar system of fields, and whereas effects spawn emitters, emitters spawn particles. Emitters define a long list of fields which can be used to control particle emission behavior. These fields are also split into two groups: time-graph controlled, dynamic fields which are interpolated over an unlimited chain of time / key value pairs, and static flags which parameterize the emitter's general behavior.
Examples of dynamic emitter fields include particlelife_base and particlelife_variation. These two fields are used to determine the lifetime of each particle spawned by the emitter. The base component defines the default particle lifetime, while the variation component defines a range [-variation, variation] of deviance from the base value. This variation is randomly distributed, using a standard linear random generator.
Emitters use this base / variation concept for many of their dynamic fields. The particle emission quantity, particle size, particle speed, emission force, and other fields all use this dual base / variation time-graph controlled paradigm. Other fields don't use it, for example, visibility_life is time-graph controlled but has no variance. This field controls the length of time for which each particle is visible.
Now, all this leads to a very powerful, highly flexible particle effect system. But it'd be awfully nasty if you had to control it all via scripting. Luckily, T2D Early Adopter comes with a (very basic!) particle editor. This saves you from ever having to script any particle effects. The Early Adopter particle editor isn't at all the prettiest or most user-friendly tool ever made, but it is fully functional and you can do anything with it that you can in script.
Emitters efficiently handle particle spawning and control, keeping a particle pool handy to minimize memory allocs. Particle rendering is quite efficient as well, though there are still some important optimizations to make after the Early Adopter release.
Emitters also provide a rich interface for querying their current field values, and include debug rendering information.
What's more, particle effects can be saved to disk, for later re-use.
Very cool. And that's not all... like all of the standard objects in T2D, particle effects are derivatives of fxSceneObject2D. That means effects can be manipulated like any other object.. they can be moved, mounted, scaled, assigned to groups and layers, and even have physics interaction!
I don't think even Melv fully realizes how cool this system is. And if he does, then he's way the hell too humble about it. By all rights, he should be out screaming his head off about what a badass he is for creating it. :) In all honesty, I'd pay just for a real-time particle effects system like this. There are particle systems without as much power (let alone being real-time!) as this system out there that people pay pretty big bug bucks for, for use in film, scientific visualization, etc.
Once we have a polished particle editor, I bet all kinds of people will produce dazzling particle effects, and I'm sure we'll all while away hours just sitting around staring at them. Mmm.. shiny.
Note: the T2D reference documentation contains a complete list of every script-accessible field and method for particle effects and emitters, as it does for all objects in T2D.
Further Note: presently, T2D interpolates over time-graphs only linearly, but in the future other common interpolators will be implemented.
Scoop: just a couple weeks ago I was contacted by two experienced engineers who are interested in porting this particle system up to Torque (and TSE). So, no promises, but watch this space for more details. :)
With that, we've covered the basic objects found in Torque 2D. Between the core scene object, sprites, scrollers, tile maps, and particle effects, you have all you need to make every kind of 2D game.
I'm just realizing that this .plan is almost ten full pages long already. If I'm lucky, maybe two or three people out there actually read the whole thing. It's still not done yet, but it'd probably be best to split this technical overview up into two pieces. This .plan covered the core objects in the engine, so watch for Episode II: Attack of the Core Systems tomorrow! (Or very soon afterward, depending on how much sleep I'm willing to deprive myself of tonight). You can see the outline for tomorrow's .plan below. (Update: the next .plan is out :)
Thanks for reading. If you made it straight-through the whole thing, with its utter lack of pictures or funny personal anecdotes or really any redeeming qualities of any sort, hats off to you, friend. You are indeed a hardcore technophile. ... You pervert.
Collision
Physics
Layers and Groups
Mounting
Object picking
World limits
Camera
Scenegraph
Torque integration
C++ source available
Detailed documentation
(continued in the next .plan
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!| Anthony Rosenbaum (Feb 01, 2005 at 01:49 GMT) |
| Eugene Goh (Feb 01, 2005 at 01:56 GMT) Resource Rating: 5 |
| Josh Williams (Feb 01, 2005 at 02:02 GMT) |
Edited on Feb 01, 2005 02:02 GMT
| Dan MacDonald (Feb 01, 2005 at 02:16 GMT) |
| Shannara (Feb 01, 2005 at 03:22 GMT) |
| Jay Barnson (Feb 01, 2005 at 04:01 GMT) |
| Pat Wilson (Feb 01, 2005 at 04:13 GMT) |
Jay, right now T2D runs on anything Torque runs on and less! (In this case, less is more as far as minimum system requirements) There are a lot of upcomming changes to Torque that are not finalized yet and that I can not talk about however keeping in the theme of our commitment to making TGE (T2D included) available to the broadest platform base possible.
| Matt Harpold (Feb 01, 2005 at 05:13 GMT) |
T2D sounds awesome! Especially the tiling capabilities.
| David Montgomery-Blake (Feb 01, 2005 at 06:22 GMT) Resource Rating: 5 |
And if you look at the software projects released in the last 10 years that's saying a LOT. Even if you look at 2D filters for any software package (GiMP, PS, PSP, etc).
Melv rocks, but we all knew that. I'm just glad that GG saw the potential in T2D. I can't wait to get in on the EA release.
| Matthew Langley (Feb 01, 2005 at 06:36 GMT) Resource Rating: 5 |
| Josh Williams (Feb 01, 2005 at 06:59 GMT) |
Edited on Feb 01, 2005 07:00 GMT
| Joshua Dallman (Feb 01, 2005 at 07:28 GMT) |
| Phil Shenk (Feb 01, 2005 at 08:12 GMT) |
| Greg Ellwood (Feb 01, 2005 at 10:18 GMT) Resource Rating: 5 |
Great post Josh, I made it all the way through and am already looking forward to part 2.
| Melv May (Feb 01, 2005 at 10:24 GMT) |
I've kinda' become Melv 'mother' May to Josh as there's a line I always seem to be repeating to him ... "go to bed you fool, do you know what time it is?". Enjoyed the episode#1 read, can't wait for episode#2 and hopefully lots of others did too. If you read it, then please just post to say you did so that we can encourage Josh to post more!!! Please please please. :)
@Joshua: As Pat quite correctly stated, backwards compatibility is very, very important to us! It's one of the main reasons why we've got a 'chunked' sprite. It means that you can effectively have huge sprites but still only need 256x256 texture support on your card. I'd expect someone who knows very little about TGE to get up and running in an hour or two and most of that would probably be learning how to use the scripts. If you already understand the scripts then I'd expect it to take minutes to understand how to get a sprite on the screen. If you've been playing with T2D for a few days then you'd simply be amazed at what you could actually do for something like GID! The good thing about T2D is that you can learn the capabilities as you go along, you don't need to understand all the features before you start driving it. You don't have to setup dozens of parameters just to do a single thing, most stuff is real easy and T2D does the hard work for you, as it should be.
@Phil: T2D allows you to use the tilemaps in whatever manner you require. To answer your question directly, T2D will cull tiles that are not in the view but it's more flexible than simply that. Sure, you could make a tilemap that's huge and simply move the camera over the tilemap surface and T2D would do all the software culling of tiles for you. The thing is that the tiles don't use the screen as a primary clipping region, this would mean that the tiles would always have to sit within the view. Each tile layer can be moved around just like any other object, it can have its own size and be rotated arbitrarily, as any fxSceneObject2D can be. In-fact, T2D doesn't restrict features inherited from the core, no matter how inappropriate they may seem. You could, for instance, mount a tile-layer onto a sprite which itself is mounted onto a fxScroller which is itself mounted on a particle effect etc ... if you so wished! Anyway, back to your question; the tile-layer can have an unlimited number of tiles and you can specify the size of the tiles themselves. The tile-layer renders these tiles within the objects window which isn't necessarily the screen window and it culls the tiles that are outside this window or outside of the view. Most of the time you'd place your tile-layers so that they sit squarely on the screen and just position/pan the tiles, essentially like a virtual window but, as with all of T2D, it doesn't force you to use it in certain ways.
Josh covered this well but this is personally one of the things that I'm most happy about (although the particle-engine is a close second); the fact that all objects inherit from fxSceneObject2Ds huge set of capabilities without causing them to be cumbersome monstrosities (GameBase anyone?). Tech-talk about T2D is one thing, using it is another. I've been personally satisfied whilst doing T2D demos/tutorials that I can just "get stuff done" quickly. I won't say too much because I'll be going over ground that Josh is so adequately about to cover but when you want stuff to just work, it does, full stop. Object A mounted onto B? A.mount(b); Load and play cool particle effect? new fxParticleEffect(fx); fx.loadEffect("splash.eff"); fx.playEffect(); Create and configure an object? new fxAnimatedSprite2D(mySprite) { scenegraph = mySceneGraph; config = mySpriteConfig; };. Very easy stuff. You can now get on with the complexities of the logic of your game rather than worriying about the rest of it.
@Shannara: Just like to reiterate what I said on another thread about your concern about "gotcha's" on GG third-part product releases. Hopefully, from Joshs post, you can start to see the under-belly of T2D and what exactly you'll get when it's released soon. If you have any other questions then please ask either here or privately to Josh/myself; that of course goes to everyone. Ask away.
On a personal note, I'd just like to say that I've pretty much dedicated my life to T2D over the last 6-9 months. I wake thinking about it and fall to sleep wondering if I could've done something a better way and that's no joke. No really, I do. I worked almost solidly over xmas and I've taken many days off work, just so that I can dedicate my full energy to it. Now the reason I say this, isn't so that you can feel sorry for me, quite the contrary, I do it to myself but it does come back to one of Shannaras questions on a different thread; basically, will T2D be everything that it's 'hyped-up' to be?
Although that could be taken offensively, it is a valid question. Now believe this or not but the reason I work so damn hard on T2D (as do all of the GG guys, not just me) is that I can't bear the thought of selling something that I wouldn't want to buy myself. I mean that sincerely. The great thing about Joshs plan is that it's technical and not vague marketing-speak. This isn't hype, it's detail, it's what's in T2D now and there's even more to come (when Josh has had some sleep)! Upon release, Shannara, if you go out and buy it and it's all you expected it to be then I'll sleep well that evening and with all the hard work that's been put into it, there's no reason to think you won't be totally happy with it. :)
I would ask that you all be part of T2D; go out and try it, buy it, provide some feedback, all of which you'll be able to do soon. My connection with the community now is T2D so I'd love to hear your thoughts on what you'd want from it. We think we've thought of most things that'll be needed but there's always great ideas from the community so don't just read this thread, be part of it...
- Melv.
Edited on Feb 01, 2005 10:34 GMT
| Dan MacDonald (Feb 01, 2005 at 10:44 GMT) |
| Melv May (Feb 01, 2005 at 10:54 GMT) |
- Melv.
| Markus Nuebel (Feb 01, 2005 at 11:45 GMT) |
Very informative ... give us more.
-- Markus
| Matt Harpold (Feb 01, 2005 at 12:24 GMT) |
In all seriousness, I read the entire plan, and hopefully part 2 will be more of the same. (Ie, technical capabilities and not market speak)
Any word on the 2.5D/camera view capabilities?
How hard will it be to incorporate 2.5D/iso onto the existing camera class if it's not there already?
Also, what're the plans for being able to use mappy as a (basic?) tile editor, especially tied in with the above question?
| Melv May (Feb 01, 2005 at 12:36 GMT) |
[quote]That
Edited on Feb 01, 2005 12:44 GMT
| Joshua Dallman (Feb 01, 2005 at 13:07 GMT) |
Quote:
will T2D be everything that it's 'hyped-up' to be?
An engine is only as good as the games being made for it, that's what I say. Technology is no good for its own sake. It's going to be up to the community (and those outside it joining us for the first time) to make some kick-butt games for T2D to make it really shine. The burdon's on us, Melv, not you! You've done your part, now we'll have to do ours.
| Melv May (Feb 01, 2005 at 13:14 GMT) |
- Melv.
| Matt Harpold (Feb 01, 2005 at 13:31 GMT) |
The occlusion on objects passing behind tiles was going to be my question, but you've answered that. (More or less)
We'll probably tackle that problem at some point if we get to it before you do!
| Corey Martin (Feb 01, 2005 at 13:31 GMT) Resource Rating: 5 |
| Matthew Langley (Feb 01, 2005 at 15:46 GMT) Resource Rating: 5 |
Love your work Melv and Josh, can't wait.
| David Montgomery-Blake (Feb 01, 2005 at 16:55 GMT) Resource Rating: 5 |
Post more.
:)
| Melv May (Feb 01, 2005 at 17:25 GMT) |
- Melv.
| Shannara (Feb 01, 2005 at 19:06 GMT) |
From the replies I have read, it looks like there will be basically a directplay type clone for all pre 1.0 versions of T2D, then there will be complete networking (like what Torque has now) for version 1.0, end of 2005.
Thanks for clearing that up, I have about a year to wait before purchasing T2D.
| Melv May (Feb 01, 2005 at 19:15 GMT) |
Networking will be TGE networking well before year end of 2005. If this is just cynicism then please take it elsewhere, there's no need for it.
EDIT: Okay, this is perhaps a little too harsh but really, that conclusion just isn't correct. If that's been said before then it's just plain incorrect. Prioritising of certain features will always happen, supply and demand but networking has always been on the top of the list. The primary reason for all the hard work over the last two months has been to lay a groundwork for the important networking that's going to happen ASAP but after EA1. Maybe it'll be in EA2, who knows?
- Melv.
Edited on Feb 01, 2005 19:49 GMT
| Josh Williams (Feb 01, 2005 at 19:55 GMT) |
| Stephen Zepp (Feb 01, 2005 at 20:01 GMT) |
While down at the Torque Boot Camp presentation in Orlando, Ben Bradley demo'ed a really neat screen full of objects that had some nifty physics--gravity, impulse collisions, etc. They would stack up, the stack would vibrate a little as the various impulse play between the objects in the stack and nearby objects became damped down, and then settle into a static equilibrium.
Something that made every single person in the room blink: Ben was running the demo in windowed mode, and he moved the window itself using the mouse (note: NOT anything in the "scene" but the actual Windows(tm) window the application was running in).
Every time he moved the window, all of the objects within the window appeared to receive the impulse of the window itself moving--and jittered down to a different static equilibrium after a few seconds.
Honestly, I have NO clue if this was a bug, a planned physics state, unplanned "emergent behaviour", or simply an illusion--but it was one of the most impressive visual effects I have ever seen!
Edited on Feb 01, 2005 20:13 GMT
| Ben Woodhead (Feb 01, 2005 at 20:09 GMT) |
Later, Ben
| Melv May (Feb 01, 2005 at 20:16 GMT) |
- Melv.
| Shannara (Feb 01, 2005 at 21:02 GMT) |
----
I
| Josh Williams (Feb 01, 2005 at 21:38 GMT) |
Stephen, cool re: the GAMES conf. I wish we would've had some of the new demos we're working on ready for you guys to show off.
| Melv May (Feb 01, 2005 at 22:50 GMT) |
[quote]I
Edited on Feb 01, 2005 22:53 GMT
| Matt Harpold (Feb 01, 2005 at 23:23 GMT) |
On a more serious note, would it be at all possible (from a licensing point of view) to use TNL at some point for T2D?
| Jay Moore (Feb 02, 2005 at 01:15 GMT) Resource Rating: 5 |
| Matthew Langley (Feb 02, 2005 at 05:19 GMT) Resource Rating: 5 |
| Josh Williams (Feb 02, 2005 at 07:35 GMT) |
Jay, everybody just gives you marketing guys a hard time because they love ya so much.
| Melv May (Feb 02, 2005 at 08:20 GMT) |
@Jay: Josh? Sleep? Man, those words just don't sound right together somehow. ;)
- Melv.
| Gabor Forrai (Feb 02, 2005 at 15:26 GMT) |
Im crying for a good particle system, but looks like i will got it...in T2D :) I need phisics, easy prototype possibilities...i will got it...in T2D.
T2D purely rocks, my crew will to use it as it will be to released.
The T2D develepment looks like the most exciting process (except TSE) in the garage. Isnt it ?
I must to say again : i cant to wait to put my hands on the technology ! Could be better to got it sooner than later ;)
Thanks Melv and Josh, your works looks like rockhard as always, or are you a professional tale-talker Josh ;) Im voting on the first aspect !
Edited on Feb 02, 2005 15:28 GMT
| Jeff Tunnell (Feb 02, 2005 at 19:19 GMT) |
T2D is an amzing product. I have seen it in operation here at GG, and it blows me away. I think it will be our biggest selling product.
-Jeff Tunnell GG
| Corey Martin (Feb 02, 2005 at 19:50 GMT) Resource Rating: 5 |
It's coming.. Oh yes, it's coming..
| Shannara (Feb 02, 2005 at 21:01 GMT) |
Anyways, back to Josh, I cant wait to see it in action.
| Stephen Zepp (Feb 02, 2005 at 23:42 GMT) |
| Shannara (Feb 02, 2005 at 23:58 GMT) |
Now that the replies were fleshed out nicely, well... ;)
| Robert Brower (Feb 03, 2005 at 02:35 GMT) |
Robert Brower
| Josh Williams (Feb 03, 2005 at 09:10 GMT) |
Just an update here guys... looks like I won't realistically get time to do this .plan until the weekend. Sorry about that.
| Phil Shenk (Feb 03, 2005 at 09:46 GMT) |
My own paltry visions have been dreaming of 2d sidescrollers and top-downers with dynamic lights playing across tilemaps, sprites, etc. Diablo, Nox, etc did amazing things with gouraud shaded tiles, and I've been thinking about this for awhile now. Will T2D offer any semblance of lights on 2D entities?
And then I started thinking about... what if there were per pixel lights effecting specular and normal-mapped 2D entities? Imagine how a rocky ground tilemap would look with per pixel normal mapped lights playing across it. Or spinning asteroids with bumps and craters catching specular highlights... All in 2D!
Anyway, maybe I'm on crack. Seems like a cool idea though.
| Melv May (Feb 03, 2005 at 10:25 GMT) |
- Melv.
| Phil Shenk (Feb 03, 2005 at 16:17 GMT) |
| Charlie Malbaurn (Feb 04, 2005 at 06:46 GMT) |
I mean do they support things like 32 bit alpha blend? Stuff like that
| Melv May (Feb 04, 2005 at 08:51 GMT) |
- Melv.
| Gareth Davies (Feb 04, 2005 at 11:50 GMT) Resource Rating: 5 |
Way to go guys!
Just think of how easy it will be to make a match 3 / bubble popper now ;)
Wow I could almost hear that collective groan :P
| David Montgomery-Blake (Feb 04, 2005 at 19:37 GMT) Resource Rating: 5 |
Well, okay, they're not that hot or little, but I still want it!
| Matthew Langley (Feb 04, 2005 at 20:06 GMT) Resource Rating: 5 |
| Matt Harpold (Feb 05, 2005 at 16:25 GMT) |
| Corey Martin (Feb 05, 2005 at 16:55 GMT) Resource Rating: 5 |
| Melv May (Feb 05, 2005 at 17:05 GMT) |
Josh just went to bed not long ago. Poor guy was up until 8am without sleep from the night before. Some of that was my fault, we were discussing T2D design stuff for the last few hours.
He should be doing this very soon though.
- Melv.
| Matt Harpold (Feb 05, 2005 at 18:00 GMT) |
He's probably dreaming of particles and tiles and stuff right now. ;)
| Melv May (Feb 05, 2005 at 18:04 GMT) |
I think he's more than likely having a nightmare, tossing and turning, grumbling and muttering.
Oh who am I kidding, he's probably still awake and on his compy. ;)
- Melv.
| Charlie Malbaurn (Feb 06, 2005 at 00:43 GMT) |
That would be cool.
Hell, it's going to be cool regardless
| Matt Harpold (Feb 06, 2005 at 02:23 GMT) |
| Matthew Langley (Feb 06, 2005 at 03:16 GMT) Resource Rating: 5 |
jk, but no seriously
.... @Melv -"just like to clarify that there was a continent and an ocean between us!"
glad you added that Melv lol
| Josh Williams (Feb 06, 2005 at 03:53 GMT) |
Everyone, re: lighting and shaders, etc... all I'll say for now is, yes that would be darn cool, we like doing cool things, and we've thought about this *a lot*. So....
| Charlie Malbaurn (Feb 06, 2005 at 05:57 GMT) |
I know everyone who played those types of games always wondered what they could do with whats out there now.........
| Josh Williams (Feb 06, 2005 at 06:13 GMT) |
| Charlie Malbaurn (Feb 06, 2005 at 06:22 GMT) |
If youi finish it soon though, I can stop hunting you down in other threads :)
| Matt Harpold (Feb 06, 2005 at 19:14 GMT) |
Are there any plans (post?) EA release for non-source versions of T2D?
| Corey Martin (Feb 07, 2005 at 03:11 GMT) Resource Rating: 5 |
| Josh Williams (Feb 07, 2005 at 08:07 GMT) |
| Charlie Malbaurn (Feb 07, 2005 at 13:45 GMT) |
I would love to see something that was small enough to put 2d games in a web based enviroment.
| Charlie Malbaurn (Feb 07, 2005 at 15:45 GMT) |
I think that's a hint :)
| Corey Martin (Feb 07, 2005 at 16:54 GMT) Resource Rating: 5 |
| Matt Harpold (Feb 07, 2005 at 17:09 GMT) |
I don't quite see how you could use TGE/T2D to make java games, though.
Also, can't wait for the next one. We're hanging on your every word, Josh!
| Charlie Malbaurn (Feb 08, 2005 at 04:00 GMT) |
| Matt Harpold (Feb 08, 2005 at 05:42 GMT) |
| Charlie Malbaurn (Feb 08, 2005 at 14:52 GMT) |
I'm looking at it from that point.
Small is wonderful.
| Edward F. Maurina III (Feb 08, 2005 at 19:49 GMT) Resource Rating: 5 |
Although I'm already too busy between EGTGE, my day job, and game projects ( which I'd like to find time for), I am really looking forward to the Torque 2D engine [being completed]. I'm sure I'm not alone in this, but I have a list of game idea a mile long and not all of these ideas are suited to the Torque 3D or TSE environments. Some really require a 2D approach instead. Not having a 2D engine to work with I placed those items on the shelf long ago. Now with Melv's T2D coming I've begun to revisit that dusty pile of ideas...
@All - It is my great hope to see many new games come to IGC'05 and among them T2D games!
EdM|EGTGE
Edited on Feb 08, 2005 19:52 GMT
| Corey Martin (Feb 09, 2005 at 15:34 GMT) Resource Rating: 5 |
| Matt Harpold (Feb 09, 2005 at 19:02 GMT) |
You must be a member and be logged in to either append comments or rate this resource.
