Level Editor - NESdev BBS

Level Editor
by lynxsolaris on 2007-03-13 (#22422)

Hello,

Since I started here I've used the .db style format for all my level data. However, my recent project is quite big and doing this .db format has become quite a headache to manage. I'm always getting confused on whats going on where after while. I've spoke (well typed) with Tokumaru a bit and I believe it's time I started looking into writing my own level editor. While I use C a lot, I've never attempted a level editor before and am having some issues getting started. Any thoughts, ideas, possible graphic libraries I should use, etc to get me started would greatly be appreciated.

by Bananmos on 2007-03-13 (#22423)

If you're really serious about making the ultimate graphics/level editor, I'll happily write you a big list of suggestions for features and overall design philosophy. :)

However, if you just need something that works decently, I would recommend you to use Open tUME instead.

It's main drawback that I see is that it only supports grid backgrounds, and thus you can't easily include sprites in your level design. And of course the fact that it only runs in DOS at low-resolution.

But depending on your project, these drawbacks may or may not matter to you. Developing grand tools for a project often results in having no time for the project itself. So before starting, you should ask yourself if the gain compared to using an existing tool is really worth the effort.

by lynxsolaris on 2007-03-13 (#22424)

Hi Bananmos! Thanks for your reply.

Bananmos wrote:
If you're really serious about making the ultimate graphics/level editor, I'll happily write you a big list of suggestions for features and overall design philosophy.

However, if you just need something that works decently, I would recommend you to use Open tUME instead.

I'd like some way to create and arrange my metatiles so that I can keep myself straight! It's very easy to get lost with 9,000 .db statements
If I could do that with "something that works decently" then I'm all for it. I've been working on my project for about 6 months now (not everyday, obviously) and I'd hate to spend 6 months on a level editor.... but whatever will make it easier for me in the long run. At this point I'm not sure whats easier for me in the long run, though.

Quote:
And of course the fact that it only runs in DOS at low-resolution.

That's the immediate drawback for me. I'm in a pure Linux environment. I could try to "wine" it ... but I'd rather run things natively if I can.

Re: Level Editor
by tepples on 2007-03-13 (#22426)

lynxsolaris wrote:
Any thoughts, ideas, possible graphic libraries I should use, etc to get me started would greatly be appreciated.

I'd suggest using either wxWidgets or the Allegro library. Both are portable between Windows and *n?x. Or you could make a level editor inside the game engine that saves to SRAM.

by Celius on 2007-03-13 (#22431)

Yeah, what I usually do is I make a NES ROM that is a level editor, and it saves the data to SRAM. I was planning on making one that uses the gun, so I could do things with the mouse, and I still might. I think it'd be really handy. It's just a little harder because you'd have to check for sprites in several different places. I actually don't know TOO much about it, so I can't really say anything else about that.

by tokumaru on 2007-03-13 (#22432)

lynxsolaris wrote:
That's the immediate drawback for me. I'm in a pure Linux environment.

Try DOSBox... It's light, it's free and it's pretty stable... I'm sure the linux port is as well. Most WinXP users have to rely on this tool to run DOS programs also...

Open tUME wrote:
Open tUME can create, edit and use composite tiles that are created out of other tiles. E.g., you can start with 8x8 pixel characters, then create 16x16 pixel tiles, each composed of four 8x8 characters. You could then continue the process and make 128x128 pixel, each composed of 64 16x16 composite tiles.

I liked this part, because that's exactly how I handle my level maps. I just hope it allows for non-square entities... I'll give this a try!

Celius wrote:
I was planning on making one that uses the gun, so I could do things with the mouse, and I still might.

That'd be tough, because you'll not be able to handle movement with the light gun... It could work if you could shoot buttons for options, and shoot source and target places for movement. Yeah, I think you might have something there.

The thing with the light gun is that you can only check if it shot a white pixel or not. So, whenever you expect the user/player to shoot something, you have to place white squares for each thing that can possibly be hit (or do a sort of binary search and get rid of groups of things at a time).

But yeah, I guess it could work, depending on how you design the interface.

by Bananmos on 2007-03-14 (#22434)

Btw, another big drawback of tUME is that it doesn't provide you with any functions for editing the character data itself. You'll have to switch to another program window where you edit the characters using an image program of your choice, then switch back and reload the graphics file to see the result. Again, this may or may not be a big problem depending on your project.

by Bananmos on 2007-03-14 (#22435)

Quote:
Or you could make a level editor inside the game engine that saves to SRAM.

...

Yeah, what I usually do is I make a NES ROM that is a level editor, and it saves the data to SRAM. I was planning on making one that uses the gun, so I could do things with the mouse, and I still might. I think it'd be really handy. It's just a little harder because you'd have to check for sprites in several different places. I actually don't know TOO much about it, so I can't really say anything else about that.

No offense people, but I keep hearing ideas like these every now then, and I consider them the most misplaced effort there is. Cross-development is the way to go for just about any console. Sure, doing a tool for the NES will always give you some coding experience, but designing a good game engine for the NES's limitations is already quite a challenge in itself, and you'd better not waste your time designing your development tools around these limitations as well.

Take some time to learn a widget API instead. In the long run, it will both save you lots of time and open up lots of more possibilities for your tool. And on top of that, knowing a widely used widget API willl fit nicer into your resume than having made a tool for console emulators.

by tokumaru on 2007-03-14 (#22438)

Bananmos wrote:
It's main drawback that I see is that it only supports grid backgrounds, and thus you can't easily include sprites in your level design.

I guess they make it clear that you need tools to convert from their format to your format... I don't know how their grid backgrounds are layed out in a file, but scanning a grid background and calculating object coordinates from it shouldn't be hard at all.

Quote:
And of course the fact that it only runs in DOS at low-resolution.

I don't think this is such a drawback... I tried it in DOSBox (on a really old PC) and it ran perfectly. The resolution is not such a big deal... when running the levels on the NES the resolution will be even lower than that anyway.

Bananmos wrote:
Btw, another big drawback of tUME is that it doesn't provide you with any functions for editing the character data itself.

I don't think it should. Everyone has their favorite sprite-drawing app, and it would be impossible to include one that pleased everybody.

I don't know what the best approach for "the ultimate level editor" would be. Everyone uses a different level format for their games, because each engine is a different engine. Some people need speed, some people need huge levels (making use of weird compression schemes), some need both... Some scroll in both directions, other are side scrollers, and all of that has an impact on the format of the level.

So, there is no way for "the ultimate level editor" to be prepared for the designs of every game programmer. I don't see any other way for this to work, other than the editor saving everything using a format that's easy to understand and work with, so that the programmer himself can code converters to the desired format.

I'd like to hear some of your ideas on the ideal level editor, though, as this subject really interests me.

Quote:
Cross-development is the way to go for just about any console. Sure, doing a tool for the NES will always give you some coding experience, but designing a good game engine for the NES's limitations is already quite a challenge in itself, and you'd better not waste your time designing your development tools around these limitations as well.

I don't know... I think this is a completelly valid way to code an editor. Graphical limitations will hardly get in the way, as the level is supposed to be displayed on that same system. A few things would be pretty much impossible to do, such as zooming, but I don't think this is so bad.

Quote:
Take some time to learn a widget API instead.

Not all NES programmers program anything else, and that would be a waste of time for them if all they want to do is NES games. For them, coding the editors with 6502 ASM sure is a great learning experience, and they'll not be wasting brainpower with anything useless for them.

I do quite a lot of web programming as my job, but I still like very much the idea of an editor that runs on the same platform as the game itself. I just think that the usual 8KB of battery-backed RAM is a bit too little to work with, but I guess there are ways to use up to 32KB for that if you bankswitch that memory area...

And I really liked the idea of using the light gun as a way to use the mouse for editing in emulators. I really would like to see that.

I haven't decided how to go about the level editor in my game yet. My level format is pretty complex, and I doubt any existing editors will help me much. I'd hate to code some half-assed windows program just to get the job done, but I also don't want to spend months on coding an editor.

by tepples on 2007-03-14 (#22441)

tokumaru wrote:
Bananmos wrote:
Btw, another big drawback of tUME is that it doesn't provide you with any functions for editing the character data itself.

I don't think it should. Everyone has their favorite sprite-drawing app, and it would be impossible to include one that pleased everybody.

I think this has something to do with placement of NPCs, monsters, and such. Does tUME support that?

tokumaru wrote:
And I really liked the idea of using the light gun as a way to use the mouse for editing in emulators. I really would like to see that.

That or just wire an NES controller port onto a Super NES mouse. Both systems use same underlying clocked-serial protocol.

by bunnyboy on 2007-03-14 (#22442)

If you don't want to learn any gui programming, just use a paint program then write a bitmap -> level format converter. Each pixel is one tile or metatile, with the rgb value as the tile number (or translated to view better). Overall very simple programming and easy to use.

by Celius on 2007-03-14 (#22444)

I agree with what tokumaru was saying. I don't want to HAVE to learn any other programming language. I fully plan on learning C, and C++ and all that stuff, but not now. I don't want to be in the middle of making a game, and then have to put it off because I'm learning another language so I can make levels for a game. So for now, the NES ROM way is the way to go.

Also, I'd only use my level editor with an emulator, because you already have the mouse to use as the light gun, and the cursor is on screen, and if you can pull it off, it can work a lot more similar to a PC program. I don't know why you'd want to use it on the real NES. To be sitting in a chair, shooting at the screen, telling people that you're making a level, I think you'd feel pretty rediculous. But it wouldn't look/feel/be as strange on an emulator.

by tokumaru on 2007-03-14 (#22446)

tepples wrote:
I think this has something to do with placement of NPCs, monsters, and such. Does tUME support that?

It seems to only support placement of objects/enemies on grids. Since it is wasteful to store them like this (because of a bunch of blank "tiles" with nothing), you'd have to convert from this grid format into coordinates, to make a more compact list of objects. That's what I understood from their demo. Yeah, they have this nice demo that shows what the program can do.

tepples wrote:
That or just wire an NES controller port onto a Super NES mouse. Both systems use same underlying clocked-serial protocol.

Except nobody will really run this on a NES and dump the contents of the SRAM chip afterwards... that'd be mostly for emulators, where you can use the mouse instead of the gun. How many NES emulators emulate the SNES mouse? If there are any, then a real mouse would be great.

The light gun way does not seem to bad. If using the binary search way to look for a hit, some 12 frames should be enough to tell which exact tile (out of the 960 possibilities) was shot. That should be enough for a level-editing interface.

bunnyboy wrote:
just use a paint program then write a bitmap -> level format converter.

Yeah, I've seen people doing that before. There are a couple of problems with this though, as it's visually impossible to distinguish colors that differ by one unit, and I might just want to place metatile 25 right beside metatile 26. That won't be asy to see.

Also, I don't think that would work well with my level format, that is not made of metatiles that are made of tiles. My levels are made of screens, that are made of structures, that are made of blocks, that are made of metatiles, that are made of tiles. This is so that I can have huge Sonic-like levels, without using much memory. There is no way to edit that in a simple bitmap.

by never-obsolete on 2007-03-14 (#22447)

Celius wrote:
I agree with what tokumaru was saying. I don't want to HAVE to learn any other programming language. I fully plan on learning C, and C++ and all that stuff, but not now. I don't want to be in the middle of making a game, and then have to put it off because I'm learning another language so I can make levels for a game. So for now, the NES ROM way is the way to go.

i don't care much for it as a general purpose language, but i find that visual basic 6 (never tried .NET) was perfect for these types of things. i spat out an editor for my level format in a few hours.

though, at heart it's still a BASIC derivative...

by tepples on 2007-03-14 (#22450)

tokumaru wrote:
tepples wrote:
That or just wire an NES controller port onto a Super NES mouse. Both systems use same underlying clocked-serial protocol.

Except nobody will really run this on a NES and dump the contents of the SRAM chip afterwards... that'd be mostly for emulators, where you can use the mouse instead of the gun.

Checking 960 tiles through a binary search might be difficult, as it would require turning parts of the nametable on and off quickly, and the gun/mouse would have to stay still for those frames. But fortunately, you wouldn't have to check all 960 tiles. You could time how many scanlines it takes between sprite 0 and when the Zapper's photodiode turns on in order to get a fix on the Y coordinate, and then you'd have only 64 tiles (32 columns by two rows) to check.

Quote:
How many NES emulators emulate the SNES mouse? If there are any, then a real mouse would be great.

Nestopia claims to emulate a mouse, but I don't know whether it's the same mouse as the Super NES mouse that was bundled with each copy of Mario Paint.

If you only need one direction, you could try using the Arkanoid paddle.

by tokumaru on 2007-03-14 (#22453)

tepples wrote:
Checking 960 tiles through a binary search might be difficult, as it would require turning parts of the nametable on and off quickly

This would not be a problem. The first screen should be all black to make sure the gun is not pointed to a constant bright light. This one is easy, as it can be done without any tile writing, turning the screen off and setting color 0 to black will do it. Since the screen is off, you can use the time to draw the next screen, half white, half black (which wouldn't be possible just with vblank time). The next sections (1/4 of a screen and less) will fit in vblank, as you can just store the same value over and over, it's just a fill, so it's quick.

You could even use palette tricks, and do a lot of black and white switching by just changing the palette, and that'd give you some more time to update sections of the screen. Not complicated really. Also, maybe you don't need to address individual tiles, and checking for hits to 16x16-pixel blocks could make it all faster.

Quote:
and the gun/mouse would have to stay still for those frames.

That may be a problem... let's say you can detect which 16x16-pixel block was hit in 8 frames. That's a somewhat small fraction of a second, if after a click you don't move the mouse right away, you'll be fine.

Quote:
Nestopia claims to emulate a mouse, but I don't know whether it's the same mouse as the Super NES mouse that was bundled with each copy of Mario Paint.

I think that is a mouse used on those pirate educational NES-based PC's. If there is any documentation of that, it could still be useful.

by albailey on 2007-03-16 (#22465)

Since I'm almost done my Sudoku game for NES (which I need to have completely done for a game show in April), in May I am planning on starting writing a level editor. (to go with a side scroller NES game I'll be starting this summer. )

My last utility was a nametable editor (and palette, and pattern table editor and numerous other stuff I found useful) so I'd likely wire them all in together.

If anyone has suggestions/wish-list for features, or a list of things they wish they had done differently when they wrote theirs, let me know.

If I actually get anything done, I'll make it available. Assuming it doesnt suck. It''ll be in Java.

Al

by Celius on 2007-03-16 (#22466)

It's funny that you say that, because a while ago, I was working on a sudoku game myself. And I made a level editor for it that used the idea being discussed. It was really cool, because it used the exact same engine as the game does, and you could alternate in between permanent and non-permanent numbers, and you'd just lay the puzzle out, and it'd be saved in the proper form into SRAM. By permanent, I mean the numbers that are layed out that you can't change. It's basic, it just made me proud because it was one of the first editors like that that I made. It didn't use the light gun, though.

by mattmatteh on 2007-03-16 (#22468)

i have never used a level editor. but might interested in helping. i wouldnt mind coding it in qt, gtk, or sdl. i mostly code in C. C++ and OO is weak.

matt

by Bananmos on 2007-03-17 (#22482)

Quote:
I think this has something to do with placement of NPCs, monsters, and such. Does tUME support that?

...

It seems to only support placement of objects/enemies on grids. Since it is wasteful to store them like this (because of a bunch of blank "tiles" with nothing), you'd have to convert from this grid format into coordinates, to make a more compact list of objects. That's what I understood from their demo. Yeah, they have this nice demo that shows what the program can do.

Actually, I was more talking about using a small number of sprites to add graphical detail to your levels. Since the NES has such limited palettes, you might want to use sprites to make your level more colorful. (though overusing them will give you flicker of course)

For example, imagine you're making a platformer and your player arrives at the big guardian tree of eternal life or whatever. You might want to have some apples hanging from the branches, and it won't look very good if they can only be placed on a 16x16 grid.

And since you mentioned NPCs and monsters as well: you might want to have some nasty vultures sitting on branches, which will sweep down to attack a player who walks past the tree.

I don't see how such levels could be built with tUME, so only being able to place stuff using grid coordinates is a big drawback IMO.

by Bananmos on 2007-03-17 (#22483)

Ok, here are my personal thoughts on a level/graphics editor for tile-based systems:

Quote:
So, there is no way for "the ultimate level editor" to be prepared for the designs of every game programmer. I don't see any other way for this to work, other than the editor saving everything using a format that's easy to understand and work with, so that the programmer himself can code converters to the desired format.

Yep, this is exactly how I think it should be done. Do not limit yourself to using a fixed format implemented for a single system. Instead, just handle maps with any possible configuration, and have your program save everything it in an easy understandable text-based format. (XML comes to mind) Then provide well-commented and documented source libraries for reading the files and examplifying conversion programs that will convert the data to binary formats suitable for different systems and/or game engines. No need to put any hardware restrictions in the program itself as the conversions tools can handle those.

The editor itself would have most of tUME's editing features, but be able to handle layers with transparency where each layer can different grid setting. For example, your main editing area (for levels or graphics) might have a room with 16x16 grid setting. To organize your tiles, you would have one with an 8x8 grid setting where you build composite 16x16 tiles from 8x8 tiles. You might also have another kind where you'd build structures of 16x16 similar to Metroid.

If I were to use the editor for making sprite object frames made of small 8x8-sprites, I would simply use a grid setting of 1x1 which would allow me to place my 8x8 tiles at any pixel position. Of course, in this case the editor would need some intuitive scheme for priorities since a tile could overlap another. (even if most NES designers made sure tiles wouldn't overlap, check out Megaman's face for example) A flag to specify if two tiles can occupy the same coordinate might also come in handy, since you might want to place two 8x8 sprites at the same coordinate when making sprite object frames, but probably want a placement to overwrite another when editing grid-based levels.

And if I would like to make some fancy cut-scenes, I might use one grid-based layer with either an 8x8 or a 16x16 grid setting and another one with a 1x1 grid setting. This way I could use BG for the main parts of a full-screen image and then fill in details with sprites. A method very often used in high-quality NES games, which most graphics programs and level editors lack any intuitive support for.

Of course, there should also be good support for animating inside inside the editor. Animation should not be limited to a fixed number of frames per single tile. For example, if I want to animate my sprite objects, I want to be able to specify a sequence of sprite object frames to reference for each animated frame, along with a time length. Nowadays, I use a bitmap program for animating my sprites, but that treats every frame as a pixel image, and for storage and flicker considerations, it'd be nice to be able to arrange a set of 8x8-sprites directly instead.

In the ideal case, animation should also include scrolling different layers. Maybe even scripted with some easily addable script language?

Last of all, it would be neat if there were some typical image editing tools avialable to edit the graphics data itself inside the editor. But that's kind of overkill and shouldn't be bothered with until the more important features are implemented.

I advise everyone to take a look at the tUME demos. (which are actually preferable to watch in DOSbox, since they run awfully slow in Windows for some reason) Especially if you have any plans on rolling your own editor.

by tepples on 2007-03-17 (#22485)

Bananmos wrote:
Actually, I was more talking about using a small number of sprites to add graphical detail to your levels. Since the NES has such limited palettes, you might want to use sprites to make your level more colorful. (though overusing them will give you flicker of course)

For example, imagine you're making a platformer and your player arrives at the big guardian tree of eternal life or whatever. You might want to have some apples hanging from the branches, and it won't look very good if they can only be placed on a 16x16 grid.

In Super Mario World for Super NES, the first thing Mario sees is the big guardian tree. The game actually stores this as one object, where the decompression handler for the tree adds several apples to the level.

by Memblers on 2007-03-20 (#22559)

OK, you guys have inspired me to do what I'd been wanting to do for a really long time. Which is to write my level editor for a simple game I'd been wanting to make for a while. I need the coding practice.

It's very low-budget though. I'm not sure if it'll be useful for anyone else (maybe). I might keep it built it into the game, though it'd have to run on Squeedo to worthwhile on a cart (WRAM + 4-screen + FlashROM + XMODEM = my NES is my computer ).

So far I'm only planning on supporting horizontal scrolling, and having the editor lay out metatiles + 2 attribute bits. I'll see how it turns out, I just started on it the other day.

by tepples on 2007-03-21 (#22562)

Memblers wrote:
(WRAM + 4-screen + FlashROM + XMODEM = my NES is my computer ).

Add a keyboard, a hacked Super NES Mouse, and an ATA controller for a CompactFlash slot, and something like Doctor PC Jr. might actually be doable.

by mattmatteh on 2007-03-21 (#22571)

are you coding it yourself or is this a group project ? what are you coding it in? what is the intended operating system?

matt

by Memblers on 2007-03-25 (#22627)

Here's a demo of what I have so far. It's not much to see, but I just fixed a horribly annoying bug (in some code I wrote years ago, even!), so I'm proud and have to show it off to someone who understands what it's for.

There's no saving or loading yet, but the editing works.

select = change mode
a = place tile / select tile
b = change attribute (selection mode only)

http://www.parodius.com/~memblers/nes/editron/editron-demo.nes

Source is up in that folder too, but it's nothing pretty.

by albailey on 2007-03-26 (#22630)

I like it.

My wife told me that she remembered playing a game called pinball factory when she was younger. I can see something like what you've done being readily applied to a game like that.

Al

by Bananmos on 2007-03-28 (#22673)

I should admit that there's one category of games where making the level editor run on the NES is indeed a good idea: Puzzle games with a built-in level editor are great for this. When you have the game engine working and the tiles drawn, a built-in level editor would be great for designing new levels and being able to try them out immediately.

Not to mention that once the game is done, you have a cool level constructor for the gamers to enjoy.

by beneficii on 2007-04-03 (#22836)

For a while, I've considered making a generic Mario level editor which assumes that levels are composed of object and enemy data and that lets you define the objects and specify their sizes, etc. You would be able to store stages to their own file or even convert them to code. It doesn't seem like it would be technically difficult, just a lot of work.