Whether you are working with a large team or a small one it will be important to have your organizational and time management skills sharpened in both the business and creative side of things. The process of game development is a mix of computer science and production, which takes every game from its very basic concept stage to a shipped product. The development process consists of several stages (see Figure 1.2).
Figure 1.2 Typical game development cycle.
The concept stage is where the developer is essentially deciding what type of game they will develop. Concept art and/or a prototype will be developed to further share the idea with others.
Pre-production follows the concept idea by allowing the team time to develop resources and design documents that will be used in developing the game. After a game design document (GDD) is created, the audio designer can begin to think about what type of tools and resources are needed for the game’s audio development. This is a great stage at which to create mock-ups and source material.
Early on in the production stage is typically when a vertical slice is created. This is a short playable build of the game, which acts as a proof of concept. It’s typically used to secure funding. Throughout the production stage the game is being refined and further developed.
As the development matures through the production stage, an alpha build of the game is thoroughly reviewed by the quality assurance (QA) team. QA is an important phase in the cycle which evaluates the games mechanics, value, and design. As the game runs through QA, testers are looking for bugs or missing features through white-box and black-box techniques. You will notice in Figure 1.2 that pre-production, production, and testing is an iterative cycle as developers may often have to go back to pre-production or production to make changes and fix bugs. It’s important to note that an alpha build may not contain all the planned features and may be a very unstable build, which could result in crashes and data loss.
The beta phase is entered when a build is generated with complete features. During this phase there may be some instability in the build and it is possible to uncover new bugs, but it’s technically in a state in which it can be delivered to publishers, reviewers, and as a limited public release to beta testers.
The gold master or release phase is typically the final release prepared for distribution. There may still be some bugs, which can be fixed via patching. During this phase the marketing and community management is in full ‘go’ mode. The development team may still be in the production stage during the release as there is usually additional DLC (downloadable content) and patches that need to be prepared.
You may be wondering at what stage the audio team is brought onto a project. The answer is – it depends on the project. The pre-production stage is an ideal time for the audio team to be brought on. Some teams will even bring in audio during the concept stage for input. Often the audio team is brought on during alpha or later. This is unfortunate because bringing on an audio team early means they have more time to plan, gather source material, and experiment with ideas.
Games are usually on a strict schedule with milestone deliverables along the way. Regardless of when audio is brought in, there will always be necessary planning to keep the team in sync with the production cycle. Publishers want to hit the mark and have the product ready for holiday sales or conferences like E3. Even independent developers (or indie devs) need a plan to push their game to the starting gates. For indie developers it’s important to choose a time for release that won’t be overshadowed by an AAA release or big industry news.
Whether you get started during the pre-production phase or later, there are a number of questions you can ask the developer to be sure you have all the info you need to complete your tasks. It’s important to ask these question before contracts are signed (a topic we will cover in Part IV: Business and Networking). Once signed contracts are in place, the next step is to review the game design document (GDD) and (ideally) play an actual build of the game. This will give you a feeling for the game mechanics as well as the overall visual aesthetics. If the project is in the early stages of development however, you may only have concept art and a storyline to work with. This still offers valuable clues toward finding the right source.
During the information-gathering process or pre-production you will want to suggest additional assets that the developer may be overlooking. Once you have enough information and ideally a build of the game to play through, you can start mapping out your plan.2 If you have a very quick turnaround time you may want to work out which assets are top priority with the developer and see if some lower priority assets can be patched in with an update at a later date.
Milestones are typically set by the developer and their publisher. An asset list may be provided to you by the developer or you may be asked to create your own based on your play through of the build. If this is the case, be sure to review your list with the developer to ensure you didn’t miss anything. The development team will utilize development methodologies such as Agile, Scrum, Waterfall or Design Sprints to keep the project on track. It would be helpful to be familiar with these methods as well as some of the collaboration tools used in the process.
Reading through the game design document (GDD), if there is one, is a great way to understand all the tiny details about the game. Be aware of the fact that as the game development moves forward deviation from the GDD is not uncommon.
You may have heard of crunch and tight deadlines in game development. Sometimes even the best plans fall short and that leaves a desperate situation in which to turn the ship and get things done in time. Planning from the start and not overplanning can help avoid crunch and a lot of game development companies are doing their part to be mindful of quality of life and limiting crunch. After all, long crunch times can lead to poor work generated from overworked and exhausted individuals.
In the Sound Lab (companion site) we provide some example asset lists, schedules, and additional information regarding development methods and collaboration tools.
Research
Research is a fundamental part of the pre-production process. Audio references can help determine the sonic direction of your project. Throughout Parts I and II of this book you will be reminded of research opportunities that include critically listening and breaking down a sound in order to reconstruct it.
Developers may already have an idea of the game’s sound vision before you are brought on to the project. Often the vision and delivery specifications may be relayed to the sound team in the form of a written brief. Understanding how to interpret the direction and follow through with asset delivery according to spec is an important skill. When you are unsure if your ideas and theirs are on the same page, it’s best to open the lines of communication with the developer by asking for further details. Once you have an idea of the direction for your soundscape, careful research will help further flesh out the details. Research isn’t copying another game or film sound, but rather it helps inform your own ideas and provides further inspiration.
Making Use of Downtime
Whether you just finished a game audio project or have extra time away from your day job or education, you want to make use of this downtime. When you are playing games make assessments of the audio. Start practicing with a new plugin or try a mic in your collection in a way you haven’t used before. If you have a field recorder be sure to do some experiments with all the settings to find the sweet spot. Use this time to increase your skill level and be ready for the next project.
The Sound Lab
Before moving onto Chapter 2, head over to the Sound Lab for additional reading and practical exercises on the topics discussed in Chapter 1. We will review game development roles in depth, essential skills and tools including looping assets, example asset lists and schedules, and how to make the most of your downtime.
Chapter 2 begins Part I, the sound design portion of our textbook. We encourage you to read through the entire book, but as we mentioned in the Introduction, if you are only interested in music composition for games you can skip Part I and move directly onto Part III, Chapter 8. From there we recommend reading Part IV, Chapters 10 through 12 for the business side of game audio.
Notes
1 M. Kamp, T. Summers, and M. Sweeney, Ludomusicology; W. Cheng, Just Vibrations.
2 When working remotely you may not always have the ability to work directly with the game engine or even a build of the game. In this case you would work with animations and screen captures of game play provided by the developer.
Bibliography
Cheng, W. (2016). Just Vibrations: The Purpose of Sounding Good. Ann Arbor, MI: University of Michigan Press,
Kamp, M., Summers, T., and Sweeney, M. (2016). Ludomusicology: Approaches to Video Game Music. Sheffield/Bristol: Equinox.