KAM (Graduation Project)

Context

KAM is an isometric turn-based roguelite RPG set in Turkish mythology, built in Unity as our graduation project. Five of us worked on it across two semesters. You play Göktay, the shaman of his Oba, who enters the Spirit Realm to recover a soul the evil spirits took.

I was the only developer on the team. Every gameplay system below — and the architecture behind it — was mine, alongside shared design work on the game itself.

My Role

I worked across both design and implementation, and owned every system that supports the main loop:

• Isometric camera and player movement
• Interaction system for chests, portals, bonfires, pickups and the skill-tree altar
• Inventory, quick slots, item pickups and collectible logic
• Turn-based combat, the Action Point system, and the timed-hit mechanic
• Enemy roaming, detection, combat behaviour and enemy skills
• Skill tree and permanent progression
• Oba hub and Spirit Realm run loop; bonfire save, death and respawn flow
• Persistent world state for chests, bosses, pickups and shortcuts
• Combat UI, HUD, tooltips, damage popups and the combat log
• Audio management and scene transitions

Design Question

How do you keep turn-based combat tactically interesting and physically engaging, while keeping the whole thing small enough for one developer to build and maintain in two semesters?

Turn-based combat has a known failure mode: it becomes a menu you click through. A roguelite makes that worse, because the player repeats the same encounters run after run. The system had to reward thinking and stay active moment to moment — without growing past what a single developer could finish.

Goals & Constraints

Goals

• A complete loop rather than isolated mechanics: explore, fight, collect, save, unlock, die, return stronger
• Combat where a turn is a decision, not a reflex
• A framework that accepts new items, enemies, skills and interactables without rewriting core systems

Constraints

• One developer for all gameplay code, across two semesters
• A five-person team whose art, narrative and audio work depended on my systems being ready
• A scope that had to ship as a graduation project, not a wishlist

Design Decisions

Action Points, and what happens when an action fails. Actions cost AP, and the UI disables what the player cannot afford. The decision that mattered most was the failure case: a failed action must not spend AP or end the turn. The system checks whether an action can execute before it consumes anything. Defend then became a way to bank AP for a stronger play next turn — which is what makes turns differ from one another instead of repeating.

Timed hits that do not own the damage. A rune appears for half a second during an attack; hitting the right key adds damage. I kept this system out of the damage logic deliberately — it returns a result (miss, success, perfect) that the combat system interprets. Input timing, UI and damage calculation stayed separable, which is what later let skill-tree upgrades modify timed-hit outcomes without touching combat code.

One shared unit model. Player and enemies both run on a shared CombatUnit handling health, damage, status effects and death checks, with a central turn manager owning turn order and win/lose resolution. Centralising that meant combat results fire exactly once — no duplicate UI updates, repeated audio cues, or inconsistent outcomes.

Query skill effects, do not hardcode them. Rather than writing skill bonuses into every combat script, systems ask a central effect layer whether a bonus is active. Adding a skill does not mean editing combat.

One interaction flow for every object. Chests, bonfires, portals, pickups and the skill-tree altar share one detector and one prompt; each object defines only what it does when used. New interactables cost almost nothing to add.

I split the project into layers — game flow, combat, progression, inventory, interaction, save, UI, audio, enemy logic — specifically so that UI, combat, inventory and saving never owned each other’s logic. That separation is what made each system testable on its own.

Playtest & Evidence

We ran a playtest on 19 May 2026 with 24 participants, asking about pacing, the rune mechanic, skill-tree build-crafting, balance and audiovisual feel.

Measure	Score (out of 5)
Overall enjoyment	3.66
Rune / timed hit	3.73 — highest rated
Visual aesthetics	3.50
Replayability	3.41
Skill tree	3.39
Sound design	3.37
Controls	3.33
UI clarity	2.91 — lowest rated

Two findings changed my priorities.

The timed hit was the right bet. It scored higher than anything else we measured. The assumption that players want an active moment inside a turn-based system held up under test.

The UI was undermining systems players otherwise liked. Only 58.3% found the exploration-to-combat transition fluid; 41.7% did not. Reading individual responses explained why the skill tree scored mediocre: players were fighting the interface to spend points, not disliking the skills themselves. One tester maxed out the rune and skill-tree ratings, gave graphics a 4 and sound a 5, and still called the game unbalanced — because the UI never explained why they died. Players who rated UI and controls lowest never gave the combat system a chance at all.

That is what the data actually taught me: unclear feedback does not read to a player as “confusing”, it reads as “unfair”.

Iteration

The playtest produced a three-part action plan, and we worked through it:

1. UI/UX overhaul — top priority. We redesigned the interface around the evidence: making combat state (HP, Action Points, turn order) immediately readable, and reworking the skill-tree layout so browsing it feels rewarding rather than obstructive.
2. The exploration-to-combat transition. Cutting transition lag and smoothing the camera so entering combat stops breaking immersion.
3. Encounter balance. Lowering enemy health and making spirit-fragment accumulation less punishing, so a run rewards entering combat instead of avoiding it.

Alongside those, we went back through the build and raised the quality of what was already there rather than stacking new systems on top.

Result & Reflection

The final build is a complete roguelite loop: a hub, a run, tactical turn-based combat, permanent progression, persistent world state, and a save/death/respawn flow — built by one developer inside a two-semester deadline.

The architectural decisions paid off in a way I could measure. Because timed hits, skill effects and interactions were kept modular, responding to playtest feedback meant changing presentation and tuning values rather than rewriting combat. The decisions that cost me most were the ones I made before I understood the problem; the ones that saved me were the ones that refused to hardcode.

What I would do differently is test earlier. We had working combat long before we had 24 people play it, and the most damaging problem we found — UI clarity dragging down systems players otherwise enjoyed — is one a five-person playtest would have caught months sooner. Building the systems was the part I already knew how to do. Learning that the interface, not the mechanics, was the bottleneck is the part I took with me.