• Hey! Guest! The 39th GMC Jam will take place between November 26th, 12:00 UTC and November 30th, 12:00 UTC. Why not join in! Click here to find out more!

Alpha A grander level editor

Hello everyone,

With a lull in my schedule for the moment, I've started to make a grander editor. I have made quite a lot of in game level editors in the past, but this isn't about them. Instead this is a new level editor that will most likely be used by a lot of people in the future.

THE PREVIOUS EDITOR:

There were a lot of features here, but it was just a small scale. A single room, three layers for background, foreground, and solid objects. No tile painter since the game could auto tile generated tiles on the fly like most of my games.

THE ROOM EDITOR:



The first step, was doing something I've never done before, and that's a room editor for a grander scope. Maps with several rooms. My previous editors had shortcomings where they could only update the room you were in. Now you can edit an entire map's worth of rooms. Each color represents a different room and it's a bit messy since the more rooms you have, the more the colors blend together.

Everything is bound to screens like older games. The use is simple, click a room and drag to add to the room. Click a not room to make a new room. Right click a screen tile to remove the room.

THE SOLIDS EDITOR:



After the room editor comes the solids editor which I have done for a lot of other level editors. In this case, there is a key to let you toggle between the two editing functions. Everything I've ever done with map editors has been relegated to color. Whites are standard ground, oranges are enemies, yellow is the player spawn, greens are ladders, aquas are drop through platforms and so on. It's just the simplest way to offer a visual representation.

In this phase, I also made a selection tool. Click + drag to select areas, which can then be removed with the delete key. Holding the selection and hitting control would fill the entire selection with the color selected. Dragging via the right mouse button through selected area will deselect the area to cut a hole. Right mouse button alone will select the color you're hovered over like an eye dropper. This was just a quick way to get things up and running.

THE TILE PAINTER:


Unfortunately I can't show off the tilesets I'll be using due to an agreement, so instead I'll show you an old tile painter I had come up with. In this instance you can see the ability to select multiple tiles and stamp them into the world.

With the new tile painter, you can do the same thing, but there are more details to see what you're doing. I also allowed for coordinates of the tile to be saved rather than the tile index. This is to allow for ever changing, growing tilesets to be used and not become useless because someone updated their tileset to be too wide.

LOADING EXISTING MAPS:


I have made a lot of maps over the years using relatively the same color codes. There are a lot just lying around, so here's a larger, more impressive map. There are two ways I can pull this map in and that's either by .pngs or .txt files with the data from the .pngs.

At this time I created several more layers, as I've always used layers for rooms, liquids, foreground, background, and three miscellaneous layers that hold most of the same data (solids, extras, guides). Unfortunately the .txt files that hold the data didn't account for three separate layers, they just dumped everything into the same layer.

With so many layers, it was time to see the visuals better. Active layers had 100% alpha and other layers had 10% alpha as you'll see below.



THE PICKER PANEL:


The picker panel was created back with the tile painter, but here I retooled it for the colors of every object in the game... all 200 objects. This was easy enough to do since when I add a new object to any game, I give it a color, but now I gave it a name, and a placeholder for the description.

I also optimized the drawing process more because originally each change had to redraw the surface layer, so now it just draws / removes what you just did from surface layer. This turns a stutter effect into a smooth process.

THE PICKER PANEL (phase 2):



The picker pannel can be clicked + dragged to move it around. It modifies itself to fit the screen. It can be clicked to open and close it. There is now a description and name to so what's being selected.

I took the time to optimize the picker panel to only trigger every 3 frames so what dropped the frame rate to 300 is running back at 1,000+ frames per second. The picker panel performs perfectly at present.

More functionality was added such as the middle mouse button to pan the screen, hovering the mouse at the edge of the window will pan the screen. WSAD + arrow keys already did the same.

CLOSING THE FIRST POST:
As you can see it's still a work in progress and I have a lot more to craft. Another part of this grander editor was to keep it simple, so it's only a single object which can be drag and dropped into other projects. In the past, there were tangled webs of objects for the panels and other things.

Hopefully someone enjoyed reading this.
 
