Where we left off last time, I had just finished implementing all of the base features of the level editor, and created the first example level. What I’ll cover in this final post about this topic are the final touches: making it look pretty, adding some quality of life features, and doing some user testing.
Saving and Loading 🔗
Of course, one of the main things you need in a level editor is some way of saving your levels while you’re working on them. And it’s no good if you can’t share your levels with other people, too. But combining these two things into one proved challenging, so I decided to have two separate saving and loading processes instead. One of them would be to save to or load from a file on your hard drive, and the other one would be to generate or load in the 64-bit encoded string we talked about in the first part.
In this way, your computer could deal with the filesystem, but if someone wanted to send their level to someone else, they could just send the code for the other person to load in. This avoids the hassle of needing to send binary files back and forth between users. (This, of course, also presupposes that we’re in some magical world where there are actually at least two different people making custom levels for each other to play.)
Anyway, the first thing I needed to do to make this possible was to add UI icons in the top right for all of these new features. I banged out a few icons in Aseprite, including both unpressed and pressed versions. I think they don’t look all that bad, if I do say so myself.
Another thing I needed to do was make the level title editable and saved in the level code. This was pretty easy, I added a button to open up a menu to rename the level, and I just appended the level name in ASCII to the end of the buffer when saving.
Saving to files was made pretty easy by the Godot standard library. The FileDialog node makes dealing with the filesystem dead easy. I took the default name to save as the name of the level, with a .lvl extension, since it’s a custom binary format. Then when loaded I could filter by this extension to only select real levels. Of course this is easily bypassed, but it’s a nice sanity check anyway.
At this point I had another video to show my team.
The code menus were even easier, just a few Labels and LineEdits. You can see at this point I was still dealing with the erasing bugs (see the stray edge on the right side). At this point I was still handling the edges as separate tiles. I didn’t realize you could make the edges part of the ground tile until I started writing part 1 of this series!
Ditching the ScrollContainer 🔗
One small thing that I dealt with around this time was the button layout. As you can see from the videos, there’s only room for 6 tool buttons on the bottom row. I expected this, so I made the whole thing scroll horizontally inside of a ScrollContainer. This kept tripping me up, however, especially since I was reusing the gate icon for the erase button at the time. So I decided to make things a whole lot cleaner by shrinking the buttons down.
I lost the ability to show the icon and text at the same time, but I made up for it by having tooltips appear when you hovered over the buttons. I also added an actual eraser icon, for even less confusion.
User Testing 🔗
I was finishing up this feature right around Christmas, so I was home in Hawaii with my family at the time. So I took the opportunity to see how intuitive my UX was. I put my skills to the ultimate test: having my family try it out. I asked one of them to try to see if they could recreate one of the levels from the base game, with only a photo as a reference and with minimal guidance from me.
The first results were rough. The first thing that was not obvious was that the user needed to click on the tool button to select and option. Once they figured that out, placing tiles was easy enough. Objects were the same way, although they were momentarily tripped up by my auto-unselect feature that I added. It also took quite a while before they figured out that you needed to click and drag to place wires. And they needed some prodding to figure out how to change the weight of an object.
Needless to say, none of this was the fault of the user; the blame lay squarely on me. It’s really tough to step out of your head and design a UI to make it intuitive for people. I ran into the same issue when playtesting most of my other game jam games. Really what I needed was a comprehensive tutorial that explained all the buttons and how to work them, but that was out of scope for this feature.
But I had an idea that could get my 70% of the way there, and one that was far less hard to implement too: help text. The text you see in the image above is one such example, letting the user know they need to click a button to select a tool. I made this text context-dependent as well, so it did things like:
- Letting the user know they could click and drag to place multiple tiles, when they had the ground tile selected.
- Telling them you had to click and drag to place wires, if they had the wire tool selected.
- Saying that objects could only be placed on ground tiles, when they had an object tool selected.
- Telling the user about clicking an object to edit its weight.
This was hacked in very last minute, as you can tell from the code:
# Triggered when the user presses a tool button.
func button_toggled(toggled_on: bool, idx: int) -> void:
ground_preview_tile_map.clear()
free_current_object()
if toggled_on:
object_to_place = idx
allocate_object()
if object_to_place in [START_TILE, NORMAL_TILE]:
%HelpText.text = "Place a tile by clicking an empty area or place multiple tiles by clicking and dragging."
elif object_to_place == WIRES:
%HelpText.text = "Click and drag from tile to tile to place wires. Wires do not need to be placed on ground tiles."
elif object_to_place in [FINISH_PAD, GATE, TOGGLE, BUTTON]:
%HelpText.text = "Objects like finish pads, gates, etc. must be placed on ground tiles."
else:
object_to_place = NOTHING
if level.objects.get_child_count() == 0:
%HelpText.text = "Select a tool by clicking one of the buttons below."
else:
%HelpText.text = "Select a tool by clicking one of the buttons below.\n"
%HelpText.text += "You can edit a button/finish pad or turn a gate from closed to open by clicking on it."
After adding this feature, I had another relative try the same challenge, and the results were night and day. They got through 80% of the challenge without any input from me at all. I was very happy. A full tutorial feature would still probably help, but again, I got most of the way there with a fraction of the effort, so I consider that a big success.
Conclusion 🔗
And that’s it! That’s the final post I’ll ever make about this feature (hopefully)! It’s been a long time coming, and this was a lot of work, but I’m glad I did it. The problem solving I had to do to make all of this work was very rewarding. Now all that’s left to do is get my teammates to merge this pull request.
I have a few more ideas for posts floating around in my head, and I like the shorter-form style I’ve been doing for these: it’s much easier to sit down and write something when you’re going into it knowing it’s not going to be a total slog. I hope you enjoyed this post and this series, and I’ll see you next time.