Game One

Let's make a game! The default choice is to extend the ARENA V2 project, but if you prefer you can work off the PLATFORMER or BOUNCE project if that fits what you want to make better.

Start by copying the relevant project into this new repo. You'll be working on the game all week, it's due next Monday.

Grading for the game is not based on how fun it is, as that would be unrealistic. It is based on participation and progress. The goal is to make something quickly, try it out, and improve it. That's why we have these in-class activities throughout the week.

If you didn't finish the ARENA V2 assignment (new enemy), I will treat your game one work as a late submission for that, assuming that you work off the ARENA V2 code and make at least one new ability, effect, behavior, and enemy for your game. You should be doing that anyway.

Monday, August 4

Get a partner, open a text document, and take turns being the one to type.

Generating Ideas

This is brainstorming! Go fast, say the first thing that comes to mind and keep going.

Alternate coming up with brief character descriptions. Four total. One sentence, give them a recognizable role or type and some defining characteristic. Example: Jorge the lawyer is a squid pretending to be human.

Alternate coming up with brief scenario descriptions. Four total. One sentence, give them a recognizable setting and some defining characteristic. Example: Alien cats have infested a national park to harvest shoes from tourists.

Alternate coming up with brief, unusual mechanic descriptions. Four total. One sentence, give them a recognizable role or type and some defining characteristic. Example: Roaches swarm on you and slow you down.

Generating Designs

Brainstorming. Don't stop and think through how you'd make it work, just generate lots of ideas.

Randomly pick one character, one scenario, and one mechanic and come up with a one-paragraph game description. An "elevator pitch" to sell the idea. Do it two times.

User Focus

Pick your favorite of the three descriptions you just did. You're not committing to make that game, this is an exercise.

Fill in the following questions for that game design:

1. What is the feeling you want the player to experience when playing this game?
2. Describe three short, specific, in-game player experiences that promote that feeling. Games are interactive, so it's what they do combined with what happens to them. These experiences should capture what you believe will make the game fun to play. (Not sure? Think about experiences you've had in games you loved.)
3. Describe the core mechanics of the game that enable those experiences to happen. This is at the level of things that you could implement.

Share the file and both of you commit it to your own repo.

Wednesday, August 6

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 you what functionality they have added to the game. This is not about specific code, it's about features (e.g. a new enemy) and systems (e.g. save points).

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 your repo (not in the Unity project).

Follow the steps below to review each feature that the developer described to you. There may be one or more than one, it's actually up to you what constitutes a "feature".

Review Step 1

Assess the feature overall. Does it work? Is it complete? Summarize in the code_review.txt file what they described and what you found so we know what it is you're reviewing.

Review Step 2

Go through the code files for this feature line-by-line and leave comments on the following:

• 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.

Review Step 3

Back in the code_review.txt file, write a summary for this feature. Include a list of the code files you reviewed for this feature and any overall feedback on the design decisions and implementation.

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

Friday, August 8

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.

Monday, August 11

Show Time!

Let's play some games. You have to be here to present your game to get credit for it.

Since these will be rough demos, print out whatever instructions are needed for people to play so that you don't have to sit at your game the whole time. Put your name on the instruction sheet so I know whose game I'm playing.