This page is meant to be a guiding document for the overall direction of the final project. If you have any additional questions about these high-level guidelines feel free to ask. Each of the various assignments that make up the final project have their own specific requirements. If you notice any case where a specific rubric conflicts with something here please reach out but err on the side of trusting this page.

Overview

The core requirement for the final project is that your team make an excellent educational game.

Questions of target demographic, subject area, platform, etc. are up to you (subject to the few limitations below). The final game you hand in should be playable by course staff without your live assistance but beyond that expectations for length and complexity of game vary depending on platform and subject matter. As a rough guideline, non-digital or tabletop games should be a mostly "complete" playable prototype providing roughly 15-30 minutes of gameplay. Digital games are more likely to resemble a vertical slice of a larger experience and provide roughly 5-15 minutes of gameplay. That being said expectations for where each team's game should end up will be refined over the course of the project in coordination with us. The timeline and deliverables are designed to be highly flexible and adaptable to whatever specific format or subject context you are planning to design for. In the language of the Playful Production Process you can think of the full arc of the final project as taking your team through Pre-Production, where by the end of the project you could pitch the concept to some entity to green light an actual production process.

In addition to turning in a Playable Prototype of the game itself, a key component of this assignment will be documenting your design and your process. You will turn in a Game Design Macro document that describes your learning and experience goals and overall plan for the game. You will also turn in a Production Log that captures the progress of your design and how things change throughout the course of the project. This means capturing brainstorming sessions, knowledge elicitation think-alouds, playtesting, prototypes, evaluations etc. This process documentation matters just as much as the final product does.

Throughout the course of the project there will be 2 check-ins where you will present the current state of your work to the class to get peer feedback, turn in a current snapshot of your work (i.e., Playable Prototype, Game Design Macro, and Production Log), and submit a short individual reflection on the state of the project. The snapshot of your work will be graded against the same rubric that will be used for the final submission so we can give you course corrective feedback.

Finally, at the end of the semester, you will show off your final product in a Final Project Showcase where you will give a "show floor" style pitch for why your game works and could be worth further development.

Limitations

You are free to design a game for any audience, subject matter, or platform subject to these limitations:

No Arithmetic Fluency Games
1. unless you can convince us that you have a really compelling and unique idea, the world has enough of these
No Digital Games using 3D Art or Animation
1. unless you can demonstrate at the Scoping Proposal stage that you already have the existing skills to work with 3D art assets.

Assessment Components and Dimensions

At each iterative stage of the project we will look for evidence of 5 Components of your work and assess them along 5 Dimensions. Each stage is assessed against the same rubric as if it was the final deliverable with the expected level of progress adjusted based on the stage of the project (i.e. a lower score is necessary to get 100% on early check-in than later ones). This allows us to give you course corrective formative feedback and helps you prioritize your focus as you progress. It is fine to not have evidence for a given component at earlier stages of the project as we expect things will fill out over time.

Components

Learning Design

The Learning Design component covers the elicitation and specification of the educational content that your game will be about. While there is generally not a prescribed order to the project, this component should probably be your first focus in almost all cases. Defining the learning goals of your game is a crucial step in your project.

To inform your design you will need to specify both the scope and sequence of the particular pieces of knowledge you are targeting. Your final learning goals should be stated with enough specificity that a teacher, instructor, parent, or other decision making stakeholder who might consider using your game could easily determine whether it was relevant to what they want to teach or learn in a given instructional situation. Further, your goals should be backed up by an investigation of what novices struggle with in your domain, either through Cognitive Task Analysis as we have discussed in class or some other Knowledge Elicitation method as your domain requires.

Experience Design

The Experience Design component covers the formulation and evolution of the kind of experience you want your game to create for players. This component will contain a lot of your thinking with respect to the Game Elements of your design. It will include thinking around your Core Gameplay Loop, the key systems players interact with, and why you chose to design those elements in the way you did. Additionally, this component will cover some aspects of whether your game design would actually appeal to players in your target demographic and how you know this.

Ideation / Prototyping

The Ideation / Prototyping dimension covers the exploration of a design space through brainstorming and prototyping ideas. Within the broader design process this dimension could be viewed as the expansion phase to explore new ideas. Within the scope of the assignment, my interest is to see that a breadth of ideas was considered rather than merely committing early to a narrow focus. As a very rough guidelines I would expect ~6 prototype iterations throughout the course of the project but that expectation depends heavily on the type of game you're making. This is also a place to highlight how learning science principles and boarder experience goals are considered in your early process.

