I began my work on Heroes of Dragon Age as the Combat (System) Designer and finished as the sole Producer on the game, responsible for running it as a live service with a very small team (as everyone else had been pulled away to work on Star Wars: Galaxy of Heroes).
For now, I’m going to focus on the game design part. For the live services producer side of things, check out my writeup of my time on Star Wars: Galaxy of Heroes, as I was doing basically the same job (but more).
But First, Some Background
When we started Heroes of Dragon Age, the mobile CCG market was unimaginably different from the way it is today. Long story short:
- There were zero mobile CCGs from prominent Western developers
- There were a few crossover hits, mostly from Japan
- All of these games featured exclusively 2D art, mostly in a lush anime illustrative style meant to imitate physical trading card games
- Most “battles” played out with static images and the occasional particle effect
- They were only just beginning to experiment with animation
Surveying this quickly-growing market with breakout hits like Rage of Bahamut and Blood Brothers, Capital Games saw massive potential. And we saw parallels between these early mobile CCGs and the text-heavy games that inspired the studio’s first breakout success as a startup, Superhero City. And what was Superhero City’s biggest innovation?
Animated battles.
So, here was the pitch for Heroes of Dragon Age: Combine the collection-focused gameplay and gacha-driven economy of Japanese mobile CCG’s with the experience of a fully 3D (but still automated) battle system using the characters from the Dragon Age universe.
Because the combat was going to be automated, the design team felt that it would need to still feel strategic in order to be satisfying to Dragon Age superfans.
And that was, for many months, my sole job: Build a combat system in which the battles played out automatically that still felt strategic and interesting. Not an easy feat!
Step One: Paper Prototype
(Before I continue, I want to thank Heather Gunn for leading the project during its early months and providing mentoring and advice that contributed enormously to my work.)
My first task was to create a paper prototype. If the game wasn’t fun on paper, it wouldn’t be fun on the screen.
I got the team together to brainstorm. We agreed that we wanted the game to feel ‘tactical,’ so character position would need to matter in some way. We settled on placing characters in a 2×2 grid, with the front row gaining an attack bonus and the back row gaining a defense bonus. Then we brainstormed a bunch of mechanics and matched them up into character archetypes.
Fun fact: At this stage, we wanted characters to have different abilities depending› on whether they were in the front or back row!
I spent some time designing and balancing the characters and abilities, fiddling with numbers with the goal of creating a game that could be played (and more importantly, understood) with cards on a table and some dice. So naturally, the next step was a studio-wide playtest!
I created a PowerPoint presentation with every character as a separate slide, then printed a bunch of copies of the whole presentation with four slides to a page. Now we had a card game.
To play the game, I gave every player a pile of cards and asked them to make a team out of four of them. Two players would face their teams off against each other, calculating turn order with card initiative and rolling dice to determine damage and whether or not special abilities would proc.
Everybody had a good time. The playtest was a success!
…except for a few issues. There were several mechanics that players (and I) forgot about in the midst of playing, like (importantly) that the abilities would change depending on the placement of the characters.
Wanting to err on the side of the combat system being easily understandable, I cut out any mechanics that people forgot about over time. Character abilities were simplified to one per card, regardless of placement.
Step Two: Unity Prototype
The next step was to build a prototype using Unity. The studio actually built two separate prototypes at this stage: One to demonstrate the final look and feel, and one to experiment with mechanics, timing, camera angles, etc. I worked with a programmer on the latter.
The Unity combat prototype was a lot of fun to build. We set up a scene where every character was represented by a different colored capsule with a little label above it. We recreated all of the characters from the PowerPoint cards, with all their stats easily adjustable.
I spent about a month playing around with this demo, using it to determine the right speed for the characters to move and the right ‘time to kill’ values to keep battles strategically interesting without dragging on for too long.
After the basics were down, we needed to really start balancing out the game and making sure we had some real rock/paper/scissors relationships between different teams. To do this, we built some tools that allowed us to create pre-made teams and then run through battles multiple times as quickly as possible with every combination of teams, dumping the values in CSV format. We imported those values into Excel to find the variance in win/loss values between each team and then rebalanced accordingly.
Step Three: The Real Thing
At some point, we got to do what every game team with a prototype wants to do: We threw out the prototype and started over.
Because the combat system was fully automated, we could run all of the combat logic on the server and just send the client a timeline of what happened. This had several advantages:
- Cheating in combat is literally impossible
- We could change or add rules or mechanics on the server without updating the client
- Battle simulation was nearly instantaneous
That last point allowed us to recreate the Unity prototype’s mass combat simulation feature on the server, and it ran even faster. In fact, I could submit a CSV of pre-made teams, request 10 battles between every combination of 20 teams, and get back a CSV of results in just a few seconds.
With that tool, the real work began.
For many months, the majority of my time was spent in a single spreadsheet, filling in stats for hundreds of characters.
The first step was to calibrate an internal combat power rating for each character that we could use as a guide for character stats. I had flags in the spreadsheet for each type of thing an ability could do, like how many targets it attacked, whether or not it applied status effects, and the character’s speed. Each of those acted as a modifier to its power rating, which started with damage as a base value. After setting up all the formulas, I ran the simulator with some expectation that characters and teams were evenly matched, then had to change all the weights when (for example) characters with AOE attacks were clearly far better than all others and needed their damage output reduced more than expected . Once these values felt more or less correct, it was time to move on to mass-producing characters.
Here’s the process for creating characters:
- Start with a list of all Dragon Age characters, from companions and other important named NPCs all the way down to the generic ‘fodder’ characters like Hurlock Archer and Nug, then pick a character to put into the game
- Propose (to the design team and to BioWare) their rarity, lore faction, color faction (our version of an elemental faction system), and ability
- Take a first pass at stats for the character and then define how their ability works in XML
- Put the character in a team with other characters of the same rarity and run the aforementioned combat simulator to make sure they’re not over- or under-powered
- Rinse and repeat
There was, of course, coordination with the art and sound teams for the second step. Characters needed to be budgeted based on, for example, how visually different the four tiers of each character needed to be, or whether or not they could use an animation rig we had already made.
Oh yeah, that’s right – because we were modeling the game after Japanese mobile CCGs, we borrowed and adapted the character evolution mechanics as well: Each character had four tiers, and could be ‘tiered up’ by sacrificing duplicates of the same character. So, we needed four versions of every character. With over 100 characters at launch, that meant 400+ rows of stats to balance in the spreadsheet and 400+ character models in the game. (Fortunately, Capital Games abandoned this system in the next game, Star Wars: Galaxy of Heroes.)
There were actually more lines in the spreadsheet, though. We ran into an issue when balancing PvE: We wanted to re-use the ‘generic’ Common and Uncommon characters (like city guards, random Darkspawn, etc.) in more difficult battles, but the only way to make them a challenge was to boost their character levels into the hundreds. The player level cap was much lower than that, so it just looked… weird.
The solution was to duplicate every “fodder” unit to every rarity, up to Legendary. There were about 50 of these, so duplicating them for four or five additional rarities, four tiers each, created another 800 or so character records in the spreadsheet! (At this point, we had long passed the point of Google Sheets being able to keep up with this massive spreadsheet, so it was moved to Excel and I rewrote my Javascript XML exporter in C# and built it as a command-line tool. Yup, internally, Heroes of Dragon Age’s characters are defined with thousands of lines of XML!)
Fortunately, because these characters were never going to appear in PvP and PvE balance doesn’t have to be nearly as precise as PvP, I didn’t have to run these hundreds of characters through the automatic simulator.
Epilogue: Live Service Time
Once the game was launched, the next logical step was to start releasing more content.
Since I was the person responsible for designing and integrating characters, by default I was the person to get new content into the game post-launch. This eventually transformed into a new role as Live Services Producer, and I was given an entire team to train to do the job that I had been doing by myself for about a year. And for another year after that, the Live Team (as we called it) iterated and refined our process from a slapshot “we don’t know what works so let’s just try stuff” approach into a lean, consistent machine that generated consistent revenue despite (eventually) a complete lack of client update support.
About a year and a half after the game’s launch, the studio decided it was time to pull its Heroes of Dragon Age team into the Star Wars: Galaxy of Heroes team and transition live services duties on Heroes of Dragon Age to a team in another location. I and the game’s Executive Producer at the time (now at Boss Fight Entertainment) interviewed and hired a few game designers, and flew the most experienced one to Sacramento for a few days to learn everything possible about running Heroes of Dragon Age. A few weeks later, the Sacramento office physically reorganized – out of the three major working areas, the one that had been devoted exclusively to Heroes of Dragon Age for about a year would become the artist room for Galaxy of Heroes, and the formerly Heroes of Dragon Age team migrated downstairs to join the slightly smaller live services-focused half of the Galaxy of Heroes team.
To learn more about what it’s like to run a live service game, check out my writeup of my time as Live Service Producer for Star Wars: Galaxy of Heroes.