Associating game data with Tiles/TileLayer
by James Paradies · in Torque X 2D · 06/29/2007 (5:11 pm) · 2 replies
Hi all,
I'm just wondering if there are any thoughts on the "best method" for a couple of tile-based game basics:
1. Associating game data (e.g. movement costs, visibility, event triggers) with tiles on a tilelayer.
2. Fog-of-war/ Line-of-Sight (has anyone tried to implement this yet)?
There doesn't really seem to be a good way of associating game data with a tile:
Relying on T2DTileType.ObjectType to provide game data doesn't seem to be ideal - it can't really be used to specify a tiles movement cost for example.
As for event triggering, Tiles don't seems to allow components to be attached, and the tile collision handling seems to be delegated to the object colliding with the tile, not the tile.
Does this mean that each Sceneobject that could trigger an event should have a "tile-event -trigger" component? This doesn't seem like too great an idea either - I think I would be much cleaner to have the component attached the T2DTileType.
Is subclassing T2DTileType a sensible solution for solving this issue?
I'm just wondering if there are any thoughts on the "best method" for a couple of tile-based game basics:
1. Associating game data (e.g. movement costs, visibility, event triggers) with tiles on a tilelayer.
2. Fog-of-war/ Line-of-Sight (has anyone tried to implement this yet)?
There doesn't really seem to be a good way of associating game data with a tile:
Relying on T2DTileType.ObjectType to provide game data doesn't seem to be ideal - it can't really be used to specify a tiles movement cost for example.
As for event triggering, Tiles don't seems to allow components to be attached, and the tile collision handling seems to be delegated to the object colliding with the tile, not the tile.
Does this mean that each Sceneobject that could trigger an event should have a "tile-event -trigger" component? This doesn't seem like too great an idea either - I think I would be much cleaner to have the component attached the T2DTileType.
Is subclassing T2DTileType a sensible solution for solving this issue?
#2
As a workaround you could do use the ObjectType to assign a category (e.g. "DesertTile"), which you then use to associate to your game data in code. This way you can use TGBX for map design (problem being that you need an object type for each variation). Since you can combine object types, you can have separate types for triggers and such (remember that there's just 64 of them).
Taking it a step further (i.e. my feature request), I think TGBX tile editing should have a way of explicitly managing the TileTypes. Currently you implicitely define one by selecting the material and other options, and then applying it to the tilemap. You can reuse existing types by picking them, but there's no way (that I know of) to manipulate the type itself. For example when I wanted make an adjustment to the collision image of a TileType, I needed to pick a tile with that type, make the adjustment and re-apply it to EVERY TILE of that type. It would be much easier to just manipulate the TileTypes (one option being to manage James's components).
Matias
07/01/2007 (11:54 pm)
I remember having similar thoughts as James, but ended up going in some other direction. But James's suggestion about managing T2DTileType components in TGBX sounds like a valid feature request. And in his case "the right way(tm)" (i.e. managing the game data in TGBX). As a workaround you could do use the ObjectType to assign a category (e.g. "DesertTile"), which you then use to associate to your game data in code. This way you can use TGBX for map design (problem being that you need an object type for each variation). Since you can combine object types, you can have separate types for triggers and such (remember that there's just 64 of them).
Taking it a step further (i.e. my feature request), I think TGBX tile editing should have a way of explicitly managing the TileTypes. Currently you implicitely define one by selecting the material and other options, and then applying it to the tilemap. You can reuse existing types by picking them, but there's no way (that I know of) to manipulate the type itself. For example when I wanted make an adjustment to the collision image of a TileType, I needed to pick a tile with that type, make the adjustment and re-apply it to EVERY TILE of that type. It would be much easier to just manipulate the TileTypes (one option being to manage James's components).
Matias
Torque Owner Ben R Vesco