The Ideation / Prototyping and Playtesting / Evaluation components both relate to the actual meat of the design process and are highly interrelated. In thinking about reporting on your progress you don't necessarily have to make them separate sections and it might actually be better to give more of a narrative account of the various iterations and playtests you went through to create your final game.

Playtesting / Evaluation

The Playtesting / Evaluation dimension covers the collection of player feedback as well as any evidence of learning and how it informed the design process. Counter to the Ideation dimension as an expansion phase this one represents a narrowing phase where ideas are focused based on user feedback. In addition to the results of playtests we are interested in how playtesting sessions are conducted and what insights come from that process. This is also the component where we will look for what is the evidence basis you use to judge that your game could be an effective educational game? As we (will) discuss in the Spectrum of Evaluation lecture we don't expect you do have done a full true experiment to prove your game causes learning but what is the strongest argument you can make to justify your game is educational given the time and resources you have?

The Ideation / Prototyping and Playtesting / Evaluation components both relate to the actual meat of the design process and are highly interrelated. In thinking about writing a report you don't necessarily have to make them separate sections and it might actually be better to give more of a narrative account of the various iterations and playtests you went through to create your final game.

The Game

While the other components mainly deal with your design thinking and process toward creating an educational game, the Game component assesses the ultimate outcome of the process. The majority of this component will be assessed against the others. We will be looking for how well you executed (or are executing) on the goals you originally set out to do and how your final game ties all of the work together.

Assessment Dimensions

Each component above will be evaluated along 5 dimensions:

Clarity - How clear and understandable is the work? Can we understand what you intended to convey?
Quality - How well executed is the work? Is there a clear attention to detail and are things well put together?
Credibility - How credible is the work presented? Is it believable and well thought out? Does it appear to be backed by rigorous processes and/or principled decision making?
Integration - How well integrated is the work of a given component to the others? Does the work in the component connect to the others? Does it seem to be aware that it is situated within a broader process?
Innovation - How unique or novel is the work? Is there some really cool or interesting ideas involved?

Deliverables

There are three primary artifacts you will hand in for the final deliverable and as drafts at the Check-in stages of the project: a Game Design Macro document, a Production Log, and a Playable Prototype. This set of deliverable formats is a relatively new introduction to the project and my hope is that this helps to streamline the process but feel free to ask questions at any time about what is expected with the structure of these docs.

Game Design Macro

A Game Design Macro is a short document describing the high level plan and direction for your game. In general, the goal of a Game Design Macro document is to describe all the important parts of the game to an extent that could help set direction on a project as it moved from pre-production to production. The Playful Production Process book has an extensive chapter on making these documents, but we'll be adapting their description a bit to an educational game context. The exact contents of each team's macro document will shift a bit based on the format of game you're designing but in general they should have at least these two sections:

Learning Design Overview

This section should describe the general plan for the learning you are trying to achieve in players and how you plan to accomplish it. Concretely this would describe your specific learning goals, the learning mechanisms you're targeting to achieve them, and any particular learning targeted aspects of your player experience design. Most of the evidence for the Learning Design component of the project will be reported here.

Game Design Overview

This section should describe you game's core design aspects. It should contain a short introduction to all the most important aspects of the game design or narrative elements of the game. Most of the evidence for the Experience Design component will be reported on here. The exact structure of the Game Design Overview is pretty game and genre dependent, beyond describing the Core Gameplay Loop of your design along with any key object, verbs, or rules you might consider:

If you game has any important systems or economies what are their loops?
If your game has characters who are they?
If you game has a story what is the general arch of the story?

The Playful Production Process also describes a Game Design Macro Table as a component of a Game Design Macro. Whether or not you make one of these depends on the structure of your game. If you are making a digital game with a series of levels you might consider making one to lay out your level and learning progression together, however, if you are making a tabletop game, it may be less relevant to include.

Production Log

The goal of the Production Log is to give us a window into your process and provide a central hub of links to your actual working documents. Throughout the project we assume you will be working in a wide variety of documents and formats. You might have Miro, Figma, or Mural boards for brainstorming, task descriptions and observation notes from knowledge elicitation, mood boards or work in progress art, iterations of physical prototypes, repositories of code, etc. The Production Log should provide us links to all of these things in chronological order so we can follow the development of your projects over time. Essentially, anything you make relevant to the project should be linked in someway from the Production Log. Most of the evidence for the Ideation / Prototyping and Playtesting / Evaluation components will be reported here.

