Inside the Video Game Industry

Game Developers Talk About the Business of Play

Judd Ruggill, Ken McAllister, Randy Nichols, Ryan Kaufman

• Publisher: Routledge
• Year: 2016
• ISBN:
  9781134076581
• Edition: 1
• Topic: Business
• Subtopic: Media & Communications Industry
• Index: Business

Inside the Video Game Industry offers a provocative look into one of today's most dynamic and creative businesses. Through in-depth structured interviews, industry professionals discuss their roles, providing invaluable insight into game programming, art, animation, design, production, quality assurance, audio and business professions. From hiring and firing conventions, attitudes about gender disparity, goals for work-life balance, and a span of legal, psychological, and communal intellectual property protection mechanisms, the book's combination of accessible industry talk and incisive thematic overviews is ideal for anyone interested in games as a global industry, a site of cultural study, or a prospective career path. Designed for researchers, educators, and students, this book provides a critical perspective on an often opaque business and its highly mobile workforce.

Additional teaching materials, including activities and study questions, can be found at https://www.routledge.com/9780415828284.

1
Programming

► Introduction

Programmers—also known as engineers, or more colloquially, coders—develop and modify the software environments, apparatuses, and technical assets that enable games to be built, compiled, executed, and played. This work may occur within a commercially available game development suite (e.g., Unreal Engine; Unity 3D), a proprietary development environment, or a combination of the two, and can involve scripting as well as programming. Additionally, programmers are tasked with optimizing the software’s process performance—including the development of patches and hotfixes—as well as additional post-release content.

Programming personnel typically occupy one of three primary position classes—programmer, lead, and technical director—with the lead and technical director serving in a broad supervisory or administrative capacity that usually involves interfacing with other development disciplines and the public. Depending on the game type or studio size, programmers may take on specialty roles, focusing on engine, tools, artificial intelligence (AI), or network development, for example.

As a result of specialization, programmers often work closely with one or more other development disciplines. A graphics engineer, for example, may work with the art department to create new visual effects, simulating camera lens flare or optimizing the number of characters or particles on screen at a given time. Similarly, AI programmers may collaborate with game designers to create specific non-player character behaviors and movement patterns in order to greater challenge players.

Because programming typically requires a high level of technical proficiency, programmers have often earned at least an undergraduate degree in computer science/engineering prior to entering the programming discipline. Like other software engineers, programmers tend to use common programming languages such as Java or C++ in their work, though they sometimes adapt these languages to the needs of a particular game or software application. As a given piece of game code can be used for many purposes, from displaying graphics on-screen to simulating artificial intelligence in creatures and enemies (all of which must be integrated and work well with many other pieces of code), using a common codebase is highly desirable among programmers, especially those working in large teams.

According to the 2014 Gamasutra Salary Survey, programmers earn an average annual salary of $93,251 in the aggregate (“Transitions” 2). Programmers with fewer than three years of experience earn an average of $71,855 annually, while programmers with six or more years of experience earn an average of $103,789 per year (Ibid.). By comparison, lead programmers and technical directors with six or more years of experience earn an average of $116,151 and $135,781 annually, respectively (Ibid.). Additionally, US-based programmers earn approximately 12% more on average than their Canadian counterparts, and 50% more on average than European programmers (Ibid.). Finally, male programming personnel average $93,977 per year, while female employees average $79,318 annually (Ibid.).

John Sietsma Programmer

John Sietsma is a programmer and educator. He is currently on the faculty of the Academy of Interactive Entertainment, and previously worked for Many Monkeys Development, Chocolate Liberation Front, League of Geeks, Dekko Experiences, Big Ant Studios, Transmission Games, Arterial Software, 80–20 Software, Spinifex Computing, and Victoria University in a variety of capacities, including as lead programmer, senior programmer, programmer, technical director, games developer and designer, and creative developer. He has also worked as a freelance developer. He holds a master of technology degree in intelligent systems from the Royal Melbourne Institute of Technology and a Certificate IV in Training and Assessment from Selmar Education Institute. His shipped titles include Armello, Wollongong University Kinect Experience, Oscura: Lost Light, Oscura: Second Shadow, Table Top Speed, Dekko Monkey, ACO Virtual Orchestra, Jewel Collector, Rugby League Live, Heroes Over Europe, and Ashes Cricket 2009.

* * * * *

How did you come to work in the game industry?

