Gnostic Dungeon - Game Design Document Outline

1. High Concept

A terminal-first, top-down, turn-based infinite dungeon crawler built in Go, designed to be playable over SSH from Termux. The game is mechanically rich, visually simple, narratively sparse, and focused on repeated descent, death, spiritual ascent, and reincarnation.

The player awakens in a false reality: an infinite dungeon that functions as prison, world, graveyard, and cosmic machine. In life, the player survives materially. In death, the player ascends spiritually through the prison's gate structure. Reincarnation returns the player to weaker regions of the dungeon with spiritual knowledge preserved and material strength lost.

The game aims for:

• NetHack-style terminal readability and systemic interaction
• Dark Souls-style loneliness, indirect storytelling, and hostile world logic
• Roguelike body-reset progression with persistent metaphysical growth
• Minimal UI and minimal exposition
• SSH-friendly controls and low graphical dependency

---

2. Design Pillars

2.1 Terminal-First Simplicity

The game should feel at home in a terminal window. Everything important must be playable, understandable, and satisfying in ASCII or other minimal text glyphs.

2.2 Narrative Light, Lore Deep

Story is not delivered through long dialogue or cutscenes. The world communicates through enemy forms, item descriptions, recurring symbols, room types, death/rebirth cycles, and environmental traces.

2.3 Death Is Progress

Death is not merely failure. It is a required transition into the spiritual progression layer. The body dies, the soul ascends, and true advancement occurs through surviving or mastering the gate structure.

2.4 Matter Resets, Spirit Persists

Material growth drives individual runs. Spiritual growth defines long-term progression. The body is temporary; the soul is the real build.

2.5 Systemic, Not Content-Bloated

The game should prioritize reusable mechanics and clean interactions over huge amounts of handcrafted story or decorative systems.

2.6 Solitude and Hostility

The world is mostly enemies, remains, structures, and mysteries. There are no towns or social hubs. The only recurring personality is a strange, eccentric merchant who appears in the dungeon.

---

3. Player Experience Goals

The player should feel:

• alone but not aimless
• weak at first, but increasingly dangerous through understanding
• curious about the world's hidden structure
• tension between preserving a build and cashing it out
• attachment to rooms, corpses, items, and traces of old runs
• that the dungeon remembers, even when the body does not

The player should gradually realize:

• the dungeon is reality for most beings
• death does not free them from the prison
• the gate structure is part of the trap
• Names and Aeons are tied to the architecture of escape

---

4. Platform and Technical Direction

4.1 Target Runtime

• Go-based terminal application
• Playable locally or remotely over SSH
• Designed for Linux servers and Termux clients
• Input model optimized for keyboard-only play

4.2 UI Direction

• terminal-native presentation
• tile/grid display using ASCII or simple Unicode glyphs
• no dependency on mouse input
• readable on narrow mobile terminal screens if necessary

4.3 Design Constraints from Terminal Target

• low information density per screen must remain playable
• menus must be shallow and fast
• logs must be concise and meaningful
• color should help, but not be required
• the game must remain satisfying even with extremely simple rendering

---

5. Genre and Structure

A solitary top-down turn-based roguelike / dungeon crawler with persistent spiritual meta-progression.

Primary loop:

1. awaken in a weak body in lower dungeon regions
2. explore, fight, scavenge, bind Aeons, gather gear and materials
3. claim temporary sanctums and push deeper
4. die in the material world
5. ascend through the gate structure in spirit form
6. gain spiritual progression, Names, memory, permissions, or truth
7. reincarnate into a weak new body in weaker dungeon zones
8. seek lost gear, past sanctums, and deeper truth

---

6. Setting Premise

Everyone awakens in the dungeon.

They live there, fight there, starve there, worship there, scavenge there, die there. Most beings never conceive of anything beyond it. When they die, their bodies remain in the dungeon and their souls are processed through a false spiritual ascent. They are then reincarnated back into weaker regions of the dungeon to begin again.

The dungeon is infinite or functionally infinite. It contains remnants of countless cycles: ruined chambers, false shrines, workshops, hidden rooms, barricaded refuges, collapsed sanctums, gate structures, and traces of prior attempts at escape.

The answers are in the dungeon, but buried under repetition, violence, and false order.

---

7. Narrative Delivery Approach

