Skip to main content

Project banner

Rune & Rust

Rune & Rust is a text-based dungeon crawler written in C#. No rendering engine, no sprite sheets, no game framework, just state machines, narrative branching, combat mechanics, and the raw building blocks of the language. It's the odd one out in the project menagerie, and deliberately so.

Why a Dungeon Crawler?​

There are two honest answers:

Three-level dungeon cutaway: lit entrance above, partially explored middle, dark depths below.

The practical answer: Game logic is one of the best workouts for software design patterns. State machines, the observer pattern, the command pattern, strategy pattern, composition over inheritance: these aren't textbook abstractions in a game. They're the difference between code that works and code that collapses under its own weight. A dungeon crawler touches all of them in a context where the consequences of bad design are immediately visible (the goblin attacks during the inventory screen, the player walks through walls, the dialogue tree loops forever).

The honest answer: Sometimes you need to write code that stabs a goblin instead of parsing a compliance document. Creative coding keeps the brain flexible, and there's a particular satisfaction in modeling combat mechanics with pattern matching expressions that no amount of enterprise software development can replicate.

What It Teaches​

Rune & Rust is a learning project, but the lessons transfer directly to non-game software:

Six game states connected by transitions: Explore, Combat, Dialogue, Inventory, Rest, and Death.

State Machines. The game has a finite set of states (exploring, combat, inventory, dialogue, etc.) with well-defined transitions between them. This is the same pattern used in workflow engines, protocol handlers, and UI frameworks. C#'s switch expressions and pattern matching make state machines particularly elegant:

var nextState = (currentState, input) switch
{
    (GameState.Exploring, "fight")    => GameState.Combat,
    (GameState.Exploring, "inventory") => GameState.Inventory,
    (GameState.Combat, "flee")         => GameState.Exploring,
    (GameState.Combat, "attack")       => ResolveCombat(),
    _                                  => currentState
};

Narrative Branching. Dialogue trees and story branches are graph structures. How you represent them in code (nested conditionals, data-driven node graphs, scripting engines) determines how maintainable and authorable the content is. This has direct parallels to chatbot flow design and multi-step AI agent workflows.

Component Architecture. Game entities (players, enemies, items, rooms) are composed of reusable components rather than inheriting from deep class hierarchies. An enemy with health, inventory, and AI behavior has three components, not a three-level inheritance chain. This composition-over-inheritance approach is the same one that scales well in enterprise applications.

Serialization and State Persistence. Save games require capturing the entire game state in a serializable format and restoring it later. This is the same challenge faced by any application that needs to persist complex state: workflow checkpoints, session resumption, crash recovery.

The Design Patterns Connection​

One of the planned blog posts (#11 in the content plan) draws explicit parallels between game development patterns and AI orchestration:

A pattern matching decision tree: PlayerAction branches into Move, Attack, and Use with C# match expressions.

  • A game loop is an event loop. An AI agent's tool-use cycle is an event loop.
  • A dungeon has rooms with affordances (doors, chests, NPCs). An AI agent has tools with schemas (parameters, return types, descriptions).
  • A player navigates a world by choosing actions. An agent navigates a tool ecosystem by choosing function calls.
  • Game state determines what actions are available. Agent context determines what tools are relevant.

The parallels aren't forced; they emerge naturally from both domains dealing with the same fundamental problem: an autonomous entity making decisions in a structured environment.

Technology​

Rune & Rust is written entirely in C# without a game engine or framework. It uses:

  • Pattern matching for state transitions and combat resolution
  • Records for immutable game state snapshots
  • Nullable reference types for safety across the entire codebase
  • JSON serialization for save state persistence
  • No external dependencies beyond the .NET runtime

This is intentional. The project's value is in the design patterns and the learning, not in the framework. If the framework does the interesting work, you haven't learned anything.

Where to Find It​