Level design and format.
Monkey Forums/Monkey Programming/Level design and format.
| ||
| Pulling this conversation over here from face book to try and get some more points of view.. I'm working on a game at the moment, where my levels are a collection of tiles, currently my class has the following fields, and most of these would be stored in file. field x:Float field y:Float field velx:Float field vely:float field radius:Float field mass:Float field life:int field hexTile:int field hexGlow:Int field sprite:GameImage field shake:bool field shakeForce:Int field shakeDuration:Int field shakeTime:int Field powerup:Int I will probably expand this set of fields as I expand the functionality of the tiles themselves, my question is what would best suit this data in terms of file format for my levels. I guess my options at the moment (using diddy) would be Json,Xml or Plain Text. there are a number of additional properties that I will need to also add to what ever file format I end up using so flexibility might be a consideration.. |
| ||
| I assume those are entities that will be added with a level editor? I don't really know what you're asking here. For my platformer I went with run level encoding, not xml or anything like that. It worked. When programming games I tend to do things in a very straightforward brute force way. This might bite me in the ass at some level of complexity but for now using manager classes of various sorts and strict encapsulation is doing what I need. |
| ||
| Yeah those are all fields from my tile class, which would need to be represented within the level file format, but that class and the things it needs to do will increase in complexity. I am wondering what the best file format to use would be, for example I could do the above in a comma delimitaed plain text file like this. level,x,y,velx,vely,radius........ or xml
<Level Name="1">
<Hex>
<x>100</x>
<y>100</y>
</Hex>
</Level>
or Json
{"Level": "1"{
"hex": {
"x": "100",
"y": "100"
},
"hex":.......
And that's normally what I would use, I tend to like yourself just brute my way through things, but this time around I want to try and use the best option for the job. I am swaying between XML and Json and I know they have some differences so I guess what I really need to know is how well does monkey handle each with the available modules, or will or is there anything I need to be aware of. I kinda vaguely recall a post about xml and some one couldn't get diddy(I might be miss remembering here....) to read a child property??? sorry it was a while ago and I don't recall specifics. |
| ||
| Why the heck do you have velocity on tiles? |
| ||
| a suggestion some one made in another thread, the longer the player takes to clear a level I will start to drop all tiles down, will be like a cascade of tiles starting with the bottom left most tile and then rippling up the screen until all active tiles have fallen one space. Also planning some special tiles that actually move around the screen, probably nothing to complex just moving left and right within an area or up and down, or a combination of the two, moving targets might be really hellish to hit tho so that will all require testing. |
| ||
| Blogged about this.. |
| ||
| I use json for my level formats now. In the past, I used csv/ini hybrids, ascii grids, and even png files like Jayenkai. I don't worry about space efficiency anymore though, since the data's automatically compressed when put into a package on platforms like android where that space efficiency matters. The only thing to worry about is parse speed, and if that worries you, you should go with a binary format. But for most things I recommend json, since it is a very good balance of extendability and readability (by humans). Parsers are easy and light. I normally don't like XML due to both the complexity of the parsers (relatively speaking to json) and how verbose it needs to be to get the point across. |
| ||
| James that's a sweet way of laying out a level, but unfortunately I need to store data in such a way that I can save extra information about each tile, for example power-ups can be placed under specific tiles, or in the case of a warp/teleport tile i need to be able to say tile A warps to tile B. I have now bookmarked that post tho because I know for sure that's going to be handy at some point. Nobuyuki you think Json is easier on the eye than XML? guess its a personal thing I find xml easier to read. As for load times thats something I wont really know until I test it. |
| ||
| I still think you can heavily reduce the complexities of what you're doing. ...this is your hexagonal breakout thing, right? Start with a grid.. Let's say 8x12 tiles. Give yourself 8 base colours to play with, and the loader can add extra hue parameters for effect. So, for placement we need only use letters ABCDEFGH 0 for nothing, A for red, B for orange, C is yellow, D is green, E is cyan, F is blue, G is purple, H is white. The loader can deal with x-offsetting every other line, so that the hexagons line up correctly, so giving exact co-ordinates isn't an issue. If one of the blocks needs two hits to be removed, simply double it's letter, so for example a two-hit Red A become an I. A three hit orange B becomes an R .. Need more base tile types? Move on to lowercase, and you've another 3 whole sets of 8-letters to play about with. Once your layout grid is done, you can add a secondary "attributes" grid. Here, 0 would be nothing, A would mean it's hiding powerup#1, B would be 2, etc. As for "teleport", reverse your thinking somewhat. Instead of saying "this tile should go to this tile", think "these tiles are group 1" Inside that secondary attributes grid, simply define them as 1/2/3, then get the loader to deal with all of the "this one connects to that one" stuff. Two simple ASCII grids, and you can achieve a whole lot of functionality. You might even prefer to intermingle the two grids, to create a two-character-per-tile grid, but compressing those is usually a bit trickier, since there's less repetition. |
| ||
| I use serialization to save data |
| ||
| Paul - Yeah, when values start to get complex, XML starts to look pretty horrible. The verbosity gets in the way, there's an ambiguity over what should qualify as an attribute vs. a value inside an element's opening and closing tags. What ends up happening is a lot of people make these lists of self-closing tag things at the deepest level -- but it isn't always this way, and you can't really nest inside a self-closing element. Moreover, after you start deep nesting you'll find it hard to see blocks of code, especially if it spills past the edge of the screen and even moreso if you use word-wrap to see the entire tag. Json is more terse, which doesn't always mean better, but since the format's so simple, it's really easy to understand at a glance. There are no ambiguities between when to use element values and attribute values requiring guidelines or careful forethought, since practically everything but arrays and the root object are always key/value pairs. Properly-formatted json lines up neatly, with less overlap than XML. Json parsers are usually less code than XML parsers, and often json objects can be de/serialized faster, too. Etc. |
| ||
| Paul - Yeah, when values start to get complex, XML starts to look pretty horrible. The verbosity gets in the way, there's an ambiguity over what should qualify as an attribute vs. a value inside an element's opening and closing tags. What ends up happening is a lot of people make these lists of self-closing tag things at the deepest level -- but it isn't always this way, and you can't really nest inside a self-closing element, so it can get kinda messy. Moreover, after you start deep nesting you'll find it hard to see blocks of code, especially if it spills past the edge of the screen and even moreso if you use word-wrap to see the entire tag. Json is more terse, which doesn't always mean better, but since the format's so simple, it's really easy to understand at a glance. There are no ambiguities between when to use element values and attribute values requiring guidelines or careful forethought, since practically everything but arrays and the root object are always key/value pairs. Properly-formatted json lines up neatly, with less overlap than XML. Etc. |
   |