Level editors
Moderator: Moderators
Level editors
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.
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.
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.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.
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.
Useless, lumbering half-wits don't scare us.
-
Celius
- Posts: 2159
- Joined: Sun Jun 05, 2005 2:04 pm
- Location: Minneapolis, Minnesota, United States
- Contact:
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.
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.
I get the picture...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.
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.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.
That doesn't sound like much fun either!You could use an hex editor if you feel more confortable that way
I have the skills, I don't have the time or the patience right now though.If you have skills to make yourself a level editor, by all means do it, especially if it can handle multiple games.
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.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, 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.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.
Use java then.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.
Useless, lumbering half-wits don't scare us.
- never-obsolete
- Posts: 403
- Joined: Wed Sep 07, 2005 9:55 am
- Location: Phoenix, AZ
- Contact:
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.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.
has anyone successfully installed java on a portable device?
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.
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.
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 :)
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 :)