Justin Gibbs
Just like everyone else in our industry, I got into game development because I love games. I always thought that I would be a programmer because I liked math and science. I migrated from Dallas, TX to the University of the Pacific in Stockton, CA to chase my dream of making video games by getting a degree in computer science. The main reason I ended up in California, in particular, was because I also wanted to play collegiate volleyball. I studied hard and did well in my computer science studies, but it became apparent after two years that I would be better off playing club volleyball rather than competing for a spot on the Division 1 team.
I enjoyed computer science and club volleyball so much that I decided to stay an extra year to get a master’s degree and play one more year of volleyball. The first time I thought about being a producer was during that last year. I got injured and was forced to coach the entire season. Our team hosted the league championships and won it all on our home court. I enjoyed helping my friends and teammates accomplish something, beyond what we thought was possible, more than I enjoyed being on the court. At the end of the year, I attended the Guildhall at SMU to get a Masters of Interactive Technology in Digital Game Development with a Specialization in Production and began my career as a producer.
My sports background is important to me and heavily impacts my production style. Many aspects that are important to game development are also important in sports like conflict management, goal setting, accountability, etc. I approach production the same way I do coaching volleyball, and that’s by focusing on developing the fundamentals of the team in terms of development, teamwork, and communication. My greatest asset as a producer is my soft skills, and my ability to communicate about those fundamentals.
Production Philosophy
Game development, as volatile as it is, requires an approach that can deal with the ever-changing landscape. Our priorities are always shifting, whether it’s because we find gameplay that’s fun, expectations or requests from clients change, or new contracts come in. My approach to problem-solving in game development is simple fundamentally and is the same as my personal values.
People working together can accomplish more than they can alone, and if people constantly work on improving themselves, their teammates, and their work, then they can respond to almost any challenge with gusto and fervor. I take the approach of coaching and helping developers collaborate and iterate in efficient ways towards common goals to get the most out of the teams I work with.
Fortunately, Agile development shares a lot of the same underlying principles, and Agile, combined with Scrum and a little bit of Spiral methodology, make up my production approach. I’ll share below some of the pillars I think a team needs to follow to cultivate a collaborative and iterative environment when developing games.
PUBLICIZE TASKS
Whether on stickies or on some sort of project management software like Jira or Hansoft, tasks need to be public so that each team member is aware of the work being done across the team. Tasks that are public give team members the ability to check those around them against what they're doing. This helps them hold one another accountable to the work they are committed to completing. It also helps everyone understand the current status of the game.
SET SHORT DEADLINES
Working in short incremental bursts helps keep the team focused on the immediate task at hand instead of the monumental amount of work ahead. An old programming adage is that there are no big problems, just combinations of smaller problems. If something goes wrong, it also becomes easier to pivot at your deadlines since they are closer together. With shorter deadlines, it’s easy for the team to take some time to evaluate themselves and the product more often, leading to more improvements over time.
GET SOMETHING WORKING QUICKLY
In order to take an iterative approach with a game, there needs to be a first pass, so we can see what needs to improve. I prioritize getting something working on screen very highly. From there, it becomes a lot easier for people to communicate what’s in their head and how to move forward. The same is true for teamwork. If I can help a team define how they’ll work together early, we can then work together to improve it many times by the end of a project.
FAIL FAST
Making decisions on game design and production methodologies can be a large task. Trying a lot of things out quickly provides a lot of value because we can better understand what works and why, as well as what doesn’t work and why. If I can teach a team to follow this principle, we can quickly make decisions about what we want to cut or keep. If a team believes that failing is okay as long as we fail fast, they’ll arrive at solutions quickly, and will better understand the problem space.
CLEAR TEAM STANDARDS AND EXPECTATIONS
Holding someone accountable is scary for a lot of people, and it’s easy to appear aggressive or emotional. Having a clear set of expectations and standards can help ease that problem and encourage teamwork. It’s a lot easier to hold a teammate accountable if we’ve talked about expectations and agreed upon a method ahead of time. Standards include descriptions of behaviors that are rewarded and behaviors that deserve reprimand. If we have a blueprint of how we’ll work together, it smooths communication and helps encourage feedback.
GATHER DAILY WITH THE TEAM
Game development is really fun. Everyone that’s on a game development team has at least one common interest in video games, and it’s easy to get them to know one another simply by bringing them together. More often, culture develops faster when the team is interacting and getting to know one another. When we meet, it also provides avenues for helping each other or giving feedback which I believe are important aspects of high-functioning teams.
