Designing an open-source dungeon crawler

In September 2017, I saw an ad for a tiny pocket retro console, called the Arduboy, and rushed to buy one: I clearly remembered reading various articles a year or two prior about a guy that made a Tetris business card and thinking “Wow, how cool would that be?”. Well, it happened that “that guy” got funded from Kickstarter, and started mass-producing a sturdier, more customizable version of his original business card.

The ArduBoy

As stated on the website, Arduboy is a 8-bit system that can be re-programed with your own games, as long as you know C++. It is based on the Arduino hardware, and the specs are “retro” to say the least:

• 1-bit 128×64 pixels screen
• 8-bit processor at 16Mhz
• 32kb Flash storage (well, 28 really), 2.5kb RAM, 1 kb EEPROM
• Piezo speaker

For development, it uses the Arduino libraries, and particularly an Arduboy library specifically developed for it. Games and apps can be flashed on the board from your computer by using the provided USB cable. The device is supported by an enthusiastic community and new games are being released daily.

The PROCESSING prototype

I must confess that when I bought the Arduboy, I could have done a bit more research – not that it would have changed the outcome – about the development requirements: because it was based on Arduino, I somewhat assumed it would be compatible with the Processing language (some sort of JAVA layer) that I became familiar with from teaching it at SCAD. So I naturally got quite excited about developing my own games for it.

I quickly realized that everything had to be developed natively in C++. At this point I decided to stick with my original idea and develop a working prototype in Processing, and try to rely on the very helpful community to help me with translating the code from Processing to C++.

Using Processing was making sense for me on many ways:

• It’s a very fast prototyping tool that has all the right libraries (I love working with it, it reminds me the glory days of Flash)
• I could focus on solving the gameplay programming challenges with a language I know pretty well
• It generates very light code that could “proof” my game staying below 27K
• At worst, it would lay the foundations for a future C++ translation, at best, it would compel one of the community developer to help out with the project.

10 to 12 hours of work later, I had my first working prototype (yes, Processing can be that fast!), made a video of it and posted it in the community forums

That approach paid-of, and a community member, Simon Holmes @filmote got excited about the project and decided to help out! It was good news, because it turned out that porting my code to C++ would have been much less straight-forward as I had hoped: developing for such a tiny device requires heaps of optimization!

The game design

Being a child of the 80’s, I grew up with games such as Dungeon Master, Wizardry or Eye of the Beholder (one of my all time favorite). This type of games was very popular on pretty much any machine in the 80’s ranging from the ZX-81 to the Amiga. A lot of “adventure” could be conveyed through simple graphics and gameplay, and there is nothing quite so primal as exploring a maze, slaughtering monsters and collecting loot – so it made a lot of sense trying to port that experience to the Arduboy.

I took a good look at the gameplay pillars of the genre and identified the game loops that would have to be present in our product – without them, the game wouldn’t function as well:

• Exploration: this core loop provides the “meat” of the game: it’s all about finding your way out of the maze, and in to a new, more complex maze.
• Fight: this loop provides the challenge to the player’s exploration loop as well as acting as a feedback system to the player’s progression
• Loot: this loop provides both a gameplay challenge (inventory management) and a short term reward system.
• Level-up: this loop provides the mid-term rewards and allows the players to make (somewhat) meaningful decisions about their character.

Hopefully, with a good integration of these loops, we would have a game that would feel “whole” yet be simple enough to fit within the 27K limits of our hardware (knowing that graphics would take most of that space)

For those of you interested about the design process, you can download the very simple Game Design Document written for the game here! (the document is provided “as is”. Some screenshots are outdated and some information has changed since release)

Production challenges and solutions

A good while ago, I was hired to produce assets for a Legend of Grimrock clone in HTML5 and in doing so, built my own prototype in Flash, so I already had wrapped my head around the assets production pipeline for that type of project.

The secret is really about how you divide your screen into tiered sections and “layer” your assets from far away to close-by.

The production of assets can be frustrating when you are dealing with HD assets, but in our case, with a viewport of 63×56 pixels, the creation of the assets needed was much faster, even-though not without its problems.

While my first wall set was done pretty quickly and was your average “brick wall”, I was really committed to having some variation: ideally, I wanted each new maze to use a different wall set.

When I work on a game, the creation of art assets is usually not the challenge. Time, number of assets can be the challenge, or integration in the engine, but usually not the creation part. However, this time, I got surprised: technically, a section of a wall (if we take a close-up left section, for example) is 16×56 pixels – knowing that this representation obeys perspective rules. I realized it was incredibly hard to put details in that size, with only 1 color, while respecting the perspective. Every attempt I made ended up feeling cluttered and hard to read on our small screen.

Wall sets being our biggest budget in term of graphics, and due to my inability to provide good looking variations in the time we had imparted ourselves, we decided to stick with only one tileset, and use the memory left for more enemies, items to collect, etc.

User Interface

With a limited set of buttons available on the device, we needed to be careful about setting up our UI so that the game would be usable without ending being frustrating for the player.

The directional buttons to move in the maze were of course a no-brainer, although I’m still hesitant about allocating our “down” button to a 180 degrees flip rather than a step back. The A and B buttons are allocated to the validation of an action, or cancelling it. When no action is selected, B shows the player inventory.

Choosing actions, like the type of attack or defense you want to use in combat, or managing the inventory is done by selecting icons with the directional buttons and validating the choice. Can’t get much more old-school than that!

