Plan for Melv May
by Melv May · 07/09/2004 (10:05 am) · 18 comments
... continued from previous plan
I've been quiet for the last few days but that's because I've had my head down coding-hard in the 'zone'.
Started working on the tile-map functionality of T2D and it's going really well. Severe lack of piccys in this plan I'm afraid but the code that's gone on in the last few days will more than make up for it.
I'm working on an abstracted tile-map core that allows people to write their own importers for popular tile-map editors with the ultimate goal of getting one built with the TGE for WYSISYG editing.
The functionality of each tile is essentially, quite simple with each one being defined as one of four types:-
Static
Non-Animated Renderable Tile for simple background graphics.
Dynamic
Animated Renderable Tile for complex animated effects.
Script
Can generate custom script commands when tile is shown or hidden. These can be limited to running n-times only if required. This allows you to build functionality to do almost anything and use these tile entries to trigger key events such as end-of-level or spawning events etc.
Active
Custom-Built Tile-Object Class. There's a core class that these objects are built upon. They have time-base, collision and rendering capabilities very much like the core object class fxSceneObject2D with the exception that these objects automatically track their associated tile position. They can be used for AI gun-turrets or almost anything. They also don't have to render if you don't wish. They do provide a great framework for generating in-situ intelligent tile-map objects without the fuss of having to track the tile-map itself.
Another neat feature I'm working on is the 2D object portal. This object is generated automatically by the framework and can be accessed from both C++ and script. It's a simple concept but it allows a nice level of abstraction for object communication. Let's say that you've developed a really neat rotating gun turret tile-object that you want to track the "player" or any object that you care to name. First, you can develop the object to track a fixed-named portal object or even a dynamic one but for our example, let's say it's fixed to track the "player" object.
When the actual "player" object is generated in the game (which could be any object based upon the core) then it registers itself with the object-portal in the scripts with '%portal.addObject(%myPlayerObj, "player")'. From then on, any object that wants to reference the 'player' object simply uses .%portal.getObject("player")' to get a reference to it. Our cool AI gun-turret class is programmed such that it tracks and fires at the "player" object. It does this in its time-update function by getting the object via the object-portal and tracking its gun appropriately. This tile-map object (or any other type of object) can have object-context data referenced via the object-portal. The good thing about this is that no messy fixed-dependancies are there, only named references.
There's support for forward and reverse lookup in both C++ and scripts.
Anyway, time for a bath and then back to work ... this is the best fun I've had for ages....
... and it's my birthday on Saturday and I've got a big party!!! :)
- Melv.
I've been quiet for the last few days but that's because I've had my head down coding-hard in the 'zone'.
Started working on the tile-map functionality of T2D and it's going really well. Severe lack of piccys in this plan I'm afraid but the code that's gone on in the last few days will more than make up for it.
I'm working on an abstracted tile-map core that allows people to write their own importers for popular tile-map editors with the ultimate goal of getting one built with the TGE for WYSISYG editing.
The functionality of each tile is essentially, quite simple with each one being defined as one of four types:-
Static
Non-Animated Renderable Tile for simple background graphics.
Dynamic
Animated Renderable Tile for complex animated effects.
Script
Can generate custom script commands when tile is shown or hidden. These can be limited to running n-times only if required. This allows you to build functionality to do almost anything and use these tile entries to trigger key events such as end-of-level or spawning events etc.
Active
Custom-Built Tile-Object Class. There's a core class that these objects are built upon. They have time-base, collision and rendering capabilities very much like the core object class fxSceneObject2D with the exception that these objects automatically track their associated tile position. They can be used for AI gun-turrets or almost anything. They also don't have to render if you don't wish. They do provide a great framework for generating in-situ intelligent tile-map objects without the fuss of having to track the tile-map itself.
Another neat feature I'm working on is the 2D object portal. This object is generated automatically by the framework and can be accessed from both C++ and script. It's a simple concept but it allows a nice level of abstraction for object communication. Let's say that you've developed a really neat rotating gun turret tile-object that you want to track the "player" or any object that you care to name. First, you can develop the object to track a fixed-named portal object or even a dynamic one but for our example, let's say it's fixed to track the "player" object.
When the actual "player" object is generated in the game (which could be any object based upon the core) then it registers itself with the object-portal in the scripts with '%portal.addObject(%myPlayerObj, "player")'. From then on, any object that wants to reference the 'player' object simply uses .%portal.getObject("player")' to get a reference to it. Our cool AI gun-turret class is programmed such that it tracks and fires at the "player" object. It does this in its time-update function by getting the object via the object-portal and tracking its gun appropriately. This tile-map object (or any other type of object) can have object-context data referenced via the object-portal. The good thing about this is that no messy fixed-dependancies are there, only named references.
There's support for forward and reverse lookup in both C++ and scripts.
Anyway, time for a bath and then back to work ... this is the best fun I've had for ages....
... and it's my birthday on Saturday and I've got a big party!!! :)
- Melv.
About the author
#4
With this, I could convert my most recent 2D game into Torque with minimal fuss, since it's entire structure is controlled by non-visible elements in the tile map.
Keep up the great work!
PS: Enjoy yourself, leave the PC alone for a while, even though I know you must be excited about T2D. I know I sure am!
07/09/2004 (10:28 am)
Holy poop, Melv, this is sounding better and better! The portal-based system there will help object tracking a lot. I could see this being used for multi-piece objects, for example a giant boss ship that has armor plates, or satellite turrets that you can shoot off. That way, no messy object IDs to keep track of.With this, I could convert my most recent 2D game into Torque with minimal fuss, since it's entire structure is controlled by non-visible elements in the tile map.
Keep up the great work!
PS: Enjoy yourself, leave the PC alone for a while, even though I know you must be excited about T2D. I know I sure am!
#5
Best wishes, and all that jazz
Keep on Torquin' !!
07/09/2004 (10:33 am)
Happy Birthday, can't be there in person, but certainly am in spirit :)Best wishes, and all that jazz
Keep on Torquin' !!
#7
Seriously though, I'm in the zone so I'm finding it difficult to leave the PC for 30 minutes to eat but on Saturday I'll be socialising again, drinking merilly and probably falling asleep in a drunken slumber.
Then on Sunday, with a stinking hangover it's keyboard time again........ %)
Thanks everyone. :)
07/09/2004 (10:52 am)
Must leave PC for 5 minutes ... cannot find strength ... compelled to code ... just one more tile-map function ... must break free ... arrrggghh.Seriously though, I'm in the zone so I'm finding it difficult to leave the PC for 30 minutes to eat but on Saturday I'll be socialising again, drinking merilly and probably falling asleep in a drunken slumber.
Then on Sunday, with a stinking hangover it's keyboard time again........ %)
Thanks everyone. :)
#8
07/09/2004 (11:33 am)
Two .plans in a row without pics? I'm disappointed, Melv! ;)
#9
This one's probably more interesting to David/Bil. I've been experimenting with various paradigms for tile-map control/rendering and I've kind of choosen a way to go forward. Hopefully, you'll not find a problem with it but I'd like your opinions on potential holes in the design.
Let me clarify how the tile-map stuff will hang together...
Above I explained how the tiles are encoded but never mentioned anything about other custom meta-data. I'm not exactly convinced that with the above scheme, you'd don't need meta-data but I'd like to be proven wrong here. One thing that is obviously essential are the collision flags. I've opted for a scheme where you've got a single collision flag e.g. collidable. The object that collides would get contextual info on the tile it collided with and it's here that there's a possibility that meta-data could be useful? It would be interesting to know if fully extendible meta-data was essential or a few fixed abstract fields only.
I was also wondering if having four collision flags, one for each tile-edge would be useful. This could be used so that you could jump up through a ledge in a level game if you were travelling upwards but you couldn't fall through the ledge if you landed on it. Would this be handled some other way I've not thought about?
I'm trying to think about lots of different 2D game styles and see how I can topple my framework. So far it's standing-up pretty well but I've been focusing on the tile-map stuff over the last few days. I'd appreciate some ideas of how certain meta-data/collision-flags are useful in different games. Hopefully the script/active tile-objects will cover lots of nasty magic-number IDs but maybe there's always a need for some kind of meta-data. Collision data is my primary concern at the moment; what's too much and what's too litlle?
Anyone with experience of writing tile-mapped games could seriously help me with this decision.
Anyway, I've decided that having each tile-map layer as a seperate object makes things much more flexible as well as it fitting into the scenegraph in a much neater fashion. Each tile-map layer exists as one object and can be loaded from disk. In-fact, there's going to be a helper to load-up multiple layers from a single file but each layer is a seperate object.
The obvious problem to this is having to control the panning of each layer but don't worry! My design allows for a layer-manager object to which you can add as many layers as you wish. The layer-manager is the central point which has the pan/zoom capabilities as well as the automated scrolling control. When you instruct it to pan left, it will communicate this to all the attached layers as well as the objects and move them appropriately. You'll be able to set per-layer scaling factors for parallax effects.
Let me explain why I think this is better. First, each tile-map layer can be positioned at *any* layer you want and even moved dynamically as it's just a standard 2D object with all the features that they come with. Secondly, fogging will be added soon which is kept at the scenegraph level. Any object (including one of these) will be affected by fog. Object collisions will continue to be unified rather than having a 'special' system for tilemaps. An object will be colliding with a tile-map layer which will itself do the collision check and provide the appropriate collision detail.
Another advantage is that any layer can be hidden, scaled, twisted, mounted .. anything. If it's available in the core, it's available here. You want the tile-map to spin? No problem. You want one of the layers to load a different tile-map set dynamically? No problem. You want to swap the imageMap that a layer is currently using dynamically? No problem. You want the fog of different layers to change dynamically? No problem. You want a certain layer to stream-in tiles from disk? No problem. All this is possible and more and it all comes from the fact that a tile-map layer is nothing more than a fxSceneObject2D that is designed to load/render tiles.
Okay, this post is getting too big so I'll stop now.
Mmmm ... big 'ol glass of Johnny Walker Black Label Whisky in front of me now ... sip.
- Melv.
EDIT: @Eric: Yeah bud, I'm sorry. I find it so distracting to write cool whizzy spinny things. I've purposely avoided it for the last few days just so that I can get on. Plenty of cool tile-map stuff on it's way soon...... :)
07/09/2004 (11:34 am)
Okay,This one's probably more interesting to David/Bil. I've been experimenting with various paradigms for tile-map control/rendering and I've kind of choosen a way to go forward. Hopefully, you'll not find a problem with it but I'd like your opinions on potential holes in the design.
Let me clarify how the tile-map stuff will hang together...
Above I explained how the tiles are encoded but never mentioned anything about other custom meta-data. I'm not exactly convinced that with the above scheme, you'd don't need meta-data but I'd like to be proven wrong here. One thing that is obviously essential are the collision flags. I've opted for a scheme where you've got a single collision flag e.g. collidable. The object that collides would get contextual info on the tile it collided with and it's here that there's a possibility that meta-data could be useful? It would be interesting to know if fully extendible meta-data was essential or a few fixed abstract fields only.
I was also wondering if having four collision flags, one for each tile-edge would be useful. This could be used so that you could jump up through a ledge in a level game if you were travelling upwards but you couldn't fall through the ledge if you landed on it. Would this be handled some other way I've not thought about?
I'm trying to think about lots of different 2D game styles and see how I can topple my framework. So far it's standing-up pretty well but I've been focusing on the tile-map stuff over the last few days. I'd appreciate some ideas of how certain meta-data/collision-flags are useful in different games. Hopefully the script/active tile-objects will cover lots of nasty magic-number IDs but maybe there's always a need for some kind of meta-data. Collision data is my primary concern at the moment; what's too much and what's too litlle?
Anyone with experience of writing tile-mapped games could seriously help me with this decision.
Anyway, I've decided that having each tile-map layer as a seperate object makes things much more flexible as well as it fitting into the scenegraph in a much neater fashion. Each tile-map layer exists as one object and can be loaded from disk. In-fact, there's going to be a helper to load-up multiple layers from a single file but each layer is a seperate object.
The obvious problem to this is having to control the panning of each layer but don't worry! My design allows for a layer-manager object to which you can add as many layers as you wish. The layer-manager is the central point which has the pan/zoom capabilities as well as the automated scrolling control. When you instruct it to pan left, it will communicate this to all the attached layers as well as the objects and move them appropriately. You'll be able to set per-layer scaling factors for parallax effects.
Let me explain why I think this is better. First, each tile-map layer can be positioned at *any* layer you want and even moved dynamically as it's just a standard 2D object with all the features that they come with. Secondly, fogging will be added soon which is kept at the scenegraph level. Any object (including one of these) will be affected by fog. Object collisions will continue to be unified rather than having a 'special' system for tilemaps. An object will be colliding with a tile-map layer which will itself do the collision check and provide the appropriate collision detail.
Another advantage is that any layer can be hidden, scaled, twisted, mounted .. anything. If it's available in the core, it's available here. You want the tile-map to spin? No problem. You want one of the layers to load a different tile-map set dynamically? No problem. You want to swap the imageMap that a layer is currently using dynamically? No problem. You want the fog of different layers to change dynamically? No problem. You want a certain layer to stream-in tiles from disk? No problem. All this is possible and more and it all comes from the fact that a tile-map layer is nothing more than a fxSceneObject2D that is designed to load/render tiles.
Okay, this post is getting too big so I'll stop now.
Mmmm ... big 'ol glass of Johnny Walker Black Label Whisky in front of me now ... sip.
- Melv.
EDIT: @Eric: Yeah bud, I'm sorry. I find it so distracting to write cool whizzy spinny things. I've purposely avoided it for the last few days just so that I can get on. Plenty of cool tile-map stuff on it's way soon...... :)
#10
07/09/2004 (11:43 am)
Happy Birthday Melv! 
#12
It's unlikely. Trust me, no-one is more upset than me about this but it's just too close to the expected birth-date of my new baby and my conscience simply won't let me go.
Not all is lost as I'm working hard now to have something special for the IGC with T2D. Something exclusive and most definately cool so I guess I'll be there in demo-code if not in person.
You didn't think I'd be giving away all the features of T2D now did you? I've got to save something good until last........
- Melv.
07/09/2004 (12:26 pm)
Paul,It's unlikely. Trust me, no-one is more upset than me about this but it's just too close to the expected birth-date of my new baby and my conscience simply won't let me go.
Not all is lost as I'm working hard now to have something special for the IGC with T2D. Something exclusive and most definately cool so I guess I'll be there in demo-code if not in person.
You didn't think I'd be giving away all the features of T2D now did you? I've got to save something good until last........
- Melv.
#13
07/09/2004 (1:31 pm)
Hey Melv, seems more and more interesting ! Happy birthday ! Don't abuse Mr. Walker !
#14
I've been talking with Mr Walker and Mr Intel all night long and I'm now most certainly ready for bed. I've been typing preliminary documentation for what I've done so far before it gets too big to even consider that task viable.
Goodnight everyone for I sleep now and wake up nearly a year older; who says time travel isn't possible?
I go to dream a 2D dream. ;)
- Melv.
07/09/2004 (1:36 pm)
Thanks. :)I've been talking with Mr Walker and Mr Intel all night long and I'm now most certainly ready for bed. I've been typing preliminary documentation for what I've done so far before it gets too big to even consider that task viable.
Goodnight everyone for I sleep now and wake up nearly a year older; who says time travel isn't possible?
I go to dream a 2D dream. ;)
- Melv.
#15
I was reading your Script type tiles and thinking that the tile object behind it should have a bevy of events a user can register (much like the message callback or overriding the event itself). So something like onCollide, onEnter, onLeave (or onEnterNorth, onEnterEast, etc. if you go with events tied to each edge. Hmm, maybe an edge to define the edges of the tile and an onEnterEdge(%edgeNo) and onLeaveEdge(%edgeNo) event). Anyways, this way single types of tiles could respond to events (like a radiation tile that saps the user entergy with each step) or entire layers (weather layer perhaps with changing effects?).
Personally I think a tile should handle collision with something that would normally collide with it (derived from ShapeBase?). Another thing might be the ability for a tile to send a message to the object colliding with it and let it deal with how to handle the collision?
In any case, a separate class to handle the tile, the tile layer and whatever else you have going would be the way to go. I'm thinking about Gauntlet from the old days where you would be randomly teleported to another location on the map. You could have a series of tile types. Some would teleport you (by sending a message to the tile layer to finding an appropriate new location), others would slow you down or electrify you. I'm thinking it would be good (and this is from scripting side) that each tile, layer or map could have it's own datablock? Then you could create water tiles with a water datablock using certain particle effects, and land ones with others (I'm thinking ahead to TSE with shader rendered tiles, I know, silly me...)
I think you have all the bases covered. In time as we get our dirty hands on this resource and start building samples I think some things will rear up but sounds great so far!
07/09/2004 (2:28 pm)
As always, nice stuff Melv. When I implemented the tile objects in CDX, I created an abstract TileInfo class (or something like that name). This was a blank base class that a person could override to handle storing information in a tile (in an OO way rather than through variables). They could override certain events (or at least that was the plan) on a tile, a group of tiles, a layer, or the entire map.I was reading your Script type tiles and thinking that the tile object behind it should have a bevy of events a user can register (much like the message callback or overriding the event itself). So something like onCollide, onEnter, onLeave (or onEnterNorth, onEnterEast, etc. if you go with events tied to each edge. Hmm, maybe an edge to define the edges of the tile and an onEnterEdge(%edgeNo) and onLeaveEdge(%edgeNo) event). Anyways, this way single types of tiles could respond to events (like a radiation tile that saps the user entergy with each step) or entire layers (weather layer perhaps with changing effects?).
Personally I think a tile should handle collision with something that would normally collide with it (derived from ShapeBase?). Another thing might be the ability for a tile to send a message to the object colliding with it and let it deal with how to handle the collision?
In any case, a separate class to handle the tile, the tile layer and whatever else you have going would be the way to go. I'm thinking about Gauntlet from the old days where you would be randomly teleported to another location on the map. You could have a series of tile types. Some would teleport you (by sending a message to the tile layer to finding an appropriate new location), others would slow you down or electrify you. I'm thinking it would be good (and this is from scripting side) that each tile, layer or map could have it's own datablock? Then you could create water tiles with a water datablock using certain particle effects, and land ones with others (I'm thinking ahead to TSE with shader rendered tiles, I know, silly me...)
I think you have all the bases covered. In time as we get our dirty hands on this resource and start building samples I think some things will rear up but sounds great so far!
#16
07/09/2004 (7:15 pm)
What? No pictures?
#17
@Erasor: Naw, sorry. Just dull code at the moment but it always ends-up in lots of screenies. Watch this space. B)
- Melv.
07/09/2004 (11:46 pm)
@Bil: Excellent, thanks for the info. Just one thing, ShapeBase? *shudders* ;)@Erasor: Naw, sorry. Just dull code at the moment but it always ends-up in lots of screenies. Watch this space. B)
- Melv.
Torque 3D Owner Xavier "eXoDuS" Amado
Default Studio Name