Early gymnasium project

Turn-Based JRPG Prototype

An early Unreal Engine combat prototype built entirely with Blueprints, included to show where my game-programming journey began.

A three-character party facing a group of spider enemies in the turn-based battle prototype.

RoleBlueprint Programmer

EngineUnreal Engine

ScriptingBlueprints

Project stageEarly prototype

In motion

Gameplay and systems

Selected moments from the original gameplay recording, showing the early Blueprint systems working together in a complete battle.

Battle loop highlightsA 67-second edit showing party combat, commands, abilities, target selection, and the reward sequence.

The party and a line of spider enemies positioned for turn-based combat. — **Party and enemy formation**Three party members face several enemies while the HUD tracks combat resources and character attributes.

A party member attacking while status bars and character attributes are visible. — **Party status**HP, MP, levels, and combat attributes remain visible as attacks change the state of the battle.

A character action menu displayed during the turn-based battle. — **Action commands**The active character can branch into attacks, magic, techniques, and items through contextual menus.

A spell selection menu displayed over the battle arena. — **Spell selection**Magic is grouped into categories before the player chooses an ability and a valid target.

The victory screen showing rewards and level progress for the party. — **Victory and progression**The results screen awards experience, money, loot, and character level progress after the battle.

Overview

Project concept

This turn-based JRPG prototype was one of my earliest game projects, created while I was in gymnasium. I have kept it in my portfolio because it shows the point where I first began turning game rules into connected systems rather than isolated experiments.

The prototype moves a three-character party through battles against groups of enemies. Players choose actions from command menus, select abilities and targets, manage HP and MP, and receive experience, currency, items, and level-ups after winning a battle.

Role

What I worked on

I implemented the gameplay with Unreal Engine Blueprints. The project archive contains the battle game mode and player controller, player and enemy unit Blueprints, field encounters, ability and item hierarchies, battle positions, transitions, and the widgets used throughout the combat flow.

My work connected turn-based actions to the player-facing interface: party status, action commands, target selection, magic, techniques, items, damage feedback, and the victory screen. Although the project no longer opens cleanly in a current engine version, the surviving recording demonstrates the complete battle loop working together.

Design focus

Core pillars

Readable turn flow

Each turn moves from character selection to a command, an ability or item, a target, and a visible result before control advances.

Party resource management

HP, MP, attributes, attacks, healing, and character levels give each party member a persistent state during battle.

Complete battle loop

Encounters continue through multiple enemies and finish with experience, money, loot, and level progression rather than ending at a single attack test.

Implementation

Technical contributions

Turn-based battle control

Connected the battle game mode, player controller, unit positions, and action flow that coordinate party members and enemy units.

Abilities and items

Structured attacks, black and white magic, techniques, consumable items, MP costs, target selection, and effects such as damage and healing.

Battle interface

Built widgets for action commands, party status, ability lists, items, targets, floating damage, and per-unit battle information.

Rewards and progression

Completed the loop with a victory screen that distributes experience, money, collected items, and character level-ups.

Process

Implementation notes

Blueprint asset structure

The project separates battle control, units, abilities, items, field encounters, and UI into dedicated Blueprint assets. That was my first practical experience dividing a game into systems with distinct responsibilities.

Contextual command menus

The interface moves through layered choices for attacks, magic schools, individual spells, techniques, items, and valid targets while preserving the active party member's turn.

Battle results

After the final enemy is defeated, the combat state feeds a separate results view with earned experience, currency, loot, and visible level progress for each character.

Reflection

Challenges

As an early project, the main challenge was learning how many states a turn-based battle must coordinate: the active unit, available commands, chosen targets, animation timing, health, mana, defeated enemies, and the transition to the next turn.

The project also taught me how quickly large Blueprint graphs can become difficult to maintain when responsibilities and dependencies are not planned early. Its current engine-version problems are part of that history.

Learning

What I learned

This was where I first learned to think in systems. A battle is not one feature; it is an agreement between rules, data, characters, input, feedback, UI, and progression.

Looking back at the project makes my later progress visible. I now place more emphasis on clear ownership, reusable components, data-driven content, smaller interfaces, source control, and planning for change.

Next steps

Future iterations

If I rebuilt this prototype today, I would use explicit battle states, data assets for units and abilities, event-driven UI updates, and smaller Blueprint components with clearer responsibilities.

I would also separate original gameplay logic from marketplace content and generated Unreal files, then keep the project under source control so engine upgrades and technical decisions are easier to review.

Explore

Project links

Back to projects