Before we begin
This is the first post of a series in which I share the game development philosophy I’ve cultivated over the course of my career. This philosophy is by no measure complete, it is and will be ever evolving to meet the challenges of the equally rapidly evolving nature of gamedev.
Why is this necessary?
As our industry evolves our approach to making games must evolve with it and as recently as the early 2000 we crossed an evolutionary threshold for which we have not yet adapted. Previous to this threshold game teams were predominantly composed of programmers (or software engineers) who would build out the game engine, infrastructure, and toolsets used by the (very few) content creators on the team. Due to this high ratio of programmers involved in projects most of our challenges were similar to those of software development teams in the tech sector and so we adopted their methodologies to great effect - Agile + Waterfall hybrids. However, with the advent of ubiquitous game engines and off-the-shelf technologies that enable us to develop hit titles this balance has changed.
The ratio of programmers on a AAA game team has shifted from being between half and two-thirds programmers to around one-third. This is not to say that fewer programmers are involved in the industry but rather the infrastructure, engine, and toolset development has become centralized to engine teams who serve multiple game teams in a client-service relationship model. Unreal Engine and Unity are examples of mainstream engines heavily used throughout the industry where most of the staff are engineers in such a client-service model. Even the big publishers of our time have large centralized technology teams who support their proprietary engines in a similar albeit exclusively internal model. The result of this industry wide evolution is that programmers are now a minority within a game team but most of us are still employing development methodologies that are focused on solving for their particular workflows.
What ends up happening on most modern teams is we employ Agile where we can. Then some waterfall-ish approach to the other parts of the organization where Agile doesn’t work. Even the teams where we apply Agile we have to bend the practices to fit the needs of the particular team because most of our teams are now cross-functional; only the teams made up entirely of programmers can practice SCRUM as it’s taught through the various certification classes.
We have reached a level of maturity where it is time we created a methodology tailored to game development. This methodology should seek to incorporate the best elements of other methodologies from industries who have similar problems to our own but adapt them to suit our unique context.
Who is this for, and through what lens was it written?
This is for leaders of game development teams to help shape their organizations to make great games. Think of this writing as a proposal for a new contract between all parties involved in making a game: from the entry level testers to the top-most CEO and everyone in between.
It is not intended to guide any specific discipline (or department) within the larger organization. As in, it’s not meant to give insights on how to write better code, how to design features or experiences, nor how to test, or even produce a game.
This is meant to guide the wholistic execution of getting a game from idea to market, to success.
Who are Gamedevs?
A gamedev is any individual who makes a material contribution to the development of a video game. If your activities directly affect the game in development at any stage you are a gamedev. This can include (but is not limited to) creation of designs or assets, coding or scripting, planning or direction, testing, and management.