This is the engine for a game I just released. No menus here - just mouse clicks to plot tiles, cursor keys to scroll around the level and other keyboard commands for other misc crap, like playing ff7chocobo.mid while I work. Worst editor ever, I know, but I had to make it in about two evenings.
All of the other editors are looking great, especially the first one by Fifth!
In response to Eternal Entertainment, I guess there are only 2 methods you could use: recording the values in an ini file, or using an array.
If making an editor is not your thing, then you could derive the level layout from a small gif image, or, if it's a single screen game, "draw" the level layout in a text file with numbers, e.g.
1="1000000001"
2="1000000001"
3="1999999991"
(where 1 equals walls and 9 equals, like, crocodiles)
Really though, I think most people will agree that using arrays would be the best system to use. inis are okay but everyone will laugh at you and it's a switch you'll have to make eventually. Think underpants to boxer shorts.
?
I'm not using inis. I use in-game textfiles, it's bad for patches since you need to update the whole application and not only the levels, but it's good in the way that the player can never now if he has found all areas and such since their's not any external files to tip the player off. But I agree on arrays probably being the most suitable object for the task. And alas, I too will, in time, switch to boxers...
Yeah, but arrays waste much more space just to store a few numbers.
The last editor I made (for a game I never finished anyway) would load a normal text file, where each ASCII character represented one tile. Then, I just used String Parser to get the ASCII index of that character, and plotted the corresponding tile to that position.
I mainly use editors when I need additional power from MMF. For example, having different sounds when you walk over certain tiles, or making some tiles carry your scent (grass) and some not (water).
I really feel like making another editor just as a chance to develop some interface ideas I've had recently.
Yeah, but arrays waste much more space just to store a few numbers.
Not, as I've said before, if you structure your data properly. Given that we know the exact size of each element it's possible to parse your data so that multiple values are stored in each cell, effectively producing a 3+-dimensional array without the control data you usually need in text-based storage. In an ideal implementation, this approach could very well produce smaller files than a text system.
Of course you can create simple vector-style text-based storage without control data, but it would be next to impossible to manipulate manually so there wouldn't be any real advantage to it.
Sure, you could optimize the array system. But why take crap and make gold out of it? Besides, the average klikker can't be arsed (and doesn't know how) to do that anyway.
axel: Writing a parsed array system requires exactly the same amount of effort as a parsed text engine, and has the added functionality of being an array.
And if your criticism is that the 'average klikker' is disinclined to do something like that, the same could be said of caring about size wasted with vanilla arrays.