Hello everyone and welcome to the third installment of our Developer Interview Series. I’m Sitri, a Community Intern here at Warner Bros. Games Boston, and together we’re discovering the roles inside the team that creates Game of Thrones: Conquest!
Thank you to everyone who chimed in within the community about our last interview with our Production team. It was great hanging out and chatting with folks on Discord about this last month. Make sure to stick around until the end to learn how you can take part in our next installment!
This month, we’re doing a deep dive on our Systems Design team with Hexx, Tank, Crux, and Arctic!
Game design is broken out into many sub-disciplines such as Economy, Live Operations or Technical Design. Systems Design specifically deals with the translation of high-level game concepts into complex systems of pacing, balance and more. From proposal to implementation, their work cascades out to every other department as they begin to execute on new features and core game mechanics.
Simply put, Systems Designers set the intention and adjust the numbers to develop the best game experiences they can for our players in Game of Thrones: Conquest!
…. And now let’s get into the questions!
Q: How would you define your discipline and the work you do?
Tank: Systems Design is very involved in the rules and balance of the game. A lot of attention and time is given to combat, stats, and how different mechanics interact with each other. New game mechanics and features are also planned out and integrated with the feedback of other disciplines. In addition to planning things, there’s a lot of data to put in about what’s been designed.
Hexx: Systems Designers walk the line between math nerd and psychologist. We need to assess what kind of features and updates satisfy both the needs of the players and the needs of the development cycle. There is a lot of deliberation and negotiation as we try to make viable and sustainable new features, while also keeping all the existing features up to date.
Q: What’s your “day in the life” as a Systems Designer for GOT:C?
Tank: A day in the life of a Systems Designer starts with checking emails and our work chat, figuring out what needs to be done first and what systems are being worked on. Tasks for the day are usually either writing out documents on new features, additions to old features or putting in the data for them.
Hexx: It depends on the phase of development. During pre-production, it’s a lot of research, document writing, and iterating on feedback from other developers. During development, it’s a lot of excel work and finding compromises to issues that allow you to maintain the integrity of the feature while also hitting deadlines.
Crux: I plan my day depending on the number of meetings that are scheduled. Some weeks there are a lot of meetings, other weeks not so many. That all depends on where various teams are in their development cycle and whether they need game design input.
I’m currently working on a new feature that is still early in development. Although the system is planned out on paper and other disciplines have just started working on it, there’s still a great deal of design work that needs to happen. This specifically means my time is spent in Excel to work out numbers, progressions, what players can achieve from it, and more.
Collaboration is also important. In addition to collaborating with other designers, I work closely with Product Management to ensure that new features support their goals for the game. When working on new features, engineering, producers, artists, QA, and others work together very closely. When it comes to designing new Heroes, I also work with the Community team (who offer feedback on design, as well as creates articles for players.)
Q: How does your role differ from other Design disciplines?
Arctic: The Systems Design team is, in part, the idea factory for features big and small, and is responsible for taking those ideas from pen and paper through development. Those features may eventually get handed over to the Live Operations team, the tip of the design spear for building out fun new experiences for the player to participate in. The Technical Design team is responsible for making the rest of the design team’s lives easier. If there’s a way to automate something that a designer has to do on a regular basis, then it’s Technical Design’s responsibility to pinpoint these opportunities and make them happen.
Q: How does a new idea for a feature work, from proposal to implementation?
Tank: A new feature usually starts as a goal of some kind. For example, Red Temple was created to help players get back into the game faster after getting zeroed. It’s easier to recover resources and the rest of your army if you can quickly get some troops back to go gather and fight.
This goal, and idea, are put into a proposal, a rough document that explains the idea in some detail. This will go over the goal, how it will be addressed, and the basic flow of how the system will work.
From the proposal, after some approval from other teams, a design document (also known as a spec) will be created. The design document is a larger, more detailed explanation of exactly how the system will work. It also integrates work from our UI designers, our art team, and other disciplines.
Eventually, the design document gets picked apart and divided into work for all the disciplines involved in the feature to work on, and there’s a lot of iteration to go through as other designers, artists, and engineers get deep into tasks.
Crux: The process for getting an idea turned into a feature and added to the game has changed throughout the years. In the beginning, it all starts with an idea that can be turned into a short proposal. It gets reviewed by the design team and other teams, such as the project managers and directors. It often gets weighed against all the other asks for the game. A lot of ideas die on the vine and that’s just the process you have to get used to, as a designer.
An idea may then move to the spec phase, which is a more detailed writeup of the design, but it doesn’t necessarily have to require all the specifics for the feature.
At this point, the feature can change substantially depending on feedback from the various teams. For example, the events team might see an opportunity where aspects of the system could be used for an event, or an engineer might offer a suggestion on how to do something better. There’s an opportunity for the feature to see a lot of iteration on paper before anyone starts to implement it. Just having a spec completed doesn’t mean it’s ready to be implemented. Sometimes priorities change midstream, feature lineups can shift, or resources are diverted to other things.
But if the spec is complete and the stars align, the feature goes to a pod of implementers to work on the feature. A lot of people get involved at this point to schedule the feature: UI/UX works on wireframes, engineers plan server/client architecture, designers and a project manager nail down specifics with game economy and numbers, artists work on the artwork, QA on test plans, and producers keep it all moving efficiently and keeps the team organized.
Q: What are some projects that you’ve worked on within Game of Thrones: Conquest?
Tank: One of the earliest systems I worked on for Game of Thrones: Conquest was our Troops and our Combat system. Figuring out how our troops could interact with each other and use combat stats to create the battles and results that we have was quite the task. These systems are something I still keep an eye on today to see how we can use them creatively in new ways or to mix things up with new stats.
A lot of work is also done to try to maintain game balance with combat stats and our systems. Tasks such as designing Gear sets, Trinkets, and Armories come up every month. A lot of player feedback, in addition to our internal data, is used to help decide what stats we decide to use.
Crux: I’ve been working on Game of Thrones: Conquest since early development, so there are a good number of systems that I’ve worked on: Troops, Combat System, Monster Spawner, Seats of Power, Tyrion Quests, City Buildings, Dragon Talents, Research Trees, Allegiance Gifts, and Heroes.
Combat and Troops are probably the most ‘core’ systems I’ve worked on. I did the initial design work on it, which involved a lot of crunching on numbers, meeting with engineers and artists, and playtesting. Before the game was released, another designer took ownership of those systems and made additional adjustments. Even though a system might have an initial owner, that doesn’t necessarily mean they will forever be the owner. It’s not uncommon for a system to be handed off to another person, as tasks and owners can shift over time. For example, I handed Combat and Troops to another systems designer so I could shift my focus to other systems (Seats of Power, Allegiances, and Tyrion Quests). I was handed Tyrion Quests from another designer, as they gave more focus to crafting and game economy. Everything we do is highly collaborative, and effort is shared based on schedules and resources.
Arctic: One of the oldest features I worked on would have to be Expeditions. It’s the feature I cut my teeth on. There was definitely work prior to that feature for me, but that was the first big chunky experience I got to take from start to finish. Some of our earlier players might remember a rather strange Expedition involving a “Sir Pants Alot;” stub (or place holder) data that I spent entirely too much time writing, which, needless to say, was never supposed to see the light of day, but of course did. That one was on me. Oops.
One I’m particularly fond of was KvK, or Kingdom vs. Kingdom. This was a feature I got to work alongside a more senior designer who showed me the ropes in terms of what building a massive feature required. I built out a spec alongside the real one and helped to shepherd the system out the door. It was fun to see that one go live and see the reception it got.
Hexx: The most used system I have/am working on is Seats of Power. It’s the cornerstone of our game and something we want every player to be able to participate in. More recently we’ve taken on a task to update and improve the system given how gameplay metas have evolved. We’ve planned various iterative designs to hone in on something that maintains what players like about the feature while also giving them something new and exciting.
Battlegrounds is the new hotness and something we are investing a lot of time and effort into. It will allow us to create new/interesting combat experiences that we would otherwise be unable to do within the current live kingdom environments. We want to provide players a safe environment where they can engage in strategic/social content without having to worry about the persistent dangers of life in Westeros. Additionally, Battlegrounds allow us to explore new locales and experiment with new types of cooperative and competitive gameplay.
I’ve also had some fun entering stub (or placeholder) data and strings (text) as we started working on this feature. For a while, we had new Battlegrounds Heroes who were best in slot for Traps and Siege. Also, the Iron Gate: “It’s a gate… made of iron.” Stub data allows us to start testing as early as possible, but we obviously put a lot more thought and care in before we deliver the final product to players.
Q: Does player feedback tie into your work as a Systems Designer?
Crux: Player feedback from our Discord community and other sources is an incredibly important factor for us, especially with our monthly Hero and craft gear plan. I rely heavily on our Community team to help curate that feedback.
Hexx: Player feedback is the impetus of everything we do. Just because the math is right doesn’t mean it’s a good experience. Plus, there’s only so much we can predict during development. We take a stab at how we think players will utilize a system – but once it goes live, we really get to see the experts put it to use and we learn from that. Many times, we adapt the system to how players are actually using it vs. what we expected.
…. And now let’s learn some fun facts about the team!
Q: What’s your favorite troop type?
Tank: Siege!
Crux: I have to say Cavalry because I like their faster march speed.
Arctic: My favorite troops are all sitting in the med tent currently….
Hexx: Siege – underappreciated, but nothing is more satisfying than to send another player’s Keep packing!
Q: If you were a stat, what would you be?
Tank: Light Capacity – saving troops feels pretty good.
Crux: Number of Times Zeroed – because I’m sure I hold the record.
Arctic: Troop Defense.
Hexx: Dead to Wounded.
Q: Who’s your favorite Game of Thrones character?
Tank: Hodor!
Crux: Lyanna Mormont. She’s fierce, brave, blunt, and not into small talk.
Arctic: Tyrion, ‘cause he drinks and knows things.
Hexx: Oberyn Martell – I just love the Martells’ revenge storyline.
Q: What animal could you beat in a fight if you were unarmed?
Tank: Canadian Goose. I can see them being mean enough to start one, but they’re not too big.
Crux: As one who appreciates the strength, resolve, and craftiness of animals, I’ll opt to flee from the fight.
Arctic: A squirrel, if I could catch it.
Hexx: 3-toed Sloth. Maybe the only creature that’s slower than me.
We hope you enjoyed this look into Systems Design!
Stay tuned over the coming months as we interview other disciplines and learn more about the process of developing Game of Thrones: Conquest.
What departments would you want to see interviewed? Do you have suggestions for future questions? I’d love to hear your input, as well as any other feedback or suggestions you have for the series!
Tag @Sitri on Discord in the #general-chat channel, or send a PM, and let’s chat!
