Mistvorn Games

Starting with spikes

· Dungeon Delve

My latest game concept requires me to implement a number of game mechanics that I am inexperienced with. So, before working on the real game, I made a list of mechanics that I can spike to help me build understanding of how they work and prove they are viable on a phone. Each spike is one small throwaway prototype. This post covers the first three.

Dungeon Delve (a working title) is a top-down deck-building dungeon crawler for phones, built in Godot 4 with C#. It’s played in portrait with taps: tap the ground to move, tap a mob to attack. You’re a treasure hunter who takes quests at a tavern, delves, and comes back to upgrade a small loadout of cards.

My rules for a spike

Spike 1: tap to move

Question: Does tap-to-move feel responsive and readable on a phone, and what camera suits it?

Answer: Yes, after one fix (below). The camera is tilted 75° below the horizon, 25 m from the hero, and takes about 1.5 seconds to catch up with it. The hero itself responds to a tap at once.

A large green ring on the floor marking where the finger is held down A panel of sliders over the game for camera tilt, distance, lag, ring size, held-ring size and hero speed

The thing I didn’t expect: with the camera 25 m away, your finger covers both the spot you tapped and the ring that confirms it. The ring now grows to five times its size while your finger is down, so it shows around your fingertip, and shrinks when you lift.

Some Godot notes:

Spike 2: a procedural dungeon

Question: How do you build a procedural dungeon? Can navigation work across rooms assembled at runtime, and how long does generation take on a phone?

Answer: From six room pieces on an 8 m grid, with 4 m doors in the middle of a cell edge so the doors of any two neighbours line up. The generator starts from a dead end and grows by picking a random open door and putting a random piece that fits behind it. Then it closes every leftover door with a piece that fits, so every doorway leads somewhere. The end room is the one furthest from the start, counted in doorways.

Navigation works: I bake one navigation mesh over the whole dungeon after the rooms are placed. My fallbacks were pre-baked rooms and links at the doors, and I didn’t need either.

It’s fast: on the Pixel 3 a 100-room dungeon is generated, built and baked in about 140 ms, and it’s walkable about a third of a second after generation starts. The gap is the navigation map catching up, which took 10 physics frames. The screenshots are from the Mac, so the timings shown in them are lower than the Pixel 3’s.

The six grey room pieces seen from above: dead end, corridor, corner, junction, crossing and a large room A 100-room dungeon seen from above with a yellow line marking the path from the start to the end The hero following the yellow path line along a corridor of the generated dungeon

Some Godot notes:

Spike 3: tap to attack

Question: Can you control a fight with taps alone?

Answer: Yes. Tap-to-attack worked with a sword and a wand, and both phones held 60 fps. My first guesses at damage, attack speed and range were good enough that I left them alone.

The hero hitting a mob with a sword, both flashing white from the hit, with a red ring under the target and damage numbers above both A wand shot in flight towards a targeted mob, which shows a yellow exclamation mark

Tap a mob once and the hero keeps attacking it until it’s dead or you tap something else. A red ring marks your target, and a mob that notices the hero shows a yellow “!”.

The hero needed a few rules of its own:

The hero never reads input. A tap becomes a command (move here, attack that), and the hero carries out the last one it was given. That’s been true since Spike 1, and it’s what lets an autopilot issue the same commands later.

What’s next

The next three spikes: an autopilot that takes the hero through a dungeon by issuing those same commands; skill cards; and fog of war.

All devlog posts