I was a professional software developer for seven years before I joined the game industry. At one point during that time, I was working on a search engine that had some intelligent features and I was also playing a lot of games. That combination got me thinking about non-player characters and how they behave, which in turn made me want to study that stuff further. So, I enrolled in a graduate program to study intelligent systems, and my research focused on modeling emotions in non-player characters. I then got a job as a tools programmer in a game studio and soon became lead of the internal technology team. After that, I moved into making augmented reality games. During this period of my career, I worked independently for companies that weren’t primarily games companies but tech and venture-oriented organizations. After that, I got involved in starting a game studio, and now I’m a game programming teacher.

Is AI still of interest to you?

Believe it or not, I’ve never done any AI in games, even though that was the reason I entered the industry. I suppose the psychological aspect of AI remains interesting to me, but the technical stuffhas dropped away. As I’ve progressed through my career, I’ve become more interested in game design, and this was particularly so when I was doing augmented reality work. That sort of work is really about how people experience a new technology. What affordances are there? What experiences can people get that are unique to this particular combination? I still keep up on stuff related to the psychology of game playing, and I read regularly about how to design for the different emotional states players go through during play.

How do you apply this knowledge to your development process?

I apply it all the way through development, but especially at the beginning because that’s the danger place in terms of purely functional design. You actually see this a lot in indie games, where the design revolves around a particular mechanic or functionality. I think programmers often naturally fall into the engineering role, where they think, “I’m going to make this game, I’m going to take this mechanic and put this twist on it, and that’s what’s going to make the game really great.”

I try to focus more on the player experience really early on and adopt it as an essential decision-making tool. I ask, “What am I feeling here? What’s the goal?” and I use my answers as a reference for design decisions. If the game is about a sense of wonder and surprise, for example, then I’ll use that sense as a reference when I’m thinking about the mechanics, aesthetics, and what I’m going to add to the game. Doing this enables me to fact-check the design against the player experience or emotional state I’m shooting for.

What are the principal job tasks of a lead programmer?

Communication with the other departments is a big one. There’s also some task scheduling typically, but the job is mostly about having a knowledge of everything that’s being built, managing the team of programmers that’s doing the building, and providing technical design advice. Another way of thinking about the job is that it involves a lot of talking to people when they’re building different systems, making sure those systems are being built in a good way, and ensuring that the builders are getting lots of feedback. Additionally, being a lead programmer means managing team spirit, and making sure people are pulling together. It also means writing code yourself. If there are any gaps in the development process, you fill them. You take on jobs that others haven’t gotten to, and you write systems.

The great thing about game development is that you have all these disciplines working together, and it’s really enjoyable to be a part of the group. But you have to be careful to make sure that you’re communicating well and understanding what other departments need. Being the lead programmer means thinking beyond programming and staying connected to all the work being done in the other development areas. That’s true for all the disciplines in game development, and part of what makes development so challenging and rewarding.

What are some of the workplace similarities and differences in the companies you have worked for?

When I worked for Dekko, the augmented reality start-up, development was very much focused on getting funding. Everything we did was short term by necessity. You had goals to attain over the span of a few weeks that were vital, which were then replaced by a new set of vital short-term goals after the first ones were achieved. This is different from typical game development, where you have just the one major goal of seeing a game completed at the end. There are short-term goals in typical game development too, of course. There might be a festival coming up or a publisher coming in and a certain feature needs to be ready. But those goals are in the context of a much longer development cycle, which is the main focus. With Dekko—and really any start-up—our focus and efforts were much shorter. We might need a thirty-second grab to show investors, or a brief demo to get into the news somehow. Everything was much smaller scale, including the timelines.

The augmented reality technology and experience in general was also new when I was at Dekko. As a result, there was a lot more cycling around ideas, a lot more rebuilding things and re-doing parts of a given game over and over again based on testing or just trying out new ideas as we were feeling our way around. That kind of work is also different from more conventional game development because the process really involves looking for something you can put into an investor’s hands that they’ll immediately understand and can have a great experience with even if they aren’t interested in games. The target market for the products with Dekko was the investor, not the consumer, which makes you think about the processes and goals of game design and development differently.

When you’re making a game for an investor who has no games experience, you want something that may not necessarily be challenge- or progress-based like a more conventional game. That’s because you need to be able to put the person at the start of the experience and have them immediately enter a very small loop that’s instantly enjoyable. This is especially important with a new technology or an inexperienced audience. If someone isn’t used to games or how to control them—particularly with something new like augmented reality, where most of the mental battle is getting used to how things work—then the game itself has to be a very light experience. It needs to not be frustrating at all, because you don’t want someone to pick up the game and immediately die or fail to fulfill its challenge. So a lot of game building for an investor involves going for other senses such as wonder, excitement, or perhaps even an entirely different emotional register than you’d find in traditional games, which tend to focus on challenge and mastery.