As I mentioned in the game design section, inventory management was a core pillar of our gameplay. How ever, due to the size of our screen, and to the fact that I wanted to force players to have to choose which items to keep and which to discard, we kept the inventory size to only 3 slots. I was really reluctant at the idea of having the player “scroll” through many pages of inventory.

Every action in the game is represented by an icon: for example, in combat, with the right equipment, you can have up to 4 options: Attack, Defend, Use a magic spell or drink a potion. All these selectable actions are represented by a small 18x18px icon.

Ultimately, I’m pretty happy with where we landed: the game is simple enough to pick-up, easy to use, yet offer all the game loops we were planning on, in a satisfying manner, given the restrictions of the device.

Level/encounter design

Dark & Under includes 3 levels: the first one is pretty straightforward, and is composed of 4 15×15 tiles. It is supposed to teach you the “ropes” of the game, and provide players the satisfaction of finding their first exit somewhat quickly.

The second and third level are significantly more complex, take more time and require some backtracking in order to complete.

The enemies difficulty also scale accordingly to the difficulty of the level, the player starts battling rats and slimes, and ends up killing Occulars (our version of the trademarked Beholder!) and dragons.

Mid-way through production, my partner @Filmote surprised me with a fully developed level editor for the game. So far, I was laying out the levels in Photoshop and an Excel spreadsheet, so it was a definitive improvement. Although, at first, I got extremely worried that adding this new tool would delay our development (bugs, and developing full code and functionality for two products instead of one).

Ultimately, my fears were unfounded: I ended up needing a significant back-and-forth on the level and encounter design and having the editor helped tremendously.

Technical challenges & Testing

One of the most significant technical challenges we had to constantly face were both the amount of storage the game is using (about 27K) and most importantly, the amount of access memory available. For this reason, we have some limitations on how many items and  monsters can be present on an active map , or how big a level can be, for example.

Saving bits here and there were a constant priority. @Filmote was helped, mid-production by another coder, @Pharap that would focus at attempting to save as much memory as possible. At this point, we were flirting with the hardware limits on a daily basis, only to have some magical re-writing of a function to send us back below the max.

The code discussions, and the tricks they used were way beyond the intelligible point for me! All I know is that this level of optimization comes with years of experience with the language and there was no way I would have been able to pull it off while learning C++.

While I did a fair bit of testing myself, it was important to have an extra pair of eyes on the game, someone that would play it from a fresh perspective, not ensconced in his own design patterns.
We tasked another community member, Scott R. (@Keyboard Camper) to play the game again and again, and hunts bugs, or gameplay anomalies so that we could fix them before release.

With his help, we caught a fair amount of problems within the game, some that had become transparent to me. Once assured that Scott could beat the game, we were ready for release!

Promotion

As the game was getting ready for launch (at this point, we were in the testing phase) I started putting together some material to promote it within the community. I had been offered a couple pages to write a pixel-art tutorial in the Arduboy Magazine (page 26 to 31) as well as a page to advertise our upcoming game.

Having spent most of my career in advertising, I wanted our ad to be “legit” and be driven by a strong concept. Given the retro nature of the device, I imagined an ad that would echo, and gently mock the software ads from the 70’s and 80’s.

Borrowing the codes of these ads was easy: I decided to stick with Black and White, and emulate the low-print quality by texturing my paper heavily, and putting emphasis on the half-tone patterns of the picture.

I wanted to play with the incredibly sexualized codes of the era, while still toning them down significantly to be more aligned with nowadays more considerate humor. Since our device is literally a pocket console, I decided to go with a photo-shoot of the game in a denim back-pocket of a woman (Thanks to my benevolent model!), while letting the text carry a bit of the “double-entente” that one could expect from that period.

I even found a way to wink at J.R.R Tolkien: ““It’s a dangerous business, Frodo, going out your door. You step onto the road, and if you don’t keep your feet, there’s no knowing where you might be swept off to.”

The ad was supported by a custom web page: http://www.garage-collective.com/darkunder/

Yes, for those that wonder, it’s all hand-coded in the notepad, the old-school way!

Launch and post-mortem

The game was officially launched Wednesday December 20th at noon. So far, it seems that the community reception is very positive, with users leaving comments such as

I love this game. It is perfect. very simple to understand right away yet very complex for an Arduboy game. I was so excited to download it! Thank you for creating this masterpiece dungeon game! – Kyle

It also seems that the game will be featured on the Arduboy homepage at the next refresh.

The best part to me was to see people running Dark & Under on their custom Arduboy platform: it really shows the creativity and technical prowess of the community!

 

The whole process from inception to completion roughly took us two months. It’s a bit more than I originally thought it would take, but going in, I had no idea of the amount of fine-tuning and optimization the code would take.

I’m used to work with “game engines” like Flash or Unity for hardware that range from Mobile devices to computers, all in all, pretty forgiving devices. Working under such tight constraints was new, but also delightful! I love being framed by hardware or/and software constraints: it helps make decisions, and delivering products that push these boundaries feel extremely satisfying.
I’m very happy with the final product, I’ve met very talented people in the meantime, a community that is very helpful, insightful and creative!

I need to take a break and go back at making art that feels more aligned with the current industry, but I know full well than in a short while, a couple of weeks? a month or two? I will be hitching to go back to Arduboy and plan a new game.

Screenshots