NEM:Recall

Client Request

The client aimed to build a unique anime gacha game with a strong narrative focus and AI-driven character interaction — something that would stand out from traditional genre conventions.

At the same time, the project required:

A fully functional beta version within fixed deadlines
A scalable backend to support live operations
Flexible systems for balancing, storytelling, and AI integration
A gameplay experience that would be both innovative and understandable for players

As development progressed, the scope evolved significantly, requiring continuous alignment between vision, design, and technical implementation.

Game Design & Balance System

One of the biggest challenges on the project was turning a broad creative vision into a game that players could actually read, understand, and enjoy.

The core concept mixed several layers at once: a 4-card party system, turn-based battles driven by speed-based action order, attribute advantage rules, character roles, skill cooldowns, ultimates, progression, equipment, and a gacha economy. In the GDD, cards were designed around roles and identities — for example, Ezra as a high-HP brawler, Yume as a healer, and Runa as a high-speed mage — while combat relied on dynamic turn order, passive triggers, and an attribute triangle between Lucid, Nightmare, and Daydream.

The game also needed clearer genre logic and stronger balancing rules so the experience would feel familiar enough for players to learn quickly. Stepico helped bridge that gap by translating raw ideas into a more structured gameplay framework: documenting mechanics, defining how progression and combat systems should work together, and identifying where the design was drifting too far from player expectations.

Our game design work focused on several key areas:

Making the combat model readable

We helped shape a combat structure where players bring exactly four cards into battle, with characters acting based on speed, and with decisions built around basic attacks, skills, and ultimates. The GDD also defined dynamic move order and a visible action queue, which gave us a strong base for making combat more legible and strategically understandable.

Bringing balance to character and role design

Since each card combined character identity, role, stats, passives, and active skills, balancing wasn’t just about numbers — it was about making each unit feel distinct without breaking team-building logic. Stepico helped structure those relationships and tune the proportions between aggression, survivability, speed, and support value so the roster could feel coherent rather than chaotic. This aligned with the broader system described in the GDD, where cards could be upgraded through leveling, uncapping, ascension, and skill upgrades.

Improving progression and economy logic

Balancing also extended into the meta layer. The GDD outlined a fairly deep progression model with card leveling, duplicates converted into shards, ascension, equipment slots, stamina-gated farming, pity-based gacha rules, and multiple in-game shops. Stepico’s role here was to help shape the proportions behind those systems — including free-to-play vs paid value, upgrade pacing, and resource flow — so the beta would not just function technically, but also make sense as a live product.

Using playtests to validate design decisions

A key turning point mentioned on the call was that playtesting helped reveal where players struggled with unusual mechanics and unclear balance. That feedback made it easier to ground discussions in actual player behavior rather than assumptions. Stepico used those insights to recommend adjustments that improved clarity, lowered friction, and moved the game closer to recognizable genre standards without losing its identity.

Flexible Balance & Tuning System

To make balancing faster and less painful, we supported a more flexible, config-driven approach. Combined with the backend configuration system mentioned on the call, this made it possible to adjust character parameters, progression values, and gameplay tuning without heavy code-side rework. That mattered a lot for a project where features and requirements were still evolving.