Interconnected gameplay systems

Exile

A released hybrid game that connects timed 3D resource gathering and village development with 2D top-down combat and persistent progression.

My role: Solo Programmer and Designer
Context: Solo Project · university project
Period: 2023
Status: Released Windows build · source available

View source on GitHub Play on itch.io

Exile 3D daytime resource and village-building phase in a forest settlement — The daytime preparation phase connects resources to later defensive pressure.

Exile 2D nighttime combat phase showing the knight fighting an enemy near the settlement — The 2D night phase turns daytime preparation into direct defensive combat.

01 · Overview

Project overview

Exile alternates between a timed 3D preparation phase and a 2D top-down defence phase. Resources gathered by day support buildings and upgrades, while combat at night tests those preparation decisions.

The implementation joins two presentation styles through shared progression, persistent state, scene transitions, and a central game manager.

The economy had to keep prices achievable across difficulty modes. Daytime also needed to provide enough preparation time without removing the pressure created by each night.

02 · My role

What I built

Developed resource nodes, shops, building placement, upgrades, interactables, and affordability rules for the preparation phase.
Implemented 2D combat, enemy spawning, difficulty flags, scene transitions, and the day-to-night progression flow.
Created reusable interaction interfaces and ScriptableObject-backed configuration to reduce coupling between systems.
Persisted player statistics, resources, difficulty, and world/building state through a GameManager and PlayerPrefs save/load workflow.

Project scope

Project-wide capabilities

Timed gathering, village construction, shops, upgrades, and an economy of preparation choices.
Top-down combat, enemy pressure, scene flow, UI, audio/settings, and difficulty selection.
Reusable interactables, data-backed configuration, and saved player/world progression.

03 · Decisions

Gameplay loop, economy, and pacing

How the project structured its systems, interactions, and delivery constraints.

One loop, two modes

Explicit phase transitions keep the 3D preparation and 2D combat modes connected through resources and progression.

Reusable interactions

A shared interaction interface lets resource nodes, shops, and world objects expose consistent player actions.

Persistent central state

The GameManager carries player and world progression across scene changes and reconstructs saved building positions.

Economy across difficulty modes

Prices and preparation time were designed to keep buildings and upgrades achievable on each difficulty while preserving a reasonable run length measured in days and nights.

Simple night scaling

Known limitation: the main scaling rule only adds one enemy each night. The rising count increases time pressure and encourages faster, more efficient resource gathering during the day.

04 · Problem solving

Challenges and responses

Concrete constraints are paired with the implementation or design response used in the project.

Challenge

Keeping two visual modes connected across scene transitions.

Response

Used shared resources, stats, difficulty, and world state so progress remains meaningful after each transition.

Challenge

Avoiding bespoke interaction code for every resource, building, and shop.

Response

Introduced reusable interfaces and data objects so systems share contracts while retaining distinct behaviour.

Challenge

Keeping progression achievable as nighttime pressure increases.

Response

Balanced prices, daytime gathering time, difficulty settings, and the expected number of day-night cycles so preparation remained possible.

05 · Iteration

Implementation checks and known limitations

Tested the economy and difficulty settings across the day-and-night progression loop.
Exercised save/load behaviour across scene changes, resource updates, settings, and reconstructed buildings.

What I learned

What the project changed

Persistent state is the connective tissue when different scenes and gameplay modes must feel continuous.
Clear shared interfaces help a prototype grow without making every feature depend directly on the player controller.

Future pass

What I would improve

Replace PlayerPrefs with a versioned save format and add corruption/migration handling.
Improve onboarding and feedback around phase timing, resource goals, and building effects.
Replace the one-enemy-per-night rule with a richer curve that can vary enemy composition and pressure without blocking progression.

Related work

Dungeon Wipe

Solo Project · BSc final project · research prototypeReleased Windows build · source available

A released Unity dungeon-survival game with a custom JSON level editor, runtime level reconstruction, combat systems, NavMesh enemies, scoring, and a health-responsive potion system used in published DDA research.

Role: Solo Programmer and Designer
Built: Built the grid-based editor, prefab placement workflow, JSON serialization, custom-level selection, and runtime level reconstruction.

View Dungeon Wipe case study Play on itch.io View source on GitHub

O2D top-down action gameplay on an alien planet

O2D

Eight-Person Team · GN! Game Jam #15Completed game-jam project · playable Windows builds

An eight-person Unity 6 jam project about defending an oxygen base from alien waves while gathering fuel, crafting upgrades, and using player abilities.

Role: Programmer
Built: Contributed as a programmer within an eight-person game-jam team and helped deliver the completed playable build.

View O2D case study Play on itch.io