AIE's Minor Production Process
Tags: production, gamedev, scrum, academia
Published: 2019-09-18 00:00:00

---
title: AIE's Minor Production Process
published: true
description: "Modeling our academic production process after industry processes."
tags: production, gamedev, scrum, academia
date: 2019-09-18 00:00

cover_image: https://thepracticaldev.s3.amazonaws.com/i/gzwr2jmvbfngj3allo7d.jpg
canonical_url: https://terrehbyte.com/aie-minor-production-process/
---

_This was edited by [Lizz Rizzo (@lizz0id)][lizz] and published for the [Academy of Interactive Entertainment][aie] on its website_.

[lizz]:https://twitter.com/lizz0id
[aie]:https://aie.edu/aie-minor-production-process/

One of the most valuable parts of the course for our Game Development students is the opportunity to collaborate with their peers from other disciplines for their final project at the end of each school year.

Internally, those projects are referred to as "[Minor Production](https://aie.edu/what-is-minor-production/)" and "Major Production" respectively for our first year and second year game students. Every year, students fall prey to the same problems: communication issues, gaps in technical skill, unclear direction from faculty, or just interpersonal conflicts in general. This year's changes continue the trend of improving the process, which in turn creates a stronger student experience.

## Adopting Scrum for the Students

Our efforts to introduce Scrum to students to posture healthy team habits have been successful in past Minor Production projects, which simulates a studio environment. Teams naturally find the transition to be rough at first, but many later report feeling comfortable with the process by the second or third sprint.

We treat attendance as if the students were working full-time in a studio environment. Honoring the daily stand-up was difficult for students that had trouble getting to class on-time. Efforts from students to flex the schedule or conduct multiple scrums to mitigate issues were effectively trading attendance issues for communication or productivity issues. Any further issues are escalated to be monitored under administration.

Faculty designates specific blocks of time to allow for Sprint Planning and Sprint Retrospective sessions. While students are always eager to criticize their work, teams were much more adept at identifying and resolving issues this time around. Rather than focusing on the problems with the product alone, teams were able to also address issues with their process. Pipeline problems like scale issues were non-existent in later cycles.

In addition to the above rituals, we ask each team to present recent developments to the class as a whole. Public presentations not only reinforced the idea that their work should continue to create value for the player, but also provided faculty with an opportunity to review each team's work in a single sitting. If there were any issues with a team's priorities or progress, it would become immediately visible to all faculty members. This improved our response time and efficacy in resolving issues on teams.

To facilitate project management, we use Hack n' Plan, a user-friendly service that models some common Scrum concepts like backlogs and user stories. Its categorized Kanban boards allowed students to track task progress by discipline to minimize clutter.

## Switching to Perforce

A major software change for this year was the transition away from Git as our preferred version control solution to Perforce in response to industry feedback. From the student perspective, Perforce allowed them the ability to lock down files to prevent others from making changes while they're working on it.

Merging two sets of changes to code is doable, but reconcile concurrent changes to art assets often resulted in lost work. Removing the need to merge allowed us to eliminate a way for students to lose their work. Unfortunately, students still lost work from improper use of Perforce, as was the case with Git.

A side-benefit of adopting Perforce was the reduced difficulty in training artists to work in-engine to improve their iteration time. Programmers were able to focus on bug-fixes and feature development rather than integrating art assets (at least, to a lesser degree). This also meant that artists could get more immediate feedback on their work rather than being blocked by busy programmers. In both cases, this led to better iteration times which allowed for more refined work from all departments.

## Publishing for itch.io

![A screenshot of Shakti Unlimited's itch.io page, featuring controls and copytext](https://thepracticaldev.s3.amazonaws.com/i/05xl0rtfzb4i3arvbqmb.png)

Minor Production had always been conducted strictly internally, which left students unprepared for when Major Production rolls around due to its inclusion of a public showcase. To address this, each team had to publish on itch.io in order to better inform the process of creating a public brand for the game.

This was a double-win for us: students were able to publicly showcase their work online while also giving them an task with a very measurable outcome. Work on the page itself naturally led to questions about branding and messaging: how would a team describe its product to the public? It also promoted discussions around creating instructions for on-boarding players into the game, which often gets forgotten in the midst of the development.

All of the Minor Production projects are publicly viewable on our [itch.io profile page](https://aieseattle.itch.io/).

## Introducting the Game Design and Production Department

Every AIE campus struggled with the integration of the Game Design and Production (GD&P) department, which is a new venture comparted to its Game Programming and Game Art counterparts. In our case, GD&P students found difficulty with finding parts of the production process to take ownership of.

Documentation of design work on the game clearly fell on GD&P in the form of Word documents and project management tools. Some found themselves largely monitoring Hack n' Plan while others felt trapped under paperwork for weeks on end.

The confusion only worsened with expectations around GD&P's direct contributions to the game itself. How programmers and artists should expect to collaborate with their designers was unclear, which led to numerous cases of miscommunication. Teams were left with levels they weren't sure how to build or game loops that needed more playtesting and refinement.

Conflicting messaging also occurred internally around the responsibilities of the GD&P department leading to confusion even within faculty members, which then cascaded down to the students. We hope to better form next year's curriculum around a more well-defined set of expectations will benefit everyone.

## Plans for Next Year

As we plan for next year's production projects, the ultimate goal still rings clear: we must be training students on the skills that will help them most with navigating the challenges they'll face in the workplace.

Making them effective at their craft is not enough by itself when students expect to work in an industry that needs collaboration from so many different fields and specialties. The production projects are a primary way for us to train and evaluate students on their job readiness.

Areas for major improvement for us include:

- Better modeling the different roles that exist on game development teams
- Training students on the framework of Scrum and AIE Seattle's implementation
- Addressing common pipeline issues ahead of the production projects with prior lessons

We poured a lot of effort into formalizing many of the "Scrum" or "pipeline" or any myriad of broad expectations that we had placed on the students in prior years. Now with the groundwork laid out, we can focus on how we can prepare and communicate with students during for future production processes.