Behind the Scenes of Building a Star Wars FPS - Video Game Engineering Stories

Behind the Scenes of Building a Star Wars FPS - Video Game Engineering Stories - Interview with Charles Roman (Technical Director, Respawn Entertainment)

Video game engineering is a community that demands a lot of dedication, and it’s difficult to get into.

Yet it’s super exciting for many of us, since video games have inspired many careers in tech.

In this blog post, we take a deep dive into video game engineering via leadership stories.

Charles Roman, Technical Director at Respawn Entertainment, gives us a sneak peek into laying down the technical groundwork for a Star Wars FPS currently in development with no official title yet. He touches on topics from getting to the company, to when and how he requires his team to write engineering proposals. Written based on episode 4 of the Level-up Engineering Stories podcast hosted by Karolina Toth.

This post covers:

• The path to Respawn Entertainment
• Adapting to remote management
• Learning remote management
• Leader onboarding in remote
• Hiring video game engineers
• T-shaped engineers
• Learning habits
• Soft skills
• Process changes
• Growing leaders
• Cross-functional collaboration
• Support
• RFCs
• Utilizing feedback in video game engineering
• Customer feedback
• Learning from competitors
• About Charles Roman

How did you get to Respawn Entertainment?

Like many people in our industry, I was getting a lot of outreach messages on LinkedIn, but I was happy with my position at Riot Games, so I rarely even took a second glance at them. There were only a handful of studios that could have piqued my interest.

Respawn Entertainment was one of the few, so when they reached out to me, we started talking. I got an understanding of the position they were looking to fill, and I got to know the project during our conversations. The position became a no-brainer.

I’d hired and built my team at Riot over the years. It consisted of 13 software engineers total, but I was only managing half the team at the time. They were a fantastic group of people, so leaving them was difficult, but this opportunity at Respawn was too good to pass up.

Taking on a technical director position was the next step for my career. When I joined, we had seven engineers on the team, and it was my job to scale the team to over 20 people by the end of the year. We’re currently at 16, so we still have open positions.

At Riot Games, technical leadership and engineering management is split into two domains, but I always preferred doing both. I like staying close to the technology realm, so my current role is a better blend of the two worlds for me.

How did you adapt to remote management?

Learning remote management

The pandemic opened my eyes to the possibility of being a leader on a fully remote team.

I always felt like there was too much metacommunication going on in personal interactions to move everything to remote, like body language, eye contact, and other intangibles. Getting stuck in the pandemic forced me to hire and build relationships with people remotely, and it made me realize that remote management works.

My current team is fully remote with people from all over North America. Building relationships and building trust in a remote environment have been my biggest challenges recently, as I’ve never met any of my team members in person. We’ll try to set up an offline get-together somewhere, but that will be the exception rather than the rule.

Leader onboarding in a remote team

Before I came to Respawn, it had been a long time since I joined a new company. I’d been working with the same people for about seven years, so I planned my leader onboarding carefully. I read the book, The first 90 days by Michael Watkins, and used that to lay out my first period at Respawn.

First impressions are important when you join a new company, because you can step off on the right foot or the wrong one. I put a lot of emphasis on that. I was hired to lead an established team with some people who had worked together on previous projects, which created a delicate situation.

I started out in information-gathering mode for the first month to avoid making my team think I wanted to change everything around them. I was looking to understand how they worked. They had been successful without me, so I wanted to let them know that my goal was to gather information and understand how everything worked in the company.

I hold weekly one-on-one meetings with all my engineers. It’s essential to build connections because in a remote environment, you can’t meet people in the kitchen to grab a drink. You have to keep making time for them so you get to know each other, and to give them a chance to regularly discuss any topic.

How do you handle hiring video game engineers at Respawn?

When I arrived, the hiring process at Respawn wasn’t getting me the information that I needed to make good hiring decisions. I had to address that as soon as possible.

There are three pillars to hiring that I wanted to build into the process. Changing hiring is a big deal, so I started by explaining my reasons for these changes to everyone involved to get buy-in.

My goals were:

1. Making good hiring decisions
2. Inclusivity
   
3. Prioritizing candidate experience

T-shaped engineers

I’m generally looking for T-shaped engineers.

The top of the T symbolizes the breadth of an engineer's knowledge, like familiarity with different languages and stacks. The depth of the T stands for their specialization, like rendering, graphics, or networking. We call it broad tech and deep tech.

We have a take-home test in the interview. So far we’ve found that the shortest we can make it is about four hours. We have the candidates bring it with them to the interview, and we do a code review together. I like this process, because it makes interviewing so interesting—it doesn’t even feel like work.

The idea is to demonstrate what it would be like to work with us. Our engineers have to be able to talk about their code and explain how they came to a solution.

Learning habits

Software engineers deal with new tech all the time. When you’re hiring engineers fresh out of college, I always try to understand their process for learning new things.

In interviews, I ask people to walk me through the process of their most recent learning experience. It doesn’t need to be related to engineering—snowboarding or a new hobby you picked up is just as good. There’s no right or wrong answer.

I’m interested in seeing the method each candidate uses to learn new skills, because it can be different for everyone. Some people are visual types, others read books, while others dive in at the deep end and come out with new knowledge on the other side. I do this to make sure that when they need to learn something new, they know how to set themselves up for success.

For example, I like to learn by reading books, watching videos, and getting as much knowledge as I can before I start practicing.

