Sign in to follow this  

Map editor, tileset information

This topic is 4713 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

While considering the rewriting of SDL_isometric (isometric graphics renderer) I decided to first write a good isometric map editor so I wouldn't have to hack the maps files with vim or something :) The editor is open source (GNU GPL) and uses gtkmm (C++ wrapper for gtk+) for the GUI. XML is used for data files to make it easier for other developers to write conversion tools for their own formats. At the moment the editor can render a diamond map and you can place a box tiles by mouse (and make piles of boxes) so basic rendering and screen2map conversion is working. It will support both diamond and staggered maps but I'm testing with diamond because I've heard they appeal to woman and I'm getting desperate :) Anyways I've been thinking about tilesets and tiles in general and how I want my editor to use them. Tileset (in my mind) is a collection of tiles which are similar or have some logical connection. For example it makes things easier for the user if she knows that the grass tile she is looking for is in the same tileset with all other grass tiles and so on. Tilesets could also define relations between tiles and other useful information for the editor. For example tile presenting a transition from grass to mud could have transition information attached to it. Editor could then use this information to automatically generate transitions from grass to mud. If you have ten different tiles for grass you could tell the editor that they present the same thing and are interchangeable. Again editor could use this information to make large fields of grass look better by using ten different grass tiles instead of one. All advanced features can be added later and only the most basic information is now needed. Here is the list of basic attributes I could come up with: Tileset - name - list of tiles Tile - name - image (filename, colorkey) - position in image (there can be many tiles on one image) - width and height - offset (used in rendering) And converted to XML it could look something like this (I'm putting the data to tag attributes instead of enclosing it inside tags. Tell me if this is stupid :) tileset.xml <?xml version="1.0"?> <tileset name="ground"> <image filename="ground.png" colorkey="#0000FF"> <tile name="grass" x="0" y="0" w="64" h="32" offsetx="0" offsety="0"/> <tile name="stone" x="64" y="0" w="64" h="32" offsetx="0" offsety="0"/> <tile name="mud" x="0" y="32" w="64" h="32" offsetx="0" offsety="0"/> </image> </tileset> I've setup a project page which can be found here. I will upload more screenshots when new stuff can be done. I propaply implement the basic tileset/tile system on weekend and make the first release when it's working. Tell me what you think about the format, the editor and everything. -- Jarmo Hekkanen

Share this post


Link to post
Share on other sites
Sounds interesting, just a couple thoughts:

1. Are you going to support tiles of different sizes in a map? If not I would just specify tile size once for the tileset and not for every tile. This makes it less work to update your xml files if the size changes and makes it harder to get invalid data in there on accident.

You might support tiles that are different multiples of a base tile size, in which case I would store the base size in the tileset and the multiple in the tile. This is a pain for the game engine to deal with however so I would make all the tiles the same size and allow the definition of tile groups which can be placed in the editor. That lets the designer work with different sized tiles but your engine only needs to deal with one size.

2. Instead of having x,y coords for each tile I would store the size of the image in the tileset definition and only store the index of each tile. The location of the tile in the set can be calculated with ease from the index. This gets more redundant information out of your xml and makes it less error prone and easier to maintain. You might also make the index implicit from the order of the tiles in your tileset.

I like the screen shots, you might want to think about adding support for slopes to the height transitions.

Share this post


Link to post
Share on other sites
Quote:
Original post by Solias
Sounds interesting, just a couple thoughts:

1. Are you going to support tiles of different sizes in a map? If not I would just specify tile size once for the tileset and not for every tile. This makes it less work to update your xml files if the size changes and makes it harder to get invalid data in there on accident.


Yes, the editor will support tiles of different sizes. I don't see the benefit of using single tile size (apart from simplifying the data files :) and the editor shouldn't force user to split their graphics if they are bigger than one tile.

Quote:

You might support tiles that are different multiples of a base tile size, in which case I would store the base size in the tileset and the multiple in the tile. This is a pain for the game engine to deal with however so I would make all the tiles the same size and allow the definition of tile groups which can be placed in the editor. That lets the designer work with different sized tiles but your engine only needs to deal with one size.


Let say that you have a stone wall in your map and in the game you blow a hole through it and now you want to change the tile in map cell x,y,z to wall_nw_hole. This is easy when using one tile for the wall but things get complicated when the wall is splitted to many tiles. You have to track down all the tiles belonging to that particular section of wall and change all of them. This could be easy if the lower tile is x,y,z and upper is x,y,z+1 but when the wall is big you end up making side steps and other dirty things. You could solve this by carrying the tile group information to the game's data and use it to find the correct tiles but I still think it is easiest if you just use one big tile and do some offsetting and stuff in the rendering.

If all tiles in tileset (or image?) are the same size there could be a tile_width/height attribute in the tileset or image tag specifying the size of all tiles in this particular tileset/image.

Quote:

2. Instead of having x,y coords for each tile I would store the size of the image in the tileset definition and only store the index of each tile. The location of the tile in the set can be calculated with ease from the index. This gets more redundant information out of your xml and makes it less error prone and easier to maintain. You might also make the index implicit from the order of the tiles in your tileset.


Yes, it is easy to calculate the positions when tile size is static (and could be done if this is the case and there is tile_width/height attribute present) and this could be done with dynamic sized tiles as well but would require the artist creating the tileset image some level of understanding how the coords are calculated. This could also lead to fragmentation (wasted space on tileset image) but still it's worth considering.

Quote:

I like the screen shots, you might want to think about adding support for slopes to the height transitions.


Height transitions could be done using the same technique as tile transitions so adding them should be easy. I'm glad that you like the shots :)

What are the benefits of static tile size and does that mean that all tiles should be limited to the rectangular area of one tile (for example 64x31) or that all tiles should be diamonds? I understand that having all tiles as diamonds could help in the renderer because you could construct stacks of tiles that occupy the same tile space (just made this one up :) on the screen (screen is divined to diamonds and each of these diamonds has a list of tiles that are rendered to that particular diamond/tile space). You could easily do culling by starting to render from the top of the stack and stop rendering when you hit a tile that has no transparent areas (or perhaps continue rendering but only render tiles that are part of some object and use some dithering thing to make the object partly visible through the wall).

--
Jarmo Hekkanen

Share this post


Link to post
Share on other sites

This topic is 4713 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this