Plan for Melv May

#1 Melv, another option, which I used with my students, if you want to load a dumber format. Is to use mappy and simply save the files as .map when you save them.

Its pretty dumb still, but it works ok. FMAP is preferable though.

#2 Phil,

I downloaded the code and at first I was really not happy about having to implement it all but I guess I was tired or something because today I took another look at it and the FMAP stuff is pretty simple to understand. My main wrangling now is with the way I want each of the 8 supported layers to seemlessly integrate within my own discreet layering system. I've got some ideas but I'm not going to start work until I'm happy with it.

I should have a game plan this evening ready for some coding tomorrow night.

The main thing that concerned me was the use of embedded graphics within the format but this removes the problem of editor/renderer graphics references but it could lead to bloated graphics sizes if the same set of graphics was reused for different maps. This may not be strictly true as there may be something I'm missing but it seems to be the best-in-class.

I saw the MAP format and instantly I thought yes! Then I thought about all the budding TGE'rs and all the requests for FMAP support that will inevitably come if this is proved useful so I thought FMAP is probably best done first ... rough crowd. ;)

- Melv.

#3 What's so nice about FMAP? Does it hold variables, like collision, layering, etc?

#4 Yes. FMAP has custom fields which can be assigned to the block graphics. Block graphics can be animated. It's got upto 8 layers. It's fairly well documented. The editor seems stable and there's a capability to run under Linux as well as windows, also Java I believe. The file format is chunked so that all the data is contained completely within a single file.

The big winner for me is that it's got a stable editor that's been around since the beginning of time and there's also ISO/HEX map support.

- Melv.

#5 Question about collision Melv :o)

I am planing an isometric game along the lines of Cadaver (if anyone even remembers that game....showing me age!)

What support do you have for such things. In a pinch I can rig up something to check what tile the players character is on and if they are moving to an occupied, dangerous tile but, just thought I'd ask you in case i'm missing something obvious

#6 Peter,

To start off, I've only got so much time so I'm only going to implement the rectangular tiles immediately. HEX/ISO renderers will come after I've finished this and the particle-engine. I say *only* like it's not a bucket-load of work. ;)

Sure, collision is obviously a big thing and there's already a comprehensive and extendible collision-detection system in the framework. The new object will handle collisions exactly the same way. The ISO is a little different and will take more thought, small steps, small steps. :)

I've got a very good idea of how I'm going to integrate FMAPS into the framework. Rather than having one UBER-tile renderer, I'm going to split down the support into three objects for rect/hex/iso support. To load/render a tile-map will be no more difficult than getting a single sprite on the screen. In-fact, the rest of the system won't have *any* code directly related to the tile-maps, it's all in the tilemap object itself.

The way it will work from the script side is that you'll generate a new fxTileMap, tell it the FMAP file (or use a datablock to configure this as you would any of the other objects) and it's ready to render! Just like any other object, you can position/size it how you like. If you want to rotate it then fine, jeez, it'll even have it's own physics that it inherits from the core although the usefulness of that is limited.

When you move your 'player', the tilemap object will detect a trivial collision and the fxTileMap will then determine what/if the collision is a(dependant upon the collision config/layers) and feed that back to the colliding player object. The beauty of this system is that you can have as many tilemaps loaded as you require and position where you like although graphics constraints may limit this. The tilemap will *not* be fixed at a certain position or anything like that. An example of this being used in anger would be a split-screen two-player where you want two games with different players running. The same tilemap either in the same/different windows and/or possibly a different scenegraph. Reusable tilemaps like this would come from using the fxTilemapDatablock2D object. Hey, I've at least named the objects!! ;)

As you know FMAPS have 8 layers for rendering; my system currently supports 32 layers and can be changed to support more/less with a flick of a switch. If the tilemap is a single object then it can be placed into any of my 32 layers. What I'm working on now is to leave this ability but what the object does is 'inject' the renders of each of the FMAP layers into my layer system seemlessly; an interesting problem. This means that if you position the fxTilemap object into my layer 10 then the layers 0-7 will be rendered in layers 10-17 of the framework. This will be neat because the objects you move around need not have any specific links to the tilemap itself. This will allow you to have a consistent layer reference independant of the inconsistency of the layer-support from FMAP to T2D. Confused? ;)

Because I'm doing a custom renderer I'm going to take the opportunity to allow for superate effects on each layer. The most important that come to mind is fogging and scaling.

Wow, information overload, sorry.

- Melv.

EDIT: I'll just add that I'm pretty confident on what needs to be done now that I've had a chance to go over it all. My initial schedule would be for a demonstration by the end of the week but that's if I don't encounter any major hurdles I haven't yet thought about!

