Game Design Quests and Assessments
Table of Contents
- Required Games
- Critical Analysis Quest
- PICO-8 Game Jam Quest
- Unity Game Jam Quest
- Team Game Project
- Team Game Physical Prototype
- Team Game Design Document
Required Games
Quest Information
For this class, you are required to play two different games that we will analyze throughout the semester.
| A Short Hike by adamgryu | Celeste by Maddy Makes Games |
|---|---|
 |  |
| Available at: itch.io, Steam, Nintendo eShop, and other platforms | Available at: itch.io, Steam, Nintendo eShop, and other platforms |
| Objective: Complete the main story of the game | Objective: Complete through the beginning of Chapter 4 with and/or without assists turned on |
| Estimated time to complete: 2 hours | Estimated time to complete: 3 hours |
Notes about Celeste:
- We are going to be talking specifically about the assist options in Celeste. Even if you can get to Chapter 4 without the assists, make sure to play the game with them at some point to see how they work. Also, if you need to use the assists to make it to Chapter 4, that’s fine. Try to at least get through Chapter 1 without them, however.
- While a controller is not strictly required, you’ll have a better time with the game if you do not use a keyboard. Controllers are available to borrow, if needed.
Quest Submission
No submission required specifically for playing the games, but you need to complete them before the Mini-Boss Battle.
Critical Analysis Quest
First, watch this:
Quest Information
What is a critical analysis, and why do we care?
A critical analysis is not just a game review. We are not concerned with how many out of five stars, or any numbers from 0 to 10, or whether or not a game is “fun” (whatever that means to you). It also does not just mean a list of things that are wrong with the game. The word “critical” in this context does not mean “fault-finding,” but rather a thorough and unbiased look at the game.
Analyzing a game in this way is useful when discussing or comparing games. You can say “I like the card game ‘Bang!’ because it’s fun” but that does not help us as designers to learn why it is fun. We must look at the parts of games and how they interact in order to understand how each part relates to the play experience.
It is also useful when examining our own works in progress. For a game that you’re working on, how do you know what to add or remove to make it better?
To complete a Critical Analysis Quest, write a paper (probably at least 3 pages) that does the following:
- Give a high-level description of the game, game’s history, or other introductory information you think is appropriate. (Probably roughly a paragraph or so - enough to get your point across, but doesn’t go too deep into details.)
- Describe what the game actually is. Example: How would you describe the gameplay of Super Mario Bros. Wonder to someone that had never played it before? You want to tell them enough so that they get a good enough sense of the game and gameplay that when you go into deeper detail about aspects of it, they can follow what you are saying.
- Pick one (or two) main “interesting” aspects of the game and describe why and how they are interesting in the context of the mechanics, dynamics, and aesthetics and the formal elements of the game.
- Example: What about the wonder flower mechanic in Super Mario Bros. Wonder sets it apart? What aesthetic is it drawing on? How does it change the mechanics of the game?
- Try to understand why the designer chose those elements and not others. Why this particular player structure, and why that set of resources? What would have happened if the designer had chosen differently?
Basically, prove to me that you have some thoughts as to why this game does what it does, how it is executed, and why it is interesting to consider. Comparing and contrasting how this game did something versus another is another way of approaching this question, but shouldn’t be the only thing a paper utilizes.
Quest Submission
Submit a PDF of your paper to the appropriate assignment in Gradescope.
You will complete this assessment twice:
- once for either A Short Hike or Celeste
- once for a game of your choosing (including the other option of A Short Hike or Celeste)
If you choose your own game, it can be a game you have already played, although you may need to refresh your memory. If you need some thoughts on what games to play, I’m happy to offer suggestions.
Some content here used with permission from Game Design Concepts by Ian Schreiber.
PICO-8 Game Jam Quest
See Canvas.
Unity Game Jam Quest
See Canvas.
Team Game Project
Quest Information
Build a game! Okay, you need more than that… :-) Every game will be different, so there’s no way to say “you must have X feature” in reality. But here is how the staff will evaluate your games.
Is it a working game?
Simply put, the game should function without any obvious bugs or failures. The game should:
- play and feel like a completed product, not something still in beta form;
- have an obvious start and end to the game, with the ability to “play again,” depending on the nature of the game;
- have working and understandable controls.
Points are earned for how well the game performs during playtesting.
Is the game engaging?
Does the game grab the player and make them want to play more? A successful game will:
- draw the player in and entice them to keep playing;
- have a unique and interesting mechanic;
- feel good to play (appropriate controls, difficulty, etc.);
- be fun/enjoyable to play.
Does the game meet its aesthetic goals?
Can a staff member quickly and easily identify one or two aesthetics from your game? Does your game focus on and emphasize those aesthetics?
How polished / refined is the game?
We do not expect perfect art assets or anything like that. We do expect the game to look “put together,” is playable, and feels like something that could be given to someone not in the class and they could play it without a ton of assistance.
How did the team work together?
Game documentation, team evaluations, use of GitHub all fall under this category. XP is earned here through:
- high evaluation marks from teammates;
- the documentation submitted follows the outline and contains all necessary information;
- GitHub was used effectively, showing good software development techniques.
Quest Submission
In the root of your repository, create a README.md file that contains the following sections in this order, with headings identified to make it easier to read through the document. Also include this information in a PDF that is submitted to Gradescope.
- Name of game
- List of all team members, including computing IDs
- GitHub link (PDF for Gradescope Only)
- Game pitch - Two to three sentences describing your game (you can reuse old text for this from previous assignments)
- How to play - What do we need to know in order to play the game? Controls? Setup? Anything and everything you think we need.
- Amount/type of content available - Explain how many levels, what major features are available, etc, basically so we don’t miss anything you created
- Lessons learned - What did you learn about game development through this process?
Team Game Final Submission Document Template
Team Game Physical Prototype
Quest Information
Using the materials provided, create a physical prototype of some aspect of your game. This could be a level or a mechanic, but it should be something that is:
- Representative of your game
- Shows part of your design process for your game
- Is “playable” in some fashion
- Shows some thought was put into the design
Basically, the goal is to do a “rough draft” of some aspect of your game to help you think about how you will translate your design into code. Consult the prototyping chapters of Fullerton for more information.
Quest Submission
One member of your team should fill out the following document: Physical Prototype
As a part of this document, you MUST have pictures of your prototype!
We will also be demoing these in class on Monday, March 20. Make sure yours is ready by then! (The final version of the document is not due until 11:59 that night.)
Submit the document into Gradescope, making sure to add all team members when submitting.
Team Game Design Document
Quest Information
Based on the generic game design document by Benjamin Stanley and Alec Markarian @ https://dkrikun.files.wordpress.com/2016/11/game-templatea-strategy.pdf, complete your own game design document from this Google Doc template: https://docs.google.com/document/d/19fnqYeRXly8SpMzW-6bxTWp-Dn4pprCihvJw_edlhtE/edit?usp=sharing.
Quest Submission
One member should submit the design document as a PDF into Gradescope, making sure to add all team members when submitting.