I’m looking for curiosity and the willingness to learn in our candidates. (It's the top hiring criteria for engineers based on the State of Software Development 2022 report.) I want my engineers to dig into everything and figure out what makes things tick instead of just taking everything at face value. Whether you’re working with JavaScript code or the Unreal Engine, you can take a deep dive into the tools you’re building on top of.

Naturally, I don’t expect everyone to become an expert at everything. I just want to see what piques the curiosity of my future colleagues.

Soft skills are essential

In the past, I’ve seen leaders prioritize the coding side of the interview process. Currently, I feel like I found a good balance between interviewing for soft skills, personality, and technical skills.

The game industry demands an extreme amount of cross-collaborative work. You have to work with other people from different disciplines, so the ability to communicate your ideas and gather information is essential.

What processes have you changed since your arrival?

I like to compare the role of leadership to a machete in the jungle. You clear a path for the teams and give them clarity, so when they’re doing their job, they have clear answers for all high-level questions.

Growing leaders

We’ve been having growing pains as we go from 30 people to 60, and we have plans to scale up to about 180. As we reach different stages in size, we need different communication methods to keep building a great product rather than fall apart. We had to have more discipline with our processes, like planning, prioritization, and estimation.

Currently, I have more work than I plan to take on in the long run, but I’m already mentoring one of my engineers to lead a team. I've broken up my team into smaller teams based on sub-disciplines, like gameplay, tools and systems, artificial intelligence, rendering and networking. At some point, each team needs to have its own lead.

I’ve been working on empowering the people on my team because I want to be able to delegate leadership tasks to them. I’ve been trying to identify potential leaders on the team, building them up and moving management tasks over to them.

Cross-functional collaboration

Game development is a cross-disciplinary process. You have artists, designers, and engineers, and you have to keep them aligned. For example, an artist may do something that impacts the performance of the game, so you have to get in front of these problems.

Cross-functional collaboration is difficult to manage with a team of 60 people. You can't have a conversation with each of them, so you have to rely on your engineers to gather information on the ground level. You need to create an environment for that and focus on building relationships with other department heads, so the information flow works on each level.

Support

Artists and designers have different expectations, and they work in different ways. It keeps everything fresh for me, but it also poses management challenges.

When I arrived at Respawn, the team was structured along the lines of disciplines. Artists, designers, and engineers were doing their thing separately.

I don’t like that type of organization for video game development. I pitched the idea of forming cross-functional teams, where we organize the work around features, like the movement system, weapons, etc.

This setup allows people across different disciplines to talk more frequently than they might otherwise. Keeping each discipline together forces people to put extra effort into communicating with their cross-functional peers, who they’re actually building a feature with.

Keep in mind that organizing around features isn’t a silver bullet for every company.

I proposed this, we rebuilt organizational decision making this way, and it solved certain issues, but it also caused others. In this type of organization, engineering is spread across 10-12 pods, so it’s more difficult for each department to stay in line. You have to build processes to enable engineers to communicate with each other.

RFCs

A process I implemented to help engineers communicate across different pods is RFC, which stands for “request for comments.” We’d been doing this a lot at Riot Games. The idea is to write a proposal including the problem, your proposed solution, and the alternatives you’ve considered.

Engineers will often look at a problem and go with the solution they know best. This can be efficient, but at the early stages of setting up a project, the systems you’re building tend to be foundational. Going with the most obvious solution could hurt you in the long run.

RFCs force people to leave their comfort zone, consider alternatives, write a document, and discuss their reasoning with other engineers. Going through that process can get you alignment on the team, and it can get you to the best solution.

We also have an approval process on top of this, where specific people have to sign off on certain solutions before you can move on to the next step. We don’t do this with every feature, but when it comes to big projects, I may ask the team to do RFCs.

Utilizing customer feedback and learning from competitors

Customer feedback

UX research team

We have a user experience research team at Respawn. They work with us to figure out what questions we need answered from a large play test, so we get value for the work we put into it. On the Star Wars FPS, we’ve done one big test so far, but it was still internal and far from the alpha stage.

Setting up a large beta or alpha test comes with a large cost, so you have to balance that with the benefits. Making a demo is extra work that you could put into scheduled tasks. Preparing demos all the time can set development back in the long run.

If you're a Star Wars fan, you can find free Star Wars icons for your projects.

Internal feedback

In game development, your customers are players, and a lot of your employees are players as well. It’s an obvious advantage, so we use ourselves as the first line of defense. We’re continuously playing our own game, giving feedback about the systems.

When we need feedback, we set up channels to collect feedback from the team. For example, we set up Slack channels with different integrations for different rounds of feedback.

Competitors

Playing other games

In the market of first-person shooters, there are plenty of competitors. We'd be stupid not to look at other FPSs, and see what they're doing. On the other hand, we can’t have knee-jerk reactions to other games.

We have clear goals and ideas for our game. We’re paying attention to any innovative solution coming out and trying to learn from that. Most of our engineers love video games, so it's not a big ask to tell one of them to check out a hot title; they’d probably play it anyway.

For instance, EA and Respawn give out a stipend to support employees in purchasing games.

Talking to other studios

We’re talking to other developers at game industry events. For example, the GDC (Game Developers Conference) just happened, which is a great place to pick up new ideas and techniques. It helps everyone in the industry build on each others’ experiences.

There's room for a lot of games out there with many niche audiences. In my experience, it’s not cutthroat competition among studios. One movie getting released doesn’t take away the air from another movie, unlike tech platforms, where Facebook wants everybody to use Facebook.

About Charles Roman

Charlie is currently the technical director at Respawn Entertainment working on a Star Wars FPS with no officially released title yet.

Previously, he joined a startup called Radiant Entertainment. He helped build a free-to-play fighting game called Rising Thunder, which ended up getting acquired by Riot Games. He stayed at Riot for six years, working on a project called “Project L” as senior engineering manager.

Outside work, he loves playing video games, and getting away from his computer biking, hiking, and camping with his family. He’s taken time during the pandemic to continue learning as a woodworker and try his hand at kombucha brewing.