The Forbidden Hell is a C++ console text-based horror adventure game built solo as a university assignment. The player wakes up in The Forbidden Hell forest - a location notorious for unexplained disappearances and murders - and discovers they can cast magic spells. Narrative decisions are driven by RNG, and the world is populated with a full turn-based RPG battle system inspired by Final Fantasy XIII.

The game is built entirely in the terminal - no engine, no renderer. The UI is driven by FTXUI (a C++ CLI UI library) for fullscreen interactive menus, with FMOD handling all BGM and SFX audio. Custom save/load writes player state to a proprietary .the_forbidden_hell file format on disk.

Inspirations for tone and feel: Blair Witch Project, Final Fantasy XIII, Silent Hill Homecoming, Slender: The Arrival, Resident Evil 3, and The Evil Within.

While it was frustrating to find that my game refused to open, it made me recognise the importance of testing games on various devices to check for compatibility or more generalised issues.

The project also hit a fundamental technical constraint mid-build: FTXUI and windows.h cannot be included in the same translation unit. They produce compile failures due to symbol conflicts. This forced significant architectural decisions - any system that needed Windows API access had to be physically separated from any file that included FTXUI headers. Code that had already been written had to be restructured or removed.

The combat system is a turn-based Final Fantasy XIII-inspired loop. Each turn the player selects a role, which determines what four actions are available. Damage types are resolved against per-element weakness/resistance/immunity tables for each combatant. The only thing missing is the ATB (Active Time Battle) gauge - which is not suitable for a game like this.

Nine damage elements govern all combat interactions:

Status ailments operate independently on both sides of combat: Bleed, Poison, Weaken, Curse, Protection, Regeneration, Elude, Block, and Dodge.

Five regular enemies inhabit the forest, each with three signature moves and their own element affinity profile. The boss encounter features full voiced audio:

The game's world was designed as a fully interconnected forest settlement with distinct zones. The player starts at the Forest Camp Site and progresses through a series of locations, each with its own narrative beat and encounter type:

• Forest Camp Site — starting location; narrative intro and world-building
• Narrow Path — transition zone with ambush encounter potential
• Wooden Town — hub area housing three shops: Twisted Fate, Tommy's Wonky Wizardry, and Giant Green Market
• Hotel — rest and save point; narrative-heavy location
• Toilets Building / Abandoned Wooden Building — unsettling interiors with horror encounters
• Construction Area & Radio Tower — mid-game locations tied to the main mystery
• Tunnel — linear high-tension gauntlet zone
• Forest Paths & Picnic Area — open exploration with random RNG encounters
• Riverside — final approach zone before the endgame

The game is a pure C++ console application. There is no engine, no renderer - everything runs in the terminal. The architecture straddles a difficult constraint: two of the core libraries cannot coexist in the same translation unit. Furthermore, my implementation of FMOD was buggy, leading to eventual memory leaks.

FTXUI - fullscreen terminal UI. Used for interactive menus, tab containers, sliders, and animated selection. The main menu, settings, and all in-game navigation panels run through FTXUI's component system.

FMOD - audio engine. Separate System, Sound, and Channel objects per audio stream. BGM loops: two main menu variants, four battle tracks, one post-battle track, one boss theme. SFX are one-shots. Volume and channel management handled manually.

Windows API - SetConsoleTextAttribute drives all terminal colour (red, blue, white - runtime selectable). SetConsoleTitle, GetSystemPowerStatus (battery level display in main menu), Sleep, SetWindowLong (disable console resize), and GDI console outline drawing are all used.

RNG - std::mt19937 Mersenne Twister seeded with std::random_device, with uniform distributions for both integer and float ranges. Used for narrative branching decisions, random encounter events, and stat variance in combat.

A clearConsole() function with a loading screen animation text - simulating the player character walking between locations - is used throughout to smooth transitions. waitForUserInput() halts execution at narrative beats for pacing.

The player starts with baseline stats and levels up through an XP system. On level-up, stat points can be allocated across HP, ATK, MG, and DEF - with a bonus stat allocation every five levels:

• HP: 175 base
• ATK: 5.8 base
• MG: 4.3 base
• DEF: 1.74 base

Inventory items available in shops and as drops:

• Bandages - restore 30 HP
• Potions - restore 50 HP
• Antidotes - cure Poison status
• Elixirs - full HP restoration
• Mage's Potion - restore 100 HP, +30 max HP permanently, apply a random stat buff

The FTXUI/Windows API incompatibility was the single most disruptive technical obstacle. The two libraries cannot coexist in the same file - this isn't a minor include order issue, it's a fundamental conflict between FTXUI's abstraction layer and the raw Windows console API. Resolving it required restructuring files mid-development and removing some already-written functionality. This took significant amount of time.

The project also had to be migrated to a fresh project space partway through development after the original FTXUI CMake setup failed in a way that could not be repaired in-place. Starting over in a clean environment cost significant time.

Outside the submission failure, the architecture forced by the FTXUI/windows.h conflict produced some unexpectedly clean design. The strict separation of concerns - audio in its own unit, Windows calls in theirs, FTXUI in theirs - mirrors patterns you'd apply intentionally in larger codebases. The constraint produced a cleaner project structure than a purely unconstrained build would have.

The final hefty challenge that appeared near the end of the development, was the infamous FMOD memory leaks. It seemed as if FMOD were not clearing the played sounds from memory, therefore, the memory would keep growing every sound that is played, causing out of memory error internally.