Elysian Shadows

CC Ricers wrote:So I'd like to know how some of you start your approach with making a level editor. Do you start by planning out what the how "level files" will be formatted? How about the interface? Is it any better using a customized GUI that is part of the rendered graphics versus the Windows way of adding menus and form elements?

CC Ricers wrote:Thanks for your input, kostiak2 and programmerinprogress, but I already know the ideas behind writing out tile maps with text editors. I am more interested in how to automate the process of making tile maps by taking a graphical approach to building levels, and not typing in text with something like Notepad.

CC Ricers wrote:MarauderIIC, that's some real helpful information. I guess it does make sense to have your editor use the same engine as your game.

In that case should there be a parallel in development for both the game and the editor? In other words, keep the code updates persistent with the engine so that your editor doesn't suddenly stop working for your game. Do you have your editor share some of the source code with the game?

Since I have a game state manager already set up, I was thinking that I can have it two states in the same program so switching between "edit" mode and "play" mode a breeze.

case PLAY:
player.getInput();
player.processInput();
level.update();
level.draw();
break;

case EDIT:
player.getEditInput();
player.processEditInput();
level.update();
level.draw();
break;

programmerinprogress wrote: You missed the point I was trying to make... My point was that you CAN automate this process using a level editor.

I treat games as map readers and map editors as Readers and Writers.

I tend to create an array, or some other type of container, to store the map references when the map is first loaded, then I use my editor to change those numbers, and tell the program to save the new map to the map file (truncating it's previous contents)

If memory serves me correctly, I tend to paste my screen (in the editor) with SDL rects, and check for collisions and mouse clicks, if there are any clicks, the system change the correspondant value of the tile in the array, and makes updates to the file (you are free of course, to wait till the user wants to save the map file, or close the app, if you don't want to immediately save the file).

I hope this answered the question a little better.

MarauderIIC wrote:Well, if your editor uses the same engine, it's in the same project. So you push a button to switch to edit mode while playing. It just reuses like, Map::load(), but you have to add Map::save(). I think that answers both questions and clarifies your one statement in there, right?

MarauderIIC wrote:

CC Ricers wrote:So I'd like to know how some of you start your approach with making a level editor. Do you start by planning out what the how "level files" will be formatted? How about the interface? Is it any better using a customized GUI that is part of the rendered graphics versus the Windows way of adding menus and form elements?

Usually my level editors are dependent on the engine. By the time I get started on a level editor, my engine loads the levels in a certain format. If this needs to change, it changes in the engine then in the editor. And honestly I never really did any deep planning on level files -- just some rough idea that I then design my engine to load.

As for GUI, the only level editor of mine that had any real progress was entirely text-based. But it was a text-based game. The editor was built into the game and if you had the right permissions you could invoke it from the game's prompt. Instead of typing, for instance, "look", I typed "edit" and then it presented the editor menu. Since it was an internet game it just re-output everything every time you went through the menus (as opposed to a clear screen / re-output). It was possible to jump to a certain subsystem or edit a certain NPC or item or whatnot without going through the main editor menu. For instance, if there was an NPC in room #4, I would teleport myself to room #4 (just "go 4") and "look" to see what all there was. If it presented me with

"[ EXITS ]
ROOM TITLE
ROOM DESC
Some item is here.
Bob the Builder is here.
Your mom is here.
Megaman is here.
Some player is here."

I could either "edit npc 2" or "edit npc mom" and it would bring up the NPC editor menu with that NPC loaded so I could edit its stats, description, shortname ("Your mom"), longname (also "Your mom" in this case). I could also "edit npc" which would bring up a numeric npc selection menu for that room (with npc listing for the zone as a sub-option), in case I had trouble finding the keyword for some reason (say if the names were accidentally blank). Also, from any room, I could "edit vnum 4" to bring up the editor for room 4 in the current zone I was in (which has the NPC editor as a menu option, along with change room exits, change room title, change desc, and so on). I could do something like "edit 2-4" to edit room 4 in zone 2. "Edit zone 2" from any zone to bring up the zone editor menu, etc. To make a new room off of a room, I would go to the room and then "edit exit N" and select "new room" from that menu (I could also assign it to an existing vnum). To make a new room that's not connected to anything, just "edit vnum new" or "edit vnum (some vnum that's not taken)" and then save it (no save == no new room). So quick access to subsystems and locations as well as instantaneous changes was a major design point. You might keep this in mind when designing a level editor

Oh, I love talking about that. I miss it [HD failure]

eatcomics wrote:Yeah I remember reading about that and really wanting to play it... Then I found out you were irresponsible and didn't back it up... I almost cried... well not really... oh and btw I don't back up my code that often either...

MarauderIIC wrote:

Code: Select all

void Stage::load() {
(1) : I'm not sure why you multiply by 32. What happens if we have 1*32 in the same row? They overwrite each other?
[/quote]

The number int the file is the tile number to use. The x position in the tile, determines what part of the tilesheet this tile is. So if the tile number is 3, i will multiply it by 32 to get the x position that tells me from where in the tilesheet i should blit, when i want to draw it.

The position in map(a vector of vectors of tiles vector<vector<Tile> >) decides where the tile should be drawn. Is that also a bad way of doing it?

ismetteren wrote:

MarauderIIC wrote:

Code: Select all

void Stage::load() {
(1) : I'm not sure why you multiply by 32. What happens if we have 1*32 in the same row? They overwrite each other?
[/quote]

The number int the file is the tile number to use. The x position in the tile, determines what part of the tilesheet this tile is. So if the tile number is 3, i will multiply it by 32 to get the x position that tells me from where in the tilesheet i should blit, when i want to draw it.

The position in map(a vector of vectors of tiles vector<vector<Tile> >) decides where the tile should be drawn. Is that also a bad way of doing it?[/quote]I see. That's fine. I was thinking setX was setting the x position in the level. Of course not since you're using a 2D vector, so that was my bad, ha.