|
CRPG Tile Based Engine/Editor Question submitted by (21 December 1999)  |
Return to The Archives |
 |
 |
|
I'm working on creating a CRPG tile based engine like the one used in
Final Fantasy 3 (FF6j). So far, I have the tile structures and renderer
*mostly* complete, but I'm still looking for ANY information regarding other
problems I've been having:
Can anyone help??? |
||
 |
 |
 |
|
|
|
OK, I'm going to break this down into two sections - how to make tile
structures, and how to make a level editor once you know those structures. Section 1 - Making tile structures: Start by finalizing exactly what information you want contained in your levels, and where that information should be stored. In the typical tile based game, there are three main places you can store information: 1) In the level header, which means it applies to the entire level. 2) In the tile structure, which means it always applies to that tile, regardless of where the tile is placed in the array. 3) In the (x,y) index of the map array, which means it applies to whatever tile is in that space. To do this, you'll have to make your map array out of objects or structs, instead of just basic data types. That's a bit nebulous, so let me nail it down with an example. Say you've got some nifty alpha-blending (transparency) effects in your game, and you use an integer to represent how transparent something is. If you store that integer in the level header, the entire level (i.e., all tiles, and all spaces on the tile grid) will have one transparency value. Not too exciting. But, if you carve out space for that integer in the tile structure, then each tile can have a different transparency value. That's a lot more flexible. Finally, if you carve out space inside each and every (x,y) index of your tile array, then each space on the map can have a different transparency value, which is even cooler - the exact same tile can have different transparency values depending on where it's placed. Unfortunately, the more stuff you store in the (x,y) index of your tile array, the bigger your level files become. With a medium sized map (say, 100x100 tiles), you're looking at about 40,000 bytes of information (100x100x4 bytes - 4 bytes per space is just enough for an integer, or a pointer, to specify which tile is currently in that space). 40k, that's not too bad. But realize that for every additional integer you store in the map array, you increase your 100x100 tile level size by 40k. So obviously, you want to be very careful about where you store things. Practically... most of the time you can get by with between 4 and 8 bytes per grid space. Most additional information can be stored in the tile structure. Exactly what information is there depends on your game. A bit of good hard game design will give you a nice list of things you need, along with where they should be stored. Section 2 - Making a tile based level editor Tile-based level editors are very similar to the pixel-based art programs of the old days, like DeluxePaint II. The old paint programs basically gave you a huge array of pixels, plus a way to select a pen color and draw. At its most basic, your tile editor should give you a huge array of tiles, plus a way to select a tile and draw. There's a lot of GUI code in the typical level editor... when I made my shareware tile editor, MapMaker 5, I found that dealing with the tiles was easy compared to dealing with the GUI. This means that your first difficult decision is whether to use the Windows GUI, or to roll your own GUI. If you have solid GUI code already written, it might be easier to use that (or maybe even integrate the tile editor into the game, as some RTS games do)... but I wouldn't suggest it. For a beginning project, you'll probably want to make your editor a plain-old Win32 application. Application frameworks (like MFC) can really help you here. I can't really go into specifics from this point on, because a lot of it is going to vary depending on the language and framework you use. But, I will offer some hints and a rough "plan of attack" that I learned over the course of getting MapMaker up and running. 1) First, write your tile-grabber code (i.e., a program that converts BMPs into tiles). Again, this should share the tileset loading code with your map editor. 2) Next, finalize your tile rendering code. If you have to hard-code tiles into the array for now, that's OK. Just get it rendering, and scrolling beautifully. (BTW - if you can swing things so that the editor and the game share the same rendering engine, do so. It's worth it.) 3) Tile editors are very interested in which (x,y) array position of the map the mouse cursor is currently hovering over. One of the most called functions in any editor takes (x,y) coordinates and returns the (x,y) position in the map array that corresponds to those coordinates. 4) The code to save and load a map should be done early, that way, you can create a "test map" and use it to excercise features. 5) Once you've got save/load code, start working on the actual editing. That is, letting the user select a "tile pen," and letting them "draw" on the array with that pen. 6) Next, figure out a way for users to edit everything inside the tile structure (except maybe the pixel data itself), inside the level header, and inside each grid space (if you store anything besides tile pointers in there). 7) From there, add the other features you need... but test early, test often. Don't be too anxious - hold off on moving to the next step until you're sure everything before it is done and working perfectly. Contrary to what you might now think, creating a tile editor is not hard.... like everything else in programming, it just requires careful planning, a good design to work from, and a bit of dedication and patience. Response provided by Mason McCuskey |
||
|
|
|
This article was originally an entry in flipCode's Fountain of Knowledge, an open Question and Answer column that no longer exists. |