Narrative remains intentionally light.

7.1 What the Game Avoids

• long exposition scenes
• party banter
• town dialogue trees
• frequent NPC interactions
• lore dumps

7.2 What the Game Uses Instead

• item descriptions
• enemy naming and forms
• room archetypes
• corpse remains from prior runs
• recurring symbols and sigils
• Aeon encounters
• gate encounters after death
• sparse merchant lines
• hidden Name discoveries

7.3 Merchant Function as Narrative Valve

The eccentric merchant is the one recurring personality. He provides just enough speech to imply memory, cycle-awareness, and wrongness, without becoming a normal quest-giver.

---

8. Core Systems Overview

Major systems:

• movement and map exploration
• turn-based combat
• material and spirit stat layers
• Aeon capture, binding, and invocation
• dynamic class calculation
• searching, traps, and hidden rooms
• loot, equipment, and inventory
• scavenging and crafting
• sanctum claiming and room fortification
• corpse recovery and run archaeology
• death/ascent/reincarnation progression
• Name discovery and gate progression
• recurring merchant economy

---

9. Core Map and Exploration Model

9.1 Grid-Based Navigation

• top-down grid map
• each step is a turn
• every tile matters
• enemies, loot, furniture, dropped gear, corpses, containers, and structures occupy real positions
• all meaningful loot exists either on a real tile or on a real enemy/body until recovered
• exploration should support a top-down action-adventure feel with loops, shortcuts, revisits, and knowledge-gated return paths rather than feeling like disconnected abstract floors

9.2 Fog of War

• unexplored areas remain hidden
• visibility and line of sight matter
• perception, room lighting, and spiritual effects may influence what is revealed

9.3 Room Identity

Rooms are not empty filler. Each room should suggest a function or former purpose.

Examples:

• storage room
• shrine
• library
• crypt
• barracks
• workshop
• reliquary
• hidden chamber
• Aeon seal room
• merchant room

9.4 Secret Content

Exploration supports:

• hidden doors
• trapdoors
• concealed loot
• false walls
• sealed chambers
• knowledge-locked discoveries

---

10. Material and Spirit Progression

10.1 Material Stats

Run-based, body-dependent values. Mostly lost on reincarnation.

Candidate stats:

• Might
• Agility
• Vitality
• Skill
• Sense

These may be partially shaped by body generation or body-roll rules at the start of a life, with spirit progress biasing better starting vessels over time.

Possible effects:

• weapon effectiveness
• carrying capacity
• hunger endurance
• dodge and ranged precision
• trap interaction
• physical search effectiveness
• break force and material harvesting

10.2 Spirit Stats

Persistent soul-dependent values. Retained across death.

Candidate stats:

• Will
• Insight
• Memory
• Faith
• Presence

Possible effects:

• resistance to fear, domination, and gate coercion
• hidden truth perception
• Name retention
• Aeon binding strength
• invocation strength
• corpse recovery memory
• sanctum persistence
• gate progression success

10.3 Final Calculated Death State

At death, the player enters ascent using their full calculated build:

• material stats
• spirit stats
• equipment effects
• bound Aeons
• afflictions and blessings
• current run conditions
• active class calculations
• current bodily condition, including wounds, missing limbs, prosthetic replacements, or other major body-state changes if those systems are enabled

This makes the material run meaningful preparation for spiritual progression.

---

11. Life Phase

The life phase is the material run.

Activities:

• explore rooms and corridors
• fight enemies
• gather food and survival supplies
• loot and equip gear
• search for traps, caches, and secret routes
• bind Aeons
• gather materials
• claim sanctums
• descend into stronger regions

Primary player pressures:

• survival
• hunger
• risk management
• inventory decisions
• whether to push deeper or consolidate
• whether to spend Aeons or preserve build stability

---

12. Death and Corpse Persistence

12.1 On Death

When the player dies:

• the body remains at the death site
• gear may remain on or near the corpse
• the room or surrounding area may change
• enemies may gather, loot, or mutate around the corpse
• the soul leaves the dungeon and enters the ascent phase

12.2 Corpse Recovery

In later lives, the player may:

• track old corpse sites
• recover lost equipment
• find the body guarded or altered
• reclaim items from corrupted remains
• discover that the dungeon has transformed the site

12.3 Archaeology of Old Runs

