Andrés Ortiz Suárez on Game Development, Technical Leadership, and Shipping Real Games

Context

Andrés Ortiz Suárez is a game developer, lead programmer, and lead designer with experience across narrative games, action-adventure projects, RPGs, and full production teams.

His background includes work at Deck Nine Games, Airship Syndicate, Naughty Dog, and other studios. His shipped projects include Life is Strange: Double Exposure, Wayfinder, Ruined King: A League of Legends Story, Darksiders Genesis, Battle Chasers: Nightwar, and Uncharted 4: A Thief’s End.

What makes this interview especially interesting is the mix of programming, design, technical leadership, and shipped production experience. Andrés has worked not only on code, but also on how features, systems, teams, and creative decisions survive real game development.

This interview is about game development from the inside: how teams move from ideas to playable systems, how design and engineering work together, what breaks during production, and what helps games actually ship.

MAIN TOPICS

Game Development
Game Production
Prototyping
Scope Management
Technical Leadership
Design & Engineering Collaboration
Game Development Planning
Indie Game Development
Shipping Games
Team Management

Interview

Q: You have worked as a programmer, lead programmer, and lead designer across different types of games. How has your view of game development changed over the years?

I feel like over time, my interpretation of what priorities should be in game development have changed drastically. When I knew relatively little about the complexities of making a game, I believed what was most important was telling a good story – I subscribed to the notion that games are stories, and the best ones are the ones that tell a memorable story.

To this day, I consider myself a storyteller – I still think this is important. But my priorities have radically shifted.

I’ve learned a bitter truth, that someone once put very eloquently: “Games hate being made.” Any time a game ships successfully, it’s a small miracle.

For this reason, the focus of the best teams in the industry has been on successfully shipping games as a team – repeatedly, consistently, and with an eye to always improving their process. It’s not, contrary to my initial beliefs, on staunchly defending an existing story, or questioning every proposed change.

Good teams move fast, test often, are open and quick to change, and are candid about what isn’t working. And above all, they ship games together, and get better at it every time.

Your goal shouldn’t be to make the best game ever made – it should be to build the team that will eventually make the best game ever made.

Q: You have a rare mix of programming and design experience. How does a technical background change the way you think about game design?

I’ve always felt like an unusual engineer. I care about code – writing elegant code, understanding the underlying systems I’m using, and constantly finding better software engineering patterns and being unafraid to go back, address tech debt and refactor.

But programming is also, to me, a means to an end. I program because there are things I want to make real, or game design I want to make work.

Conversely, my technical ability means I think about game design very systemically. I break down elements in any design into abstract technical systems, and this helps me design with possible technical solutions in mind; and when I’m programing systems, I have strong instincts about what kinds of features a system might eventually need, leading me to architect that system in a way that’s much more easily extensible.

It also gives me a unique edge in problem solving with around design needs – while another engineer may struggle with a specific design feature request because the system doesn’t work the way the design team is asking it to, I can jump in with creative solutions that circumvent system limitations while still achieving the design goals we need.

My experience has given me perspective over architecture and the intentionality of design alike.

Q: When a game idea moves from paper to a playable build, what usually changes first?

Unfailingly, any time you move a design from paper to playable, there will be things you got completely wrong. How a space or a moment feels, how a script plays out, how players naturally move through a space.

Moving to a playable prototype as quickly as possible is critical for validating or disproving the many hypotheses you’ve made when planning the idea.

If it’s a level, the flow will probably be wrong. If it’s an ability, it will probably not feel good for some reason and need animation, effect or input changes. If it’s a cinematic, it will probably be too slow, too long, or be unclear, and will need iteration.

I have a mantra I’ve started to share with designers, learned from my years in art school: “Your design documents are your sketches – they are practice. Once you start on the painting, the painting is what matters. Your sketches are not the painting.”

Documentation is important, but people often get caught up in what was written down – once it’s in the game, that is the thing that needs to be improved, and that’s what people should be iterating on.

Q: What do teams often underestimate when planning a new game feature?

Taking the time to get it right!

Regrettably often, teams will plan a feature, but push out its initial development until very late in production. The assumption is “we’ve talked about it and we know what we’re going to do; but it’s lower priority, so we’re moving it up on the schedule.”

