Game Design Quests and Assessments
Table of Contents
- Required Games
- Critical Analysis Quest
- Unity Engine Quests
- 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.
Games currently under consideration are:
- A Short Hike
- Celeste
- Balatro
- Return of the Obra Dinn
- Summerhouse
- Fez
- Chicory: A Colorful Tale
- Untitled Goose Game
- Papers, Please
- Undertale
- Headlines and High Water
- Loddlenaut
- Wake: Tales from the Underlab
Quest Submission
No submission required specifically for playing the games.
Critical Analysis Quest
First, watch this:
Quest Information
What is a critical analysis, and why do we care?
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).
Critical analysis 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.
Critical analysis 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.
Critical analysis 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 assignment, write a paper (probably at least 2-3 pages) that does the following (and most likely somewhat in this order):
- Give a high-level description of the game, game’s history, or other introductory information you think is appropriate. I would expect also to see what you believe the games main aesthetics are here (as defined by the MDA paper).
- Describe the game’s formal elements. Do not interpret at this point, simply state what is there.
- Describe the results of the formal elements when put in motion. How do the different elements interact? What is the play of the game like? Is it effective?
- Specifically discuss the mechanics, dynamics, and aesthetics 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?
Some questions to ask yourself during a critical analysis at various stages:
- What challenges do the players face? What actions can players take to overcome those challenges?
- How do players affect each other?
- Is the game perceived by the players as fair? (Note that it may or may not actually be fair. Perception and reality often differ.)
- Is the game replayable? Are there multiple paths to victory, varied start positions, or optional rules that cause the experience to be different each time?
- What is the game’s intended audience? Is the game appropriate for that audience?
- What is the “core” of the game - the one thing you do over and over that represents the main “fun” part?
NOTE: Literally just answering the above questions WILL NOT result in a good score. I expect you to put some thought into how best analyze the game you are looking at. Some of these questions make no sense for certain games and tossing “an answer” to them in your paper would be frowned upon.
Quest Submission
Submit a PDF of your paper to the appropriate assignment in Gradescope.
An example Critical Eye on Hearthstone from Spring 2014
You will complete this assessment at least 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)
- optionally one more time as your Player’s Choice Quest
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.
Unity Engine Quests
There will be a number of assignments to learn Unity. The final number and nature of these assignments has not been determined yet.
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.
Setup and GitHub Classroom
- One member of your team should accept the GitHub Classroom assignment at https://classroom.github.com/a/lSFanMG- and name the repo the name of your game.
- I expect your team to use good development practices with git, branching, etc.
- You can use any frameworks/libraries that you find available. Make sure to cite them!
Project Check #1
At this stage, you must have:
- The repo initialized
- The project created and can launch to at least Cornflower Blue
- Some ideas/examples of what your sprites/assets could be
You do not have to have any significant functionality at this point. However, note that your design document is also due on the same day!
Project Check #2
At this stage, you must have:
- Your basic mechanics working to the point that they can be demoed
- More sprites/assets in the game
You do not have to have done any significant level design at this point.
Project Beta
At this stage, you must have at least two levels (or whatever equivalent that is for your game) that are fully functional and can be played by someone NOT on your team without significant instruction or guidance. We will be doing playtesting of games and the game needs to be up and running!
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.