Form into a team of 1-5 students. Your team will last the entire quarter. You have a choice as to how you will form your teams. You can either:

1. Form the team group yourself and ask professor for sign-off.
2. Ask professor to put you into a balanced team.

Once formed your team cannot be changed after they're formed. You must work through any problems together as a team. If a teammate drops off the face of the earth you'll have to manage without them.

Browse IndieCade Winners and 10th anniversary winners here

IGF Finalists and ALT CTRL

EACH STUDENT BRAINSTORMS 50 GAME IDEAS

Every student must brainstorm at least 50 game ideas by themselves. When brainstorming by yourselves keep in mind that the final game will have to deliver ONE MINUTE of awesome gameplay. ONE MINUTE of incredible gameplay is superior to several minutes of good or average gameplay. Review the lecture from the first day of class if you need help or inspiration brainstorming ideas.

EACH STUDENT RATES EACH OF THEIR 50 IDEAS USING THIS METRIC

After each student brainstorms 50 ideas they must rate each idea in terms of how easy it is to make in terms of art, code, and audio (1 hardest - 5 easiest) as well as how innovative and appealing it is (1 least innovative - 5 most innovative). Game ideas that score 9-10 are great because they are easy to develop as well as innovative. Using this scoring process each student selects the top 2-3 ideas and pitches them to her or his team.

EACH STUDENT PRIVATE PITCHES 2-3 IDEAS TO THEIR TEAMS

In these pitches you present to your team outside of class include:

1. Game Titles - offer at least 3 different titles for your game idea
2. Game Goal - is the game is supposed to 1) win game festivals, 2) become a successful commercial indie title, 3) or get it onto art galleries
3. Easy to make - explain why is your idea 1) easy to prototype, 2) easy to art, 3) and easy to finish with a ton of polish in a quarter
4. Innovative and Appealing - explain why is your game innovative and appealing

Each student should document all of their brainstorm and pitch materials and make them available to their team however they see fit, e.g. google docs. Details from other ideas can often help solve design/art questions/challenges later on in the development process.

CREATE YOUR TEAM'S CHAT GROUP:

Create a discord group for your team to chat. Create channels for art, design, audio, and programming, as well as any other channels you wish. Use Discord to communicate quickly and easily with your team regularly, check in several times daily.

CHOOSE YOUR TEAM'S PRODUCER:

The producer is not the leader or director of the project. They can't unilaterally make decisions for the team. They have no more authority than anyone else on the team to tell others what to do.

What the producer does do, however, is pay special attention to things that effect the entire group. They accomplish this by performing three additional tasks:

1) Regularly update the team's schedule. The plan to complete the game will need to be periodically adjusted to address emerging issues and opportunities.

2) Lead through example. For example, if a teammate lacks confidence or is doing poorly for whatever reason, the producer should privately lend an ear to the student and offer encouragement or advice if necessary.

3) Think about and foster a positive team dynamic. For example, brainstorms are much more successful if food and drinks are incorporated (sugary snacks and caffeine are helpful!). The producer doesn't necessarily have to bring refreshments, just make sure that it is brought by somebody.

As a team, come up with a game idea that you'll develop over the course of the quarter. The games must be easy to develop in terms of art and gameplay, innovative in their gameplay, and use 1 or 2 buttons as their input to limit scope and maximize polish. The goal of your game is to win independent game festivals like IndieCade etc.

The idea you pitch can be from your individual brainstorms or some new idea that you all come up with together. The purpose of the pitch is to establish a clear understanding of the kind of game your team wishes to make. Internally, this helps everyone on your team get on the same page. Externally, it helps us understand exactly what you're hoping to do and provide informed feedback. Any team that pitches a game that seems too complicated or not innovative will be rejected and you will have to present a new game idea next week. If you pitch twice you can still get an A if the second pitch is great.

Include all 6 of these in your Power Point presentation:

1. Game Titles - offer at least 3 different titles for your game idea
2. Easy to make - explain why your idea is 1) easy to prototype, 2) easy to art, 3) and easy to finish with a ton of polish in a quarter
3. Innovative and Appealing - explain why is your game innovative and appealing
4. Mechanic - loose sketches clearly illustrating your core mechanic in the game context
5. Precendents Overview - list the most similar games to yours in terms of gameplay
6. Approximate Screenshot - loosely sketch what the player will see on screen. How big and where in relation to each other are things onscreen?
7. Art Style - loose sketches showing art style

