Torque Retro 2D! *Progress*

#21 As for tiling maps, one of the best tile map editors out there is something called Mappy. It supports multiple layers, all types of tile formats (hex, square, iso), and other great features. Very simple to use and open source. The file format is easy to use and probably could easily be read into this 2D mod with only a few lines of code IHMO. You can check out Mappy here:
www.tilemap.co.uk/mappy.php

#22 Thanks David/Bil.

I downloaded 'mappy' after stumbling over it a couple of weeks ago but I've not had chance to look at it properly yet, something which I'll rectify today or tommorrow.

You guys seem to be well upto-spec on this kind of stuff so it may be worth me describing how/what T2D actually does in terms of layering etc.

A day in the life of a T2D object...

The object gets generated within the scripts and is immediately added to the system. In its onAdd call, it takes the oportunity to use the selected configuration data (if any and totally optional) to configure itself. At this point, it's pretty useless because it's not been added to any T2D scenegraph. When you do this (or you could've done it in the datablock stage) it's ready to work wonders for you.

The system renders from the viewpoint of a window. The window is a standard bare-bones GUI control and it issues a request to the T2D scenegraph to render within a selected camera view. The scenegraph does this by using a sub-component of the T2D scenegraph called the container-system. This sub-system does the culling and produces a list of candidates for rendering and places them into a structure sorted by layers and then sub-sorted by layer-order (another property of each object). The T2D scenegraph then simply renders the layered-list back->front and hey-presto, the scene!

The two important things to note here regarding layering is that each object can be placed onto a specify layer (and changed at any time) which controls its rendering order (and selectable collision masking). The other component which is automatically maintained by the system is the layer-order. The layer-order controls the order in which each discreet layer renders its objects. You can control this at the T2D scenegraph level by selecting whether the last or first objects are 'on top' and its maintained automatically from then. You can always promote/demote objects within their layers if you require. This means that the layer-orders don't jump around (causing a distracting effect) according to their relative spatial position. In my movies I forgot to turn this on and you can see the awful effect in there...now it's on by default as 'last is on top'.

The world does not have a cap on its size and is only limited by the range/precision of the F32. If an object wanted to render the scene itself, then that's possible although I've not messed with it as it's simply a natural side-effect of the way I've done the scenegraph so portal-style effects are possible.

I've made almost every property of the core-object dynamic so you can change this at any time from C++ and the scripts. Things like layers, groups, position, size, rotation, physics, collision, scenegraph, mounting etc can be changed every frame if you required.

continued...

#23 ...continued

I've tried to pack as much game-abstracted capability into the core-object as I can. This functionality can be overriden but in there, there's dynamic-sizeable maskable AABB collision-detection, auto-rotation, physics, mounting, layered-rendering and more.

The collision detection system is driven by the T2D scenegraph. This may sound a little odd but I wanted to achieve a state where people can include collision-detection, physics and all the other support without having to put in key routines and other features. I wanted a state where it would automatically happen unless you explicitly told it not to do so. Collisions are handled by the scenegraph and it looks at the objects to see if they have they have collisions enabled. It then does the appropriate work in finding objects that collide. Apart from the spatial component, each object has two methods to control what objects it can collide with. Each object can be told to collide with any/all layers/groups. You can assign an object to any group for any arbitary purpose but the intent is to filter collisions. You may have all 'aliens' grouped as 10, their projectiles as 11, you as 12, your projectiles as 13 etc. When you put the players ship on the screen you configure its collision detection to only collide with groups 10 & 11. You guys know this kind of stuff already as collision groups but I thought I'd be clear. You can additionally restrict collisions to any/all the rendering layers for further tuning and more efficient searching and far better performance.

Finally, tile-maps...

I'm not sure of the value of the approach of supporting tile-objects at a low-level. I was thinking more of developing an object that simply loads/renders tiles possibly as normal and isometric or more probably, two seperate objects with similar functionality. The isometric has more complexity due to the nature of how objects 'fit' within the scene in terms of Z-order and so it may make the normal one seem over complex and simple is what we're doing here. :)

I always like the idea of hiding as much as possible of the nitty-gritty from both C++/scripters alike but still offer the functionality.

The tile-object can be setup to read in n-layered maps and render them appropriately. My problem, and this is where I need to do some reading, is how to get 'mappy' to provide useful tile references. I presume this is configurable using some kind of tag/mask system?

