Game Two

Game Two

START

Game Two! This one is open-ended, you can create any game you like. The more ambitious a game is, either because of a larger feature set, more unique mechanics, or more technical challenges, the less time you will have to refine the actual game play. Simpler games have more potential to be fun quickly, so decide what your goal is for this short, two-week sprint.

There is no checklist for this project. It's time for you to write your own meaningful commit messages that clearly described the features, fixes, and changes that a commit contains. I will give you less points if I have to search and guess what you did.

You can work with a partner if you like. Coordinating work is an extra layer of challenge, but if you have good process you can get more done and it's more fun to work with a friend. If you work in a team, you must use branches and when you merge a branch you must detail the contributions of that branch in the commit message. Each partner only gets credit for the things that they commit.

Same rules as before. You can use assets, tutorials, etc, but you must have a citations.txt file in the root of your repo that cites everything that you used. I need to know what is your work that I am giving you credit for. You are encouraged in this project to experiment with AI assistance and develop your ability to use the tools and evaluate them. You should also cite art assets even though that's not being graded here. Get in the habit of giving people credit where due.

Pay attention to the class activities below. You are expected to have new code committed for each one. Grading will look at the progression of the game and how you iterated on your design. Showing up with a game on the last day will receive a low grade.

When you make your new project DO NOT FORGET TO PUT THE .gitignore IN THE PROJECT FOLDER.

Intro to 3d example repo for you to follow along: https://classroom.github.com/a/R-5gGY64

Monday, August 12

1
Kickoff

Game Design

Answer the questions below in a design.txt in the root of your repo. Upload pics of your sketches.

High level: Objectives & conflicts

  1. What is the player's goal, and what do they need to do to achieve it?
  2. What are the most significant obstacles/conflicts to the player succeeding?

More specific: The central system dynamics

  1. What is the most important player action? The most common?
  2. List the possible ways that the environment can respond to those actions (outcomes).

Commit to a specific idea

  1. List 2-3 player experiences that will make the game fun and interesting. Be specific and player-focused!
  2. Draw out a sequence of screenshot sketches showing what a player would see during those critical gameplay experiences from question 5. Pay attention to what information is on screen (environment and UI elements). You have to commit to a certain visual perspective here (2d/3d, fixed or rotating camera). Use your phone or a webcam to scan those sketches and add them to the doc.
  3. Write a 1-2 paragraph description that "sells" this concept to potential players. Try to capture what makes it uniquely interesting. Describe at least the premise, aesthetic, core gameplay and how you win or lose.
  4. Working title

Rapid Prototypes

You will build a rapid prototype to explore some part of your game design as quickly as possible. There are two types:

  1. Gameplay prototype: Build something playable to answer a specific question about the player experience and whether it is enjoyable.
  2. Technical prototype: Do a proof-of-concept for code functionality you're uncertain about. This reduces project risk by quickly figuring out if a high-risk part of the design is feasible or needs to be replaced.

Your gameplay prototype should be narrow in scope, player-focused, interactive, and focused on common interactions. You want the player to perform actions, get feedback, and see outcomes to complete the loop. Keep it simple and focused—you only have around a week.

Avoid poor choices like intro screens, menus, additional levels, graphics and sounds, or things that only happen at the end of the game (e.g. boss fight). Focus on the core interactions with the environment (moving, fighting, dialogue, crafting, dodging, abilities, etc.) that are supposed to make your game fun. Don't overlook feedback to let the player know what's happening (e.g. hit, miss)—it's critical.

Write a paragraph detailing your prototype in your design.txt. Start with what aspect of gameplay it tests or what technical concern it addresses. Be very specific about exactly what playable experience or proof-of-concept you will deliver. Don't just say "Make X"—detail how the entire planned interaction will go (player and entity actions, reactions, outcomes) and what constitutes successful delivery.

Wednesday, August 14

2
Prototype

Prototypes

Everyone will give us their pitch from the design doc.

Code Review

With a partner, do the follow process both ways, with each of you acting as the developer and the reviewer.

Part 1: Explanation

The developer opens their project. Commit and push first! (Make sure that your current code is safe.)

The developer explains to the reviewer what functionality they prototyped.

Do this both ways.

Part 2: Review

Switch computers! As reviewers, each of you are now working independently, not together. Download this template code_review.txt file into the root of the repo (not in the Unity project).

Run the game a few times and assess the features that the developer described to you. Do they work? Are they complete?

Summarize in code_review.txt the functionality that the developer described and what you found when you ran the game.

Go through the applicable code files line-by-line and leave comments in the files on the following. Keep a list of the files you review in code_review.txt.

  • Faults: Code that doesn't work as intended. Doesn't run, errors, doesn't implement the functionality, missed edge cases.
  • Style and intent: Hard to read, can't tell what it's doing or why. Formatting, naming, comments, simplicity, clarity.
  • Structure: Doesn't fit with the code or framework (Unity), would be hard to adapt and maintain. Classes, functions, consistency, redundancy, error handling, data structures.

Commit and push the review, which includes the comments in the code and the code_review.txt.

Part 3: Discussion

When you are both done, walk through your review comments with the developer.

Monday, August 18

3
Playtest

Playtesting is a critical part of the game development cycle. To an extreme degree, player experience is the only thing that matters about a game. This is similar to agile development in apps, which are also defined by the user experience, but moreso.

First, we'll do the in-class playtest activity using this playtest_script.pdf. (I'm bringing printouts.)

Second, create a text file in the root of your repo called playtest.txt. In it, write a summary of what you saw and heard from your testers. One or more paragraphs, but no more than a page. What worked, what didn't, what was fun, what was frustrating, what was confusing, and what are your plans to address those issues.

Wednesday, August 20

4
Checkin

The point of this check-in is to make sure that everyone is on track for Friday's final.

Option A

Come to class and get stuff done. I'll be there to answer questions, help with troubleshooting. I will also want to hear from everyone where you're at and what you're aiming to finish up. If you have any doubts or questions or feel like the project isn't going how you hoped, this is an opportunity to triage and let me see where you're at.

Option B

If everything is going great and on-track with no questions or concerns, then you can do this remotely. Make a nice, detailed commit before the end of class time describing where you're at and what you're aiming to finish up. I'll look for these after class.

Friday, August 22

5
Complete