The entire pitch should be around three minutes long. Everyone on the team must speak and present at some point during the pitch. Chose someone from the team to take notes during feedback. Each team will receive several minutes of feedback from the class.

How to Pitch Effectively:

Thoroughly practice the pitch with your team outside of class before you present it in class.

Your pitch should be lively throughout. Make your presentation image-heavy rather than text-heavy. Speak over a series of images rather than read screen after screen of bullet points.

Teams revise ideas based on feedback and work on prototyping their core ideas as quickly as possible. ASK FOR HELP AND ADVICE FROM THE TUTORING LAB, CLASSMATES, UNITY FORUMS, ANYWHERE YOU CAN.

If you cannot prototype the core gameplay in a week, or if you do prototype it but it is not fun (but frustrating, boring, confusing, etc.) you will have to revise your game idea and repitch.

The goal in this prototype is to show that the core mechanic is fun and the game is within scope for this class. Program everything using throwaway code. Whatever you do DO NOT program systems, just handcraft everything and do it quick. The goal with this assignment is to get your game working at its most basic level and see if it is fun and within scope for the class.

Publish your prototypes as a Unity web build so it is playable in browser and everyone can easily play it. Share link with class on Discord. Tutorial on creating Unity web builds: https://www.youtube.com/watch?v=JZqTHjjtQHM&feature=emb_title

Artists should rapidly produce sketchy, rough art that approximates the look and feel of what you're going for. The art doesn't need to be integrated into the prototype (if that helps speed up development) at this time and can be shown separately. Try to create an approximate vision of the game to evoke the overall feel. If the sky in your final game will be purple then make your sky purple. If enemeies are going to be 2x the size of the player then make them approximately that size.

Decide what the 2-3 most important sounds are for the prototpe, for example maybe it's "tapping punch button" and "enemy getting punched" in case the punch hits the target. Find sound placeholders online or make your own, for example here are some woosh sound effects for "tapping punch button" at www.sounddogs.com. Similar to the art, you do not have to integrate the sound effects into the prototype yet if you don't have time.

Establish a production schedule for the quarter. Each item and task should have a begin and end date as well as who is responsible for it. Here is an example production schedule.

Break each list item into its component steps. For example a 3D character would need 1) concept art; 2) 3D model; 3) UV; 4) texture; 5) rig; 6) walk animation; 7) run; 8) attack; 9) getting hurt; 10) dying, etc. If you have a score at the top of the screen that has to be arted as well. Be sure to include EVERTHING the game will need.

Share your schedule with the teacher via email, even if it's just a link to a google spreadsheet.

As your schedule changes in the future please share the revision with the teacher.

Find 5 people in your target demographic who are NOT IN THE CLASS and who are unfamiliar with your game idea.