Old bodies, broken barricades, and ruined sanctums should make prior runs feel materially real.

---

13. Ascent Phase

The ascent phase occurs after death.

13.1 Purpose

This is the metaphysical progression layer. It determines persistent advancement, not just immediate run success.

13.2 Themes

• false heavens
• gate systems
• guardians
• spiritual trials
• judges or prison mechanisms
• Names and truth checks
• resistance to being recycled

13.3 Gameplay Goals

The ascent should:

• use the player's final build in meaningful ways
• reward spiritual preparation
• advance long-term progression
• feel dangerous, not automatic
• reinforce the world's prison-cosmos premise

13.4 Possible Structures

To be decided during prototyping:

• turn-based combat encounters
• trial rooms / symbolic challenges
• choice-driven gate tests
• minimal spiritual sub-map
• hybrid of combat and ritual checks

---

14. Reincarnation Phase

After ascent, the player returns to life in a new weak body.

14.1 What Persists

Likely to persist:

• spirit stats
• discovered Names
• knowledge of gate structure
• Aeon knowledge or affinity
• class unlocks or tendencies
• some map memory
• some sanctum traces
• corpse site tracking if supported by Memory or related systems

14.2 What Is Lost

Likely to reset or mostly reset:

• material stats
• consumables
• most run-specific resources
• current depth
• temporary material power

14.3 Purpose of Reincarnation

Reincarnation is the bridge between systemic reset and long-term progression. The new body must be rebuilt, but it carries a stronger soul.

---

15. Aeon System

Aeons are captured spiritual powers encountered as bosses and bound as part of the player build.

15.1 Acquisition

• found in seal rooms, shrines, hidden chambers, or boss spaces
• fought as unique or semi-unique encounters
• bound through a capture/ritual mechanic rather than merely looted

15.2 Slots

• player has two Aeon slots
• both slots contribute to build identity

15.3 Bound State

A bound Aeon provides:

• stat modifications
• passive bonuses
• one or more techniques
• influence on dynamic class calculation

15.4 Invocation State

Aeons can be invoked to unleash stronger effects:

• summon-like effects
• burst power
• utility revelations
• recovery or destruction

When invoked:

• their bound bonuses disappear temporarily
• the player may lose associated techniques
• the player's class may shift
• the build becomes spiritually unstable or reconfigured

15.5 Pair Logic

Different Aeon pairs can unlock:

• hybrid classes
• combo techniques
• stronger dual-invocation effects

15.6 Narrative Role

Aeons are not just battle pets. They are fragments of power, imprisoned forces, or pieces of the prison's hidden architecture.

---

16. Dynamic Class System

Class is not chosen as a fixed lifelong identity.

It is calculated from:

• current material stats
• current spirit influence
• bound Aeons
• relevant gear or relic conditions

This creates shifting archetypes that reflect the player's current state rather than a menu choice.

Possible outcomes:

• martial builds
• seeker builds
• ritualist builds
• hybrid combat-caster builds
• body-heavy or spirit-heavy identities

The class system should remain readable, not excessively granular.

---

17. Combat System

17.0 Combat Tone References

The combat target is simple to read but tactically sharp: Dragon Quest-style menu clarity, NetHack-style consequence, and ranged interactions that create pressure to advance, retreat, or counter rather than just stand in place trading damage.

17.1 Combat Goals

• readable in terminal format
• turn-based and positional
• easy to understand, hard to master
• built around movement, range, build shifts, and risk

17.2 Core Features

• every step is a turn
• melee and ranged range rules
• line of sight
• enemy advance/retreat logic
• ranged exchanges should support advance, retreat, counter-fire, and pressure similar to tactical Fire Emblem-like spacing rules
• simple but meaningful status effects
• summon timing through Aeon invocation
• thrown weapons and consumable projectiles as a supported combat option

17.3 Tone Reference

Mechanically simpler than tactics-heavy games, but more dangerous and more consequence-driven than a casual terminal crawler.

---

18. Enemies

The world is primarily made of enemies and remnants.

Enemy families should include not only monsters and warped humanoids, but also demons, sorcerers, necromancers, goblins, false angels, guardians, and other esoteric prison-world entities consistent with the setting.

18.1 Enemy Narrative Role

Enemies are worldbuilding. They imply what the dungeon has done to its population and prior cycles.

