Overview and purpose
I’ve worked out a method of changing tiles at run-time using the same kind of Object ‘tagging’ system I’ve outlined in previous posts (eg Storage) using the same reasoning: the need to identify entities uniquely.
The purpose of changing tiles is to indicate a state of a Tile/Chess, and visually represent the change.
For example, a door’s opened or closed state, or a floor’s damaged or otherwise modified state.
Three elements are needed for this implementation that I call Tile Change Object (TCO).
- TCO Object (defined in the TMX)
- TCO Sprite (created in C2 through TMX loading)
- TCO Dictionary (created in C2 in conjunction with TCO Sprite)
- Tiles ‘vars’ property
The TCO Object defined in the TMX is any Object with type ‘tco’. It requires a custom property called ‘layers’ which is a comma-separated string defining a list of Layers that is meant to be changed. by this TCO. For example:
Again, the TCO Object only marks the tile as changeable. The configuration of how it changes is defined in the Tile itself.
The TCO Sprite is a Chess object that resides in its own z-layer in the Board (“Tco”). The Sprite is the effective marker of the TCO in the Board.
TCO Dictionary (TcoDict)
When a TCO Sprite is created on the Board, it creates a TCO Dictionary (TcoDict). This TcoDict’s keys is thus added using the TCO Object’s ‘layers’ property values:
TcoDict["Floor"] = "" TcoDict["Walls"] = ""
Note that the value is empty, and this means it is in its nominal state.
Tiles ‘vars’ Property
(Edit: the ‘vars’ property syntax is always in a state of flux so this part has been edited a few times)
The Tiles in the TMX which are expected to change need a property called ‘vars’. This ‘vars’ property define a state, and the Tile ID it’s supposed to use when the Tile and Layer is switched to that state. Example of a ‘vars’ value:
The ‘vars’ line is tokenised by commas ‘,’, which separate it into what we’ll call ‘subvars’
open:42 closed*:-1 broken:5 burning:a burninglow:a:2
Then it is further tokenised by colon ‘:’.
The first token is the possible state that this Tile could be in. If that state has a *, it is considered to be the default state of the Tile. This is important in the initial creation of the map, to initialise the state of each Tile.
The second token is the Tile ID (of the same Tilesheet) that represents that state. If -1 is specified, it means to use the original Tile ID that the Tile originally began with.
If ‘a’ is specified in the second token, then that means that an animated Sprite is intended.
If ‘a’ was specified in the second token, then the third token can also be specified to denote to use another Tile’s animated Sprite.
For reference this is the syntax template for a subvar:
Refer to the Animated Tiles post on how this is used.