CHAPTER 10

Development Considerations

In This Chapter

Who should make up your development team?

What tools are available to assist with development?

Will the Agile methodology work for game design?

With a limited budget, how can you work with external resources?

We have waited until chapter 10 to discuss what is needed to develop a game from a technical standpoint, but don’t let that be an indication of when you need to start thinking about development (Figure 10-1 shows you where you are in the process.) From the very first design meeting, you need to be thinking forward to your game’s eventual development. Depending on the type of game you hope to develop (tabletop or digital), the tools you may need range from Microsoft Office to Adobe tools to a sophisticated game engine.

Figure 10-1. Learning-Game Design Process: Development

Wouldn’t it be great to create a paper prototype, design the exact pie-in-the-sky game that you want, and then find the right tool or team to develop your dream learning game? Unfortunately, that’s not reality for most learning game designers. Instead, the game development budget and skills you have at your disposal, as well as technical constraints, dictate the type of game you create and how it gets developed. Given that reality, this chapter explores the tradeoffs and functionality of various game development tools. Read through the choices and then decide what budget and skill set you can allocate to your learning game.

Resource Needs and Considerations

Learning games require many roles, so they usually involve a team rather than a single person. If you can play multiple roles, you may be able to successfully design a tabletop game solo or create a smaller digital game housed within an e-learning authoring tool.

If your game is bigger in magnitude, needs high-end graphics or multiple levels, or is being deployed as a native app, you will need outside expertise. Even for early-stage game design, it’s tough to go it alone. If you are a one-person team, consider seeking out people within your organization who enjoy playing games to help you with game design and testing. Chances are you’ll be able to find people who play games at home, with friends, and maybe even on teams.

It is hard to be part of a development team if you are unfamiliar with different types of games. Having experienced gamers on your team makes the development process easier. Each round of play-testing you do typically results in altering some aspect of the game’s design. Gamers can help evaluate outcomes of play-tests and devise solutions to problems the play-test reveals.

The key roles listed in Table 10-1 provide a good start for game projects of simple to medium complexity. Large-scale projects would have additional roles such as an overarching product owner, music technicians, and level designers.

On the client side, several roles should be involved as well, including the project sponsor, subject matter expert (SME), and IT liaison.

The project sponsor funds the project and serves as the ultimate decision maker, who signs off on the game’s final version. As the game designer, you ensure the project sponsor knows what’s happening.

Table 10-1. Roles and Responsibilities of Your Design Team

The SME helps make sure that the game focuses on the content that players need to learn. Having more than one SME look at the game and contribute content may help you develop a truer picture of what needs to be learned. During development, SMEs should provide learning content you request as the instructional designer and verify the accuracy of content and any outcomes players experience as a result of decisions they make using this content. Ideally, the SME understands and plays games. If not, you can run into resistance and frustration. For example, one of the requirements a SME wanted for an online board game was that every player needed to land on every square of the board so no one would miss any content. Essentially, without the element of chance from a spinner or dice, there was no game, just a march from one square to another. What you want to avoid is letting SMEs provide too much content or too heavily influence game elements or mechanics, especially if they don’t understand game design.

If you are developing a game that runs on any type of computer or mobile device outside your existing learning management system, you need to involve someone within your IT department as soon as possible. You need guidance and decisions on these issues before you can even formulate a game design:

• Do game scores need to be sent to a learning management system?

• Are plug-ins supported with the standard browser within your organization?

• If the game is a native app, does your organization have an enterprise account where the app can reside?

• What level of security audit does your solution have to pass through?

• Who will maintain the game post-launch, answer user support questions, and troubleshoot technical problems?

• Where will the final game reside—in the cloud or on your organization’s servers? Will a single sign-on be required?

Development Tools

Finding the right development tool for your game can seem daunting. You can choose a simple template offered by many different suppliers, use a tool like PowerPoint, or leverage 3-D tools and programming languages such as Lua, C++, SQL, or Java. And, of course, there are dozens of options in between.

Understanding the various options can help guide your development efforts and provide you with a method of matching the right tool to the right type of project. Table 10-2 highlights the various tools and the games you can create with them. Be aware that with the exception of tools requiring no or low programming knowledge, the learning curve is significant. If you are doing a single game project and you want a high-end digital game, your better choice is to work with an external supplier who can do the development work on your behalf.

Table 10-2. Development Tools for Designing Your Game

The Agile Methodology and Game Design

Regardless of the type of tool you use, you need a development methodology. One method frequently associated with game development is the Agile method (Figure 10-2). This method is often preferred because it allows for rapid iterations and changes to the game as you develop it.

Figure 10-2. An Agile Approach to Learning-Game Design

