Closed Germanunkol closed 10 years ago
The {x,y} notation is a good idea.
When we want to implement the castle tiles, then we probably have to extend the tileset. 16 Tiles are not enough, because the content of each tile also depends on the diagonal neighbors. Right now, I solved that by placing extra foreground tiles. But for the level editor, this should be automated, so the user does not have to think about it. I will try to work this out.
It won't be hard to add the other tiles, I believe. It's just boring work, but not hard - we can easily make the function ground:getQuad depend on the 8-neighbourhood instead of the 4-neighbourhood.
I can do this, but I currently don't know how the tiles fit together. Maybe you could make an example .svg where all the possible combinations are present? Then I could work from that.
Or you could just add it to the getQuad and the Ground:init() functions. Note that you don't need to worry about the "similar" or "transition" functions -> you only need to append to the tall "elseif" tree at the center of the function.
Confirmed. I will try to make a full list of cases in an image, for illustration.
Added lots of commentary to the editor/ground.lua. I hope it's enough to show you what I do. If in doubt, simply print out the mStr and str values in Ground:getQuad.
I added a class "Ground" which holds the quads/coords for all the different ground types.
I'll shortly explain the idea behind it in case you need to work on it or add more ground types (and as a documentation for myself) and then list what's left to do:
In function Ground:init, one can add a new type of ground. This function should be called whenever the camera scale changes - so that the correct tileset is used. However, it must be called after the editor.init function, because that one loads the tilesets. There are functions for adding the coordinates for the various tiles for the ground (the single tile, the horizontal line, the vertical line and what I called the "thick" block of 9 tiles). Coordinates of the tiles are given as a table of two values:
{x, y}
This function makes it easier to move tiles around - if the tileset should ever change, one simply needs to change the coordinates for each tile in this class, the rest remains the same. Note: The coordinates start at 0, not 1.The class also has a funtion getQuad, which takes in the ground classes of all 4 neighbouring tiles and returns the quad (or tile type) which should be used at the current quad. Example: if all neighbouring tiles are the same type as the current tile, then the center of the thick block will be returned.
I moved away from the IDs for tiles that the Tiled had, which would only store one number for a tile and increase that for every row. While that approach had its advantages, my method with storing x and y for each tile will allow to increase the tileset's width (and not just height), without ever destroying anything in the code.
To do: