Project Overview
Abyss is a browser-based Flash 3D ARPG built by a small team of around 20 people. The project ran for roughly two years from early prototype to full launch and live operations.
The game combined fast, impact-focused combat with:
Deep character growth,
Flexible dungeon and loot systems,
And competitive modes such as a tower-push Arena.
Compared with typical browser ARPGs of that period, Abyss invested heavily in tooling, data-driven systems, and reusable frameworks, so that a small team could support an ambitious feature set and iterate quickly under strong external pressure.
My Role
My role on Abyss evolved over the life of the project:
I joined as the primary systems and numerical designer, responsible for monster stats, player growth curves, combat feel, and difficulty pacing.
Very early on I also took ownership of game structure and tools, pushing for a map editor, data-driven quest system, and structured numerical models instead of ad-hoc spreadsheets.
Over time I acted as the lead designer for systems and economy, responsible for:
The overall system framework and progression structure,
Numerical models for combat, monsters, and gear,
The modular skill system,
And later, monetization features and live balancing.
Because the team was small, I wrote most of the system design documents, designed and maintained the core data tables, and worked closely with engineering to make sure tools and systems stayed flexible enough for fast iteration.
Case Study 1 – Game Structure & Roadmap
Context
When I joined, many ideas existed in people’s heads – combat concepts, dungeons, gear, and modes – but the overall structure of the game was not clearly defined.
Team members had different mental models of:
How players should progress from early game to endgame,
When systems should unlock,
And how daily / weekly routines should be built.
We also knew that we would face tight deadlines and changing expectations from publishers, so the structure had to be clear and resilient.
Design
I focused on making the game’s structure explicit and alignable:
Game structure map
Built a visual system diagram showing:
Core loops (combat → loot → upgrade → deeper content),
How dungeons, gear, skills, and meta-systems connect,
The daily / weekly activity rhythm and long-term goals.
This diagram became the shared reference for designers, engineers, artists, and operations.
Growth order & feature sequencing
Defined the introduction order for systems and content, balancing:
Complexity,
Production cost,
And monetization opportunities.
For example, core combat and basic dungeons were introduced first, then gear depth and build customization, and only later more complex meta-systems.
Roadmap planning
Worked with the founders and leads to define a version roadmap:
Which systems and features must be in the “first playable” and launch version,
Which features would be staged into later updates,
How to sequence work so that a small team could deliver on time.
Impact
The structure map gave the team a single concrete vision of where the game was going.
It became a practical tool for decision-making: new ideas could be evaluated against the structure and roadmap instead of being added ad-hoc.
When we later had to deliver a launchable version within a very short window, the roadmap plus clear structure allowed us to cut and move features intelligently rather than randomly.
Case Study 2 – Tool-Driven Systems & Agile Workflow
Context
The team needed to:
Iterate quickly on combat pacing and difficulty,
Adjust progression and unlock logic after each test,
And keep adding content over time – all with a small headcount.
Typical browser games of that period used lots of hard-coded logic and manual spreadsheet tweaks. That approach would not survive our constraints.
We decided early that almost everything important had to be configurable, computable, and safe to change.
Design
I led the design of several key tool-driven systems.
1. Monster ID and data structure
Rebuilt the monster ID system as a computable convention:
IDs encode monster type, tier, and other key attributes,
All systems (quests, spawns, dungeons) reference monsters via these IDs.
Result: monsters and quest targets can be generated and manipulated by rules, not manual lists.
2. Map editor and dungeon rules
Pushed for a map editor instead of manually editing raw data.
Defined simple rules for solo dungeons:
One main readable path,
Controlled branches,
Clear entry and exit conditions.
Designers could quickly build and iterate layouts without engineering support.
3. Data-driven quest and unlock system
Designed a quest system where:
Every quest lives in data tables,
Each quest knows its previous and next quest,
Feature unlocks are driven by quest configuration, not code checks.
In test cycles this allowed us to:
Re-order quest chains,
Change unlock timing,
Fix progression issues without touching player data or code.
4. Planned and automated numerical models
Defined design parameters first: where players should feel power spikes, when difficulty should rise, how gear quality steps should feel.
Built cross-linked spreadsheets where:
Player growth, skill multipliers, monster templates, and dungeon difficulty all reference each other,
More than 90% of calculations are automated.
In many cases, rebalancing meant:
Adjust a small set of parameters,
Recalculate,
Save and publish updated tables.
5. Modular, configurable skill system
Decomposed each skill into configurable components:
Core effect (damage, control, buff/debuff),
Buff / debuff objects,
Projectiles or spawned entities,
Attributes and behaviours,
Links to follow-up or chained skills.
Once the framework was in place, new skills – including complex ones – could be built entirely through data, by recombining existing components.
Impact
The game became genuinely agile:
Combat pacing, difficulty and growth curves could be adjusted quickly and safely,
Quest flows and feature unlocks could be changed from data after each test,
New content (monsters, dungeons, skills) could be added with minimal engineering overhead.
For a small team, this meant we could respond to publisher feedback and internal findings without losing control of balance and progression.
Many of these ideas – monster templates, skill balance models, data-driven quests – later became foundations for my work on subsequent projects.
Case Study 3 – Signature Modes: Arena & Abyss Trials
Context
To stand out among browser ARPGs, Abyss needed memorable modes that were:
Replayable,
Mechanically interesting,
And integrated with our numerical and loot systems.
Two of the most important pillars were:
A tower-push Arena inspired by multiplayer online battle arenas,
And a multi-stage deep dungeon system players often referred to as “Abyss Trials”.
3.1 Arena – MOBA-Style Tower Push
Design
Built an Arena mode where players pushed lanes and destroyed towers.
Character kits were supported by a rune system:
Runes modified how skills behaved,
Allowed different builds on the same character (e.g. more burst vs more sustain).
Because our game had strong vertical stat growth, I designed tower protection mechanics to prevent over-geared players from instantly ending matches:
Towers used protective rules and thresholds so that games remained competitive and fun,
This helped newer or less geared players still feel they had a chance to fight back.
Impact
At the time, embedding a full lane-and-tower Arena inside a browser ARPG was relatively rare.
The mode became one of the most distinctive features of Abyss and drove strong engagement from PvP-oriented players.
3.2 Abyss Trials – Deep Dungeon & Loot Loop
Design
Created a layered dungeon chain:
Players progressed through multiple floors,
Each floor contributed to a score or performance metric,
The final stage generated a reward dungeon with higher loot potential.
Designed loot with readable, Diablo-style affixes, so players could quickly understand:
What made an item special,
How it supported different builds or playstyles.
Integrated the dungeon with our extraction / draw system, so that:
Running deeper content yielded better items and properties,
Those properties could be extracted and optimized,
Feeding back into the motivation to push deeper runs.
Impact
When Abyss Trials and the associated loot systems launched, they delivered a significant short-term uplift in revenue compared with the previous baseline, driven by higher engagement and stronger motivation to optimize builds.
More importantly, they provided a long-term endgame target beyond the main story and basic dungeons.
Results & Learnings
Results
A small team was able to build and operate a relatively ambitious ARPG by investing early in tools and data structures, not just content.
The game’s systems proved flexible under pressure: we could meet publisher requests and internal goals through structured adjustments instead of chaotic manual tweaks.
Many of the frameworks and habits formed on Abyss – tool-first thinking, computable IDs, automated numerical models – carried forward into my later work on larger mobile titles.
Key Learnings
For long-running games, system design and tool design are deeply connected. Decisions about IDs, tables and editors are as important as combat or economy decisions.
If a system cannot be safely changed, it will eventually block the game’s growth. Making things configurable and computable from day one is often the most “player-friendly” decision in the long term.
Even on constrained platforms, a team can achieve high agility by thinking in terms of rules, models and configuration, rather than only content and one-off scripts.