Quote:
Originally Posted by Jake
On tilesets: How about having data to tell MLLE that what tiles are what, in addition that what are their counterparts. For example, telling MLLE that tile 6,4 in the Diamondus tileset is a corner block, having air on left and bottom parts, and top and right parts would be walls.
|
Quote:
Originally Posted by Violet CLM
You'd want (at minimum) two bytes per tile, I think:
Byte #1: eight bits, each specifying whether a given tile (up-left, up-center, up-right, middle-center, and so on) is part of the same structure or not.
Byte #2: type of structure. Tubelectric, for instance, has multiple wall types; you wouldn't want to create a wall of mixed purple and red tiles by accident.
|
I actually thought of this too. In fact, I've included a description of each tile in Castube's readme file. If tile types can be properly standardized, I think this can be something awesome to quickly switch tilesets.
Also, if I were to ever release Castube 2, it would have its tiles seriously reorganized. If I could supply such tile information about both versions, MLLE/WebJCS could load Castube 2 without trouble into any Castube 1.3-4 levels.
Quote:
Originally Posted by Violet CLM
Although, I wonder if it might not be better to separate such things (i.e. your idea and mine both) from the .j2t files, for two reasons:
(reasons here)
|
I agree with this. Another important benefit of a seperate file is that you're not limited to 16 bits per tile. This allows for far more flexibility in how tiles are described. A tileset could have 20 different eyecandy objects, each consisting of 1-6 or even more tiles. It would be impossible to tell all those tiles apart in just 16 bits.
The following is just some brainstorming. I enjoy thinking about how to achieve these things
Let's say we've got some eyecandy we want to define. The format should find a way to store:
- The fact that the tile is eyecandy
- An eyecandy object identification (could be a number, or a name like 'vase' or 'knight' if you're thinking about Castle)
- The X and Y positions within this object
Then, the complete object is defined by placing all tiles in that object relative to another. Two or more tiles claiming the same spot in an object doesn't have to be an error: the knight in Castle has one tile with head + shoulders and another one with only the shoulders. Both could go into the same spot.
When switching a level from another tileset to Castle, the level editor may find 1x3-tile objects in the level, where the tile at the bottom is specified as "eyecandy with the special property of including part of the ground". The level editor finds the knight in the Castle tileset, which has exactly those properties. Whether the night will have a head or not can be randomized.
The specification could be extended to include a property that sets the tile's probability. This way, the tile definitions could give for example a 20/80% ratio to the headless and normal tiles. This way, your new Castle level wouldn't miss half the knight's heads
Other things that should be thought of are animations, especially multi-tile animations. And the fact that some tiles can ONLY go, say, immediately right of another specific tile. Just think of all the layer 4 background tiles with shadows on them. The specification has to be VERY specific.