The Agile method has variations, but the process is essentially a series of “sprints.” The end of each sprint, which usually spans one to four weeks, results in a working version of the game. The input to the process is the instructional goal and learning objectives, along with some relevant content to assist in prototyping. (Chapters 4 and 5 outlined this portion of the process; the Agile portion of the process usually begins with prototype development, described in chapter 7.) After you develop the prototype, your team refines and iterates, creating a new, more polished version of the game. The concept driving Agile development is that you don’t refine the game design until it is perfect and then move to development. You keep iterating on the game’s design as you develop it, until you reach a version that meets your instructional objectives and results in satisfactory learner engagement.

After the prototype process, you create a list of requirements that you think should be in the minimal viable version of the product, or MVP. The list is naturally incomplete because as you begin to develop and test the game, you discover more requirements that you need to add. Your team prioritizes the requirements, and then builds them into the next version as part of the following sprint. Once the period is over, you play-test the game again. You repeat this process until the game is ready to be developed.

In fact, the Agile process is often used in the actual development of the game as well because games look and feel somewhat different as they evolve from the first paper prototype to the final version. However, by that time, the changes should not be dramatic and made to the underlying game mechanics or game elements. Each sprint ends with the “release” of a version of your game product. Each iteration has a bit more functionality and polish until you hit the final version of the game.

Three tools help keep an Agile project on schedule: a sprint schedule, a build list, and an error log.

Sprint Schedule

The Agile process usually starts with creating a schedule that outlines the work for each sprint at a high level. The sprint schedule provides information about what is to be developed, how long it will take to develop, the timeframe of the development effort, and the time commitments of such various contributors as the artist, developer, and owner of the task to be completed. In the table, time is shown as “points,” with one point equating to a day’s effort. For example, it will take five people approximately 5.75 days to complete the first task. They are not all working on it full time, and the table indicates the exact time commitment of each person.

For the sake of brevity, Table 10-3 shows just one sprint. Multiple sprints are usually required to reach a final version.

Our intent is not to teach you Agile development, but rather encourage you to adopt a few of its primary concepts and tools. The main benefit of Agile development is its focus on small iterations and the concept of “protecting a sprint”: not adding new work into a sprint once it begins. This keeps your project moving and allows for frequent testing as you go along. The end product tends to be better and the entire process is more efficient.

If you get into developing a larger game, use Agile software created specifically to help with the process. If you don’t, you may want to create a build list using word processing or spreadsheet software. The build list is the translation of the sprint schedule into discrete tasks. It is a tool used to identify each task to be completed by an individual in a sprint.

Build List

Keep in mind that to keep the sprint moving, you should not make changes to the build list during the sprint (Table 10-4). Instead, you should discuss changes and make them before the next sprint. If you allow changes during the sprint, chaos can ensue.

Error Log

Once a sprint is complete, you’ll want to have people testing the version of the game completed in that sprint to make sure it functions as desired. If you have several people testing your game and need to collate many reports of bugs or errors, consider providing the team with a method of logging and tracking issues that arise. Table 10-5 shows a sample error log.

The error log is a good methodology for tracking problems. Sometimes the fixes are placed into the next sprint, and sometimes they are delayed based on priorities. Keeping this type of log is useful whether you are creating a tabletop game or a digital game. In a tabletop game, the errors are likely to be related to game mechanics that didn’t work as anticipated or an aesthetic that didn’t resonate with learners. In a digital game, the log might track these things as well as actual functional errors, such as a swiping function that didn’t work.

Table 10-3. Example of a Sprint in Game Development

Table 10-4. Example of a Build List

Table 10-5. Example of an Error Log

Having a process for rapidly testing and evaluating your game and then making changes will help you create the most effective learning game possible. The Agile process provides a great deal of flexibility and allows your team to adjust based on play-testers’ reactions to the game.

Working With External Resources

Fortunately, you do not have to develop a learning game by yourself. If you look closely, you may have plenty of external resources at your disposal. One idea that many instructional designers overlook is to partner with a local college’s game development program. Providing a real-world project for a class can often be a win-win situation: You will save money and students will gain valuable experience. The tradeoff is that the project process may be less polished than what you would get with a professional firm, and the quality assurance testing may be less rigorous.

For those with a bigger budget or access to an external learning game company, keep in mind that just because you are outsourcing development does not mean that you should not be involved with the process. External developers won’t know your organization’s culture or technical infrastructure. You need to be heavily involved in the play-testing, iterative design, and sprints to ensure that the learning game meets your organization’s needs. If you have a passion for game design, you may want to be part of the initial brainstorming of the game design as well.

Wrap-Up

Developing a learning game can seem like a daunting task. However, if you approach development appropriately, the process can become more manageable. Once you gather your team together and choose your development tool, seeing progress after each sprint is exhilarating. Each version brings the game closer to release and closer to being played by the learners. The next chapter will focus on deploying your game and marketing it to potential learners.