How Games Typically Get Built
👋 Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover topics related to Big Tech and startups through the lens of engineering managers and senior engineers. In this article, we cover one out of for topics from the past newsletter issue Game Development Basics. To get the full issues, twice a week, subscribe here.
Q: “I play video games, and I was wondering how building games compares to more ‘standard’ software development. I’d love to get a glimpse into the game development world, and how it compares to the software engineering approaches at tech companies.”
How games are built is a fascinating subject for me, and my interest derives from having worked with former game developers. At Skype, I worked on the team building Skype for the Xbox One console, and several engineers on that team had previously worked in games. It was by talking with them that I realized just how different the game development world is. Video games are very complex pieces of software, built in different conditions and under very different constraints than many other business applications are.
To answer the question of how the video game development sector works, I turned to Tommy Thompson, director of AI and Games, who’s a veteran of game development and of teaching it. Tommy has built his own video games, consulted on a wide variety of game projects, and for a decade has taught game development at various universities. He also runs the highly popular AI and Games YouTube channel, where he delves into how AI makes for better games, and games make for better AI.
I met Tommy in 2010 at Scott Logic, a UK software consultancy where we were both software developers on neighbouring desks. As we reconnected more than a decade later, I discovered just how much our paths diverged right after that job; Tommy spent the next ten years in gaming, while I moved on to tech companies.
In this issue, we cover:
- Getting started in games development
- Games are software, but in a non-standard way
- Typical roles within games development
- How games typically get built
- The game development lifecycle
As a heads up, Tommy is hosting his third annual AI and Games jam, 15-22 September. Over a week, participants build their own game utilizing AI in some form. Learn more or sign up if you’re interested.
With this, it’s over to Tommy:
Getting started in games development
Video game development is undoubtedly one of the largest entertainment sectors in the world. It’s a $200+ billion industry, which thrived during the strictest of lockdowns throughout the Covid-19 pandemic, when people stayed indoors and checked out the latest instalments of action-packed games such as DOOM and The Last of Us, to more relaxing experiences like Bugsnax and Animal Crossing. Or perhaps they jumped on their favourite ‘live service’ games, playing the likes of Dota 2, Fall Guys or Fortnite with friends, to enjoy social interactions at a time when we couldn’t meet up in person.
Game development is a sector that hosts a myriad of challenges. Each project typically takes several years to create, with shifting hardware specifications and emerging competitors and trends to anticipate and react to, during the process. But even in 2022, the biggest challenge for anyone keen to learn more is that gaming is a sector which is often shrouded in mystery.
Getting started in video game development, or even just understanding how it all works, is often a difficult first step. Perhaps unlike any other software development field, the tools, technologies, practices and pipelines that are typical for a video game production are not well communicated or documented to the wider world. Naturally, this leads to a gap between the creator and the consumer, as wild and inaccurate hot takes on social media regarding the recent leaks of Grand Theft Auto 6 footage show. Still, even for a typical software engineer, it can be difficult to figure out how your skills apply in this industry, and how it really works.
Back in 2010, I was working as a software engineer in the banking sector, and Gergely and I used to work in the same office. It was around that time our paths diverged, with mine leading into the world of video game development. I had actually transitioned into a career as a university lecturer in computer science. But soon after, I was teaching game development on a bachelor's degree course. Despite my enthusiasm, and some earlier work making crude games as part of my PhD research, it became readily apparent that despite being a video game player, I still knew very little of how game development worked. This is of course a problem when you’re supposed to be teaching it!
So, over the past 10 years I’ve been on a journey to learn more about game development, with my experiences in teaching resulting in me becoming course director of several games development courses at UK universities, starting a YouTube channel that marries my interests in artificial intelligence (AI) and video game development (perhaps unsurprisingly called ‘AI and Games’) and developing my own game on PC and Xbox. I now work as a developer and consultant on artificial intelligence in the video games industry; working with companies ranging from big hitters such as Intel and Ubisoft, to smaller game studios around the world, and contributing to the production of several game projects over the past few years.
In this article, my focus is on providing a high-level overview of how game development works, and how software engineers fit into that space. Naturally, there’s a lot of ground to cover, and I hope that even at this introductory level, you find it quite insightful. So, let’s start with the basics.
Games are software, but in a non-standard way
Video games can often feel far removed from traditional software, given the modes of interaction and style of presentation are often unique to this space. But in essence, it’s business as usual. As a software engineer working on a game, your task is to facilitate the introduction of new features, integrate them within a large and ever-changing code base, clamp down on bugs and other emergent problems, and ensure it runs smoothly on a myriad of different platforms with varying hardware specifications. I’d argue that my time working as a mobile developer prepared me more for my time in games, than anything else.
All this sounds a lot like a regular software development gig, but the big difference compared to most software projects, is the highly multidisciplinary nature of the gaming medium. As a game programmer, you’re part of a much larger team, catering to a variety of different needs and project requirements.
Typical roles
On a typical games project, programmers work alongside designers, artists, animators, writers, sound designers and other disciplines. It’s usually a large and diverse team working together to make the project a reality. This is undoubtedly one of the most exciting, and equally challenging, aspects of any given project. It’s a highly collaborative space, as you work together to bring the vision of the game to life. Being able to feed off the creative energies of others around you is incredibly satisfying. I often explain this working relationship as that artists make it pretty, while designers and programmers make it work.
If anything, maintaining consistency of vision and preventing feature creep is one of the biggest problems you face while working on a game. This becomes the responsibility of the directors and producers.
The director is typically at the helm of the creative vision. Directors work with different teams to paint the broader picture, making executive decisions, all the while trying to maintain consistency.
Producers work on ensuring requirements are established, tasks are properly identified, scoped and budgeted, that team synergy is effective, and whether the director’s vision is actually attainable given the time and money available.
Compared to traditional software projects, a game director acts akin to a product manager, with an emphasis upon hands-on work, leading team members below them, and focusing on the creative aspects of the project. A producer occupies an interesting middle ground between product and project manager. They’re responsible for keeping the project on track, collaborating with leadership and stakeholders – such as an external publisher – but also they keep a close eye on the product performance and work to ensure the game ships.
Depending on the size of a studio, a producer may also be responsible for business management, such as liaising with external partners and handling finances. In a worst-case scenario, the director is also the producer. But it’s generally agreed that separating the creative direction from the project management helps keep things on track.
Perhaps unsurprisingly, this whole process was heavily affected by the global health crisis and the need to work from home. It led to a number of new challenges, for which the industry is only now beginning to understand the most effective solutions.
How games typically get built
If what I’ve described of multi-disciplinary teams working together sounds exciting or intriguing, what typically makes many scream in terror is when I talk about how games are typically built. It’s an onerous, complicated and often counter-intuitive process, given so many games emerge more as happy accidents, than the products of a carefully supervised process.
Prototyping. Games start out in a prototype stage, typically built using existing art assets, or with cobbled-together solutions for the purpose of establishing the basics of functionality and behaviour. Prototypes are critical for getting a game signed off into full production, or obtaining funding from an external partner; given the ‘fun’ of the experience should be made evident and also that there is a market for the product.
Should a game move into full production, it typically becomes a mishmash of different creative processes operating at once. Programmers are building core systems, artists are establishing the visual aesthetic and style of the game, and designers are establishing gameplay, long-term progression and retention.
Integration testing is often a difficult aspect of game development. Integration testing is challenging because so many disciplines are working in parallel. This is because assets from different teams get pushed into the build at different stages, often breaking much of the game as it’s being created. Identifying and helping resolve these issues is often led by dedicated quality assurance teams – assuming the team size or budget permits. Quality assurance might also be pushed out to the latter stages of development.
In full production, you’re essentially trying to “capture lightning in a bottle” for a second time - the first time was during prototyping. Only this time, the game is significantly more complex and potentially is even being built in an entirely different game engine.
Managing feature creep is a very real problem. Games take a long time to make and the industry is an evolving and reactive beast. As new games get a foothold in the market, they can often force changes upon in-production titles in an effort to stay competitive and relevant. Trends emerge in specific genres when a new idea captures the imaginations of players. A recent example would be the adoption of ‘ping’ systems in first-person shooters, brought about by the success of Apex Legends.
New trends emerging can lead to small deviations from an existing production schedule, or an entire revamp of a concept in order to pursue a new trend. Arguably the biggest example of this in recent years is Fortnite by Epic Games. Fortnite started out as a third-person wave defence shooter, only to become a battle royale in a style akin to PlayerUnknown’s Battlegrounds, to significant critical acclaim and financial reward.
But of course, a success story like Fortnite isn’t the reality for most projects. Games can spend years in something of a ‘fugue state,’ whereby the core of the game fails to take shape until the closing months as core design and direction are not nailed down sufficiently.
Tech debt can manifest quite easily as systems are built for one purpose, only for them later to be used for another. For some large-scale projects, the initial ‘fun’ aspect is only recaptured in the final 20% of the production process, which often leads to difficult working conditions for developers in the closing weeks – if not months – of a given project.
There has been a growing emphasis over the past decade for game studios to embrace better work practices from traditional software development. Practices include:
- Test-driven development
- Automated build processes
- Agile methodologies
All these processes are introduced to better catch many of the problems that emerge earlier in production. The real challenge is then adapting many of these ideas to work effectively within this multi-disciplinary environment.
The Game Development Cycle
For games, the traditional software development lifecycle never really fits. This is because you're often working to build or rebuild the same game multiple times during production. In some instances, the game continues to be developed even after it ships.
In this section, I’ll give a breakdown of the overall process. As a caveat, this breakdown isn’t universal, experiences will vary, and practicalities will shift depending on the type of project and the size of the studio. But it at least paints a picture of how the process typically pans out. For reference, it’s worth keeping in mind that your average game will typically take somewhere in the region of 2-5 years to make.
The game development life cycle consist of these three phases:
- Pre-production
- Production
- Release
This was one out of the four topics covered in the article Game Development Basics. The rest of the article covers:
- The game development cycle, in-depth. What happens in the pre-production, production and release steps?
- Indie vs AAA production. What are the major differences between how indie games are built vs how AAA titles come together?
- Game development tools & services. Some of the custom tools used in game development: source control approaches, game engines and middlewares.
I recommend checking out Tommy’s game development YouTube channel, AI and Games. If you are interested in games development, you can follow Tommy on LinkedIn as well or subscribe to his newsletter, also called AI and Games.
Subscribe to my weekly newsletter to get articles like this in your inbox. It's a pretty good read - and the #1 tech newsletter on Substack.