Last edited:
THE CONTROLLER SUPPORT:
Is it crazy to add controller support for a level editor? Anyway, I added controller support and it works well, since this is the third editor I've had with controller support. The keys are just bound to buttons on the controller. Left bumper for left mouse click, right bumper for right mouse click. Bottom face button for control. Left face button for shift. There's even zoom and to move the cursor or pan faster, you push the stick buttons. To zoom, you hold the right trigger and move the thumbstick up or down accordingly Some things could be better such as the left thumbstick pans the screen while the right moves the mouse when it should be reversed.

THE FAMILIAR:


A menu was bound to happen, because the game already has a menu system, but now it has a list of editor functions that still need to have functionality. Things like play map, save map, save map as, load map, new map, and back are all here. It was after this that I also copy / pasted in my notification system, because it also carries the game's notification system. This notification system pops up text from below the screen and displays the latest notification, before dropping it out the bottom of the screen. I have tried to keep the editor as one single object, but it does use preexisting scripts and now the menu would count as a second object that would need to be updated when drag and dropping this into other projects.

Since my games use just about the same menu system, but have a different look, it's easy enough to copy / paste any menu code that has editor in it. Then the game's menu will change the look. That's the beauty of using simple arrays.

THE NEW MAP:


This might seem easy to explain, but there are a lot of details that went into this simple process. The editor uses grids and surfaces. Grids to hold the data, when actually the surfaces work just fine to hold the data. There was already a system to wipe the surfaces and then use a grid to restore the surfaces, but what there wasn't was a way to clear the grids. Once that was done through the tedium of repetition for almost 10 grids, I added it to the destroy event since in the future, the editor will be destroyed and without something to destroy the grids and free the surfaces, they will get stuck in memory and cause a memory leak. It was also time to create a command system for the editor. Something that would tell the editor that the menu told it to make a new map. This command system also allows for hot keys.

As for why the new map was the first thing on the menu? Because the load map feature will need it. Another reason is because to get to prototyping quicker, the game will always load the first map. So each of the maps you've seen before now have been modified existing maps.

I should point out for scale, the screenshot above is 16 x 16 screens. Each screen is around 27 x 14 tiles.

THE WARNING:


Part of making things user friendly is preventing poor decisions by asking them for a confirmation, such as are you sure you want this to be a new map? You never know when someone accidentally pressed something and you don't want them to lose any work, so you ask them. Luckily for me, this was already part of the menu with a statement system. The statement system offers a question rather than exclusively menu choices. I expect the warning to be for most other menu functions as well. While I'm here, I will also point out that yes and no follow a traffic light color scheme where green is yes or go, and no is red or stop.

THE DOLDRUMS:
I saved the dullest for last and that was a bunch of small things that took up a lot of time that can't be seen or shown off. Things like adding names to each of the objects the player can place in game. Smoothing out some objects in game, that the color coder missed. Making the maps load the .png files rather than the .txt files as the .txt files have a dump of information minus the layer they're on, because to the game it doesn't matter, but to the editor it does. So guides, extras, fronts, and solids were getting dumped into the solids layer. I also took the time to allow solids to be placed on those four layers. The game already had a way to pull in .png files to turn them into a grid for the sake of read time. It's quicker to read a number than a color.

The editor should be playable soon once all the editor menu functionality is complete. Then frills will get added.
 
THE SAVE:
In order to play the game, you have to save the game. This was the second easiest thing I'm about to tell you. Why was it the easiest? Because it already existed. Part of working on these maps is that they're all color coated micro .png files. Then when the game plays, it converts the data to .txt files to make the data exchange faster. So when saving the maps, it will first save the .png files and then convert them automatically. The conversion takes a bit of time, but better a one time wait. Saving the .png files is a time saver for the game too since the .txt files are missing the layer data. Two saves does seem a bit excessive and that might change in the future, but for now it's .png for the layers and .txt for the speedy load times.

THE PLAY:
Now for the easiest function added in this blog. Play functionality already exists, as does playing specific maps, so this was quite easy. The editor makes an _autosave of the map and then plays that _autosave. To flesh out what was a quick process, the game knows how many rooms are with the map and it knows where the player starts. Then from that player start, it loads that room.

THE SAVE AS:


The save as was far more tricky than the previous functions, because it required an input box. Luckily for me, there was already a simple input box used for the cheat console to type in functions. I took that and made something more versatile that could be used elsewhere. Another catch to save as is that it's saving a file name rather than a name, so everything beyond letters and numbers get stripped out of the file name before the game saves. To keep the new input box useful for various things, I made a finished process unique to what it was doing. Whatever is using the input box will then scoop up the variable and put it toward the function which in this case is saving.