When the system called the tile-map object to determine what collision have occurred with any object, I wouldn't require some reference for each tile to determine what needs to happen. The scrolling and sizing of tiles is not a problem, my only concern is the transportation of this tile-data from something like 'mappy' to the tile-map object. It's probably all answered in the mappy doco but I thought I'd ask.

My problem with ISO-maps is the z-order for characters draw over it e.g. occlusion. I don't want to use a 3D-engine to write a 2D-framework only to emulate some kind of psuedo-3D!!

I think I better quit there as I need to finish this 2D particle-engine. Any advice or information from your experience with this kind of tiling would be most appreciated.

- Melv.

#24 Melv,

Someone showed me this and I thought it so cool I had to see if it might inspire a little on your 2D particles. So, a little patriotic gift from the colonies: :)

Lady Liberty. Click in the night sky.

#25 Thanks Eric. :)

- Melv.

#26 Continued on plan.

- Melv.

#27 @Melv: Sounds good and I'll check out your plan in a bit. It sounds like you might have a C++ object to load tiles from a map (mappy or whatever) and use basic script objects to get them into n number of layers to load a map (much like loading a mission in TGE). Then you can get multi-layered tile maps with players running around in them, colliding where necessary.

For example, you can load in layer 1 as the floor, then load in the next layer as wall blocks and use this for collision in scripts when the player starts moving around (think of an overhead Metal Gear Solid). Which I think would rock because creating tile maps is so much easier than putting static shapes into a Torque terrain (and much more flexible).

I still think there needs to be some abstract classes (probably script base, becoming a new 2D common set of files) that represnt game objects, but I haven't seen the code for your 2D stuff. Collision in the SG is fine, but keeping track of all those collisions should be the work of the objects themselves. If I think about a TGE asteroids, I would want to have an asteroid class that can detect if it's collided with another one and handle blowing apart, creating new asteroid objects, etc. I wouldn't want (even in script) to be writing directly against the SG and aways trying to resolve collisions. I would see the SG as a data source for that information, but maybe that's just me.

Looking forward to seeing more and talking with you about this! Sounds tres cool.

#28 I never really thought about how pointless it would be to emulate 3D in a 3D engine. Funny now that I think about it. I was just thinking about the common questions that pop up whenever someone mentions tiling. But adding the complexity when it could be done just as effectively with 3D cameras, DTS's, and the 3D terrain engine doesn't make a lot of sense. Plus, I've always found it easier to make the whole model rather than painting iso tiles. Maybe that's just my lack of pixel-perfect artistic skills.

I'll look over the Mappy source a bit between my WebCT meetings today. If I recall (and it's been a LONG time since I used it), it didn't support collision layers or masks. It would just store the 8 layers and it would be up to the loading program to read in the map and work collision and such. But, like I said, it's been a long time. I'm not sure if I've used it since Victor Putz released the last version of Yak Icons back in the day.

Thanks for the insight! I hope to have a bit more to say that's relevant after the meeting and sifting through the Mappy code a bit.

#29 I'd definately want to home-bake *any* code that goes into T2D. To be honest, the only issue for me is getting the tile references (graphic/layer/collision) into a data-structure that can be rendered with a custom T2D object. To be equally candid, this isn't rocket science but my problem is that without using something like 'mappy', a cross-platform editor becomes a must which is a pain.

@Bil: All the sub-systems I've built including physics/collision-detection have the appropriate hooks in C++ and callbacks for script. All this functionality can be expanded/overwritten by objects. This means that you could write an object to manage other sceneobjects something like a manager to control all the asteroids themselves. The core class is a script-object 'fxScriptObject2D' from which everything inherits. The specialised scroller inherits from this which means it can be notified of collisions or handle them itself. For instance, if it wanted to actually detect collisions against the mountain silhouette, it could load the graphic, register itself into the system for collisions (the system will call it when a trivial collision check occurs against the AABB) and it will them do the silhouette collision and notify the system of the collision. The system then takes care of the rest of the collision stuff. Each object also has a ray-cast collision detection that it can use to override/suppliment the core line/AABB detection.

If a large 'asteroid' object decided that it had collided with something relevant then it can easily destroy itself and produce several offspring asteroids.

It's pretty flexible.

The tile-map would inherit from the core and get registered for collisions. It would then get passed any objects that trivially intersect it. It could then determine using it's tilemap dataset whether the object in question is a collision at its current position against the tilemap pan/zoomed position. This can obviously also include layers.

It's hard to describe how all this works but when a C++ object has been created, the scripting is a doddle.

Thanks for your continued interest guys. :)

- Melv.

#30 Continued here.

- Melv.