Work / Ames Nocturne

Ames Nocturne

Full-stack 2D game featuring procedural dungeon generation, AI-driven NPC behavior, custom physics, and modular architecture. Ongoing solo project.

Duration Jan 2023 – Present
Role Solo Developer
Status Ongoing (Playable)
Scale 5+ playable levels
Unity C# Game Design Procedural Generation AI Systems

The Vision

A 2D action-adventure game set in a nocturnal environment where the player navigates procedurally-generated dungeons, encounters AI-controlled enemies, and solves spatial puzzles. Every playthrough is unique due to procedural generation while maintaining balanced difficulty and engaging level design.

The project serves as a testbed for systems design: game architecture, AI behavior trees, physics integration, and performance optimization—all in a constrained scope that's actually shippable.

My Role

Game Architecture & Design

Architected core game systems using Unity patterns. ScriptableObjects for data-driven configuration. Observer pattern for events. Modular design allows independent iteration on systems.

Procedural Generation

Implemented seed-based dungeon generation: room layout, obstacle placement, spawn points. Ensures reproducibility while varying based on seed. Guarantees playable dungeons (no impossible layouts).

AI & Behavior Systems

Built finite state machines for NPC behavior: patrol, chase, idle. NPCs react to player proximity, difficulty scaling adjusts behavior. Pathfinding uses A* for intelligent enemy movement.

Performance & Polish

Optimized frame rate through object pooling, tilemap rendering, physics tweaks. Achieved stable 60 FPS on target hardware. Iterated on feel: responsiveness, camera, particle effects.

Core Systems

Game built as interconnected systems: player input → physics → AI → rendering. Each system is testable and independently tunable.

Player System

Input & Movement

  • Input handling
  • Character controller
  • Animation state machine
  • Health & inventory

AI System

Enemy Behavior

  • Finite state machine
  • Pathfinding (A*)
  • Perception system
  • Difficulty scaling

World System

Generation & Physics

  • Procedural dungeons
  • Physics simulation
  • Collision handling
  • Level management

Key Technical Decisions

1. Finite State Machines for AI

Considered behavior trees (more powerful but complex). FSM simpler, sufficient for game scope, easier to debug.

  • States: Idle, Patrol, Chase, Attack, Flee
  • Transitions: Based on player proximity, health, cooldowns
  • Benefit: Predictable, easy to extend with new states

2. Seed-Based Procedural Generation

Deterministic generation ensures players can share seeds and replay same dungeons. No "impossible" layouts.

  • Algorithm: Binary space partitioning (BSP) for room layout
  • Guarantee: Connected dungeons, guaranteed path to exit
  • Tuning: Room count, obstacle density, spawn rates all configurable

3. ScriptableObjects for Configuration

Game balance (enemy stats, loot tables, difficulty curves) stored as data, not code. Non-programmers can tweak values.

  • Flexibility: Iterate on balance without recompiling
  • Reusability: One enemy archetype, multiple instances with different stats
  • Version control: Easy to track balance changes

4. Object Pooling for Performance

Spawning/destroying projectiles every frame causes GC spikes. Pre-allocate pool of objects, reuse.

  • Impact: 10ms GC pauses → imperceptible
  • Trade-off: Slightly more memory, much smoother gameplay

Results

5+
Playable Levels

Each with unique procedurally-generated content

60 FPS
Stable Performance

On target hardware (no GC spikes)

8+ Hours
Estimated Playtime

Across multiple difficulty levels

100%
Modular Systems

Independent, testable, extensible

What I Learned

1. Scope Management is Everything

Game development scope creep is notorious. Clear scope (2D, single-player, roguelike) made the project achievable. Resisted temptation to add features.

2. Game Feel Matters More Than Graphics

Spent disproportionate time on responsiveness: input lag, animation timing, camera behavior. "Feel" of gameplay > visual fidelity for engagement.

3. Iterative Design Through Playtesting

What I thought would be fun often wasn't. Showed friends, gathered feedback, iterated. Game design is empirical, not theoretical.

4. Performance Optimization is Ongoing

60 FPS games require constant monitoring. Physics, rendering, AI—any system can cause hiccups if not watched. Profiling isn't optional.

Let's talk

Interested in game development, systems architecture, or AI design? Let's connect.