Game creation is more complicated than portrayed in Game Dev Story. I’m going to explain just how complicated it can be, but I have a few caveats: I can’t walk through every possible game feature (there are many and we make new ones all the time). I can’t provide a standard menu of features either, because there are complex interrelationships between components, and costs change based on platform. What I can do is break down some common questions and show you how we think when determining cost.
How We Assess Cost
Ultimately, cost boils down to time, but there are many different kinds of time. The most obvious kind of time is constituted by the hours spent on the project by programmers, artists, designers, quality assurance, and producers. Some projects have bottlenecks because too much work is allocated to one discipline and changes that affect that discipline become more costly. Often overlooked, Quality Assurance needs to test every possible option and combination of actions; even small changes can invalidate their audit.
There is also performance time. Games need to run at a reasonable framerate. All of the art needs to render and the programming needs to execute in the time between frames – which is 16 to 32 milliseconds. The performance budget is interesting because it pervades the entire project – if one feature grows in expense, savings need to be recouped from other features. Also, the lower your hardware specifications are, the more time will need to be spent optimizing.
We have several other important kinds of time that we try to keep to a minimum. There is inevitable load time because of limits on memory, and we often structure games in specific chunks that can be loaded on demand. Maintenance time, the ongoing support a product requires, ranges from customer service to managing servers. We want to minimize the time it takes to compile, build, and deploy the game. There is also the concept of iteration time, where we build the project with a degree of flexibility so we can quickly experiment with different options. All of these and more are evaluated when considering features.
The Cost Difference Between a 2D or 3D Game
Though there are some in between options like isometric scenes or generating 2D sprites from 3D models, for simplicity we are going to consider 2D games as completely composed of 2D art. The difference is that 3D assets are considerably more expensive to produce, and have a higher impact on performance.
In 2D, we just need to draw an object and it can exist in the game. If it is animated we need to draw each frame. The same way the original Disney movies were made the only difference is that we use software instead of hand-drawing.
In 3D, assets are composed of many components- here is a timelapse of a 3D building being created. We start with making a 3D model composed of simple shapes, and then apply the equivalent of drawing in 2D, a 3D texture map. Then we need to instruct the game engine with how to light the object; known as bump mapping, normal mapping, lightmapping. This enhances the detail of a model beyond its simple polygons. A typical strategy is to make two models: a high polygon model to generate a normal map and a low polygon model that the game can render more efficiently. Models are going to need a shader if it needs to look shiny, metallic, or glowing. You can conceptualize normal maps as how light hits an object and shaders as how much light the object reflects- in the simplest cases. You can always go further, but that should cover basic objects. If we need to animate a 3D object, we need to build a rig, which is a set of skeletal bones that map to the model’s polygons.
The performance impact is pretty clear. There is a lot more data to be considered on how an object is rendered. It is so much more expensive that games have developed a strategy called level of detail (LOD) where we need multiple 3D models that range in complexity so we can save drawing time on objects further from the camera.
The important question to ask for any feature is: what does it add to the experience? In the case of 3D, does your project benefit from the extra realism? Is there going to be interesting use of lighting? Do you need to be able to see all sides of an object? Is it important to be navigating a 3D space? Are we going to take advantage of multiple camera angles / points of view? What is the cost benefit analysis of the feature? Any expensive feature should be scrutinized before implementation, because it comes at the cost of other potential features.
The Cost of Multiplayer
One way to think about game complexity is the number of actions a player can perform. As an example take Mega Man. You can jump, shoot, and do both at the same time. As game developers, we tend to favor actions that can be performed simultaneously. If they can be combined in interesting ways, it creates emergent gameplay. If we were to make Mega Man multiplayer, we would have to think about the total number of possible interactions: the number of interactions a player can take multiplied by the number of people networked together.
We need to resolve what happens when multiple players destroy the same target, how enemies behave now that they have choices, and even stranger situations like what to do if a player A jumps on top of player B and player B jumps. Client-Server data exchanges are made for every effect players have on each other and the game world. We need to handle a player disconnecting at any point and attempting to reconnect. There are also complicated requirements like the game lobby interface to find other players and make teams.
Adding new player actions becomes dramatically more expensive to program and exponentially more expensive to QA, to the point that massively multiplayer games usually need to write AI to be pretend players for testing. It more than doubles the cost of your experience, and it does so asymmetrically in the fields of programming and QA.
The Cost of a Larger Game World
Consider a game that has levels, but unlike Pac-Man or Tetris, each level is unique. The cost of adding one more level to the game appears like it would be constant, but in reality it is not. Let’s also assume that you can pick which level you would like to play. Examples of games like these would be Super Mario Bros. 3 or Angry Birds.
As you add more and more levels you are going to hit key thresholds. The first of which is the user interface presenting the levels to the user. There is limited screen real estate to present options, and countless design studies show that too many options are overwhelming (one example is Barry Schwartz’s Ted Talk and and book). At more than 10 levels we would need a solution to display levels in groups. At more than a few hundred we would be looking at features to filter, sort, and search for levels. At some point all levels are not going to fit into memory and we would need load and unload capabilities.
On top of the linear cost of art resources, the larger and more unique your world is, the more technology will be required to create it. We can plan ahead if we know the targeted complexity of art and size of the world. Changes to either during development can have drastic effects as the costs are correlated.
Large worlds and games with long play times are atypical at Filament. Our purview of educational games is that they should accelerate your learning and instill a deeper understanding of the topic. Our games naturally trend to be smaller and shorter experiences because efficiency is more valuable to our audience.
Late Changes in Development are Expensive
Game development, particularly for something novel, starts with research and investigations that our ideas are reasonable. Traditionally we prioritize the risky parts and establish the core of the game first.
There are many ways in which something can be risky. From production’s perspective anything that takes a long time, requires an unknown amount of time, or is a parent of many dependencies is risky. The core of the game is risky from both a programming and design perspective, as it needs to be proven that it is fun and possible. The core of game is also an example of a heavy iteration feature, which we want to address early in development. Choosing an art style is risky for art and programming because it will affect the cost of art for the rest of development and it needs to fit within the constraints on performance.
The problems we solve should progressively get easier, smaller in scope, more proven, and more efficient if we have developed tools and processes to speed up the creation of the game. Game development has a natural tendency to accelerate, which is exaggerated from an outsider’s perspective that lacks insight into the research and iteration phases.
Making a change to something already built can have dramatic repercussions. It could affect multiple people’s schedules, require we revisit our budgets for performance and memory, and it could be tied to several other dependencies or affect other parts of the game. Change happens and it usually makes things better. Some of the most successful titles went through dramatic changes, but it can come with significant cost.
Multiple Releases Are Expensive
The typical frustration of a low budget project is the need for a proof of concept and the likelihood of needing to accommodate several important fundraising events. Sometimes major developers have the same issue of an overstuffed release schedule because they are trying to maintain a media storm, hitting all of the conventions with playable demos and new features to excite their audience.
Every release freezes feature development in order to QA and polish the existing project, which is more than likely on intermediate work. It disrupts production and is wasteful as intermediate work often changes and polish will need to be repeated. It adds more risk into development because your focus is switched from reducing risk to investor or user value. It also undermines the iterative nature of game development; you are unlikely to change and experiment with improvements if you are under the microscope of an important audience.
This is a tough problem. Most people have never seen what a game looks like while it is in development, much less possess the vision of what a game can become. If you can imagine a movie with many special effects, a game partway through looks like the raw green screen footage with placeholder and temporary assets. It is compounded by the fact that game development accelerates. Halfway through development most of the game, particularly the parts visible to end users, is still incomplete. There is an amazing article on Kotaku with interviews from multiple developers about game demos, particularly some of the differences between demos and ongoing development.
Conclusion
We learn these costs through experience, and even people adjunct to game development do not understand the process until they build their first game. Making games is complicated. There is tremendous strategic tension in development of what to build when, allocation of resources, and the need to assess a feature before the final polish. We possess the vision to imagine a new feature as well as foresight on how existing features will grow and interact as we add art, programming, special effects, and sound over the course of its development. Jesse Schell talks about game design as the ability to view your game through different lenses (perspectives). The same is true about analyzing cost.