Posted March 08, 2024 by Geoff
I’m making a game for 7DRL 2024! I last attempted this challenge in 2018, and I didn’t finish my game. This time, it’s happening. Dundledorf’s Castle (DC) is a survival-oriented roguelike with horror themes, programmed in the TIC-80 fantasy computer.
My two primary sources of inspiration for DC are the games Haunted House, and 868-HACK, or the work of Michael Brough more broadly.
Haunted House is an Atari 2600 game released in 1982. It’s a simple exploration game where you navigate the floors of a dark mansion, avoiding enemies and collecting pieces of an amulet. Your character is a simple pair of eyes, floating in a dark void. You can light a match to create a small light source around your player.
Haunted House (1982)
So the spark of my idea was a roguelike with limited vision, and a light source with limited fuel that must be carefully managed. If you run out of fuel, you’re trapped in the darkness.
The game is “Broughlike” in style, using a smaller map size (8x8) and a limited set of mechanics. The game is not progression- or build-oriented; most items are consumable, and you have to continuously manage your limited inventory.
Here are the game’s core mechanics:
This is tricky! I’ve never made a game like this before, and balance is key. Here are some factors I considered:
By midweek, I had something that felt like a playable game. On one particularly good run, I managed to climb 100 floors without much trouble. Granted, I made the game, so I have complete knowledge of the mechanics, but the difficulty curve wasn’t, well, curving enough!
I also wondered if a few of the items were too powerful. A big one is the shield, which blocks counterattacks. That is, if you and an enemy attack each other at the same time, they take damage, but you don’t. With proper timing you can avoid a lot of damage, and the shield doesn’t break.
Some items have infinite uses, and I’m wondering if more items need charges. Maybe the shield works 10 times before it breaks, or has a low random chance of breaking on each hit. However, even if an item has infinite uses, there’s one counterbalance: it takes up space. You only have 6 inventory slots, so if you’re carrying 2 or 3 really good power-ups, you have less space to stockpile fuel and health. As I’m writing this, I’m still ruminating on how this should work.
After some changes, here are the ways the difficulty scales from floor to floor:
Having a UX background, I greatly enjoy getting to put together the UI of a game. An important goal for me was for the game’s core mechanics and controls to be discoverable within the game itself; I don’t want people to have to read a separate blurb of text on the Itch page to learn how to play.
The interface for DC went through one major iteration based on feedback from a friend.
This is the original UI. It has this neat grid of 3x3 cells to represent all of your items, including the button prompts to access them. The big issue with this layout is it doesn’t clearly distinguish between your fixed equipment and your inventory slots. The top three cells—lantern, the slingshot, and your money—are fixed, while the bottom six cells are for items you pick up.
This screenshot is a little older, but the top-right slot eventually showed the number of coins you have.
You press the Z key (or A button) to open your inventory, and the same button to select an item to use. However, with this layout, it looks like the Z key only applies to the first item. My friend also thought that the items could be reassigned to different buttons, a la The Legend of Zelda, which is not the case.
Here’s the refined version. Those boxes are now used just for inventory slots, and how the keys/buttons map to each action is more clear. I was very happy with these changes!
Another feature I wanted for the UI was support for both gamepad buttons and keyboard keys. Fantasy consoles like the TIC-80 or PICO-8 usually define their own controller layout with face buttons; the TIC-80 uses A/B/X/Y. In practice, however, people tend to play these games in web browsers, so you still need an affordance for keyboards.
The DC UI detects your input type and swaps out the button prompts accordingly. The code is very simple:
local using_keyboard = false
function TIC()
if btnp() > 0 then
using_keyboard = false
end
if keyp() then
using_keyboard = true
end
end
Originally I was thinking this game would be real-time, so closer to the actual design of Haunted House. However, it turns out I’m an inexperienced game developer, and making something turn-based in a week was going to be more straightforward. Also, it hews a lot closer to the spirit of 7DRL.
Another core mechanic I scrapped was related to equipment: I was thinking that your hands would be a slot you move items in and out of, so performing certain actions would have a tradeoff. For example, maybe you’d have to set down your lantern to fire a shot at a distant enemy, making the action a little more dangerous. Ultimately I couldn’t make the idea interesting enough to justify it. It also made a little less sense to me once I moved away from a real-time game towards a turn-based/grid-based game.
Some other mechanics I had written down but scrapped, mostly for time:
I’m publishing this devlog on Friday, and most likely I’ll wrap things up for the project this evening. Thanks for reading!