#7 Forgot to mention that I need to get it done for the weekend because on the 10th .... it's my birthday ........ whhheeeeeeeeeeeeeeeeeeeee!

It is unlikely that I'll be capable of writing software because I'll be too XXXXXXXXXXX.

Big party on Saturday!!!!!!!!!!!!!

Feel free to send money, cards, beer or baby-clothes tokens to ....

Melvyn May
Lead Software Engineer
Pera Innovation Park
3DX-Ray Ltd
Melton Mowbray
Leicestershire
LE13 0PB.

- Melv.

#8 :o) Have a happy one Melv. My birthday is on the 13th (a tuesday so I have to wait 4 days for a party!)

You may get a nice card if the post office can find you. Heck I live in London and they can't find me sometimes!

#9 Cheers Bud.

It will not be forgotten. ;)

Happy 13th.

- Melv.

#10 Happy B-day Melv...

Actually have you evaluated other tile map editing programs as well? Ive had rather good luck with Tilestudio. Ive managed to get that data into a c++ project and a dark basic pro really easily. Plus its a really good map editor since it handles layers and everything built in. The source is up on sourceforge but alas its in delphi but it has a texted base file that allows you to tell it how to export the data. Thats why it has multiple exporters for different formats rather easily. The DBPRO exporter file was a little messed but I was easily able to edit the file so it could export the data into a file format I could use rather quickly. Oh and it comes with a bit of test data that doesnt look too bad so you can export those out right off the bat into your engine.

Danke

#11 Melv,

Happy Birthday man. Take a break and step away from the 'puter for a bit to celebrate (okay, times up you and I can't be separated from a computer for more than a few minutes).

Sounds like the plan is coming together. I'm glad Mappy is working out for you. One way to get around the 8 layer restriction is to stack 4 of them on top of each other to match your 32 layer system (either that or maybe Mappy can be upped to support 32 layers instead). In any case, 8 layers has always been a pretty good number for tilemaps and I've rarely seen too many games use more than 4 or 5. When you try to start managing 20+ layers of objects it gets pretty hairy.

Fogging sounds pretty cool but wouldn't that be better as a separate effect independant of the fxTileMap objects? If I'm thinking about the same fogging you're referring to (Fog of War?) then I would see it as something that lives above the map layer but beneath the screen (if that makes any sense).

Anyways, sounds great as usual. I'm pretty tied up with a bunch of Torque stuff I'm working on now (as well as other stuff including updating CDX to DX9) but can find time for testing or whatever. Let me know.

#12 Wait,

Melvyn May lives in Melton Mowbray?

Now I *know* your just making this stuff up...

#13 @Juan: Thanks. :) Unfortunately, I've not had much experience using either of these packages and my time is limited. I'm battling between research and simply getting it done. If anyone here has the experience to weigh the pros and cons of each then I'm certainly all ears but I need to choose quickly.

@Bil: Thanks. :) I wasn't referring to fog-o-war, I meant depth-fog. There'll be fog rendered at the layer-level as well as reference for objects that want to render so that they can support fogging during their render pass. You're correct though, a fog-o-war would be a seperate object and really easy to implement.

@Paul: No, just work around there. Small Market-town; not exactly a place where you'd expect to find a high-technology company! I live in Burton-upon-Trent around 30 miles away.

I'd be extremely interested in opinions before I jump head-first into tiling... anytime in the next 10 minutes would be great. ;)

- Melv.

#14 I'm glad you picked up the Mappy ball that I dropped when I saw that I had a three-day weekend.

Personally, I kind of like the idea of simply having a basic tilemap that you can apply to the layer so that people can use whatever their favorite map editor is. It's simple and should work with the stock collision masks you've set up in the layering anyway. While FMAP is a nice format (from the little I looked at it before running off), that's candy on top of a well-frosted cake. As long as simple tiled support is there, I'd think it would serve most purposes nicely. And there's no reason that it couldn't be extended later just like the ISO support is on the back-burner.

I'm looking forward to a strong core (which is mostly there now), but I'll gladly take any icing you want to put on it! And I can't wait to see the particle engine!

*impatiently awaits the $5000 T2D Early Adopter option*

EDIT: And happy birthday as well!

#15 Same here, three day weekend plus a week's vacation to see the family.

I have to agree with David Blake -- Mappy is neat and all that, but I'd rather that T2D be abstracted from any one tile format. Just keep the format related purely to displaying tiles from a single bitmap and handling the usual tilemap functions (collisions, layering, flipping/rotating). Then, people can write stub code to interface your tilemaps with Mappy's FMAP format, or skip that and use their own.

