Milestone: Demo / Vertical slice

The first milestone will be a demo or vertical slice of the project.

It is due Friday October 29

On Friday 22 I will check with every team about the tasks to do by the milestone, so create and assign the cards on codecks.

It has to be in-engine and playtestable (programming)

Ideally from the beginning to the end even if it involves a lot of placeholder assets.
If that’s not possible, make sure there is at least a representative portion of it functioning correctly. It doesn’t have to be the beginning.
Prepare some supplemental material to explain the rest of the game to the testers.

It has to include a “beautiful corner” (art)

Same as visual vertical slice. It should exist within the grayboxed rest of the game.

“The Beautiful Corner Simply put, a beautiful corner is a part of a level, enough to fill a single screen on the player’s computer, where the art and audio have been polished to look and sound as good as they will in the finished game. It’s a little corner of the game which has been made beautiful (or if your game doesn’t conform to traditional notions of beauty, which has been worked, refined, or crafted). In a 3D game, we might point the camera into the corner of a space, where two or more walls intersect with the floor and ceiling. The camera’s “view frustum” is the wedge-shaped volume of space that is visible from the point of the view of the camera, given its field of view, aspect ratio, and depth-culling settings. Everything that we see of the beautiful corner inside the camera frustum should look great. That includes not just the background but the objects that are present too. We should beautifully animate anything that will be moving in the finished game, and everything there should sound great. Never overlook sound design at any stage of the game design process.”
from A Playful Production Process by Richard Lemarchand

It’s a tool for planning and scoping (production)

Our projects are relatively “safe” in terms of gameplay but can be content-heavy so your goal is to make sure the scope of the project is appropriate for the time you have.

A function of this milestone is to set up the pipeline from idea to the game engine, and collect information on how much it takes to prepare assets.

The producer should seriously consider incorporating the documents made so far into a game design macro

Game Design Macro

A game design macro is a schematic version of the overall design document.
Macro is in contrast with micro design documents which expand each line of the macro.

Here’s a template also taken from A Playful Production Process by Richard Lemarchand

Here’s an example of macro for a student project (Alpaca Stacka, co-developed by CMU alumna Michelle Ma)

The game design macro represents a commitment to an upper limit for the size of the project in terms of content and structure.
Nothing should be added to it during the production, to avoid “scope creep”.

The macro should include every single part of the game, including menus and titles, not just the “core” parts.

Scheduling

Based on the macro, the producer should make an asset list that can be added to the codecks with priorities and assignments.

The producer should make a very conservative (not optimistic) estimate of the person-per-hour time you have for the game:
Number of hours each team member will work in a week X weeks left X number of team members

Track the time it took to complete tasks so far so you can estimate if you are wildly overscoping the project.

Codecks can generate burn down charts a very common tool for visualizing time vs tasks left – read more about codecks metrics features