As far as conventional game development, I’ve worked at two large studios: Transmission Games and Big Ant Studios. Both were about 100–150 people. Transmission was interesting because it was my first large studio, and we went through a big structural change while I was there. When I started, there was an engine team and an art team, and the engine team would spend months making something and then throw it over the wall to the art team. Often, what we made would be wrong, and so the company structure was reconfigured into strike teams. These strike teams worked really well. Depending on the game, there’d be a cinematography team or a terrain team, and each would have a producer, designer, artist, and programmer. It’d be a mix of people, and they’d concentrate on a particular aspect of development. This removed a lot of the communication barriers that had plagued the company previously. Programmers were less prone to making stuffthat they thought was fun or might be needed at some time in the future and instead were able to focus on solving specific problems to get a game feature done.

It’s important to mention that neither Transmission nor Big Ant were highly structured at that time. In fact, they seemed chaotic compared to the ordinary IT programming world I’d been in. It was interesting coming from outside the game industry, because there was a lot more process around what we did there than what you typically find in games. In non-game-oriented software development, there are lots of procedures related to schedules, risk management, how to code, how a feature gets implemented and checked off, and so forth. It makes a huge difference in terms of delivery. Take the game Heroes Over Europe, for example. It was scheduled to be in development for a year to a year and a half, but it ended up going for over four years. Software schedule overruns are common in any industry, however I think that with Heroes Over Europe it was a symptom of the lack of process. The finished product in those large game studios was always six months away, or two months away; it was never ready. I don’t think they’d learned to use the techniques developed in the enterprise software world that allow leaders to sit down and really schedule something to make sure it’ll be delivered on time.

There was a lot of work that was thrown away too, a lot of stuff that didn’t quite work. For example, the PlayStation 3 has a different architecture than the PlayStation 2, and so we needed a new job system for Heroes Over Europe. We spent three or four months writing that system only to find out that it wasn’t suitable and didn’t fit in with the rest of how the game worked. There was a lack of communication or lack of checking beforehand, which resulted in a big chunk of work being thrown in the garbage.

Likewise, I worked on a city generation tool meant to recreate some of the great European cities during World War II. The idea was to be able to generate Berlin or London as a fully destructible environment. We worked on that tool for about six months, and when we showed it to the artists they said, “That’s not the look we’re going for. The inside of the blocks is all wrong. We’re just going to do it by hand.” Again, work wasted and the timeline extended.

It was these kinds of things that fueled the transition to strike teams. Instead of having the engine team just make stuff—which might not have been vetted by people outside the team—strike teams made it much easier to show programming work immediately to artists, designers, and producers to see if it was on the right track. Before the restructuring, programmers ended up wasting a lot of time and then artists didn’t necessarily have the tools they wanted to do their work.

How was it possible for the development of Heroes Over Europe to continue over such a long a period and with so many fits and starts?

I think there was probably a bit of a gambler’s fallacy going on. In fact, our publisher actually went bankrupt during that time. It must have always seemed to the publisher that the finished game was only six months away, and they weren’t prepared to throw away the huge investment they’d already made if the game was so close to completion. But the completion date kept stretching and stretching, and we were working on other games at the same time, some of which were in pre-production but never went into full production.

At that time in game development, maybe 80% of the technical work was engine-related or systems-related as opposed to gameplay-related. That’s a big difference from what you might see today, especially on an indie team, where almost all of the work has to do with building and refining game-play. Back then, some of the internal technology we needed to create as part of the development process was to build systems designed to enable a fast turnaround. The goal was to make it so that if an artist was working on a model, she could make a change in the model and have the least amount of friction getting it seen in the game environment. That meant being able to process the asset, convert it, and transfer it—to rebuild the game, transfer it to the target console, and then see it on the screen. We actually spent a lot of our development time just on facilitating this kind of workflow.

Some systems we worked on were performance-related. The games needed to be able to render particles or do some sort of calculation, and there was the whole technical challenge of how to do that efficiently. And in the case of the PlayStation 3, the challenge was how to spread that work across multiple processing cores where before it had just been done on one. So there was a lot of effort spent on performance-related stuff, which, as you can imagine, also took a lot of time.

How is the work you have done in the game industry different from the work you have done elsew...