A while ago, I played with Mappy. It's nice, though if you want to add any sort of meta-data you've got to modify the editor. (Maybe it's changed since then...) I did not, however, like the fact that all graphics data was included in the FMAP file. The editor only wanted .BMP files, and it was an annoyance having to work around that. So, I ended up rolling my own tile system.

PS: Happy B-day Melv!

#16 Thanks. Looking forward to this years birthday. It's my last one as an irresponsible human being!! On the next one I'll have a young daughter!

Okay, let me summate the what the general trend is then:-

- Don't force the use of any tile-map editor.
- Create an object that would render multiple layers or perhaps any object that would render a layer and be able to have multiples of these objects linked to form the layered tile-map.
- Abstracted collision/meta-tag support.
- Some form of import interface to allow essential conversion from popular tile-map editors.


If I was to generate some system to allow conversion and then provided a core-class to render at least the rectangular layered tile-maps then that would be enough for a release? Possibly with MAPPY done as a good starter? I must admit that I'd be a little happier specifying an abstract interface of my own doing and then get MAPPY support in later.

I've not mentioned this before but I think you guys would be interested. I've been making some changes to improve the method to get graphics into the framework. This is partly due to me thinking about handling tilemap imagery but mostly to provide some degree of flexibility. The way that it'll work soon is pretty flexible. At the moment, I've got a single datablock "datablock fxImageMap2D"; with this object you can specify imagery in one of three ways:-

Mode#1 - Single Full-Frame Image
This one is the easiest and defines only a single frame which occupies the whole bitmap. This one is typically used for scrolling-backgrounds that aren't tile-mapped.

Mode#2 - Colour-Code Seperated Frames
This is the same as I've used in the demos so far and is also the same way that the TGE GUI skins work. The advantage here is that each frame can be a completely different size, controlled by the colour-coding itself and therefore the artist.

Mode#3 - Variable-sized grid frames
This is type is probably the most useful. All you need to tell the datablock is the dimension of each frame and how many horizontal/vertical cells there are. Unlike the colour-coded method, it assumes that all the frames are the same size. The advantage here is that it's perfect for defining tile-map data as each frame can be butted-up against each other. The disadvantage is that each frame defined with it must be the same dimension.

Here's examples of them being used:-

// Mode#1.
datablock fxImageMap2D(oneFrame)
{
imageMap = "images/myImage";
};

// Mode#2.
datablock fxImageMap2D(colouredFrame)
{
imageMap = "images/myColouredImage";
imageCount = 4; // Sanity Check!
};

// Mode#3.
datablock fxImageMap2D(celledFrame)
{
imageMap = "images/myCelledImage";
cellWidth = 32;
cellHeight = 32;
cellHorzCount = 4; // Omit and DB uses as many cells as fit!
cellVertCount = 8; // Omit and DB uses as many cells as fit!
};

These datablocks will be the source of all imagery loaded into the framework, including tilemaps. Every object will refer to one of these objects. I'm also putting in support to generate these maps programmatically of which I can see the first use being importers for tile-maps. An importer for FMAP would parse the file and populate one of these objects with the bitmap data. Any reference to a graphic frame would be via a mode/image/frame-index. I like the idea of a single, unified method of referring to imagery and hopefully you do too.

One of the existing objects is the 'fxAnimatedSprite2D'. It can take one of these imageMap datablocks to define the animated frames. Here's an example of a datablock and initialisation for this object that was running in the demo. Note that the 'alienImageMap' is the unified imageMap datablock and the method it uses is irrelevant to the animation datablock, all it's interested in is identifying the imageMap and the frames, the imageMap method will define what these frames actually are...

// Define the aliens animation.
datablock fxAnimationDatablock2D(alienAnimation)
{
imageMap = alienImageMap;
animationFrames = "0 1 2 3 4 5";
animationTime = 0.75;
animationCycle = true;
};

// Generate the Alien.
%alienObj = new fxAnimatedSprite2D();

// Start the animation.
%alienObj.playAnimation( alienAnimation );


I need to go away and think about an abstracted interface for tile-maps that won't hinder performance, provide meta-tags and collision support and will neatly interact with the existing layers in the framework. I'll get back tommorrow evening...

Thanks for your interest guys and please feel free to pour any of your knowledge on tile-map issues my way. :)

- Melv.

#17 If I was to generate some system to allow conversion and then provided a core-class to render at least the rectangular layered tile-maps then that would be enough for a release? Possibly with MAPPY done as a good starter?

I think so. After all, a tilemap would just be a giant array. I'm not sure what is the best way to represent this in Torque Script, however, since it does not support complex datatypes.

Maybe a special object type with a set of methods to interface with the data, like "gettile(x, y)" and such?

