Sky Vanilla Games · Case Study

Mythical Odyssey

I joined the project as a game systems designer designing features during its production and post-production phases, working alongside design and technical team in Singapore and collaborating with design and art teams in China.

Systems Design Progression Economy Live Ops
Official website
Mythical Odyssey: Nezha Reborn · Idle RPG with strategic hero combat
RoleGame Systems Designer
PlatformMobile, Android & iOS
Unity
CollaboratorsDesign and art team in Shenzhen, China.
Design, front & backend team in Singapore
Duration2 years 9 months
Jan 2023 – Sep 2025
Overview

Role: Adding strategic depth to an auto-battle idle RPG

I am sharing three cases I was involved in, shipped across production and live ops for Mythical Odyssey: Nezha Reborn: Designing a node-based roguelike dungeon feature, Iteration work of an equipment feature, designing modular event framework built with future hero releases in mind.

General scope of work
  • Development of an activity dungeon game mode
  • Development of the base for the onboarding tutorial
  • Development of the New Hero event, post launch
  • Optimisation of the mid-to-late game hero equipment system
  • Optimisation of the chat system, adding megaphone banners, scrolling announcements and notification systems
  • Optimisation of the alliance-required equipment system, and alliance event activity
  • Ongoing design optimisations across the live release version
01
Roguelike Dungeon Mode

Realm Trials

Realm Trials is a PVE dungeon mode built on a node-based progression map, where players choose paths between battles, events and rewards. Team health does not reset between battles: it carries forward until the run ends.

RoleSystem Designer
Game flow, power progression, reward structures
Team2 designers
2 engineers
2 UI artists
Timeline~6 weeks
TypeRecurring core mode

Goals

  1. Provide mid-session engagement beyond story mode progression.
  2. Introduce branching decisions, to create meaningful choice in an otherwise auto-battle system.
  3. Offer replayable content with variation every run.
1.1

Node-based progression, replacing linear choice

Problem

Existing game modes were linear in approach and offered little meaningful decision-making.

Approach
  • Designed a structured node-based progression map where players choose paths between battles, events and rewards.
  • Built the level design to position clear routes that are risky but high reward against routes that are safe but lower reward, encouraging players to make strategic and meaningful choices.
  • Ran internal testing trials and gathered feedback to balance the pacing and decision density of the experience.
Level design approach diagram showing branching node routes
Approach to the level design
1.2

Roguelike modifiers for build diversity

Problem

Base combat lacked strategic depth, because character builds were static.

Approach
  • Implemented temporary modifiers, "Remnants", that stack and synergise with the player's team across a run.
  • Designed Remnant pools across offensive, defensive and utility categories.
  • Gave each Remnant up to three increasing rarity tiers, to scale excitement across a run.
  • Added "Buffs", one-time effect modifiers that further aid a player in battle.
Node types
  • Battle nodes. Easy, Normal and Elite enemy nodes with clearly different rewards, always chosen by the player.
  • Event nodes. Mysterious merchant nodes selling items for upgrading weapons, healing pool nodes that recover team health, and buff nodes carrying one-time modifiers activated before battle.

Every node was built to make players weigh short-term survival against long-term power scaling within a run.

1.3

Content balancing without hand-crafting every tier

Problem

Manually crafting and balancing content for every player level would take far too long to complete.

Approach

Used a "Reflection" method to sustainably manage hand-crafted difficulty content across all player levels.

  • Retrieves the latest combat power and applies stat multipliers to raise or lower each node's intended enemy battle power and difficulty, scaling to the player.
  • Retrieves team compositions from PVP modes, so the content reflects the popular meta and the equipment actually available to players at each ranking.
Configuration table for the difficulty scaling feature
Configuration table for the feature
1.4

A competitive layer on top of the run

Problem

The mode lacked social and competitive components.

Approach

Added a ranking system that rewards strategy and showcases player capability.

  • Rankings reset weekly, while points accumulate daily, to reward consistent daily participation.
  • Because the difficulty system gives players of any level a similar starting line, the point system instead measures turns taken in battle and difficulty tier cleared, which differentiates capability rather than account age.
Result
  • Increased active engagement time compared with passive idle modes.
  • Created a high-replayability loop while reducing the volume of hand-crafted content required.
  • Introduced strategic depth into a largely automated combat system.
  • Remains a core recurring mode that complements the main progression loop.
02
Boss Dungeon Mode + Equipment

Rebuilding the artifact economy

A redesign of an existing dungeon mode, together with additions to the mid-to-late game hero equipment system known as Artifacts. The existing gear and upgrade loop lacked depth and long-term engagement, particularly in the late game.

RoleSystem Designer
Game flow & UX design
Team2 designers
2 engineers
2 UI artists
Timeline~6 weeks
TypeRedesign + system extension

Goals

  1. Increase boss encounters, and randomise them for all players, to improve the diversity of the artifact pool.
  2. Increase longer-term engagement with the equipment system.
  3. Increase the lifecycle value and utility of excess or unused artifacts.
2.1

Boss dungeon game flow

Boss Dungeon main page→ Select a boss→ Choose a difficulty→ Victory: resources, return to main

New difficulty unlocks above 1 star. On defeat, the player returns to the difficulty selection to pick again.

Problem

The previous design used a fixed daily boss rotation, with one boss type available per day. That tied artifact types to specific days, produced uniform progression across the whole player base, and left very little flexibility in farming.

Approach

Redesigned the mode into a node-based structure with randomly selected bosses. Each node respawns on an hourly timer, so players can take multiple battles per session while clearly tracking remaining attempts. Overall availability was adjusted to an eight-hour daily window, to better match play patterns and session planning.

Reflection

A known limitation is that randomness can hand a player the same boss repeatedly, or an undesired one, which risks frustration. Alternatives were proposed and the trade-offs evaluated. We shipped it anyway, because it still pushed players towards trading and raised overall engagement with the game.

Boss dungeon screen flow chart
Screen flow chart in Figma
2.2

Artifact Gear Feature

Problem

The existing gear system lacked depth, long-term goals and player agency. Progression was overly linear and excess artifacts had little utility. Players had minimal control over gear optimisation, which reduced build diversity and strategic engagement.

Approach

Refined the existing system to focus on clarity and usability within the broader equipment ecosystem, and to support a player-driven economy, working with a co-designer responsible for economy balancing.

  • Restructured the stats system to improve utility.
  • Introduced two additional progression paths, Ascension and Refinement.

Stats structure

  • Introduced stat ranges to break uniformity in artifact quality, which creates meaningful differentiation and raises the value of duplicate or excess items.
  • Colour-coded stats so players immediately read low against high.
  • Added reroll systems to balance randomness with a degree of player control, supporting more distinct and intentional builds.
Artifact stats window showing colour-coded stat ranges
Artifact stats window (DEFINING STATS COLOUR CODE & STATS RANGE)
2.3

Ascension Feature

Ascend tab→Select artifact→ Select artifact to consume→Upgrade→ Warning→Success

My role was to design the Ascension and Refine systems with a focus on clarity and usability. I defined a sorting hierarchy so players could quickly identify high-value artifacts by upgrade potential:

Star level→Special skill→ Main stats→Number of random stats
  • Implemented priority-based sorting, top-left to right, to surface the most relevant items first.
  • Added press-and-hold interaction to reach detailed stat information without navigating away.

The structure prioritises long-term investment value, so players make faster and better-informed decisions when choosing artifacts to upgrade, refine or consume.

Artifact upgrade flow screens
Ascend flowCHART
2.4

Refine Feature - Two iterations

Iteration 1 · consumption model

The original approach kept a consumption-based model: players refined a main artifact by consuming a secondary one to reroll sub-stats, with a chance to transfer desirable stats across. It was intended to create a sink for excess artifacts while allowing some targeted optimisation.

  • Low clarity in how stat transfer actually worked.
  • Perceived lack of control, because outcomes felt overly random despite player intent.
Iteration 2 · lock and reroll

Redesigned so players lock the sub-stats they want and reroll only the unwanted ones.

  • Gives direct control over outcomes.
  • Reduces reliance on opaque randomness.
  • Makes the system more intuitive and more predictable.
Refine version one flow, consuming a second artifact
Iteration 1 · select, compare and consume
Refine version two flow, locking desired sub-stats
Iteration 2 · lock desired sub-stats, then refine
Refine page in game
Refine page, shipped
03
New Hero Live Event · Post Launch

A live event framework

Designed a modular New Hero Event framework for post-launch content. The system lets designers configure an event by enabling, disabling or adding modules while keeping a consistent event structure, which improves scalability and production efficiency for every future hero release.

RoleSystem Designer
Event structure, live ops content design
Team2 designers
3 engineers
2 UI artists
Timeline~3 weeks
Cadence3-week event
1-week transition

Goals

  1. Introduce new hero content into the hero roster.
  2. Produce a usable template that is modular and scalable for future releases.

Config schema

1 · Event entry layer

Controls event triggers.

  • Event open time
  • Event duration
  • Event order
  • Availability status
2 · Event controller

The main configuration hub.

  • Gameplay, the mini game
  • Tasks
  • Event shop
  • Cash bundles
  • Ranking
  • Story
New event system config schema diagram
Config schema

Screens in the event

Event pageStoryMini game Daily taskExchange shopSummon page Rule pageEvent end popup
Event screen flow chart
Screen flow chart, ALL KEY SCREENS in Figma

Minigame gameplay step was broken down for the animation and visual effect artists.

Card-flipping event system

  • Designed a card-flipping mechanic with hidden rewards, to introduce uncertainty.
  • Structured reward pools with controlled randomness, balancing excitement against fairness.
  • Tuned progression pacing to frontload small wins and build towards higher-value rewards.

Each hero event is scheduled to run for three weeks, with a one-week transition between the current and incoming event so players can complete any outstanding redemptions or hero ticket draws.

Takeaways

Looking back on where things worked, and where it stopped

The hero event system improved engagement and in-game sales, but long-term retention plateaued. Future iterations could expand it with meta-progression or social competition.

01

Player agency to an auto-battle idle

An idle game removes moment-to-moment input, which makes the decisions around combat carry all the strategic weight.

Adding the dungeon mode that introduces branching routes and stacking modifiers gave players something to be good at without touching the battle itself.

02

Thoughts on Scaling content

Hand-tuning difficulty per level and hand-building tracks per event does not scale sustainably.

By leveraging the player's own combat power as a base to scale difficulty scaling progression helped avoid repeating duties to hand-craft every progression in the feature.

Building a modular event schema bought the team a long running template to build events quickly.

03

Randomness always has its cons & limits

Randomness has helped the system streamline a lot of content and features. However, there are times players agency should be respected.

The Refine Feature was iterated twice in production for a reason. Testers and Players were frustrated over the lack of control over systems that made decisions for them.

Introducing back decisions making features that players can make properly, returned the sense of agency the first version lost.