The problem with this is that your assumptions about what the feature is will probably not all line up with each other, even when you all think you’re on the same page – and you’ll also discover new issues as you put in first passes of implementation.

Game development is proven in the experience, not in documents.

The more space you create between initial implementation and final deliverables, the more likely you are to have resolved those misconceptions, solidified what a feature is and made sure it’s interesting and works well within the context of your game.

Implementing it late is realistically going to lead to you cutting it later on, because you won’t have time to get it right.

Q: From your experience, what separates a useful prototype from a prototype that only looks promising on the surface?

I’ve rarely seen prototypes fail to be useful. The way I can see this failing is when someone is asked to build a prototype, but isn’t given the right questions that the prototype is meant to answer.

Before building any prototype, you want to begin with questions – about how a feature will work in context, about why it’s fun, and about what dynamics it will add to your game.

Any prototypes you build should be geared towards proving or disproving a hypothesis for one or more of these questions.

Q: You worked on projects like Wayfinder, Ruined King, Darksiders Genesis, Life is Strange, and others. Across very different games, what production problems tend to repeat?

There are several common problems that you’ll find in developing any kind of game. They tend to fall into three buckets: problems of estimation, problems of communication, and problems of foresight.

Problems of estimation are self-explanatory; teams predict a scope, make estimates about how long it will take to complete that scope, but the estimation is flawed in some way. This happens on every game.

Sometimes when these estimates are off, people can be tempted to point fingers or assign blame, but this isn’t a useful exercise – estimates are always going to be inaccurate to some degree, and while your team will get better at making estimates over time, the best way to mitigate this is well known: track how quickly you are moving.

Have some kind of heuristic that you use to measure how “big” a task is, and see on average how many small/medium/big tasks are completed by a team. Regularly look back on that velocity and extrapolate into the future – if the amount of work is not lining up with your schedule, adjust your planning accordingly.

In the same way, well defined milestones should be designed to help ensure the game is being made in a sensible order and is on track for ship. When you begin missing milestones, it’s time to reassess, cut, and adjust your timeline.

If you don’t keep track of this from the beginning of the project and make a regular exercise of making sure you’re moving at the right pace or adjusting your scope correctly, you’re going to wind up in a situation where you’re asking your team to crunch – and as a leader, this is your fault for not planning or adapting adequately.

Problems of communication are many, but the most common way they manifest is when decisions or changes are made but they’re not adequately communicated to the people that need to know in order to respond to that change.

Sometimes this is because it’s not clear who needs to know about a decision; sometimes. On Life is Strange: Reunion, we had a complex change management pipeline where changes to a script would be tracked and documented, added to a ticket, and the ticket then populated with every single downstream change this script change would require.

This was essential, as a narrative game with script changes to a cinematic requires a lot of downstream updates like animation, camera, audio, lighting, etc.. But oftentimes this process was extremely cumbersome, and still extremely prone to user error, with few established procedures in place for validating all these changes.

Lastly, problems of foresight are the problems where we fail to look ahead when we are making a decision, and discover too late that we’ve backed ourselves into a corner, with no good way of solving this later on.

One such example was on Wayfinder, where we built large open maps for players to run around in and quest content to fill them, but the core loop of our game was centered around grinding procedurally generated dungeons.

The content and tools we were building wasn’t focused on enhancing or supporting this core loop, leading to a late/endgame

Q: How do you usually think about scope control in game development?

I have a few heuristics when I consider scope control for a game. Scope will fluctuate during development; this is normal, and it’s better to be prepared for this change and able to adapt. The goal isn’t to stop change from happening, but rather to ensure we’re making decisions with the big picture in mind. When scope changes are proposed, there’s a few key questions I ask myself:

1. What is the impact of this change – the knock on effects – how many systems does it touch, or what is the complexity that it adds?

Every change will have some knock on effects. Where combat takes place may mean a collision/combat pass needs to be done in an area that didn’t need it before. VFX/color changes may require accessibility settings changes. A camera angle change may require some assets to be upscaled in order to not look too low quality when on camera. There are some changes that are ultimately trivial, and will take at most a couple of hours of a few people’s time.

