A cornerstone of our Game Production program at The Los Angeles Film School is that student teams spend three months creating a game of their own design. At the beginning of each month-long term the team outline their goals for their game project and presents the general idea, expectations and approaches in a Mission Statement. The team then develops their game to meet these tools. And the end of the term, the team discusses their successes, shortcomings, and how they might improve. This discussion is used as a framework for the Post-mortem, which is the term’s final team assignment. The team repeats this process in the second and third months of the project.

The process we have used to teach game production has some commonalities with Scrum, a development methodology that has grown in popularity in the game industry for several years. In Scrum, the product owner creates a Product Backlog of features that the development team needs to implement in the project. The team then develops the projects in a series of sprints, which are fixed-length time periods for producing a demonstrable iteration of the product. At the beginning of each sprint, the team holds a planning meeting to decide which features they can implement by the end of sprint; this list of features is the Sprint Backlog. The sprint concludes with two meetings: 1) a Sprint Review meeting, where the team demonstrates completed work to the product owner; and 2) a Sprint Retrospective Meeting, where the team discusses improvements to their process for the next sprint. The team uses the feedback from the two meetings for planning their next sprint.

Scrum and other “Agile” production methodologies are great in that they promote planning, collaboration, adaptability, and transparency while encouraging rapid and flexible responses to change that may be necessary due to the design, technological, marketing, and client demands of game development. Unfortunately, it does require team members to have experience and discipline, which are not common traits of student teams. When I began teaching the Game Production class a few months ago, I found that students wanted to skip over the planning process entirely and jump right into development. Being students, they would also make the typical noob mistake of wanting to start producing all the game assets (art, audio, levels) immediately rather than on focusing on ensuring that the core game mechanic was fun to play. As a result, the game they produced at the end of their three-month production period was not as engaging or polished as it might be if they had taken a more thoughtful approach.

Over the holiday break I came up with a new plan for teaching our Game Production class. This new plan is based upon a hybrid methodology that is more typically used in the game industry. The hybrid approach is built upon a so-called Waterfall, or sequential, approach in which the team delivers the game in stages according to pre-determined milestones, but with the Scrum methodology being used in the time interval between each milestone.

For our three-month production period, I specified three milestones, each of which must be completed by the end of its respective month-long term:

1. First Playable Deliverable: One complete game level, or in a game without levels, 10 minutes of representative game play.
2. Alpha Deliverable: All game rules, resources, obstacles, goals, outcomes, features, and menus implemented. Art, audio and text (up to 50%) may be placeholder.
3. Beta Deliverable: All game art, audio, and text assets implemented. Game is fully playable through all player choices and game paths.

Students must present a playable version of the deliverable, along with a player survey, at the LASF Game Fair held on the last Thursday of the month so that it can be play tested by Game Fair attendees. The playtest feedback is used to produce a final version of the deliverable as well for planning of the requirements for the next deliverable.

I broke each of the three-month production periods into two-week sprints so that I and the other instructor with whom I am teaching the class can provide feedback for the month’s deliverable. At the beginning of each sprint, the student team must come up with a task list for each student to complete by the end of these sprint. This is a group assignment (so that individual team members would collaborate with the project manager on the tasks they would do and the time needed to complete them) that is graded (otherwise, the students would be inclined to forgo doing the planning in favor of work they would be graded on).

I have the students use a planning template that was very graciously provided to me by Margaret Moser, Assistant Professor of Game Development at the University of Southern California. Here is an example Backlog and Student Task List:

At 9am during each class day of the sprint, the students have a Daily Standup. That means that each student must actually stand up – not work/play on their laptops. The project manager runs the meeting, asking each student three questions:

1. What tasks did you do since our last standup meeting?
2. What tasks will you do completed before our next standup meeting?
3. Are there any obstacles in your way (that you need my help with)?

If a student team member doesn’t have tasks to do that are specifically related to the milestone requirements on a particular day, I offer the following “menu” of additional tasks they may do that day:

• Write a 500-word competitive analysis comparing/contrasting the game in development against a published game with the same genre, theme or game mechanic.
• Write a Foundational Analysis of the game (first month only).
• Write a Structural Analysis of the game (second month only).
• Write a Dramatic or Fun & Accessibility Analysis of the game (third month only)
• Set up a Wix website for promoting a game.
• Write a 500-word blog post, with images of that day’s development progress.
• Set up social networking accounts on Twitter, Facebook, YouTube, Pinterest, and Instagram for promoting the game.
• Post information about the game’s progress on Twitter, Facebook, Pinterest, and Instagram.
• Create a mock-up of box art for the game.
• Create a mock-up of an advertisement for the game.
• Create a game trailer and post to YouTube.
• Create a video blog or interview and post to YouTube.

I and the other class instructor will grade each student on his or her overall individual productivity and contributions to the project, adherence to the goals set at the Daily Standup, professionalism, and attendance.

At the end of the sprint, the class either demonstrate the game to the instructors for non-graded feedback (first sprint of the month) or make the game available for play testing at the school Game Fair (second sprint of the month). For the first sprint for the first month of production, the team is also required to implement the game’s core mechanic: the game-defining action that the player will most often be performing while playing the game.

Today is the first day that I’ve implemented this new methodology in the class, and so far so good. With only a bit of pushing on my part, they put together a plan for what they will develop during the first sprint, with an emphasis on creating a fun game mechanic. I’ll keep you posted on how things go after that!