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
Answer the questions below in a design.txt
in the root of your repo. Upload pics of your sketches.
You will build a rapid prototype to explore some part of your game design as quickly as possible. There are two types:
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.
Everyone will give us their pitch from the design doc.
With a partner, do the follow process both ways, with each of you acting as the developer and the reviewer.
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.
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
.
Commit and push the review, which includes the comments in the code and the code_review.txt
.
When you are both done, walk through your review comments with the developer.
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.
The point of this check-in is to make sure that everyone is on track for Friday's final.
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.
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.