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 Technical / System / 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.)
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
To support the design and implementation of combat abilities, I created and maintained a centralized Ability List document. This served as both a creative design hub and a coordination tool across departments.
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.
Ability Acquisition & Design Intent
The way players acquire abilities is closely tied to the same design philosophy behind the previously described progression system: discovery through experimentation. Rather than simply unlocking abilities through a linear path or level-up menu, abilities are tied to a separate system that encourages players to explore, try new things, and uncover abilities in a unique way.
Due to NDA restrictions, I can’t go into detail about the exact mechanics — but I’ve had full ownership of this design, including how the acquisition logic connects to progression, and how it supports the overall sense of player-driven growth.
When designing abilities, my goal is to offer a wide variety of effects and use cases that allow players to experiment with different builds and playstyles. Rather than guiding players toward a fixed loadout, I aim to support creative combinations and encouraging the community to theorycraft, share discoveries, and shape their own combat identity.
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.
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