The Iceberg Economics of Game Development - Part 1
Unless you are building a single player, offline game with premium monetization on just the PC platform, the cost to design and build the core gameplay is just the tip of the iceberg.
Catch Up
If you’re looking for the other parts, here are the links!
Intro
Stop the madness! This one was getting way too long to hold people's attention, so this will be a four part series.
Computer game development has more revenue than movies and has for a while now. That brings a lot of attention to the industry from people who want in on the fun. Think investors. People who want to see a return on their money in a reasonably predictable time frame.
Veteran game developers understand, however, that designing, building, launching, and running a game that results in a positive ROI is very, very hard.
A few years ago I was shown a spreadsheet that captured all the essential tasks necessary to create a movie, including budgets, timelines, and All The Thingstm. I would expect a generally agreed upon set of rules for production like that should:
🔑 provide a running start for a teams creating the thing
🔑 allow the team to focus on the intangibles required for true success - the creativity
🔑 produce reliable bounds on development time and cost, with predictable error bars
Perhaps I have been moving in the wrong circles, but after 13 years in the industry I have never seen an equivalent production framework for game development. It is true that we can visit the GDC Vault or any of the long-lived game reporting websites for information, advice, and opinions. However, it is still up to each team to figure things out.
I want that spreadsheet for game development, which means enumerating the systems needed to design, build, launch, and run a game. So let's go!
NOTE: I will use terms like issue or system or artifact to refer to various functions like payment processing, code artifacts like the game client and server, or legal/societal factors.
Core Gameplay Artifacts
This part lays the groundwork. The stuff that development teams always begin with, and what their expectations are.
The core artifacts are all the parts that you need, at minimum, to have a game. These are not the game itself, but the artifacts you need to allow people to play.
The Client
This code artifact implements, at a minimum, input processing, graphics, and interaction with the game server (whether local or remote). I can't do justice to the complexity of the client in just a few sentences; there are many books on this topic.
The Server
This code artifact implements the rules of the game. We call it out distinctly from the client because it may be client-integrated, a local service, or a remote service. Today, even many single player games have an online component in the form of a remote game server. The complexity of this software is a nonlinear function of concurrent user count.
Persistent Storage
The clients and server need to store state for the game, like difficulty levels, graphics settings, key bindings, etc. Storage can be local, but local storage can have platform specific restrictions (e.g., mobile and console). Local storage is convenient but when we want player preferences to transfer across systems we resort to "the cloud". We also frequently adopt a hybrid approach, because reasons.
Where Failure Takes Root
And here is where, in my experience, the visibility of the cost of game development often gets obscured.
A game development team in pre-production will spend scads of time and energy in the client and server. This focus is essential for finding the fun and is integral to the activities that bring joy in the development process -- the creative expression. Prototyping gameplay approaches and systems occurs here, usually with the intention to rebuild them later without the shortcuts and technical debt.
If your game is a single player PC title and your plan is to publish through STEAM or Epic for a one-time payment, then maybe you don't have a lot more to do. Well, a lot less than if your game is online, multiplayer, cross platform, and a service.
Today, reliance on premium monetization (pay once for the game) has declined in favor of the freemium, free-to-play, subscription (also in decline), or ad-supported models. These other monetization models require nontrivial support systems and so require time and effort before launch.
High revenue games tend to adopt all of these things, and a lot more not mentioned here. All of those features add time and cost.
Outro
Players can directly or indirectly interact with numerous systems through the game, delivery platform, or website. When you dig into all the parts, that covers a lot of ground that we as gamers generally take for granted. How often have you said, or heard someone say, "how can you launch that game without features X, Y, and Z?"
Each system or concern can be nontrivially complex. For example, infrastructure scalability becomes increasingly critical as your player base grows, with engineering and operational costs multiplying with each zero you add to the peak CCU target.
In the next three parts we'll go through fifteen major areas for work that can be required for your game. We'll do these five at a time, while also breaking each area down into smaller parts.
Once we have all of those, we'll have enough information to begin creating spreadsheets. Here is a graphic we'll be filling in along the way. 🙂