Print these out to guide you (PDF from Fullerton's Game Design Workshop)

For more elaborate playtesting guides use these too! (From Salen, Fullerton, Schell)

Test your latest working prototypes(s) with each of them. Coach them as little as possible to get honest feedback. It will be painful for you to shut up and watch them play if they are struggling, but it will be extremely insightful. Consult the lecture and the two readings on playtesting to not squander this opportunity to improve your game.

Your game might still be in pieces, which is fine. For example, you might have several working prototypes of different sections of the game that will later be stitched together into a single level. Every play tester should play all of your latest protoypes.

Write a one page report (150-200 words) describing what you learned and what you will change in the game. List at least 10 changes you will make to your game based on the playtests. I'm not grading this for eloquence but SPELL CHECK and use proper grammar.

Each team should email the report to the teacher.

ALPHA BUILDS:

Each team's alpha build should be festival-worthy at this point and be feel very polished.

Publish builds as a Unity web build so it is playable in browser and everyone can easily play. Share link with class on Discord. Tutorial on creating Unity web builds: https://www.youtube.com/watch?v=JZqTHjjtQHM&feature=emb_title

Show off your skills and potential in terms of art, gameplay, and audio. Focus on 30 seconds of fun gameplay that deliver upon these criteria:

1. Core gameplay loop. Make sure that average players in your target demographic can
immediately begin playing without much explanation or setup. Make sure they can discern what is happening in the game easily, plan their actions, perform their actions, and once performed determine if their actions had the player's intended effect or not. The goal is to design a game that is easy to learn (they know what to do) but hard to master (they keep trying to get better at doing it). A way to measure if you have a well-designed gameplay loop is if players want to keep replaying your short games until they can perform well.
2. Clarity. For each frame of the gameplay the player should know exactly what state the game is in, and what state each element is in (e.g. is enemy X attacking or dodging).
3. Agency and intuitive controls. The player should always know what to do and potential actions they can take.
4. Precision. Match up the visual and animated elements with coded events or hitboxes. Hitboxes are often not perfectly aligned with graphical representations. Look at every single pixel and take the time to tweak things until they are perfectly aligned.
5. Reactivity. Make everything move/happen exactly when they should move/happen and not a frame late. For example, remove the few milliseconds of silence at the beginning of sound effects or any latency between pressing jump and the avatar actually launching up.
6. Positive and negative feedback. The player should know every frame if their input was successful or a failure. Don't make them think. Make good events punchy, positive and easy to hear and read. Similarly make bad events punchy, negative and easy to hear and read.

VIDEO:

Each team's Alpha presentation will begin with a one minute video of actual screen-captured footage of gameplay. The purpose of this video is to give the class a sense of progress on what your team has concretely accomplished so far. It will also serve as a reference for the class critique. The video footage doesn't need to be edited. Just use raw reference footage. However if you want to edit this video to get it under a minute long, or to get to the important parts more quickly to save viewing time, that's fine.

Upload the video to YouTube or Vimeo and share the link with the teacher via email.

Do not add music or any audio over the top of the imagery that is not coming from the game itself (i.e. don't add cool sounds/music if it's not in the game).

PRESENTATION:

Following the one minute video, your team will briefly present an oral progress report for one minute on your game. You don't need slides for this, so please don't prepare any. Please don't discuss anything you've cut from the game, just look forward. Describe where you are and what you'll accomplish for your Final Game Build in a few weeks.

Each team will receive several minutes of feedback from the class.

Chose someone from the team to take notes during feedback.

Find 5 people in your target demographic who are not in the class who are unfamiliar with your game plan and idea.

Print out these questions to help guide you (PDF from Fullerton's Game Design Workshop)

For a much better but more elaborate guide Print these out (From Salen, Fullerton, Schell)

Test your latest working builds(s) with each of them. Coach them as little as possible to get honest feedback. Consult the reading on playtesting to not squander this opportunity to make your improve game.

Your game might still be in pieces, which is fine. For example, you might have several working builds of pieces of the game that will later be stitched together into a single game level. Have each play tester play each part of your game.

Write a one page report (150-200 words) describing what you learned and what you will change in the game.

Each team must email their report to the teacher.

DEMO:

Upload your team's final Final Build games somewhere online either as a zip or create an itch.io page for the game. Email the download link or itch.io game page link to professor.

One of the platform options on itch.io should be a Unity web build so your Final Build game is playable in browser and everyone can easily play it. Share link with class on Discord. Tutorial on creating Unity web builds: https://www.youtube.com/watch?v=JZqTHjjtQHM&feature=emb_title

Each STUDENT must email the teacher listing what they contributed to the game.

Each TEAM must email the teacher listing the things they used in the final version of their game (code, sound effects, etc.) that they didn't create themselves but downloaded or got from a source outside their team. Things teams used that included in the Unity standard assets don't have to be listed (such as the character controller, etc.).

VIDEO:

Each team's Final Build presentation will begin with a one minute video of actual screen-captured footage of gameplay. The purpose of this video is to provide a sense of what your team has finally accomplished and to "sell" the game. This footage can be edited in any way you like. Edit out confusing or boring bits, try to convey your game's vibe, story, game feel, brand etc.

Upload the video to YouTube or Vimeo and email the link to the teacher.

Do not add music or any audio over the top of the imagery that is not coming from the game itself (i.e. don't add cool sounds/music if it's not in the game).

You don't have to but can add whatever descriptive text you like over the footage or add text spliced between shots if that will help explain what we're seeing. This convention is commonly used in game trailers, for example. Let the video evoke the game's mood and sell it to the audience.

PRESENTATION:

Following the one minute video, your team will present for three minutes on your final game. This presentation can either be a:

• POSTMORTEM in which you describe what you learned in the process of making your game.
• SALES PITCH in which you don't talk about mistakes or what you've cut, but instead you present the game in the best light possible in hopes to get people to like and play it.

Either do a postmortem or a sales pitch but not both. Tell us at the start which you'll be doing.

Each person on the team must speak at some point in the presentation.

Each team will receive several minutes of feedback from the class.

Complete survey form, which you'll receive via email, to rate how the folks on your team were to work with.