18.2 Example Categories

• scavengers
• husks
• cult remnants
• necromancers
• beasts
• false angels
• sorcerers
• guardians
• warped pilgrims
• failed seekers
• flesh-crafted wardens

18.3 Bosses

Bosses include:

• Aeon encounters
• region guardians
• gate guardians
• sealed chamber rulers

---

19. Search, Traps, and Hidden Information

The dungeon should reward caution and attention.

19.1 Search Interaction

Search may reveal:

• hidden doors
• traps
• loot caches
• ritual inscriptions
• weak walls
• unusual corpse details

19.2 Sense vs Insight

Potential distinction:

• material search handles physical hidden content
• spirit-related perception handles falsehood, deeper truth, or hidden spiritual architecture

19.3 Traps

Traps should support:

• floor hazard tension
• room identity
• player-crafted defensive use in sanctums

---

20. Inventory, Equipment, and Loot

20.1 Inventory Goals

• terminal-friendly
• concise categories
• low menu friction
• meaningful scarcity

20.2 Loot Types

• weapons
• armor
• relics
• consumables
• food
• materials
• keys or seal items
• Aeon-related catalysts
• Name-linked artifacts
• thrown weapons and ammunition
• rare procedurally generated artifacts with unusual properties, identities, or affix-like behavior

20.3 Equipment Philosophy

Equipment should feel dangerous, strange, and valuable. Rare gear may accumulate history through repeated deaths and recoveries.

Longer-term equipment design may include body-slot disruption, limb loss, prosthetic replacement, or strange body-altering equipment as part of the prison-world survival theme.

---

21. Furniture, Objects, and Environmental Interaction

Rooms contain physical objects that occupy tiles and support atmosphere plus systems.

Examples:

• crates
• chests
• bookshelves
• beds
• cabinets
• tables
• weapon racks
• altars
• ritual objects

Possible actions:

• search
• break
• move
• repurpose
• open
• loot
• dismantle for materials

This supports both environmental flavor and player agency.

---

22. Crafting and Scavenging

Crafting is a support system, not the main identity.

The broader skill fantasy may eventually include specialized disciplines such as sneaking, pickpocketing, blacksmithing, alchemy, and related utility play, but these should stay grounded in the terminal-first systemic focus rather than becoming a sprawling profession game.

22.1 Material Sources

• broken furniture
• enemy drops
• containers
• remains
• special room resources

22.2 Material Types

Candidate examples:

• wood
• metal
• cloth
• glass
• bone
• ash
• herbs

22.3 Use Cases

• repairs
• simple tools
• traps
• consumables
• barricades
• sanctum objects
• ammunition or thrown items

The system should remain compact and understandable in terminal UI.

---

23. Sanctums and Claimed Rooms

The player can turn cleared rooms into footholds.

23.1 Purpose

Sanctums provide:

• temporary safety
• storage
• recovery points
• crafting presence
• landmarks across runs
• proof of prior lives

23.2 Room States

Potential states:

• unknown
• explored
• cleared
• claimed
• fortified
• overrun
• corrupted

23.3 Sanctum Actions

• clear enemies
• move furniture
• barricade doorways
• place storage
• install traps or wards
• anchor the room spiritually

23.4 Persistence

Sanctums may leave traces across reincarnation:

• hidden stashes
• damaged barricades
• symbols
• anchored markers
• notes or inscriptions
• weakened but recognizable room identity
• player-made paths, route cues, and map guidance that can be rediscovered in later lives if the player finds the area again

---

24. Merchant

A single eccentric merchant recurs throughout the dungeon.

24.1 Role

• buys junk and salvage
• sells survival goods, useful tools, and rare curiosities
• acts as a thin narrative thread
• reinforces the wrongness of the world

24.2 Tone

The merchant should feel uncanny, not comforting. He should seem aware of cycles, memory, or the player's repeated deaths.

24.3 Design Constraint

The merchant remains light-touch. He should never become the center of the story or turn the game into an NPC-driven structure.

---

25. Names and True Progression

Names are a persistent progression layer representing hidden truths about the prison reality.

25.1 Function

Names may be used for:

• Aeon binding
• gate passage
• revealing hidden areas
• resisting false authority
• unlocking deeper understanding
• class or spirit interactions

25.2 Persistence

