Overview
Project Eternal is Froströk’s hardcore top-down action RPG, publicly shared by the studio ahead of a playable build at Gamescom 2026. The core premise: no classes, no levels. Progression comes entirely from what you find and choose to wear, every piece of gear shapes how you fight, what you can survive, and which risks become worth taking.
I’ve been on the project since December 2024 as a System / Technical / Combat Designer at Froströk, focused specifically on the itemization and progression backbone that makes that premise work in practice. The progression system and the item generation and balancing pipeline below are that backbone.
(This Overview reflects what the studio has already shared publicly, including the project name itself. Specific mechanics, values, and internal names further down this page are still adapted or altered to respect NDA.)
Summary of my work
- Designed the game’s core secondary progression system, a 3-tier modular upgrade path
- Designed how weighted attribute scaling integrates into the studio’s existing item generation pipeline
- Designed combat and abilities across the full range, from ability acquisition down to frame-level input-buffer tuning and balancing
- Co-designed the game’s core USP itemization system, gear that unlocks power through player behavior instead of stat rolls
Progression System
Result: Designed the game’s core secondary progression system — a modular upgrade path that sits alongside gear — and it’s now implemented and live in the current build.
Problem: The game needed a long-term power-growth path that felt earned through experimentation, not just gear replacement — something that rewards curiosity and produces build identity, without overwhelming players who are still learning core combat.
Solution: A three-tier hierarchy:
Tier 1 – Hub Interactable Device
A home-base object with limited slots that accepts upgrade units earned from harder content, giving players a secondary path to power beyond gear.Tier 2 – Modular Units
Earned from mid-to-high effort content, each with a randomized number of slots and possible linked connections that enable synergy between what’s inserted.- Tier 3 – Insertable Fragments
Collectible pieces that slot into modular units, boosting stats or unlocking hidden passive effects when specific combinations are discovered.
The system unlocks midway through the game, after players have a grip on core combat. Early fragment drops foreshadow it before it’s explained, and discovery of hidden combinations is the core reward loop.
Goal-Oriented Progression Loop
Design Intent
Every layer is built to make players teach themselves the system through play rather than a tutorial — dungeons and elite fights become recognizable as “the place modules come from,” and finding a rare slot combination is meant to feel like a discovery worth sharing, not a stat readout.
Tools used
Used for creating UI elements and visual mockups to be used with Adobe XD to create an interactive prototype.
Prototyped the full UI/UX of the customization interface to prove the concept of customization and discovery. Including animations and placeholder SFX to help validate the core interactions.
Weapon Generation & Balancing
Result: Designed how attribute-based weapon scaling integrates into the game’s existing item construction pipeline, informed by research into Path of Exile’s random affix-rolling model and Dark Souls’ attribute-based weapon scaling. That design is shipped, now running as an in-engine tool built by programmers, and I built a standalone scaling simulator myself to prototype and validate it before any engineering time went into it.
Problem: The existing pipeline already handled static and randomized modifiers well, but had no way for a weapon’s power to reflect which attributes a player had actually invested in, the kind of build-defining choice Dark Souls-style scaling provides. I wanted to add that layer onto a system that already worked, without redesigning what didn’t need to change.
Solution: The pipeline runs in four stages. The first three were already in place: static modifiers set by item level and weapon/armor type, an optional implicit modifier per template, and randomized prefix/suffix rolls filtered by item level and tier. What I designed and documented, with a full flowchart, was the fourth stage: a check for whether the item is a weapon, and if so, an attribute scaling step where each weapon template defines which attributes it scales with, with the actual rank pulled from a weighted ladder where lower ranks are common and higher ranks are deliberately rare. If the check for Weapon Type fails, construction skips straight to finalizing the item.
Attribute Scaling & the Rank Ladder
Each weapon defines which attributes it scales with and how those ranks are weighted. Lower, more common ranks pull the weapon’s power down toward a reliable baseline, while rare high ranks create standout, build-defining rolls. This is the layer that turns a level-appropriate item into something that can still feel exceptional.
Where this is going next: currently every attribute on a weapon rolls across the same fixed range. The stated goal is a tool that lets each weapon define a different range per attribute, so range itself becomes another lever for balancing a weapon’s power over the game’s full level curve. Worth including as a “what I’d build next” note, it’s a good iteration/forward-thinking signal.
The payoff moment, already shipped in a partial form. Rolled attributes are color-graded on a lerp from bronze at the lowest rank to gold at the maximum, so a max roll reads immediately without needing to parse the numeral. The design intent behind marking it this specific way: hitting the true maximum should land as an unmistakable moment, the same jolt as a rare drop, an “I got the hit” reaction, not something a player has to double-check by reading a number. That’s the same variable-reward excitement that makes a good loot system compelling in the first place, and it’s why a max roll gets a distinct visual state instead of just a slightly-brighter number.
This is a first pass toward the fuller intent, a more deliberate, standalone callout specifically for max rolls, rather than a continuous gradient.
Weapon Scaling Simulation Tool
Result: Built a standalone weapon-scaling simulator (Google Sheets + Apps Script) to prototype and pitch the rank-based scaling system to programmers ahead of a full in-engine implementation.
Problem: Needed a fast, concrete way to communicate how the rank-and-weight scaling formula should behave, and to prove it produced sensible results across the full range of weapon power, from a modest starter weapon to an intentionally extreme stress-test case, without waiting on engine work to find out.
Solution: Each weapon type has its own config table defining damage ranges, weight distribution across the rank ladder, and per-attribute scaling windows; the main viewer pulls the selected weapon’s data from the relevant table via dropdown. A Reroll button runs a script that rolls a rank within each attribute’s range, converts it to the game’s Roman-numeral display, and calculates the resulting scaled damage against a fixed reference character’s attribute totals, letting me click through repeated rolls and see exactly how each roll changes a specific player’s realized damage. Validated at both ends of the power curve to catch balance issues the formula might hide in the middle.
Attribute types are defined once and referenced everywhere via dropdown validation, adding a new one here makes it available across every weapon table automatically
The viewer pulls a weapon’s full configuration live from its type-specific table via a lookup formula keyed on the weapon’s name, no data duplicated, nothing to update when a new weapon is added.
Rather than a flat roll across a weapon’s full range, the script splits that range into three weighted bands, so a weapon’s typical rolls can be skewed low, mid, or high without changing its overall range.
Each attribute rolls independently through its own function; a single orchestrator composes them into one reroll-everything action.
Tools used
Used to build and manage item libraries categorized by type, giving me a clear overview of all items and their properties. I also used built-in charting tools to visualize progression curves, such as how weapon strength scales over time.
Implemented custom scripts to simulate item generation logic and automate data handling. These scripts allow me to fetch and push structured JSON data into sheets, enabling quick export for use in-game.
Combat & Ability Design
Gaining Abilities
Result: Designed the game’s ability-acquisition system, replacing a traditional skill tree with a crafting-and-equip model, pitched it to my Creative Director for approval, and built an interactive UX prototype myself to validate the flow before any engineering time went into it.
Problem: I wanted ability power to fit the same rhythm the rest of the game already runs on: explore, fight, loot, return to the hub to experiment with what you found, share it with other players. A skill tree, or an NPC trainer you buy abilities from, breaks that rhythm, it’s a system bolted onto the itemization loop rather than living inside it. There was also a tonal constraint: this world is grounded in something closer to mysterious, supernatural, eldritch territory, not high-fantasy fireballs and ice bolts, so whatever granted abilities needed to produce effects that actually belonged in that world.
Solution: A container item holds no ability until it’s crafted. Crafting resources, gathered through play, combine inside it, and which combination goes in is the creative act. Those resources are tied to distinct thematic categories rather than elements, so a combination produces an ability whose effect and flavor actually reflect what went into it, in keeping with the grounded, non-elemental direction above, rather than a generic damage-type mashup. The container fills its own dedicated equipment slot, a category of gear in its own right, not something socketed onto another piece of equipment. Only a small, fixed number of these slots exist, and an ability disappears the moment its container is unequipped, nothing is permanently owned independent of gear. Because of that, there’s no separate ability list to manage, arranging and sorting containers in inventory is arranging your ability list, the same interface doing both jobs.
A freshly crafted result shows as unrevealed until confirmed, carrying the same hidden-then-revealed anticipation the rest of the itemization systems use, and for the same underlying reason: the combination space is meant to be explored and shared between players, not read off a list.
I’m designing the individual resource categories, not pre-defining which combinations should synergize into specific builds, which combinations actually work together is something for players to uncover and pass along to each other, the same instinct behind the progression system’s hidden module combinations.
What’s still unresolved: how a player gains more equip slots over time. I want slot growth to expand build breadth without falling back on generic rarity tiers on the container, this project has deliberately moved away from power-tier labels on items, so growth needs its own hook, not a rarity ladder, and I haven’t solved that yet.
Each ability entry includes:
A short description and intended gameplay use
How the ability is acquired or unlocked
Damage type, effect type, and internal tag filters for integration
A direct hyperlink to a collaboration sheet for animation, VFX, and SFX
Collaboration Approach
The linked documents go deeper into the feeling, tone, and visual intent behind each ability. For each ability, I can include information such as:
Reference images for poses, elemental effects, and visual style
Links to video references demonstrating timing or inspiration
A rough animation montage timeline showing when key moments should happen (e.g., when the windup begins, when the hit should land, etc.)
- Additional detailed information about VFX location, target type etc.
This setup has been well received by the team and makes it easy to understand what each ability or attack is aiming to achieve. It gives everyone a clear starting point, while still leaving room for their own interpretation. Something we can later refine together through feedback from me or the Director.
One more piece of how I work with the team: for attack animation specifically, I record and edit my own reference footage, re-timing sections to communicate the pacing I actually want, and pair it with written notes on why each weapon type should feel the way it does. That gives animators a visual reference and the reasoning behind it to work from, not just something to copy.
Combat Input Buffer & Feel
Result: Designed the input-buffering behavior for melee combo continuation, built by our engineers, and tuned its timing myself once it was in place.
Problem: Players shouldn’t have to spam-click to make sure an attack input registers, but the game also shouldn’t force a player into another attack just because they clicked one too many times finishing the last one. Getting combo continuation to feel intentional in both directions needed more than a single fixed input window.
Solution: Specified two distinct input-window behaviors for combo continuation: a deferred window, where a press during it executes the next attack on the window’s last frame, and an immediate window, where the same press executes right away. Together they create a brief follow-through beat between attacks, long enough for the player to consciously choose to commit to another swing or bail into something else, dodge, block, reposition, rather than the game deciding for them.
I tuned the actual timing of those windows myself: wide enough that a normal press reliably registers without spam-clicking, but short enough that leftover clicks from the previous attack don’t leak into the next window and force a swing the player didn’t mean to throw.
Tools used
I used spreadsheets to manage the full ability list, including names, descriptions, acquisition methods, damage types, and internal tags. Each entry also included hyperlinks to shared documents for animation, VFX, and SFX.
I used Figma to draft the ability acquisition flow and early UI layout concepts. It helped me communicate how abilities tie into the progression system and provided a visual reference for discussing structure, pacing, and player feedback with the rest of the team.
I built an interactive prototype in Adobe XD. This mockup focused on how players would navigate ability acquisition and equipment menus. It included animated transitions and clickable states to showcase the intended feel and usability of the interface.
Enemy Design
When designing enemies, I’ve followed a similar workflow to how I approach abilities — keeping things structured, clear, and easy to collaborate on. The enemies I designed is, as I mentioned previously, meant to be part of the onboarding experience of the game.
Each enemy starts with a written breakdown in Notion, where I describe the design philosophy, their core behavior, movement style, and how they’re meant to challenge the player and for them to beat the enemy. I then link to a shared spreadsheet that goes deeper into the design, including:
Visual and tonal references for how they should move, feel, or behave
Descriptions of any special abilities they use
Notes on things like timing, telegraphing, and their place in the overall difficulty curve
Just as with the Ability Design documents, these are meant to give animation, VFX, and SFX teams a clear starting point. Not just the mechanics, but the tone and personality of each enemy. It creates a shared vision that still leaves room for creative input as we iterate together.
For the basic enemy, I wanted to set the tone by making them feel desperate, clumsy, and slightly afraid. Giving the impression that they’re barely holding themselves together in combat. This contrast was intentional, as it sets the stage for the boss encounter that follows.
The boss, in comparison, carries a more arrogant and commanding presence. The kind of character who steps in with a “Fine, I’ll handle this myself” attitude. That shift in tone is also reflected in the boss’s animations and attack patterns, which are more deliberate, collected, and strategically paced.
There’s more planned in terms of how these personalities play out mechanically and visually, but those details will have to wait until they can be shared more openly.
As an example, one of the boss’s abilities is documented using the same structure and format as the player ability system, allowing for consistency across both design and implementation. The image shown here is a highly simplified and stripped-down version of the original document.
Again, by structuring it this way, both artists and developers can quickly understand how the ability functions, what it needs in terms of animation, timing, VFX, and audio, and how it fits into the broader encounter. This shared documentation helps align everyone on execution while still giving room for creative input during production.
Tools used
Used Notion as our compendium of current and future enemies. Detailing the characteristics, behavior and list of attacks and abilities.
Photoshop was used to create visual explanation images to showcase intent of certain abilities.
Google Sheets was used as collaboration tool to visually communicate enemies characteristics and combat abilities.
Task Gear & The Task System
Result: My Creative Director set the premise: hidden trial areas, separate from the standard gameplay area, with items acquired there carrying unique modifiers. Two things were still open when I started: what players would actually do inside these areas, and how to make those modifiers more interesting than a single rough example he’d sketched. I designed the answers to both, including the task-based unlock mechanic that’s the actual core of how this system works.
Problem: A premise isn’t a system. “Hidden areas with items that carry unique modifiers” didn’t yet answer what happens inside those areas, or what makes a modifier feel interesting rather than just a bigger number attached to a condition. It also needed to avoid the two traps ARPGs tend to fall into: gear that feels disposable once you outlevel it, or optional depth systems too complex for most players to bother with. Games that solve this well, Hollow Knight, Elden Ring, Witchfire, gate a rewarding second system behind mastery of the core loop and introduce it deliberately. That research shaped when and how this system enters the game.
Solution: I designed the task-based unlock mechanic itself: items are earned in hidden trials outside the standard gameplay area, not looted directly, and usable the moment you get them. Real power stays hidden behind “???” until a task tied to each modifier is completed through ordinary play: a kill condition, a status effect applied enough times, a defensive condition met over time. The tasks span real variety on purpose, not the same kill count restated six times, and I also designed several of the trial encounters themselves, some setting-specific, some universal, along with a few of the modifiers.
Item with Tasks
Item without Tasks
The intent behind that hidden-power framing specifically: these items shouldn’t feel like a locked box waiting to be opened, they should feel like an unfinished relationship. The item wants something from the player, and earning it through play is what makes the power feel bent to their will, not just another stat roll.
These items also carry fewer standard stats than normal gear, on purpose. The trade is build-changing effects instead of bigger numbers, a well-timed dodge that punishes an attacker, a status effect that compounds on an already-afflicted enemy, that kind of thing.
Completing a task doesn’t unlock anything automatically. The player returns to the hub and chooses to activate it, on purpose. An early-game item holds fewer hidden modifiers, while late-game item can hold several, which are revealed one pair at a time.
Trial Example
Trials comes in a variety of structures, spanning both era-specific and universal designs.
One is simple: hold a position while a meter fills and enemies try to stop you. This one fits any setting.
Another is built around a real-time trade-off: a marked enemy carries something the player needs, and killing it to take what it’s carrying disables the player’s weapon entirely, forcing them onto their ability loadout alone while a steady stream of enemies keeps arriving.
The player has to decide, in the moment, whether to keep carrying it while weakened or drop it to fight at full strength, which lets nearby enemies converge on it and start dragging it back toward where it came from, the more of them that reach it, the faster it goes, forcing a chase to reclaim it before continuing.
Quest System Design
Status: Quest content and dialogue shipped and playable on a demo level. Sequence-break behavior prototyped within the existing system, not yet a finished, named quest.
Result: Designed the quest system’s Gameplay Tag hierarchy and condition-based dialogue logic, the naming convention, replacing a traditional quest log entirely, and wrote the first dialogue and narrative content for a demo level.
Problem: Quest markers and checklists are reliable, but they train players to follow a UI element instead of the world. Since the whole hook of the game is a world whose history has to be pieced together by paying attention, that works against the tone.
Solution: The quest system tracks state through hierarchical Gameplay Tags, something like Quest.[Name].[Stage].[Event], checked directly by NPCs, dialogue, and anything else that needs to know what a player has seen or done. Each NPC conversation runs through a selector that checks the player’s current tags and picks exactly one branch, so a returning player gets the line that’s actually true for them, first meeting, mid-quest, or long since finished, not a generic placeholder.
The game also replaces a traditional quest log with a personal record written in the player character’s own voice. Entries appear as specific tags get granted, so what a player has “written down” reflects their own path through the world, not a shared checklist.
One thing I prototyped on top of this: a sequence-break behavior where a player who picks up a quest trophy before ever being formally asked gets unique dialogue acknowledging that, instead of a conversation that pretends the normal order happened. I got this working using the system’s existing tag-condition tools, proof of concept rather than a finished, shipped quest.
2 arrangements of journal logs based on 2 different orders of completion