This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Level editors

Level editors
by on (#33490)
Just wanted to ask everyone about their thoughts on this matter. Maybe some of you had to handle something similar already.

Most of my platform engine is ready, and soon all I'll have left to program are the individual objects. This means that I should start adding some real content to my game right away, so that it starts looking better than a bunch of colored squares.

Some of you might remember that my level structure is quite complex: The level map is a 2-D array of screen indexes. Each "screen" is 256x256 pixels and is composed by four 128x128-pixel blocks. Each of these is composed by four 64x64-pixel blocks, which are composed by four 32x32-pixel blocks, which are composed by four 16x16-pixel metatiles. Kinda crazy, yes, but it's the only way I found to have really big levels with the amount of memory available, and it's all working pretty nice and fast.

It would be a pain to go manually through all those structures just to make a single screen, so I coded this little command line app that reads in multiple level maps (2-D arrays of screen indexes stored in text files) and the screens used by those levels (each in a numbered text file, containing the indexes of 256 metatiles arranged in a 16x16 grid), and outputs binary versions of all the maps and structures that I need, and reports back how many structures were used so that I can increase redundancy when approaching the limit.

So, the only things I have to define manually are the metatiles, the screen maps and the level map, a lot closer to how levels are usually designed. However, this still sounds like a pretty boring task, so I wanted to know if anyone has any suggestions on making the process of designing levels less boring and more visual. Specially since I'll probably be needing help for this, so I must be able to offer people a somewhat comfortable way to do it.

Maybe there is a decent general-purpose level editor that is somewhat customizable, and I can modify my app to convert it's output into the format I need. I just don't have the time to develop a complex editor with a complex graphical interface right now, that's why I'm looking for an alternative.

EDIT: Yeah, I'm aware of this old post of mine. But I really don't have the time to code a full tool, so I figured it could be a good idea to partially use a generic one.

EDIT: It seems like I had this idea before... Guess I'll check that Open tUME again. Does anyone know of other generic editors? Preferably not for DOS (Linux doesn't help me much either)?

EDIT: Know what? I kinda like Tiled. It's simple and quick to figure out, it outputs the levels in a format that's easy enough to read and creating a new tileset is dead easy. I might just use that and change my app to convert the output into what I need. I'll give it a try sometime soon.

by on (#33495)
Quote:
Most of my platform engine is ready, and soon all I'll have left to program are the individual objects. This means that I should start adding some real content to my game right away, so that it starts looking better than a bunch of colored squares.

I am in that case since about a year but don't worry, programming individual objects is by far the hardest/more annoying part of making a game. You always found yourself too limited no matter how you handle stuff, and you always have to rewrite the whole code for your first test objects dozen of times (that's what happened to me at least). When you move to programming a boss, it's only to figure out that most of stuff becomre more compliceted, limited and annoying. And you have to write a duplical version of all routines you made for regular enemies to have their boss counterpart.

However, I always think making levels is the fun part. I usually draw them on paper and then make metatiles that looks like what is on paper, to eventually enter them in .db statements. You can make some assembly labels to help .db statements, so personally I had no trouble with that.
You could use an hex editor if you feel more confortable that way, but I'd feel bad about having one file per screen, each taking barly one dozen of bytes, and find it even worse than .db statements.

If you have skills to make yourself a level editor, by all means do it, especially if it can handle multiple games.

