Plan for Melv May
by Melv May · 07/21/2004 (12:10 pm) · 21 comments
... continued from previous plan.
Okay, I've been really quiet the last week or so and I guess you think I've been slacking-off. How wrong you'd be thinking that....
I've almost completed the tile-map functionality!
I've kept a link of all my previous plans on the how/what I was going to implement so I'm not going to go into lots of details about this work here. I know the art-work isn't that attractive but it's not supposed to be pretty because I'm not an artist but it is designed to thrash the tile-map to death!
To sum-up, you've got unlimited layers, each having an unlimited number of tiles and size. As you'll find in my previous post (see above), each tile can be either a static-image, animated-image, script-commands or active-tile (custom class for gun-turrets etc). All the layers are generated from a fxTileMap2D object and you can also have as many of these as you require as well!
Each layer that's created is a core-object which means that it has all the functionality that all the objects have such as rotation, physics, mounting etc.
A complete new feature is the ability to change any objects blending options. You can control all objects this way giving you the ability to create some pretty cool (and sometimes crazy) effects. The tilemaps are no different and you could render any of the tiles using all the src/dst blending options of OpenGL.
All this, of course, is driven by the scripts, as in this demo. The tiles come with full-collision detection using an identical system as before which works extremely well and is very fast!
The whole tile-map can be dumped to a single file ready to be loaded back using a single script-command. You can swap the tiles on-the-fly by either setting the tiles usings the scripts or changing which datablocks are associated with them and you get an instant change. There are extensions to the C++ side of things to allow for the streaming of tiles from whatever source you want.
You get to choose what layers go where and how they're rendered. It can all be saved to disk for instant retrieval. The great thing here is that everything is script-driven and paves the way for an internal editor within the TGE. You can hook into popular formats such as those created by 'Mappy' or 'TileStudio' easily. An importer would read the files such as FMAPS and drive the configuration of the fxTileMap2D either by scripts or C++. You'll probably not want to do this on the fly but rather allow the fxTileMap2D to save the map in its native format but it's your choice.
Okay, here it is, bring the questions on.... :)
All the best,
- Melv.
Windows .WMV Movies
.WMV Movie #1
.WMV Movie #2 (Rotation)
.WMV Movie #3 (Blending Modes)
Animated LEDs with Checkers!
Different Layers, complete different tile-size support!
Layer Rotation with full-collision support; note the FPS!
Fully integrated with camera zoom system
Okay, I've been really quiet the last week or so and I guess you think I've been slacking-off. How wrong you'd be thinking that....
I've almost completed the tile-map functionality!
I've kept a link of all my previous plans on the how/what I was going to implement so I'm not going to go into lots of details about this work here. I know the art-work isn't that attractive but it's not supposed to be pretty because I'm not an artist but it is designed to thrash the tile-map to death!
To sum-up, you've got unlimited layers, each having an unlimited number of tiles and size. As you'll find in my previous post (see above), each tile can be either a static-image, animated-image, script-commands or active-tile (custom class for gun-turrets etc). All the layers are generated from a fxTileMap2D object and you can also have as many of these as you require as well!
Each layer that's created is a core-object which means that it has all the functionality that all the objects have such as rotation, physics, mounting etc.
A complete new feature is the ability to change any objects blending options. You can control all objects this way giving you the ability to create some pretty cool (and sometimes crazy) effects. The tilemaps are no different and you could render any of the tiles using all the src/dst blending options of OpenGL.
All this, of course, is driven by the scripts, as in this demo. The tiles come with full-collision detection using an identical system as before which works extremely well and is very fast!
The whole tile-map can be dumped to a single file ready to be loaded back using a single script-command. You can swap the tiles on-the-fly by either setting the tiles usings the scripts or changing which datablocks are associated with them and you get an instant change. There are extensions to the C++ side of things to allow for the streaming of tiles from whatever source you want.
You get to choose what layers go where and how they're rendered. It can all be saved to disk for instant retrieval. The great thing here is that everything is script-driven and paves the way for an internal editor within the TGE. You can hook into popular formats such as those created by 'Mappy' or 'TileStudio' easily. An importer would read the files such as FMAPS and drive the configuration of the fxTileMap2D either by scripts or C++. You'll probably not want to do this on the fly but rather allow the fxTileMap2D to save the map in its native format but it's your choice.
Okay, here it is, bring the questions on.... :)
All the best,
- Melv.
Windows .WMV Movies
.WMV Movie #1
.WMV Movie #2 (Rotation)
.WMV Movie #3 (Blending Modes)
Animated LEDs with Checkers!
Different Layers, complete different tile-size support!
Layer Rotation with full-collision support; note the FPS!
Fully integrated with camera zoom system
About the author
#2
Hope the birthday was grand!
07/21/2004 (12:41 pm)
Simply amazing! This is my most awaited Torque addition.Hope the birthday was grand!
#3
You can control the sub-ordering of all objects within the layers via the scripts. You can move objects back/forward within layers and obviously to other layers. The problem is that I just spent about 5 minutes doing the art and 10 days doing the code. ;)
To save confusion, I should've mentioned that there are four layers here, the checkers being on one so they should be in-front of some of the others. Notice that different sized tiles are supported as each tile-layer is independant but linked together via the fxTileMap2D.
The birthday was superb! Dranks lots of beer, had lots of laughs and got really silly. :)
- Melv.
EDIT: I updated screenshot#4; I removed the awful blue border in the imageMaps for the shiny spheres.
07/21/2004 (12:52 pm)
@David G: Don't worry about that blending, it's just because those shiny balls had a blue background that I hacked out using Photoshops magic-wand. There's no alpha surrounding it, it's not a problem with the blending or anything. I did say it was crap artwork. :)You can control the sub-ordering of all objects within the layers via the scripts. You can move objects back/forward within layers and obviously to other layers. The problem is that I just spent about 5 minutes doing the art and 10 days doing the code. ;)
To save confusion, I should've mentioned that there are four layers here, the checkers being on one so they should be in-front of some of the others. Notice that different sized tiles are supported as each tile-layer is independant but linked together via the fxTileMap2D.
The birthday was superb! Dranks lots of beer, had lots of laughs and got really silly. :)
- Melv.
EDIT: I updated screenshot#4; I removed the awful blue border in the imageMaps for the shiny spheres.
#4
Could you put together and post a lisf of the new classes you've created and what kind of capabilities there are? Or will that be part of your rollout.
And speaking of which, what are the plans here? Time and cost of when this gem is going to be something we can touch and do something with?
Yeah, I'm impatient.
07/21/2004 (1:29 pm)
Ahhh Melv, you're driving me nuts with this resource. I'm just salivating over my keyboard here.Could you put together and post a lisf of the new classes you've created and what kind of capabilities there are? Or will that be part of your rollout.
And speaking of which, what are the plans here? Time and cost of when this gem is going to be something we can touch and do something with?
Yeah, I'm impatient.
#5
07/21/2004 (7:01 pm)
Was starting to get T2D and Melv withdrawls. Its not good to go off something this good cold turkey ;). I feel better now :D 
#6
On a side note My card came bouncing back to me Melv...next time I'll send an E-Card or learn to spell (blasted fountain pen doesn't have a spell checker :oP
07/22/2004 (12:37 am)
I'm already looking over the old C64 classics I want to remake :o)On a side note My card came bouncing back to me Melv...next time I'll send an E-Card or learn to spell (blasted fountain pen doesn't have a spell checker :oP
#7
This is about all the information I've got at the moment regarding its release.
@Bil: Here's an idea of the objects in no particular order...
Script-Objects:
fxAnimatedSprite2D - Can play defined animations.
fxTileLayer2D - Discrete tile layer.
fxTileMap2D - Manages a set of tile-layers.
fxSceneGraph2D - Manages a set of 2D scene objects.
fxSceneObject2D - The core-object that provides culling, collision, picking, physics, mounting etc.
fxSceneWindow2D - Custom GUI window with sophisticated built-in camera system. Can view any fxSceneGraph2D.
fxScroller2D - Similar to fxStaticSprite2D but has the ability to automatically scroll its contents in both-axis.
fxStaticSprite2D - Non-animated sprites; slightly higher performance than fxAnimationSprite2D.
... and associated datablocks ...
fxActiveTileDatablock2D
fxAnimationDatablock2D
fxAnimatedSpriteDatablock2D
fxImageMapDatablock2D
fxSceneGraphDatablock2D
fxSceneObjectDatablock2D
fxScrollerDatablock2D
fxStaticSpriteDatablock2D
fxTileMapDatablock2D
C++ classes only:
fxActiveTile2D - Active Tile Class used for custom tile-objects such as Gun Turrets etc.
fxAnimationController2D - Manages an animation using imagery from a fxImageMapDatablock2D.
fxBaseDatablock2D - Core datablock that handles integrity/verification of passed datablocks.
fxSceneBinReference2D - Culling/Collision system bin reference.
fxSceneContainer2D - Container system for Bin system.
I will just mention that as it stands, you only need to include the C++ code files into stock TGE for everything to work. Just add them, rebuild and you're ready without any other changes; you do not need to make a single change to any other part of the TGE codebase!
The only impact this has on my code is how/where T2D gets its timebase from and so if it were to be integrated into TGE, for example, then I'd probably start to wire-in the timebase and make a minor change to TGE build. The other impact would be registering datablock-types with TGE. At the moment, I've got a core-class, fxBaseDatablock2D that does integrity/verification to ensure that the correct datablocks are passed to the correct objects and warn if this isn't the case.
None of this *has* to change and would probably be best if it didn't as I want to make the integration stupidly simple, something which I believe I've achieved.
- Melv.
07/22/2004 (1:40 am)
I'm releasing this through GG. The main reason for this is that GG can help me with not only getting this out to everyone but also the support needed to generate a demo etc. I've already done comprehensive documentation for the whole framework including a complete tutorial on creating a basic shoot-em-up and I'll be collaborating with GG on getting this done.This is about all the information I've got at the moment regarding its release.
@Bil: Here's an idea of the objects in no particular order...
Script-Objects:
fxAnimatedSprite2D - Can play defined animations.
fxTileLayer2D - Discrete tile layer.
fxTileMap2D - Manages a set of tile-layers.
fxSceneGraph2D - Manages a set of 2D scene objects.
fxSceneObject2D - The core-object that provides culling, collision, picking, physics, mounting etc.
fxSceneWindow2D - Custom GUI window with sophisticated built-in camera system. Can view any fxSceneGraph2D.
fxScroller2D - Similar to fxStaticSprite2D but has the ability to automatically scroll its contents in both-axis.
fxStaticSprite2D - Non-animated sprites; slightly higher performance than fxAnimationSprite2D.
... and associated datablocks ...
fxActiveTileDatablock2D
fxAnimationDatablock2D
fxAnimatedSpriteDatablock2D
fxImageMapDatablock2D
fxSceneGraphDatablock2D
fxSceneObjectDatablock2D
fxScrollerDatablock2D
fxStaticSpriteDatablock2D
fxTileMapDatablock2D
C++ classes only:
fxActiveTile2D - Active Tile Class used for custom tile-objects such as Gun Turrets etc.
fxAnimationController2D - Manages an animation using imagery from a fxImageMapDatablock2D.
fxBaseDatablock2D - Core datablock that handles integrity/verification of passed datablocks.
fxSceneBinReference2D - Culling/Collision system bin reference.
fxSceneContainer2D - Container system for Bin system.
I will just mention that as it stands, you only need to include the C++ code files into stock TGE for everything to work. Just add them, rebuild and you're ready without any other changes; you do not need to make a single change to any other part of the TGE codebase!
The only impact this has on my code is how/where T2D gets its timebase from and so if it were to be integrated into TGE, for example, then I'd probably start to wire-in the timebase and make a minor change to TGE build. The other impact would be registering datablock-types with TGE. At the moment, I've got a core-class, fxBaseDatablock2D that does integrity/verification to ensure that the correct datablocks are passed to the correct objects and warn if this isn't the case.
None of this *has* to change and would probably be best if it didn't as I want to make the integration stupidly simple, something which I believe I've achieved.
- Melv.
#8
07/22/2004 (9:30 am)
Awesome stuff, Melv. :) Can't wait to start working with you on this. 
#9
Hey Mel my bro asked could this be alter to do SCUMM style games as well. We would love to make homages to our old SCUMM favorites. Quest for Glory, Space Quest etc., I know it would be overkill but after seeing today's IOTD. Torque is more than a FPS engine now. :)
John H.
07/22/2004 (1:01 pm)
@MelvHey Mel my bro asked could this be alter to do SCUMM style games as well. We would love to make homages to our old SCUMM favorites. Quest for Glory, Space Quest etc., I know it would be overkill but after seeing today's IOTD. Torque is more than a FPS engine now. :)
John H.
#10
You could certainly do SCUMM style games without this as it stands as it's just a simple case of using static/animated layers images and using the scripts to drive each scene and the objects within.
That'd be totally sweet to see a SCUMM-style game like "revenge of the mutant tentacle" done using T2D. :)
- Melv.
07/22/2004 (2:06 pm)
@Johnny: There's no reason why not. I was chatting to my bud Craig last week about the possibility of him developing, in the future, something like a set of Flash-style objects. This would be great for generating 2D intros, 2D adventure games aka SCUMM style games. What I was really getting to was a set of objects that allow primitives to be drawn, like meta-files.You could certainly do SCUMM style games without this as it stands as it's just a simple case of using static/animated layers images and using the scripts to drive each scene and the objects within.
That'd be totally sweet to see a SCUMM-style game like "revenge of the mutant tentacle" done using T2D. :)
- Melv.
#11
Sam and Max come to Garage Games! Viva la Whack a Rat!
07/22/2004 (2:50 pm)
Nice. Yes, SCUMM games were the bomb (even when LucasArts went to the cartoon interface with Sam and Max and Day of the Tentacle, even better!). A SCUMM game with Torque would be so sweet. 3D characters but with the nice simple interface of "click here" and "open door" commands. Sam and Max come to Garage Games! Viva la Whack a Rat!
#12
As I've demonstrated, the tilemap layers are standard core fxSceneObject2D objects and in that way, they can be rotated. Now this seems cool but it obviously comes at a price. There are two methods to be used here to cull the tiles.
The first, and quickest, being that only the tiles that are exposed by the size of the tile-layer object (not the total tile layer size) are dealt with but this size could be larger than the viewport meaning that tiles are dealt with before they should be. This is not so much of a problem for the rendering tiles apart from the overhead but for script tiles where commands are called when they are dealt with, this becomes a problem.
The second, and slowest, is for each tile to be checked against the viewport which can get expensive. To qualify that, it's not prohibitively expensive but is there nevertheless.
I guess the vote, is for whether being able to rotate this object is actually valuable? Don't forget that you can scroll at any arbitrary angle anyway and I've kind of got into the thinking that this scrolling although pretty, isn't that useful and guzzles CPU ticks. I don't recall many games where the tiles themselves actually rotate and not doing so enables *much* (and I do mean *much*) faster culling of the tiles.
If you don't think rotating the tiles is useful then please let me know. I'm so convinced that they're not that I'm currently writing a faster version of the render function which is used if at zero rotation and switch to that but the performance jump could be noticable with complex tilemaps so I think having non-rotation is better.
Thoughts?
- Melv.
07/23/2004 (2:34 am)
I'd like a quick vote if possible...As I've demonstrated, the tilemap layers are standard core fxSceneObject2D objects and in that way, they can be rotated. Now this seems cool but it obviously comes at a price. There are two methods to be used here to cull the tiles.
The first, and quickest, being that only the tiles that are exposed by the size of the tile-layer object (not the total tile layer size) are dealt with but this size could be larger than the viewport meaning that tiles are dealt with before they should be. This is not so much of a problem for the rendering tiles apart from the overhead but for script tiles where commands are called when they are dealt with, this becomes a problem.
The second, and slowest, is for each tile to be checked against the viewport which can get expensive. To qualify that, it's not prohibitively expensive but is there nevertheless.
I guess the vote, is for whether being able to rotate this object is actually valuable? Don't forget that you can scroll at any arbitrary angle anyway and I've kind of got into the thinking that this scrolling although pretty, isn't that useful and guzzles CPU ticks. I don't recall many games where the tiles themselves actually rotate and not doing so enables *much* (and I do mean *much*) faster culling of the tiles.
If you don't think rotating the tiles is useful then please let me know. I'm so convinced that they're not that I'm currently writing a faster version of the render function which is used if at zero rotation and switch to that but the performance jump could be noticable with complex tilemaps so I think having non-rotation is better.
Thoughts?
- Melv.
#13
One of the first things I thought of when I first saw T2D was about its application to adventure gaming. The core that you showed off initially would have worked perfectly for an adventure game as long as the artwork layers were designed correctly. That was back before tile mapping was added!
07/23/2004 (6:10 am)
How about leaving the functionality alone as it is, but giving a heavy warning with the rotation set to zero as a default. I'm thinking that having the rotation could be nice for things like level transitions, etc...which wouldn't matter as much when it comes to performance since your game logic is already past. And then you can work on the good stuff.One of the first things I thought of when I first saw T2D was about its application to adventure gaming. The core that you showed off initially would have worked perfectly for an adventure game as long as the artwork layers were designed correctly. That was back before tile mapping was added!
#14
Thanks for replying. :)
- Melv.
07/23/2004 (6:20 am)
@David: Could you explain how it would be useful for Level Transitions? Do you mean like some kind of special-fx? It does seem like an awful lot of code just so that it can be used for special-fx. Do you think it would be useful in an actual game though?Thanks for replying. :)
- Melv.
#15
I was mainly thinking of it from the special effects side. Say you have a RPG and you get into big bad brawl. You could wildly rotate and zoom the map and then transition to the battle layer. While not important to gameplay in any way, it's a common transition effect (as is the map flying around randomly, or wipes, etc).
My thought was based in the "if you've put time into it and it works but you're not happy with it, then leave it in for the 1% who wants to create a rotating tetris map and work on the remaining core functionality that the other 99% will make use of" camp.
I have no idea if that made any sense. I've been glowering over obfuscated Perl this morning and trying to figure out how its interfacing with WebCT, so my mind is a bit wonky.
07/23/2004 (9:08 am)
Actual gameplay, no. I think it would actually be confusing to move around a rotating tiled map. Or simply judging collision on edges of a rotating map. I'm sure that someone would use it effectively and make me think that it was the coolest thing since sliced bread, but I can't think of an implementation of gameplay where it would be effective right now. But the functionality is currently there if someone wanted to make wildly gyrating levels (whether for their own amusement of because they want to annoy their friends is up to them).I was mainly thinking of it from the special effects side. Say you have a RPG and you get into big bad brawl. You could wildly rotate and zoom the map and then transition to the battle layer. While not important to gameplay in any way, it's a common transition effect (as is the map flying around randomly, or wipes, etc).
My thought was based in the "if you've put time into it and it works but you're not happy with it, then leave it in for the 1% who wants to create a rotating tetris map and work on the remaining core functionality that the other 99% will make use of" camp.
I have no idea if that made any sense. I've been glowering over obfuscated Perl this morning and trying to figure out how its interfacing with WebCT, so my mind is a bit wonky.
#16
Thanks. :)
- Melv.
07/23/2004 (9:16 am)
@David: I get where you're coming from now. If it was used like that then that would be fine. I've done the zero-rotation version and it's an order of magnitude faster so that'll be the default mode.Thanks. :)
- Melv.
#17
Every play the Sonic game for the original Genesis? In that, there was a special level in which you bounced around like a pinball, as the level rotated around you. While this was simulated very craftily by using animated tiles, that is the sort of thing that a rotating tilemap would let you create.
I'd say, leave the hooks in there but just have it do nothing. Go ahead and release T2D with non-rotating tilemaps. Then, if people ask for it, and you get free time, add a new tilemap class that allows rotation. Don't let creeping featurism delay this release forever. ;)
PS: Doh! Glad to see it's not transparency sorting issue, then.
07/23/2004 (9:59 am)
@Melv: Sounds like you're talking about implementing a so-called "Mode7" style effect. (Named after SNES's video mode #7, which could rotate/scale one of its tile planes in almost any direction/size.) It'd be neat to have, but I don't see any real use for it -- As long as you want to make "traditional" 2D games.Every play the Sonic game for the original Genesis? In that, there was a special level in which you bounced around like a pinball, as the level rotated around you. While this was simulated very craftily by using animated tiles, that is the sort of thing that a rotating tilemap would let you create.
I'd say, leave the hooks in there but just have it do nothing. Go ahead and release T2D with non-rotating tilemaps. Then, if people ask for it, and you get free time, add a new tilemap class that allows rotation. Don't let creeping featurism delay this release forever. ;)
PS: Doh! Glad to see it's not transparency sorting issue, then.
#18
Thanks guys.
- Melv.
07/23/2004 (10:20 am)
@David: Okay, if Bil says yes then I guess that will be 3 for 3. :) I'll leave it in with some warning that arbitrary rotation is not as fast as zero-rotation.Thanks guys.
- Melv.
#20
08/01/2005 (7:55 pm)
Great work Melv!!! 
Torque Owner Fenrir Wolf
The only thing I did notice, in screenshot #1 and #4, however, is what looks like blending priority issues. The checkers look like they are being drawn after the other layers -- Which makes sense for the tile system, but how will this be resolved for transparent-edged sprites?
As always, you impressed the heck out of me with your progress on T2D. Can't wait to play with this!
BTW, enjoy the birthday bash? :)