When a change really starts to have knock on effects in terms of requiring new content, new AI, new voice lines, etc, the cost of a particular decision can begin to rapidly balloon. When changes like these are proposed, it’s important to evaluate how much additional work they will create so you have a clear picture of what the ask REALLY is.

1. Is this proposed change a meaningful improvement?

I tend to steer in the direction of wanting to validate that whatever change we’re making is a notable improvement to the player’s experience. If it’s trading one flavor of thing for a different flavor of thing but ultimately doesn’t really make a real difference in terms of making the player have fun, feel immersed or be delighted, it simply may not be worth doing.

On the flip side, there are some things the team is very passionate about – it may not be a notable improvement to the player, but it may improve how the team feels about the game they’re making. That can be enough of a reason to want to allow the team to do it.

1. If we are doing this, what are we NOT doing?

You can’t get something for nothing. You only have a certain amount of time or funding to make a game, and ideally you already estimated how much time it would take for you to build the content you have planned. If you’re making a change now, that is another change or bug fix you are not doing later.

A large enough change may wind up meaning a big chunk of the game elsewhere might need to be cut. Never simply accept a change in scope without considering what the trade will be – and if you don’t have a clear idea where this time will come from, that may be a reason to push back on this change.

Q: What makes collaboration between design and engineering work well?

I’ve found there’s a particular sweet spot for collaborating between engineering and design: when the design team feels supported, and when the engineering team feels like they’re able to solve problems in elegant ways.

The design team will always be trying to build gameplay with what they have available; at times they may get creative and do less than optimal things in order to get what they want working.

This is an important part of the iterative process, and it can be difficult as an engineer to want to allow unpolished prototype code to proliferate through the project.

The best approach I’ve found is to continuously find ways to give them more tools to be able accomplish their goals in ways that work within the systems we’ve built, while simultaneously keeping track of what content and features of the game are in a prototype stage and will need further work by the programming team in order to move them beyond a prototype, should we decide to keep the feature.

By the same token, engineers don’t want to feel like they’re perpetually stuck simply playing support, either – many engineers are actually very creative, and excited to try new patterns and systems.

I try to lean into facilitating the discussion between engineers and design, but letting engineers propose their own solutions and own them.

I encourage them to build modularly and anticipate problems design will have down the line, and can have recommendations about how to work within the ecosystem we have, but ultimately I want them to feel like these are their solutions.

Q: When does a game team need more technical leadership, not just more programmers?

A team needs more programmers in a very specific situation: when there is too much work that needs to be done, but not enough programmers.

Given this, you might be tempted to think that when there are teams that need support, but the programming team can never get to assisting them, this is a sign that the team needs more programmers – but that can be a trap.

The reality is the work will always scale to the number of programmers. If they’re not able to get to assisting teams, this may be a prioritization and pipeline problem, where better task assignment and flexibility needs to take precedence in order to allow engineers the flexibility to jump on to emergencies and support requests.

It’s important in technology leadership to be able to take a bird’s eye view of problems and take the time to understand why they’re happening.

It’s up to you to distinguish between situations where something about your process is hindering your team, or where you simply have too much work and not enough hands.

Q: What are some warning signs that a game project is becoming harder to ship?

A lot of things can make a game harder to ship – I’d chunk these into technology problems and people problems.

Technology wise, you want to be on the lookout for things that make the game harder to iterate on – slow build times, clunky tools.

We often have to make trade-offs during development and may sacrifice some of our iteration speed, but we should be very cognizant of these changes and make efforts to gain back speed elsewhere.

One huge red flag is instability, either in the build or in your editor tools: make sure to nip these in the bud as soon as possible, as a lack of stability can kill the ability to create content or to playtest, both of which will do incredible damage to your timeline.

People wise, many things during development can seriously affect your team’s ability to work: unclear direction or goals, constantly changing priorities, and morale drops or team burnout.

People arguing over different solutions to the same problem that feel like they’re dealing with radically different directions indicate there’s a troubling lack of clarity about what your game is.

It’s also important to remember that burnout isn’t always caused exclusively by crunch – burnout is the result of exhaustion, cynicism, and a sense of lack of agency or efficacy.