Names persist across reincarnations and should feel more important than ordinary loot.

25.3 Narrative Role

The real goal of the game is not merely surviving the dungeon. It is understanding the dungeon well enough to transcend it.

---

26. Progression Summary

26.0 Growth Curves

Progression curves may use unusual thresholds or pacing models, including Fibonacci- or golden-ratio-inspired level spacing, if that supports the intended occult mathematical flavor without harming readability.

26.1 Short-Term Progression

Within a life:

• build material stats
• gather gear
• bind Aeons
• claim sanctums
• descend deeper

26.2 Mid-Term Progression

Across several lives:

• recover old corpses and stashes
• strengthen spirit stats
• stabilize Aeon strategy
• build route memory
• deepen understanding of dungeon regions

26.3 Long-Term Progression

Across many deaths:

• discover Names
• challenge deeper gate structures
• unravel the prison reality
• progress toward actual escape or confrontation with the true creator

---

27. UI and UX Principles

27.1 Screen Priorities

The terminal interface should emphasize:

• map view first
• status view second
• concise action feedback
• low menu friction

27.2 Information Architecture

At minimum, the UI should communicate:

• player position and nearby map
• HP / hunger / key material stats
• core spirit state
• equipped gear
• bound Aeons
• brief message log

27.3 Interaction Goals

• fast keyboard play
• one-key access to common actions
• short, memorable commands
• minimal need for nested menus

---

28. Content Architecture

The game should be built so that content can scale through data-driven structures.

Primary content families:

• enemies
• items
• room archetypes
• furniture objects
• Aeons
• classes/archetypes
• crafting recipes
• Names
• gate challenges
• region themes

Content should be easy to define in data and easy to iterate without rewriting engine code.

---

29. Engine and Architecture Considerations

For Go implementation, the project should likely separate:

• game loop
• input handling
• rendering
• entity/component data or equivalent struct model
• procedural generation
• combat rules
• persistence/save systems
• content definition/loading

Additional technical priorities:

• robust save/load support
• resumable SSH sessions where possible
• deterministic or seed-driven generation where useful
• clean terminal redraw strategy
• minimal resource usage

---

30. Visual and Audio Direction

30.1 Visual Direction

• terminal glyphs only, or glyphs plus color
• strong readability
• strong symbolic silhouettes through symbols and color
• avoid overcomplicated screen decoration

30.2 Audio Direction

Optional or absent for early versions. Terminal play over SSH should not depend on audio.

---

31. Difficulty Philosophy

The game should be punishing but legible.

Failure should feel like:

• consequence of risk
• consequence of ignorance
• consequence of greed or overextension

Failure should not feel like:

• unreadable randomness
• menu friction
• hidden mandatory knowledge with no clues

The player should lose bodies often, but gain understanding steadily.

---

32. Scope Guardrails

To preserve project coherence, the game should avoid becoming:

• a social RPG
• a colony sim
• a town-building game
• a dialogue-heavy narrative RPG
• a giant crafting tree simulator
• a tactics grid game with overwhelming action complexity

The focus remains:

• terminal-friendly systems
• solitary dungeon survival
• death/ascent/reincarnation
• Aeon build manipulation
• hidden truth progression

---

33. Open Design Questions

Questions to resolve through prototyping:

• what exact form the ascent phase takes
• how many material and spirit stats are truly needed
• whether classes should be shown explicitly or inferred from abilities
• how much sanctum persistence should survive across lives
• how deterministic corpse recovery should be
• whether Aeons persist fully, partially, or only as knowledge after death
• whether hunger remains central or stays light-touch
• what the merchant's economy uses besides simple currency

---

34. Current Vision Statement

A sparse, terminal-native Go roguelike where the player explores an infinite false-reality dungeon, binds Aeons, claims sanctums, dies into a spiritual ascent, and reincarnates stronger in soul but weaker in body, gradually learning the Names and hidden truths needed to escape the prison cosmos.

---

35. Immediate Next Design Documents

After this outline, the next design docs to produce should be:

1. Core controls and terminal UX spec
2. Stat model and progression rules
3. Aeon system spec
4. Death/ascent/reincarnation system spec
5. Map generation and room archetype spec
6. Save data and persistence spec
7. Initial Go project architecture
8. Content schema for enemies, items, rooms, and Aeons