by on (#33498)
Well I'm going to make an editor in Visual Basic once I learn a few more things. It's really simple for making nice-looking programs.

But yeah, otherwise you could make a NES ROM editor that keeps the data in SRAM. That's what I've done before. And when I suggest that, I DON'T mean using it on the actual NES, because that's a waste of time, because in the end it's just supposed to give you data on your computer that you can incbin into your game.

If you don't feel you have time to write a simple application, then I think you'll have to do .db statements. However, you can design your levels on paper like Bregalad said, and enter them in as .db statements. Also, you can enter them in in a way you could understand and edit more easily, and then have a simple NES program rearrange the data to be interleaved like you want it to be.

by on (#33503)
Bregalad wrote:
I am in that case since about a year but don't worry, programming individual objects is by far the hardest/more annoying part of making a game.

I get the picture...

Quote:
I usually draw them on paper and then make metatiles that looks like what is on paper, to eventually enter them in .db statements. You can make some assembly labels to help .db statements, so personally I had no trouble with that.

When you have 256 metatiles it can be a pain in the ass to keep looking for the correct index of each one you need, and editing the level later is much harder, because it's difficult to visualize the layout when all you see is numbers.

Quote:
You could use an hex editor if you feel more confortable that way

That doesn't sound like much fun either!

Quote:
If you have skills to make yourself a level editor, by all means do it, especially if it can handle multiple games.

I have the skills, I don't have the time or the patience right now though.

Celius wrote:
Well I'm going to make an editor in Visual Basic once I learn a few more things. It's really simple for making nice-looking programs.

Yeah, the "visual" stuff makes it real easy to develop simple graphical interfaces. I was looking for something more portable though, because I do my DEV'ing in too many different PCs, so I like to use compact tools so that I can move them around easily, and Visual Basic, Delphi, C++ Builder, etc are just too large to carry around, and it's impossible to use them without having to install them. I couldn't find a simple, compact development environment that would make the process of creating a GUI easy.

Quote:
Also, you can enter them in in a way you could understand and edit more easily, and then have a simple NES program rearrange the data to be interleaved like you want it to be.

Yeah, I'll probably end up doing that. There are a few generic level editors that output a plain map of metatiles, and I'll have a small app convert that into my format.

by on (#33504)
Quote:
Yeah, the "visual" stuff makes it real easy to develop simple graphical interfaces. I was looking for something more portable though, because I do my DEV'ing in too many different PCs, so I like to use compact tools so that I can move them around easily, and Visual Basic, Delphi, C++ Builder, etc are just too large to carry around, and it's impossible to use them without having to install them. I couldn't find a simple, compact development environment that would make the process of creating a GUI easy.

Use java then.

by on (#33506)
Bregalad wrote:
Use java then.

Guess I could... I'm not too good (at all!) with graphical interfaces in Java though, and I'd still need a bunch of stuff installed (Java isn't exactly compact, you know).

by on (#33507)
Quote:
Yeah, the "visual" stuff makes it real easy to develop simple graphical interfaces. I was looking for something more portable though, because I do my DEV'ing in too many different PCs, so I like to use compact tools so that I can move them around easily, and Visual Basic, Delphi, C++ Builder, etc are just too large to carry around, and it's impossible to use them without having to install them.


theres a VB6 distribution floating around that can be installed on a flash drive called "Visual Basic Portable." i've been told it uses ~6MB and i'm sure that it violates microsoft's eula, those factors you'll have to consider. :) this would still leave you tied to windows machines though.

has anyone successfully installed java on a portable device?

by on (#33508)
Ah, this is interesting! Checking out.

by on (#33510)
Or you could just use MinGW (GNU C++ compiler for Windows) and Allegro 4.2.2 to make your editor, like I did for 8TED and 8name.

by on (#33514)
Learning C++ is kind of a task. But VB has a very simple language, and the program does a lot of coding for you. You rarely have to type anything to check if a button was clicked.

by on (#33515)
C++ is not such a big deal, the problem is learning how to work with Allegro. I must agree that with VB I'd get a much better editor in very little time. Since it's just a tool (that will not be of much use after the game is done - unless people want to hack the game), I'll probably pick that. Just tried the portable edition, it works great.

I know this is not the most professional solution, but I don't have the time to waste on mastering Allegro or getting used to C++. Thanks for the suggestions though.

by on (#33519)
If it is professional or not depends on how well you do it though. You can be professional with VB. And as you said since it's just creating data for the NES program which is the focus, it isn't a big deal if people dislike VB.

Though C++ and Allegro are not hard at all. :p

by on (#33531)
For application programming I would recommend C# over both C++ and VB.NET. It's fast and east to create GUI application in it, and it have a C++ like dialect so it's pretty easy to get started with if you have worked with C++ before. The support from MS through MSDN is great too. And DirectX in C# is pretty nice too.

I wrote a Level editor with support for meta tiles and multiple layers and what else in C# with fancy GUI for a mobile project in like two weeks (most of the time went for making things like dockable windows :P)

But for games I would still pick C++ as I like to have direct control of memory and things like that :)

by on (#33532)
If you plan to eventually port a level editor to DS, GP2X, or Pandora so that it can be used on the go, I wouldn't recommend C# for those cases either. Heck, even a Windows Mobile device struggles to run assemblies for the .NET Compact Framework.

by on (#33540)
Well of course I wouldn't recommend trying to run a level editor written in C# on a DS. But I thought we were talking Personal Computers with a IA32 compliant processor and most likely a Microsoft Windows based Operating System here (trying to be as precises as possible for tepples :P).

by on (#33541)
dXtr wrote:
But I thought we were talking Personal Computers with a IA32 compliant processor and most likely a Microsoft Windows based Operating System here (trying to be as precises as possible for tepples :P).

I'd have taken "x86 PC running Windows".

But sometimes there aren't enough "x86 PCs running Windows" to go around. I guess my prejudices are shaped by the family situation. My aunt is a single mom who has three children and one eight-year-old PC. One of these children is a ROM hacker. He would love to have tile editors and level editors that run on the DS while his brother is using the family PC for Webkinz or looking up Mega Man videos on YouTube, so that he can edit the ROM and then run it in nesDS.