In a high stakes environment where priorities keep changing and the team is constantly getting negative feedback but not being given the opportunity to make changes, a team can wind up feeling overwhelmed, exhausted, disillusioned, frustrated and despondent eventually culminating in full burnout.

If you notice people showing these signs.

Q: For smaller teams or indie developers, what parts of game development are most dangerous to underestimate?

Scope!

Indie developers, especially developers new to indie or new to game development in general, will often severely overestimate their ability to deliver on a vision.

It’s fine to start with an ambitious vision and then pivot when you realize it’s unobtainable – plenty of excellent games were born out of needing to cut down on an overscoped vision – but stubbornly chasing after the original scope you planned on and refusing to compromise on it has been the death of innumerable indie projects.

Don’t be one of them.

It is better to ship a smaller, more modest game and learn from it, and continue to make more games as a team, every time.

Q: If a small team wants external help with development, what should they prepare before bringing in outside developers or a production partner?

You’ll need a couple of things: 1) an understanding of what it is you need and 2) a clear-eyed picture of how much that will cost.

External help isn’t like having another set of hands or more new employees. When you’re working with external teams/contractors, it’s important to have clearly scoped and defined work.

Be up front and clear about deliverables – here is what we want at the end of the contract, in what formats, and what terms are expected.

Also, it will sour a relationship if you keep changing your mind about what needs to be done. Things happen, needs change, and sometimes you need to come to your contractor and negotiate a different deliverable. Just avoid doing this repeatedly.

You’ll also want to understand the current price of things; work costs money, and as an indie studio your funds are probably limited.

Be aware of what you’re willing to pay and be realistic about what that can buy you. If you can’t pay for AAA quality work, don’t expect it!

Q: What makes a game feature feel “finished” from a production point of view?

There is a secret to game development that you should internalize early: there is no “finished”. You will get a game to 80% done during the bulk of your development timeline, and then struggle for the last remaining months to get to 95%.

Perfect is the enemy of good enough. You will always have more things you can add to a feature to make it feel even better, but at some point you have to call it and move on. Simply make sure the feature allows a player to do what they need to do, consistently. Many systems and features in your game will cause friction, but realistically, only the most egregious that actually stop people from playing your game are going to be worth your time to fix. 

Q: Looking back at your work across different studios, what has helped you most as a lead: technical skill, communication, design sense, or something else?

I’ve actually learned two things that I feel have made me a better lead, and they’re not what you might expect:

1. I’ve learned to listen. A lead that won’t listen to what people are telling them is of no use to anyone. Leads need to be able to understand what their team is feeling and what they need, so they can better direct them.
2. I’ve learned to get good at predicting what problems we might run into, and being able to plan around solving them. So much of game development is just creative problem solving, and so if you’re already anticipating running into problems, you can get very good at solving them. This then makes you better at solving problems in general, so when you encounter a problem you weren’t expecting, you’re capable at handling that problem as well.

Q: What advice would you give to teams trying to build ambitious games with limited time or budget?

Bluntly: reconsider doing that. Game development is always hard, and pushing past what is reasonable for your studio to do is a great way of ensuring you wind up crunching and/or failing to complete a game. You’re more likely to destroy the team you’ve worked hard to build. There is nothing wrong with delivering a smaller, more concise experience within the means you have. Focus on your team’s strengths and structure your game around leveraging those strengths.

If you really have no choice and this is something you have to deliver on, here’s a list of the most important things to consider, in no particular order:

• Focus on answering the riskiest most unknown questions first – try to spend more time iterating and experimenting on the things you don’t know are going to be fun or you don’t know how you’re going to accomplish
• Get a first playable of your core loop up and running as quickly as possible. Play it a lot, and figure out what is missing to land the experience you want.
• Playtest often. Daily, if possible. Get the whole team involved, and get their notes after every session.
• Make milestones for yourself outside of whatever your publisher sets for you. By when do you need critical questions answered? By when do you need specific features done? If your timeline is aggressive, your goals should be aggressive.
• If you’re consistently not meeting milestones, your team is not going to be able to work at the pace you’ve estimated. Don’t double down – be honest about it, and find a way to pivot.