Beyond being a running timeline we're not necessarily looking for much extended description or explanation in the Production Log. You should provide enough description that we'll know what we're looking at if we follow links, but otherwise the Production Log should be designed to support your work as much as possible. Of the various deliverables this one is the most "for the sake of being a class assignment" deliverable. In practice you likely wouldn't document process to this level of fine granularity but it will help us to see what you're doing and be able provide feedback and direction.

Playable Prototype / Vertical Slice

In addition to the documentation of the your work you will also turn in a playable version of your game. The exact scale of what you turn in will depend on the type of game you are making. If you are making a non-digital or tabletop game then you should plan to turn in a mid- to high-fidelity copy of your game along with a final set of written instructions. If you are making a digital game it is fine to approach it as more of a vertical slice of a larger potential game, which would showcase at least 1 finalized and polished example of each major type of gameplay along with the menu or other interactions to navigate between them (ex: design 2 levels and the logic to move from one to the next).

Some things you should consider in turning in your final game:

We need to be able to play the game without your assistance so include any installation instructions, tutorials for controls, or rule books for board games.
The game can be single or multiplayer (requiring more than ~5-6 players will make it more difficult to grade but not impossible)
See the FAQ for the kinds of platforms we can reasonably support.

Project Timeline

The Final Project will be broken into several stages that will each be there own assignments. Each of these assignment stages has an implied goal to cover a stage in the design process but is also left flexible to accommodate the iterative design process that may not line up perfectly with the calendar. In general, we do expect that iterative work has been done between stages and that any work has been well documented at each check-in, but what exactly that work is will depend on the specifics of your projects.

The structure of each deliverable will be as follows:

Scoping Proposal

You will first turn in a scoping proposal for the final project. The purpose of this proposal is mainly to establish your team, an initial direction and collaboration plan for your team. It is graded as pass/fail for each of its pieces and you will get feedback from us before the next step.

Concept Pitch Presentation

To kick off the final project process we will have a class session devoted to each team pitching their initial project concept to the rest of the class. This pitch is mainly to establish your initial direction to the rest of the class and to gather feedback from your peers on things you might consider as you move forward.

Check-in Reports + Progress (One and Two)

Twice throughout the process there will be intermediate check-ins. At each check-in point you will turn in a brief report describing your current status and plans for each of the components described above. This report can be roughly 1-2 paragraphs per component, however, it should also link to working documents in your team's working directory that would be evidence for each of the dimensions so we can provide more targeted feedback on the work itself. The goal with these check-in reports is to help us provide you with formative feedback without having to spend too much time writing lengthy reports for reports sake.

Check-in Presentations (One and Two)

Along with the Check-in Reports, you will also give a short presentation to the class describing the current status, challenges, and next steps for your projects. During these presentations we will also use a structured peer feedback process to coordinate additional feedback to your team. Due to the number of teams we will split the check-in presentations across multiple days and use the remainder of each presentation day to do further work shopping of teams' ideas. The primary goal of these presentations is to the elicit peer feedback and direction from the class. Secondarily they are useful for tracking your progress over time.

Final Project Showcase Pitch

In general, the Final Project Showcase will be an opportunity to show off your game to a general audience. The event will be open to attendees outside of the course. Each team will be given a booth/table space to setup their game and present it to attendees. You will not be required to create a poster or anything but you should be ready to demo your final game to random attendees. During the event, I will cycle around between booths for you to pitch me your game. This presentation will differ from the check-ins in that you will have more time and you should treat it more like a product pitch on a conference show floor rather than a formal pitch with slides.

This year the Final Project Showcase will take place as part of the Game Creation Society's (https://www.gamecreation.org/) Spring Release event in conjunction with a few other Game Design Courses. This event will take place 3:30-9:00 April 26 in the UC. More information on the logistics of the event will be announced as we get closer.

Final Report + Game

This will be your final description of the game and the game itself. This deliverable will be different from the check-ins as you will turn in your completed Game Design Macro, Production Log, and Playable Prototype rather than write a short report on progress.

Timeline of Stages

Stage	Rough Expectation of Progress	Date
Scoping Proposal	Your team composition and a vague idea of what you want to target	Mar 1
Project Pitch	A more coherent sense of target but still general	Mar 14
Check-in 1 Presentation + Report	Learning Goal elicitation should generally have been done	Mar 26 & 28
Check-in 2 Presentation + Report	A couple iterations of prototyping should be done	Apr 16 & 18
Final Game Presentation	A playable demo of the game should be ready to publicly showcase to an outside audience	Apr 26
Final Game + Report	A final polished game should be completed after several play tested iterations	May 1

FAQs

If you have any questions about these requirements you can bring them up on the FAQ discussion board or reach out to course staff on Slack.