So, when a click project becomes complex enough, it's generally advantageous to start making editors to speed up and organize the design aspects, right? of course, the most common type would be the level editor, but perhaps people make editors for other things as well?
I made this topic chiefly out of curiosity. Is it commonplace to make an editor for one's game? Or is it easier, for the most part, to simply make levels straight in the click program's frame editor?
And for those who make editors for their games, are there limits to what types of games get an editor? I'd imagine stage-based puzzle games would be the most popular candidates for editors, but how common are editors for other genres, like platformers? And how similar would editors be made by different people? Would they end up with similar layouts and functionality?
So the point of this topic is that if you've made an editor (level or otherwise), show it off! Post some screenshots of it in an editor-worthy state!
And here's a screen-stretching shot from the editor for "Nothing" to start things off:
Go Moon!
DaVince This fool just HAD to have a custom rating
Registered 04/09/2004
Points 7998
1st March, 2007 at 16:56:08 -
Sweet editor!
I tried making an editor in my early days and horribly failed. Don't need to make one at the moment.
I designed my editor for a couple of reasons, none of which really include game complexity, because Diamond: Revolution 2 isn't complex enough to need a personalized editor.
I made a level editor 1, because external levels will mean less in-game frames and lower game size. The other reason would be the demand for a nice editor, I wanted to give people the ability to create their own levels if they wanted to, once they beat the game. Even share levels with each other.
Absolutely nothing about my level editor is truly unique though, just simple point and click.
This be the level editor for Blockguy 2. I plan on having users make levels as well, but in such a way that they can't edit the built-in levels or replace them with their own. Well, not without screwing the game up
You may notice that all walls look the same. The fun part is that when levels are loaded in the main game, the appropriate tile is automatically added (for floors or ceiling or whatever). So the level creators don't have to worry about having to set the right tile everywhere to prevent their levels from getting all ugly and stuff.
The editor graphics are all placeholders.
Making an editor is always a balance between making the game extensible and how much work you can be bothered to put into it. I've made one for a project that was meant to be based around an online database of user-submitted levels - this has actually been shelved for now, but I was really proud of the Preview feature.
Edited by the Author about eight times to get our mad IMG tag working
Here's my one for Gauntlet Runner, I'm planning on using a grid based one for Gauntlet Runner 2, because moving blocks pixel by pixel is VERY ANNOYING... I haven't got the array loading done yet but everything else is going alright . But I do like this system as it allows for a certain level of easy after you get used to it. Damn I wrote way more than I meant to... And contradicted my self several times.
I started making my first level editor a few days ago, it's a lot simpler than I thought! I can already see the benefits. Keeping your game to a single frame definitely helps a lot, and the fact that you've already made a level editor makes it really easily to implement into the game you're making
I don't know whether I'll finish and release the game I made this for, but the editor is taking shape, and functions well on a basic level
That looks like an awesome editor Fifth. Are you able to make levels exceding the limit of MMF (20000x20000 pixels) with your editor/engine? I've found that the levels for my game will be big, I have one level planned that will probably be over 90000 pixels at least, and I'd like it to be seamless. I was thinking maybe it would be a smart move making an editor if I can get it to let me make levels larger than 20000x20000.
Edited by the Author.
Edited by the Author.
Mendokuse...
Peblo Custom ratings must be 50 characters or less
Peblo's is certainly the most versatile of the bunch.
Anyway, Lukas, the way I've got it set up, no actual frame-scrolling occurs in the game, so the frame-size limit doesn't apply. Instead, everything is loaded on a page-based system (each full screen is a page, and four of them are read at one time), and, since I'm using one byte to store each of the level's dimensions, I can get up to 256 pages in each direction (although I haven't actually made any levels that big, so for all I know it might start acting strange after 128.)
So 256 by 256 pages, pixel-wise, is... *gets out calculator* 81920 by 61440 pixels.
'Course, if you really needed the room, you could add another byte to each dimension, getting... 65536 pages and 20971520 pixels across.
So it'd definitely be possible to get levels that large. It's just a matter of pulling it off.
As you can pretty much generally make up the filetype it varies from game to game. If your game was called Pac-Man I'd assume the extension would be .pml for 'pac-man level'... It doesn't really matter but that's what people generally like to do
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.
hey i gotta ask u guys a question
when ur loading active objects from ur level editor's such as enemy or foreground
does it require different code then u do for backdrops???
Its not enough,I need more
Not enough to satisify
I said I dont want it, I just need it.
To believe, to feel, to know I'm alive.
Knuckle deep beneath the borderlines.
This may hurt a little but its something you'll get used to.
Relax. Slip Away...
well using a tile system doesnt mean that u cant make really nice big backgrounds, it would take a large amount of artistic skill or just taking one of ur large backgrounds as is - and just cutting it up into watever tile size ur using (ie 16x16)
Its not enough,I need more
Not enough to satisify
I said I dont want it, I just need it.
To believe, to feel, to know I'm alive.
Knuckle deep beneath the borderlines.
This may hurt a little but its something you'll get used to.
Relax. Slip Away...
You don't NEED to have a level editor program to make levels ¬_¬ Meaning I wouldn't blame Pod for not having one seeing as you can just copy frames and replace sprites. No harm done IMO Level editing is more for players than it is for developers.
Also, I call JFrudy to post his AMAZING isometric level editor here... It, is, NICE
i dont know tim, i think a level editor is for developers can be very useful. For one you can actually program an entire game just using one Frame in MMF but loading different external levels - and u can save all those external levels to one array using the Z dimension
plus it makes a grid system easier to build faster - using MMF level editor can be tedious especially when u want it pixel perfect - ctrl+v, click with mouse, hold arrow key till u get in the right position
Its not enough,I need more
Not enough to satisify
I said I dont want it, I just need it.
To believe, to feel, to know I'm alive.
Knuckle deep beneath the borderlines.
This may hurt a little but its something you'll get used to.
Relax. Slip Away...
DaVince This fool just HAD to have a custom rating
Registered 04/09/2004
Points 7998
27th March, 2007 at 09:59:50 -
Pod did use a level editor. There are some levels you can enter where there's nothing but emptyness, proving that the level file in there was probably not found.
DaVince This fool just HAD to have a custom rating
Registered 04/09/2004
Points 7998
28th March, 2007 at 05:49:52 -
"plus it makes a grid system easier to build faster - using MMF level editor can be tedious especially when u want it pixel perfect - ctrl+v, click with mouse, hold arrow key till u get in the right position"
Snap to grid feature in MMF2. I used it for Blue Dude, it's pretty useful.
How do you make all your game's info, if all loaded from an external file, totally unhackable? I mean, if you were just loading from gamedata.arr, or whatever, anyone could easily modify your main game's level/progress/stats using their own MMF program that can easily display, and modify, all your game info.
You could keep MD5 hashes of the genuine data and compare them when they're loaded, but storing anything externally always introduces some sort of risk.
blanco: Why? Why would you bother making an anti-hack system anyway? A game's purpose is to entertain, and if people find that hacking your game is fun, then why stop them, just for the sake of stopping them? The Underside is hackable, Cave Story is hackable. Hell, there are even Cave Story mods out there.
Of course, it's different if it's an online game, and you want to prevent players from taking unfair advantage by changing game data. But if it's only a one-player game, then I can't really see why you'd want to prevent people from hacking it.
You could just encrypt with blowfish if you really wanted... I don't see the point, modding games is fun! I might release an underside mod when it's done, nice and easy to edit
If you only wanted to prevent people from changing game data, then you could just have it MD5 all external files, and compare it with a hash that you've stored in a string somewhere in the game. If you didn't want people to be able to even look at your data, then you should encrypt it. But again, I don't see the point in that anyway.
There are many reasons why you wouldn't want people to edit external files, although it depends on the game, somes games it would be great for others it would horrifically ruin.
Advertisement
Post Reply
Edited by the Author about eight times to get our mad IMG tag working