I find tile maps useful not only to store graphical layouts, but also level syntax and triggers. Your system doesn't have to include support for meta-data right off the bat, but I think it would greatly benefit people if it did. So, allow tiles to be "non-renderable" and perhaps contain pointers to other blocks of data. This way, if I were making a simple shooter, I could just mark certain tiles to point to references of, say, an enemy generator or powerup drop trigger. You could store the data per tile in the array, but I think it would be more efficient to use a simple int for each tile reference, with another pointer for any additional data for that tile. (Assuming you track the tile state information in a seperate structure, ie: tile is flipped N/S or is a collidable tile.)

Also, how low level do you want your tile system to be? For example, can I just upload my entire tile map to your tile class, and then it will automagically render tiles for the visible viewport, depending on an offset scroll value? Or will it just be a raw tilemap that I will need to continuously stuff with new tiles as it scrolls? I really don't see any advantage at all to the second method, being that's how older tile-based graphical hardware used to work. The first method just means you will need to collect the entire tile map before rendering can begin.

As for your various methods of creating animated sprites, I think they are all logical and will work fine. I'm curious about Mode #2, however -- does frame number assignment begin from the upper-left and move in a left-right scanning method?

One question though, what about animation callbacks? Let's say I have a fxAnimationDatablock2D called spaceshipShooting and another called spaceshipIdle. The Idle animation is a cyclic one and the Shooting one isn't. When the ship shoots, it plays Shooting and then I want it to cycle back to Idle. Would it be possible to set an animation callback, or perhaps a nextAnimation variable? (For example, in spaceshipShooting, set nextAnimation = "spaceshipIdle" and it will play that animation upon sequence complete.) I could always manually monitor each object per tick, but better if this could work similiar to image states in Torque right now.

Anyway, hope I can be of any help!

(Edit: Fixed HTML markup..Whee!)

#18 David,

Wow, got distracted and forgot about your post, sorry. 8(

I've been going through the abstractions for tiles and I'll post my conclusions on how I'd prefer it to work soon. I've got some interesting ideas on how to link tiles to real objects in the system and have them 'mounted' to the tilemap itself. This way they move with the map autonomously and can have any functionality you require such as AI etc. You could use this for intelligent turrets or even particle emitters, whatever.

Your question about how the tilemaps work with regards to the visible viewport is your first statement. The tilemap object will determine what to render based upon the viewport. The object itself can pan the tiles to an absolute position and automatically have that position pan. If you don't use this then you can simply have the tile-map object size really wide and have your objects physically move around the world, it's up to you and your specific game. I'll probably elaborate when I've answered some of my own questions soon. :)

The fxImageMapDatablock2D in Mode#2 does indeed scan right->down. This is exactly the same as the GUI skins that TGE uses.

At the moment (and this can easily change) animations are controlled using a playAnimation(MyAnimation). There's an optional set of parameters on this call. The full function definition is playAnimation(animationName, [autoRestoreAnimation], [limitCycle]). The second parameter is used when you play a non-cycling animation and want the animation controller to restore the previous animation when the selected animation is finished. The third parameter allows you to play a cycling animation but limit the number of cycles at which point it will check the autoRestoreAnimation flag.

There's also a script-callback "obj::onAnimationEnd(%this)" so that you can put custom code in. In the demo, when I detected a collision between the player-projectile and an alien, I didn't destroy the alien immediately. I started an explosion playing at the same position which is a non-cycling animation. When it finished, in its 'onAnimationEnd' callback, I destroyed both the alien and the explosion. All T2D objects can be destroy at any time using a special function that's core to the framework %obj.safeDelete(). The function means that it's safe to delete even from a script callback that the object makes. This defers the deletion until the frame-sequence has finished.

Keep those questions coming as it's a great way for me to see if I've missed anything. :)

Melv.

#19 Not a problem, Melv. :)

The safe-delete sounds wonderful! That's exactly why I was inquring about the callbacks. The ability to change animations based upon behavior lets you create some really complex enemies. For example, in Crusade there is an enemy that, when destroyed, will fly around randomly, emitting smoke and sparks, before it blows up. During that phase, the callback has turned off collision detection and so, so you can't kill it twice, nor collid with it.

Exciting stuff!

Mode #2: Aha! See, I haven't done any GUI hacking yet, so I didn't know it worked that way. Now I know.

#20 When I mentioned that imageMap stuff, I was finalising some of the functionality but all that stuff is not fixed and tested and it works very well.

Yes, the callbacks should enabled exactly this kind of complex scripted behaviour.

I can certainly see people writing cool script managers for all sorts of things like alien waves, boss controllers, you name it.

- Melv.