Despite my continued inability to keep to a schedule, I’m still here and still working on this RPG. Or, uh… a tilemap editor for this RPG. But that’s done now, honest! Done-ish! Kinda!
Didn’t You Say Doneish Last Time
More seriously, “done” is a difficult target to identify when it comes to games and software. Every time you look at a supposedly finished project, you find another spot that needs work. Sometimes, addressing that spot reveals larger problems that went unaccounted for–and that’s what happened here.
When I set out to make this thing back in November (ye gods, has it been 6 months?!), I made a checklist of all the things that needed to be present in order to support my one ‘finished’ map, on paper. I successfully did most of those things before my last update, with a few caveats:
Caveat 1: The tiles in the screenshot weren’t ‘real’
That’s not to say I faked the screenshot! I had the editor properly loading the old map, making it possible to view and edit stuff in it. But it wasn’t being converted to the new terrain system that would generate new tiles, instead using a hack to preserve the original tiles from Tiled through the map conversion process. That’s good for compatibility, but it also meant that
I had not validated how well the map could be recreated using only new system.
Finishing the terrain rules for my test tileset was one of the remaining items on the list. And unfortunately, that included these things you may have heard of called
stairs. We’ll get back to them later!
Caveat 2: The objects were also not quite ‘real’
Tiled has a nifty feature that lets you define and add arbitrary properties to objects. It’s not a good approach for making complex games, but I was using it for the sake of simplicity early on. Initially I was going to add this feature to the new editor, but I changed my mind. It would take a lot of time and effort to recreate this kinda bad way of working, so I changed my plans to include reworking actors with a more composition-based approach.
This will make it easier to build levels later, but also means that I can’t set up new actors the way that I used to in this new map editor. And a rework like this is a large undertaking,
too large to embark on while still working in my map editor branch. In the meantime, I hard-coded a bunch of temporary object types in the editor so that I could load and edit the existing objects in my demo level. This is another fine temporary measure for viewing & editing existing data, but it’s one that can’t sustain itself forever.
To wrap it up–I had most of the to-do list handled, and took measures to continue supporting my old maps, but some blind spots remained.
So why is the rest taking so long?
Big Problem 1: Autotiles
I have a confession to make. The tiles of my first map have seams at some of the corners. In fact,
they have always had seams at some corners. This is because I’m lazy and can’t be bothered to make a million variations unless I have to.
When I sat down to actually finish these terrain-based autotiles, I knew I had to finally tackle this problem. However, my wrists were still very screwed up and recovering…I’ve only really been back to something resembling ‘full form’ (and even that’s a bit of a stretch) for a couple weeks at the time of writing. I knew I didn’t have it in me to click a million times making repetitive permutations of tiles.
But Just Then, Ol’ Hugo Had A Terrible Idea
What if I thought…
smaller? What if, instead of making zillions of tiles by rearranging bits and pieces of my existing ones, I had the computer do it?
What if every tile in my map was several smaller tiles in a trench coat? What could possibly go wrong?
Literally nothing. It worked out great, that’s what we’re doing now, it kicks ass.
Still, it represented a major increase in scope. And more importantly, it became impossible to preserve the old map like I was doing before since tiles had…fundamentally stopped existing in their prior form. The new approach, which I’ll show in more detail later, requires a disconnect between the
visuals of a tile and the
gameplay properties. It makes sense if you think of it, if you’re drawing several miniature tiles in every ‘tile’ of your map then there’s no way to know which one represents the larger tile’s properties. I could’ve simply scaled the grid down, but leaving tiles at the same size greatly simplifies the gameplay code. And the terrain data in the new map format can easily dictate what a tile is for gameplay purposes so it was only an issue in my older maps
Then I found a second reason to ditch the old map:
Problem 2: Return To Stairs Hell
Here’s a funny story: Every tilemap I’ve made since the start of this project contains at least one critical problem with its physical structure, bar none.
I guess that wasn’t actually very funny, but it illustrates how hard it is to make these 3D-ish tilemaps in a program like Tiled.
Of note here are the stairs, specifically any vertical ones like these:
That’s not stairs,
that’s a wall. It looks a lot like stairs, but when you really sit down and
diagram it out, it makes no sense. This doesn’t matter in a game with 2D physics, but it’s a huge deal in a game doing 3D stuff.
I spent a very long time mapping out how exactly these stairs would need to be structured as terrain in order to be physically viable. And maybe, just maybe, I lost my mind a few times:
I was immediately forced to rewrite all of the staircase physics in the game. And I continued to lose my mind for a while:
…but eventually the deed was done, and stairs work and they’re fine and
I’m fine and I still haven’t written all of their tile connection edge-cases into the terrain rules because that’s just visuals and there’s like a million of them but for now I don’t care!
Where was I before I went into a staircase-induced fugue state? Right! I couldn’t keep using my old map, because
it was structurally unsound to begin with. And so was every other test map I’d made to date.
Cool! I’ll have to remake them. But am I forgetting something?
What Are Doors, Anyway? We Just Don’t Know
Before I could get to work remaking the levels, I still had a couple things in the tilemap that I couldn’t make. Doors (or more accurately, doorways) were the most obvious thing that needed work. But how?
Doorways have some funny properties. They connect to walls, but you can walk through them. They also generally appear in fixed sizes–You don’t usually streeeeetch a doorway into a different shape, it’s a
fixed structure rather than a dynamic one. And yet, my only way to make maps (the terrain system) was dynamic in nature. I knew I’d need ways to make static structures eventually, but I had assumed during initial planning that it could be put off. Now that I could no longer preserve my old maps, it had to happen
immediately.
Enter Stamps
This one also wasn’t that bad. I probably spent a week or so rotating ideas in my head until I had a design that seemed sound, then I sat down and made it happen.
Stamps are a pretty simple concept in the new editor: They’re a pre-made arrangement of tiles (visuals and/or gameplay data) that you define in the tileset itself. Then, you can slap them down anywhere in the world and they merge with the tile data they cover
but not the terrain information. This
should make them ideal for a variety of things such as rocks, trees, doors, windows…really any scene element that’s static in nature and doesn’t fully define the terrain it’s attached to.
At this point, I realized that I could also ditch saving
any real tile data in the maps I saved. Today, they just contain stamp & terrain data–when the map is loaded, that data lets it generate all the final tiles on the fly.
Problem 3: Ok, Now Change The Wallpaper
To my horror, working on stamps made me realize something else:
How the hell am I gonna make trees work?
I’ve gone and ditched a lot of traditional tilemap concepts in this 6-month map editor project. Most notably, I replaced layers with a proper Z-axis: That’s how I do 3D tile connections with my terrain.
Now let’s talk about the elusive
tree, never before seen in any of my maps. Trees have a base, a trunk, and a canopy. These need to draw in front of / behind the player and terrain. For the trunk and canopy, this is child’s play: Thanks to the Z-axis, tiles draw over objects when those tiles are closer to the camera. It’s simple!
But what about that base? You see, I’ve been informed that trees have these funny lil squiggly guys called ‘roots’. They go into, and sometimes out of, the ground. In this new paradigm of tilemaps,
these roots occupy the same space as the ground. They’ll still connect properly if I use a stamp for the tree, which I probably will. But that still implies
integrating the ground tiles into the base of every tree, because there are no layers and those tiles overlap in 3D space. That’s…I mean, it’s not gonna work in the long-term. Having to carefully avoid using certain types of ground tiles near trees, or worse
having to make multiple variations that connect to different types of ground, would extremely suck!
Now extrapolate that problem to
every decoration in the game. Furniture? Windows? Banners? Animal pelt rugs? Fountains? Random piles of boxes? Those doorways from earlier? Every single thing that wasn’t closely tied to a particular type of terrain would require workarounds. Or I’d have to do the old NES thing where they all have black rectangles behind them to save on color-count.
You get the idea. So I had to go back and re-structure how the visual part of tiles worked in order to support overlapping ‘layers’ of those mini tiles inside of the big tiles. Here’s how it all comes together:
- 2024-05-17-untitled-rpg-devlog-11-5.png (3.41 KiB) Viewed 34 times
The reality is a little more complex than that, but I could write a whole ‘nother post just about how tilemaps work. The important thing is that we’re finally done!
Right?
But What About That Map Editor?
With that (and countless smaller issues) out of the way, we come to the moment of truth. I finally felt ready to sit down and remake those maps, so I popped open my editor and…it sucks to use.
I’m not surprised. It’s an early in-development tool, there’s obviously not going to be any quality of life features or polish, the design will need adjustments, etc. But I think the current state of the editor makes it very difficult to build anything large or complex, even when I have the blueprint in front of me:
- It can be very difficult to tell where exactly you’re pointing at in 3D space. I tried to provide some helper features for this, like ‘vertical grid lines’ that appear above & below the cursor and highlighting the Z-level being edited by fading out the others, but it’s not enough.
- It’s especially difficult to work when walls are obscuring parts of the area working on. There’s not really any way to hide them right now, which makes it very tempting not to put them in at all until the very end.
- Speaking of walls, the terrain tools are really built around the idea that you’re going to fill in all of the ‘solid’ space with wall terrain. But that’s a lot of work, even with the ability to draw on multiple Z-levels at once, and it makes it hard to remove them later if you want to extend the floor. This is another area where not knowing where you are in 3D can work against you: You can visually line up two walls that don’t physically connect. It’s easy, I’ve made this mistake multiple times…
- There are also no buttons to be had anywhere in the editor. This was fine at first, but we’ve hit a point where there are too many actions and not enough obvious keys for them. This means I wind up forgetting which key an action was bound to, slowing things down even more.
These are all problems that can be solved, but as it stands I feel like I’m not in a place where I can just jump into level design. If I can’t remake my existing maps without trouble, what chance do I have when it comes to fresh content?
This puts me in a strange position–between the unforeseen scope creep and major medical delays, I’m half a year into this editor project now. And while it basically checks all the boxes, it doesn’t feel like it’s meaningfully
done. And yet, it’s blocking some major–and necessary–work such as revamping how actors are set up. The backlog is growing, even while I’ve taken a step backwards when it comes to game content and haven’t managed to…re-step it.
Sometimes, You’ve Got To Keep Moving
Despite the above, I think it’s time to wave the flag of victory, click the big ol’
Merge button in my git forge, and move on. I think solving everything is going to take a long time, and if I dedicate all of my energy to inching this through the last 5% or 10% we could be stuck in this position for months to come. Instead, I’m going to accept that the editor is still a bit of a mess, that I don’t have my maps remade (yet), and hack away at the remains on the side over a longer period of time.
This sort of scope monster is basically the reason I didn’t want to make a level editor, and only sat down to do it when it felt like I was out of options. Give me a few years and I’ll make you a fantastic level editor. But there won’t be a game attached if that happens! And when I say monster, let me be clear–this change weighs in at
5,600+ lines of code added and 650+ removed. It touches so much of the codebase at this point that trying to juggle it with other development tasks is a really bad idea. If I push the change and build over top of it, I can at least benefit from what’s there and make little improvements as I go…it’s not an approach that I could ever use at the office, but in solo-dev town it’s just fine. And as alluded to above, I
do use source control. I can grab old versions of maps whenever I want, they’re not gone forever.
Let’s pivot to the future: What do I do after this? I have two plans for the rest of the year:
Plan 1
This one’s easy, and you may have guessed it already: I really want to get that actor stuff sorted. This change is tangential to the level editor, since creating and editing actors all happens in there. Thus, it gives me a very good excuse to start polishing the UI bits related to these tasks, which in turn should help alleviate one or two of the problems with the editor today. I have some other exciting surprises planned for that as well, stuff I started working on in the backend of the game as part of my current task but didn’t get a chance to properly finish.
Plan 2
What is this game going to look like? That’s a question I still can’t answer, despite taking a crack at some concepts last year. I’d really like to nail down a visual direction for the game this summer, now that my wrist is doing a little better. And while we’re at it, I have another editor-adjacent goal in store (how very convenient, it’s almost as if I’ve been planning this).
One aspect of exploring the game’s aesthetic has to be seeing what assets and finished scenes might actually look like. With that in mind, I want to produce a handful of “visual benchmark” maps using the new editor, both to see what the game’s maps might look like and to validate how easily the current map structure lets me make a variety of different environments. I’ve been working with this very basic and
clean level design tileset, which means that the new approaches to building & rendering a map haven’t been tested with anything that looks like a real game asset. I’m expecting further issues and oversights to be highlighted by doing this, the same way I realized how much of an issue trees were going to become.
In the end, both of these threads of development ‘play nice’–they’re touching very different subjects from very different angles, so it should be possible to work on them sort-of concurrently. More importantly, they also meet at a single point: the level editor. This gives me an opportunity to continue iterating on this tool without halting the rest of the game’s development, as well as testing it in ways that haven’t been possible with my limited set of assets. I would be lying if I said I wasn’t nervous about knowingly pushing code that breaks some existing data, but in this case I think it’s the right call.
