I’m proud to have worked as Live Services Producer on Star Wars: Galaxy of Heroes for a little more than a year, from pre-soft launch preparation all the way through several major content releases following the game’s very successful worldwide launch.
To explain my role a bit more, the core Galaxy of Heroes team was split about 60/40 between the “feature” team and the “live” team. My job was to run the live team as its dedicated producer. Here’s what that meant:
Before Launch
Months before SW:GOH (as I will abbreviate it from here on out) launched, the team was still making fairly large changes to the game’s fundamental design. Because of this, not much time had been spent figuring out how the game was going to handle content updates outside of major client releases beyond the technical foundations required to do so.
So, my first three months on the project was spent mostly meeting with various members of the team. Having run Heroes of Dragon Age as a live service for more than a year, I was intimately familiar with much of what would be required for SW:GOH, but there were a few reasons that SW:GOH would be even more complicated:
- The process for creating and releasing characters was much more complex, as the combat system was interactive (unlike Heroes of Dragon Age)
- IP approvals were going to take a lot longer and information about upcoming new characters would be limited and highly secretive
- Upcoming movie launches meant we had to be extra careful when organizing and publishing our localization and data files
- Much more complex in-game economy
- Dealing with assets and client versioning meant someone would need to be on the hook for managing and merging branches every time a content update was released
Thus began rounds and rounds of meetings, first with designers and producers to collect requirements, then with programmers to understand how those requirements could be translated into practical solutions, then often with everyone at once to agree on process and workflows.
This may sound tedious, even excessive, but the truth is that this is essential work that we simply didn’t do on Heroes of Dragon Age, and we paid for it. Given the extremely high expectations for SW:GOH, it seemed better to start with over-engineered solutions and ease off than the opposite.
I remember spending at least three meetings in one of Capital Games’ smallest conference rooms, writing, rewriting, explaining, and re-explaining our localization organization and branching plan to several groups of programmers, QA, and designers. As someone with experience as a producer, game designer, and programmer, I was uniquely suited to figure this out. Why? Well, imagine building a workflow where localization has to be tagged as either development or production-ready for the sake of protecting confidential IP, but it also needs some distinction between temporary vs ready to be translated, but also marked with specific versions so that the localization team knows which lines to prioritize first… all with the end result of using ONLY translated text up to and including the next content release for the next published localization file. Oh, and it needed to support simple source files that game designers could easily check out of Perforce to edit whenever they wanted to.
Ultimately, we came up with a system that was easy for designers to work with, easy to submit for IP approval, easy to submit to the localization team, and could be published to our production servers with the push of a button.
And by the way, we had players who were taking apart the Android APK and tearing through the game data and localization files to find spoilers so we could not mess this up!
Technical Test
The first “launch” of the game was what you might call a “technical test” – The game was launched in the Philippines only (if I remember correctly) with the goal of collecting and acting mostly on crash and performance data. We also did a fake content update – basically, we incremented the version number on some asset and then forced the client to restart in order to download it.
A key thing to understand about the way the game was structured is that we would need two things that are not compatible with each others’ workflows:
- Client updates with massive new features that can take months of work or iteration
- The ability to add multiple characters to the game every month
Unfortunately, both of these types of updates have to be added to the Unity project and (due to how Unity handles / identifies assets) need to be tightly managed to allow multiple sets of dev and production assets to be automatically deployed to the right places for each build. This requires some very specific configuration and automation work, and had been (based on our experience with Heroes of Dragon Age) easy to break.
Fortunately, the tech test went well. We were able to do a dry run of the asset update experience AND the full client update experience so we could be confident that future updates would not result in undesirable behavior.
Content Planning
Once we were confident both in our workflow and on the technical side of things, we were ready to get serious about our content roadmap. Planning ahead and managing the design of all new content and characters was something I’d been doing on Heroes of Dragon Age, so I brought much of the process to the SW:GOH team.
When planning content for a character-collection game with a licensed IP, there are some important things to consider:
- Which major characters are ready for launch and which are saved for later?
- Are there upcoming releases from the IP that will either provide new characters or a good reason to promote an existing character?
- Are all major factions represented?
- Can players create a full team out of each major faction?
- Does each faction team have at least one viable build?
- Is each character useful in at least one viable build?
As you can see, there’s a lot to consider.
The “which are saved for later?” point is actually one of the most important for long-term planning, because the goal with a game like SW:GOH is to be able to function as a healthy business for many years. If every major popular character was available at launch, what would future content updates contain? Five years of Jawas and Ewoks and random characters from that famous cantina scene would not build a healthy business.
Fortunately, even when SW:GOH launched, there were six (about to be seven) mainline Star Wars movies, plus the Clone Wars series and one season of Rebels, and even the KOTOR series. Lots of beloved characters to choose from!
Still, we had to consider the fact that this was a gacha game (or rather, a game where characters come from loot boxes) and that the valuable characters are made more valuable by the presence of less valuable characters – thus, it’s necessary to have a lot of collectible characters that are storm troopers, clone troopers, Jawas, Ewoks, etc.
That being said, all purchases players make need to be valuable in some way, so it is vital that even those anonymous characters are mechanically useful and can contribute to viable team builds.
(Most older gacha-focused games have many characters that are essentially useless except for sacrificing to empower other characters. SW:GOH does NOT allow characters to be destroyed/sold/fused with other characters to make them more powerful, because it makes no sense with the internal logic of Star Wars. Ultimately it created a better experience anyway.)
Setting aside the literal content requirements, the other major factor is the pipeline itself.
One of the key tasks during the live service prep phase is to collect time estimates for every piece of content that might need to be produced with some frequency, from each department that touches it. How long does it take to get character concepts finished? Approved by LucasFilm? What about models? How long do animations take, if we need custom animations? Can we reuse animations for most characters? How long does it take to design, implement, test, and balance the abilities for a character? What’s the localization turnaround time? And how might there be prioritization and resource conflicts between the live team and the feature team?
And finally, a very important consideration: What’s already in progress? There were inevitably a number of characters that were either concepted, approved, modeled, or designed but didn’t make it into the original launch content of the game. Should those characters get priority on the content planning calendar?
Ultimately, all of these factors, along with holidays and other cultural events, were taken into account to build out an initial content calendar…
But that’s not the end! This is game development, after all, so no plan stays completely intact for more than a few weeks.
Every two weeks, I would invite representatives from art, design, PM, and marketing to a content planning meeting, and we’d talk through the upcoming calendar. Concerns would be aired, priorities would be discussed, data would be reviewed, future holidays and events would be considered, and we would inevitably shift things around.
This didn’t just extend to new characters; This content planning also included special limited-time in-game events, content expansions like raising the character level cap, new raids, and more.
War Room Meetings
The team at Capital Games knew from experience to expect a lot of the unexpected following the launch of a new game. To deal with this, I was tasked with running daily “War Room” meetings with a fairly large contingent of stakeholders: Executive Producer, Creative Director, Lead Designer, the PM team, Technical Director, TechOps lead, CS lead, CM, and (dialed it from Redwood Shores) reps from EA’s marketing and platform relations offices.
These meetings were always at 10am, and every day at about 9am I would clear out my Outlook Inbox, responding to whatever was necessary and flagging a few items as To-Do’s for later or to follow up on in a day or a week. Then, I would go through the daily or weekly reports with data about game KPIs, summaries of recent reviews of the game, summaries of customer service issues, and other feedback and concerns, and copy all of those reports into a PowerPoint deck to present to the War Room meeting.
I would always start with the previous day’s deck, keeping any agenda items that were still unresolved and hiding slides for areas that hadn’t changed from the previous day.
These meetings were invaluable for communicating and triaging issues in the early days of the game’s launch. Being able to discuss underperforming KPIs in the same meeting in which, for example, we might see summaries of the most common complaints coming into our customer service platform helped to put every issue into perspective. Often, the combination of quantitative and qualitative feedback would help game designers or programmers to connect the dots on issues that they suspected might become major problems but hadn’t been sure about before.
Over the next few months the agendas started to shorten, KPIs improved, CS complaints eased up, and we were able to hold the War Room meetings less and less frequently until eventually they stopped entirely. Even though it’s an expensive process, consuming about 100 person-hours of work every week, it was invaluable in bringing the team together to focus on the most important ways to improve the game and put it on a solid path to success.
Responding Quickly To Outside Events
One of the most important aspects of live service games is responding to outside events. These can include holidays, cultural milestones, and more… but very often, at a publisher the size of EA, it can simply be that Apple or Google contacts EA about some kind of special event they want to organize for their own storefront. This happened several times while I was working on Galaxy of Heroes, and was often with short notice and relatively little information.
Ironically, even though EA is literally the largest third-party game publisher in the world, compared to Apple, Google, it’s tiny… so when Apple and Google say “we’re having a special event, if you want to get featured please do X, Y, and Z by the end of the week,” the answer is generally “of course we can do that!” And then the live service team scrambles to put something together (and, in this case, get it approved by Disney/LucasFilm ASAP).
Because acquiring users in mobile games is so expensive, it’s nearly always worth it. A front-page feature on the App Store or Play Store could be worth hundreds of thousands of dollars in installs!
One of the major events I spearheaded on SW:GOH was the Apps for Earth promotion. This was an Earth Day feature that Apple requested, and the team’s offer was to run a temporarily Apple-exclusive event centered around Ewoks and the forest moon of Endor. To accompany this event, we sold Ewok packs and donated 100% of the profits from these packs to the World Wildlife Foundation.
The event received plenty of press coverage – here’s one example I found.
Grand Master Yoda Event
The crowning achievement of my time on SW:GOH was the Grand Master Yoda content release in February of 2016. Here’s the original press release:
https://www.ea.com/games/starwars/galaxy-of-heroes/news/unlock-grand-master-yoda-in-an-all-new-event
This update is a great example of my work at EA because it demonstrates the principles that I had refined with my live team on Heroes of Dragon Age:
- Make the release of a beloved character the centerpiece of the update
- Create a new PvE event that is the exclusive way to obtain that new character
- Require a specific faction of characters to participate in that PvE event
- Sell characters in that faction in heavily-promoted packs
When this release went live, the game shot way up in the iOS Trop Grossing charts, hitting (if I remember correctly) #3 in the US. That temporarily put the studio (and EA) in the same ballpark as Candy Crush Saga and Clash of Clans, the reigning champions of the top grossing charts at the time (among others). Of course, I can’t tell you how much money we made to get us to that point, but I can say that it was a Very Big Number, and a huge milestone for a studio that got started as a scrappy startup making Facebook games in a tiny office above a yogurt shop (true story!).
Epilogue
A few months later, I decided to leave Capital Games after seven years. I was proud of my work (and had a lot of friends at the studio) but I wanted to have some new adventures back in the Bay Area. This timing also coincided with my wife receiving an offer for a Clinical Pharmacist residency at a top Bay Area hospital, so moving back was a natural choice for both of us. Ironically, we moved from Sacramento to Redwood City, where EA’s corporate headquarters is located, so for my last few weeks at EA I was able to work on-site with a bunch of people I had previously only talked to on the phone! Generally speaking, my time at EA was fairly positive and I would definitely consider going back under the right circumstances.