Devlog 01: Making a Monochrome Dungeon Crawler RPG?

When I first got determined to make a small complete game, to finally finish a game, my idea was to make a more slavish clone of Akalabeth: World of Doom than what I ended up with. Even after mechanics and ideas changed, the look still definitely intentionally resembles it.

The whole point of making an old school black-and-white dungeon crawler, to me, was to both limit myself, and challenge myself. To make a tightly designed project and reduce scope creep. I sat down and wrote a small design doc. Even though the project changed from the initial idea, getting the sense of the size of this project was very helpful.

Gotten somewhat dazzled by the oldest of the dungeon crawlers, checking them out after the Legend of Grimrock series, I wanted to replicate the look, but use more modern game design. Out of the big 3: Might & Magic 1, Akalabeth, and Wizardry 1, it was definitely Akalabeth that I like the most – it wasn’t so stats-heavy, and the enemies actually moved in the dungeon. It really was the progenitor for Dungeon Master and its derivatives with a more interactable world, giving you a better sense of space than abstract encounters and loot of other contemporary games.

Akalabeth: World of Doom (1979). Image credit: GOG.com
https://www.gog.com/en/game/akalabeth_world_of_doom

I’m a C# software developer during my day job, and after the Unity scandal a few years back I firmly decided to work in Godot engine for this project. I was ready to create more things for the game through code than average. Also, I decided I want to try and target many platforms, mobile ones included. To this day, if you want to work with C# and html5, you have to work in Godot 3.5, so this is what Magic Locus is being made in.

So, when it comes to this art style, there are basically three options on how to achieve this look:

• Make a true 3D game and use a wireframe filter that will make the geometry look like this;
• Make 2D textures and an algorithm that skews the textures into places, to achieve a 3D environment look;
• Make a texture variant for each view distance and position on screen and assemble them without distortion;

Wireframe true 3D, by Polly, 2016, TIGForums
https://forums.tigsource.com/index.php?topic=56707.0

Layered textures example, from a tutorial by Screaming Brain Studios, 2022
https://screamingbrainstudios.com/first-person-dungeons/

Having very little experience with 3D graphics I didn’t want to dive straight into meticulously tuning shaders to achieve this consistent and unusual for modern projects look. There was also another parameter left to decide: resolution. My previous attempts at making games were all pixel art. The first thought is that it kind of clashes with vector wireframe idea. Because, you know, scalable vectors vs raster images. But here’s the thing: later, in early Ultima games, there were these pixel art enemies, and Might & Magic 1 blends this transition to textured graphics, with colourful enemies, while often having these monochrome, or low-detailed walls.

Might & Magic Book I for DOS (1987 version). Image credit: retrogamer.biz review
https://retrogamer.biz/might-and-magic-book-one-secret-of-the-inner-sanctum/

Moreover, the original platforms these games were released on were all low-res by today’s standards (280x192 for Apple II, 320x200 for C64).

If you squint, these old games walk the line between being pixel art and vector graphics, which, I thought, was greatly useful for me! I decided, as a challenge, to try and make my game at the lowest reasonable resolution. Multiplatform release meant I won’t be making it strictly landscape or portrait. So, I picked 128x128. This is smaller than Game Boy’s 160x144 and is actually what PICO 8 the virtual console has to work with. PICO 8 is fun, but the size of my project was surely to exceed its capabilities, so after humouring the idea of fully moving to PICO 8 I decided to only use its resolution and stick to Godot.

With 128x128 pixels of screen, and leaving room for the UI, the actual viewport in the final iteration of Magic Locus got only 88x96 pixels in size. I looked whether someone have already made any 1st person dungeon crawlers in PICO, and found (the incredibly difficult) Minima by Feneric:

  

Minima (2018) by Feneric. Source: https://feneric.itch.io/minima

It was clear to me: not only is it possible to make a 1st person dungeon crawler at that size, but also, at this scale, every pixel matters. The design transitions from up close vector-like lines, to pixel art just a few steps away. So, I decided to create all the sprites for the game, at all the distances, by hand, to have complete control over every pixel, like with any pixel art.

My original concept art for the view with perspective for Magic Locus

Another question that arose was the design of the enemies and objects. I did settle on pixel art overall, but was it worth it to design objects as if they were vector/wireframe as well? The thing is, I was also greatly inspired by this cover art for Akalabeth:

Cover for Akalabeth: World of Doom by Denis Loubet (1980). Image credit: IMDb

What mesmerized me in this cover was how this dimly lit scene with glowing elements was like a transition from the world of light and colors to the monochrome outlines of the game, suggesting that all of the game’s visuals were harsh light outlines and glowing ritual lines, and beyond them resided an actual physical world. I honestly think this cover is genius, and in my opinion it deserves a better visually designed game than Akalabeth, than other games I have seen, than whatever I can achieve.

My early enemy concepts: a rat, a hooded rogue with a knife, a skeleton

I decided this wouldn’t work in the long run – it wasn’t very readable, and even less so at further distances. What became clear to me, was that each enemy must have a recognizable distinct outline at every distance from the player. And inevitably, just a few game tiles away, any sprite turns into a tiny pixel art that has to be distinguishable from others. All this cemented the pixel art aesthetic.

My early concepts for skeleton and brick walls sprites

I wanted to make different walls and some in-dungeon interactivity. It was supposed to be less than the hidden button searching and the pressure pads of Dungeon Master, but more than Akalabeth’s simple enemy and boxes interaction. After my decisions on how to approach the visuals, I got the idea of how much sprite work this is for a full game. With this much work outlined for me, an idea to have a simple, but expanded upon overworld from Akalabeth was scrapped. This early on into the project I still wasn’t sure if this was a tower, an underground tomb, a lighthouse, or something else, but the focus definitely moved to a single dungeon.

At this point I could actually sit down to code the game. Skipping quite a few details I’ll definitely come back to in future devlogs, I ended up with a simple walking prototype. Blank walls, brick walls, a walking skeleton. By now, the idea still was to make a minimalistic RPG. And to me, what makes a video game an RPG are the choices – three differing playthroughs at the very least. Be it a classic warrior/mage/thief trifecta, three major endings, or at least just three mutually exclusive guilds. And it was quickly becoming apparent, that a) I like the idea of a more complex magic interaction way more than some kind of varying turn-based input for the warrior, and I didn’t want to even start designing thievery, stealth or ranged weapons in this art style and this interaction-based approach; b) my ideas for level design became more and more about magic interactions, inspired by Grimrock’s portal puzzles, Sokoban games, and Akalabeth’s magic amulet floor skipping. I also wanted to come up with a spell casting minigame that would be reminiscent of the ones from Dungeon Master and Legend of Grimrock, but still be a unique one.

An early build of the game, named Magic System at the time

The design now heavily favoured a mage playthrough as is, and I wanted to implement even more spell interactions with the game world. I made a decision to cut the warrior and thief classes/playthroughs. This, to me, meant that the game was no longer an RPG, but a turn-based adventure game. Well, I may still make different endings. And the game can still have some stats upgrading during the playthrough and an inventory, which makes it an RPG to some. But this decision also allowed me to double down and come up with a specific guy with a backstory that you play as – now a mage for sure. But now I am cautious of calling my game an RPG. If I have to put it into genre baskets, it is a turn-based adventure puzzle game with RPG elements.

And that is how the design direction of Magic Locus: Ziggurat solidified to what it is now. Thank you for your attention!