THE DETECTION:
Here's the problem when playing the game. I had always know what I was doing when making the maps, so I knew to make a player within a room. Otherwise the game crashes. Since other people will be using this map editor, I ensured a few detection processes to ensure there was a player, and that player is in a room to start with. The map will save, but it is unplayable.

To blend better with the save as, there is also a detection to ensure there is a map name, because even I fell into that trap myself. Saving a map without a name lead to a lot of ugliness in the file structure.

THE TEXTURE AND THE TILES:


The texture data was always just a visual in the editor and nothing more. Since my games auto-tile, there was never a need for a specific tile save. So the visuals of a giant texture were never saved or loaded. Up first was making a system to save the .png to yet a another file. Each tile is now its own color code that allows for a tilesheet that is 255 tiles wide and 255 tiles tall. Why 255? Because it saves as a color, not a number and 255 is the maximum for RGB values. I tried using HSV, but that didn't work, so I went with RGB.

The .txt version of the map files always had a sticker system to allow for details to get drawn in game such as the grass and bushes getting generated in game were mere stickers. The tiles get saved in the same way, just stickers that when loaded make up one giant texture per room. Why one giant texture? Because it's easier to have a single room surface than trying to draw thousands of sprites to make up a room. These are on solid objects and will never change, so the giant texture works.

Seen below is without the tiles drawn and the game just generating tiles to cover solid objects:


And here is the editor version:


THE CLOSING:
With this installment of this blog, the editor is playable and usable, so that wraps up phase 1. Now the editor just needs a lot more features that my previous editors have. It will be a long process, but should be a smooth process since I've done it before and I know the pitfalls to avoid.
 
Last edited:

hydroxy

Member
Your level editor is super neat. I came across it as I was looking to see if someone had done one like this already.

I am currently in the process of making one myself, there is something really satisfying about it, its like making a better tool with your existing tools, so when you've finished you've invested time into a great resource that will help in future. GMS2's editor is good and all, however it is impossible to beat a run-time level editor. Being able to edit levels without compiling is massively beneficial I feel to doing good level design.

I do have one question though. When painting the objects in the levels using the color picker, why not just use a to scale version of the map and paste in images of the actual objects, ala Mario Maker. Using the color grid approach is a just a different approach to what I am used to.

Also I checked out drinkingnails.com Some very cool games on there, hope to make something of equal quality soon myself :D

EDIT: What fonts did you use, they are nice.
 
I do have one question though. When painting the objects in the levels using the color picker, why not just use a to scale version of the map and paste in images of the actual objects, ala Mario Maker. Using the color grid approach is a just a different approach to what I am used to.

Also I checked out drinkingnails.com Some very cool games on there, hope to make something of equal quality soon myself :D

EDIT: What fonts did you use, they are nice.
Mostly because I haven't gotten to that part since at the moment nothing is an object, just a drawing. So I'd need to add all the art for 200+ things along with x and y offsets. I can probably drop the objects in during the drawing process, have it draw those objects, then destroy the objects. The catch would be I'd still need to write all the object_indexes for 200+ things. There is no master list of color codes to objects, when there probably should be. just to have 1 list that gets used when loading colors as objects into the game and loading colors as objects into the editor. That's hindsight planning. That and making objects in the editor to create, draw, then destroy feels unnecessary when I can just stamp the sprite. My previous platform editor stamped the sprites to the draw surface, but that was unfinished and experimental.

After saying why I didn't do it... I went and did it on a small scale:



All the color codes now have a sprite set to noone by default until I add them and a default xoff and yoff set to 8 and 8. Currently the only things that have sprites are the collectables and random enemies. By random enemies I mean they spawn a random enemy in game for testing purposes. In this case the editor represents the random enemy as a hover mine.

The drawing process is currently being drawn to the texture surface as that's the only surface that's a real size. The rest are micro .pngs representing 1 pixel for every 16 x 16 cubes. In the future, I may give the drawn sprites their own surface, but for now the texture surface works well. I'm sure the current method while imperfect saves some time.



As for the font, I need to check the specific font. It could be one that I made a few years ago to look like 8-bit standard mono space fonts.

Some fonts were made for the game and need some work:



Thanks for the comments and questions.
 
Top