Due Dates:

CONCEPT PRESENTATION — In-class Monday, 7/20
PROTOTYPE PRESENTATION — In-class Monday, 7/27
BETA PRESENTATION — In-class Monday, 8/3
FINAL PRESENTATION — In-class Friday, 8/7

DOCUMENTATION / DELIVERABLES: Due at the time of each presentation.

Deliverables are to be submitted to your team’s ASSIGNMENT folder on Box. (This will be shared with you)

All documentation should be submitted as PDF files.

Summary

For this assignment, teams have expanded in size, and the project has expanded in size. Students will be assigned to teams based upon the results of their interest survey, which will determine the type of game that the team will develop.

The game assignment for each team will feature constraints in the form of series of prompts that the team can choose from to inspire their game.

This project is of a much larger scope – with 3.5 weeks of development compared to the previous 1. This means that your design should go through MANY more iterative cycles. These will include formal iterations – which are scheduled milestones that have preset expectations for your design to have accomplished, and which will be accompanied by progress presentations and documentation deliverables – and between these formal iterations will be your internal iterations where you should repeat the cycle of design, build, experiment, reflect. Milestones will be set at a weekly pace, and your design should undergo at least 2 -3 iterations between those milestones.

Phase I: Game Concept

The early brainstorming phase, you should come to the Concept presentation prepared to explain the basics of your game and how you see it working.

PLAYTESTING

• This step does not require prior playtesting, just iteration and explanation of the concept itself.

TEAM DOCUMENTATION

The following is due by the start of class on Monday 7/20:

• Concept presentation (2-3 slides)
• Game Design Document (draft)

Phase II: Prototyping

In this phase, it is time to build out and test the first versions of your games. Use this session to try out your core mechanics. Does your game work the way that you anticipated it would? How quickly do you complete the core game loop? What issues arise that you did not expect? Most importantly, is it FUN? (and if not, why?) Your project should go through at least 2 major iterative cycles during this stage. By the end you should have a good idea of what your gameplay is like.

PLAYTESTING

• During this week, internal playtesting (trying the game with your teammates) is to be expected. If you want to use external playtesters that’s great, but not required.
• You should run at least two significant internal playtesting sessions during this phase. Take notes and be prepared to report on the results during your presentation.

TEAM DOCUMENTATION

The following is due by the start of class on Monday 7/27:

• Progress Presentation (slides in class – show us how your design is evolving)
• Game Design Document (updated to reflect latest design iteration)
• Playtest Notes
• Design Journal

INDIVIDUAL DOCUMENTATION

The following is due by the start of class on Tuesday 7/28:

• Individual Reflection – this time around you have more time to work, and more teammates to work with. How has that changed your approach to designing the game? How does your role within this team differ from your last team? What aspects of the project do YOU are you most excited about? What aspects of the project concern you?

Phase III: Beta

This is when your production really kicks in. Your goal for the end of this phase is to have your game almost entirely worked out. Your core mechanics should be tuned and your gameplay balanced. This week it is time to find the features that support this balance, and help support the “fun” of your game. It is also time to consider which features need to go – what is working against you? What additions do you reasonably have time to do? By the end of this phase, your game should be nearly complete, only needing some final polish.

PLAYTESTING

• This week should be a combination of internal playtesting as well as playtesting with outside guests – people who have never played your game before. Invite them to play multiple rounds – often someone will need to play the game a few times before grasping the mechanics, so repeated play will help expose the strategies that more seasoned players may try, and the areas of your game that you may not have considered.
• You should run at least 2 external playtesting sessions during this cycle, and be prepared to present the results.

TEAM DOCUMENTATION

The following is due by the start of class on Monday 8/3:

• Progress Presentation (slides in class – show us how your design is evolving)
• Game Design Document (updated to reflect latest design iteration)
• Playtest Notes
• Design Journal

Phase IV: The Final Frontier

This phase is all about finishing strong. Your game itself should not change much from your Beta (unless your playtesting uncovers significant issues that must be addressed). This week is all about putting a coat of fine polish on your game. Focus on the tangible aspects of your game, what you want the final player experience to be. You should be progressing your artwork to a final stage that you would expect if you were going to publish your game. Your game should come with it’s own documentation – directions/rules/how-to-play – so that a new user can open this up and successfully run a game of their own with no outside help.

PLAYTESTING

There is very little playtesting expected for this week, outside of perhaps showing your designs, artwork, and documentation to a guest to check whether or not it has the desired effect.

TEAM DOCUMENTATION

The following is due by the start of class on Friday 8/7:

• Final Presentation (slides in class)
• Final Game Assets (we will discuss what this means for each team)
• Final Game Design Document (updated for the final game state)
• Project Post-Mortem (break down how your project is going)

INDIVIDUAL DOCUMENTATION

The following is due by the end of day Saturday 8/8:

• Individual Reflection – Looking back on this project, describe your contributions to the design process. What aspects are you most proud of? What do you wish had turned out differently? How did the experience of creating this product compare to the previous projects? What have you learned about yourself over the course of this semester?

Grading

The team assignment will be graded in three parts:

• Product Grade (50%) – graded on the quality of the game you create. Is this game fun? Innovative? How well did you incorporate the mechanic and theme? Does your game have a strong core loop? Do you have a comprehensive or well thought out set of rules? Is this game balanced? This grade is subjective, reacting to the quality of the final product itself.
• Process Grade (25%) – graded on the quality of your design process. How well did you work together as a team? Did you share roles or divide responsibilities fairly? Did you run playtests? How well did your design respond to the feedback that you received? Can you demonstrate what you learned in this process?
• Documentation Grade (25%) – graded on the quality of your documentation, including reflection and final team deliverables. How well did you document your design process? your playtests? How well do you communicate your designs and design process in your presentations? Can a novice user understand your game design document?

The individual reflection document will be graded on quality of self-reflection and will be applied to the Individual Assignment grade for the class.

Due Dates:

PRESENTATION #1: Interim Presentation — In-class Friday, 7/10
PRESENTATION #2: Final Presentation — In-class Wednesday 7/15

DOCUMENTATION / DELIVERABLES: Due Wednesday 7/15 @ Noon

Deliverables are to be submitted to your team’s ASSIGNMENT folder on Box. (This will be shared with you)

All documentation should be submitted as PDF files.

Summary

It’s time for your first team assignment! This time, you will be asked to create a new game using the randomness of DICE as a primary mechanic in your game.

In this assignment, your design should evolve over multiple ITERATIONS where you build, test, gather feedback, and respond to that feedback by making alterations to your design.

Your project should go through three stages – an initial prototype/design to review in class, an iterated design that will be put before playtesters, and a final design responding to what you learned from your playtests.

Your project must feature a MECHANIC and a THEME that will be selected for you by… what else? A dice roll. These constraints to not need to be the primary focus or mechanic of the game, but they must feature in the game somehow.

Phase I: Prototype

For this section, your team’s job is to come up with a design. Use the brainstorming techniques that we have discussed to come up with a number of ideas, then select one design to iterate, refine, and and build into a prototype.

You will present this prototype concept to the class on Friday, 7/10.

Phase II: Iterate

During the prototype presentation, you will receive feedback on your design. Consider the responses that you received and look at how your game can be improved to address the issues raised in this feedback.

Next, take your newly revised game and run some playtests over the weekend with participants who are not on your team. You can do this in person with people in your home, or reach out to friends and play over a video call.

Document your playtests, as you will include your notes and conclusions as part of the final documentation.

This phase should be completed over the weekend. We will discuss playtest results in class on Monday.

Phase III: Refine

Adjust your game again, this time responding to the things that you learned as part of the playtesting process. Document these changes and run some final playtests with your team members to see how these adjustments affect gameplay.

You will present your final game in class on Wednesday. Expect to present the game itself, explain how it is played, and to discuss how the design of your game evolved over each of the phases.

You will also provide documentation at this time, as outlined below:

FINAL DOCUMENTATION – TEAM

The following is due at the start of class on Wednesday 7/15:

• copy of your final presentation [PDF]
• game design document – explaining the rules of your game and how to play. This should be written so that a novice user could read this and understand how to play the games. Include illustrations and photos where necessary. [PDF]
• design journey document – look back at the project and discuss the decision points that you encountered. What challenges did you face? What feedback did you receive? How did your design change to address this? Were the changes effective? [PDF]

FINAL DOCUMENTATION – INDIVIDUAL

The following is due by the start of class on Thursday, 7/16:

• individual reflection – Look back at this design project. How did designing as part of a team compare with the individual design process of the Hopscotch assignment? What were your contributions to this project? What challenged you? What do you wish you or your team had done differently? Document these thoughts in 1-2 pages and submit this to your individual assignment folder. [PDF]

Grading

The team assignment will be graded in three parts:

• Product Grade (50%) – graded on the quality of the game you create. Is this game fun? Innovative? How well did you incorporate the mechanic and theme? Does your game have a strong core loop? Do you have a comprehensive or well thought out set of rules? Is this game balanced? This grade is subjective, reacting to the quality of the final product itself.
• Process Grade (25%) – graded on the quality of your design process. How well did you work together as a team? Did you share roles or divide responsibilities fairly? Did you run playtests? How well did your design respond to the feedback that you received? Can you demonstrate what you learned in this process?
• Documentation Grade (25%) – graded on the quality of your documentation, including reflection and final team deliverables. How well did you document your design process? your playtests? How well do you communicate your designs and design process in your presentations? Can a novice user understand your game design document?

The individual reflection document will be graded on quality of self-reflection and will be applied to the Individual Assignment grade for the class.

Due Dates:

DELIVERABLE #1: Sections 1 & 2 Due by Friday, 7/3 @ Noon (Eastern)
DELIVERABLE #2: Remaining Sections Due by Monday, 7/6 @ Noon (Eastern)

All deliverables are to be submitted to your ASSIGNMENT folder on Box.

Both deliverables should be submitted as PDF files.

Summary

The assignment is to re-invent the game of “Hopscotch”, a common children’s game often found in playgrounds and driveways. Your task is to come up with a new and improved version of this game using the design methods that we will focus on in this class. First, you will analyze the current game. You will brainstorm many ideas, and select the best ones for further development. Then you will choose one of those developed designs and build a “prototype” version to test with live subjects (preferably someone else and not yourself). Finally you will assess your design and draw conclusions from your playtesting as to what your successes were and how to build on them.

The assignment is due in two parts. The first part covers research and early ideation. The second part has you refining, testing, and reflecting on your findings. Both of these parts will take a significant amount of time – don’t wait until the last minute!

Assignment Sections

1. Research & Analysis

The first step in design is to get to know your subject matter, and turn a critical eye to it. If you are a hopscotch expert, you probably already have many ideas as to what is great about it, and maybe how it could be improved. If you are NOT a hopscotch expert, then you need to educate yourself – understand how the game is played. A good place to start is by finding the rules – wikiHow has a great summary with helpful animations.

You should also try out the game for yourself. Often times just reading the rules or watching someone else play does not give you the full experience. Dive in and try it!

Once you have a good sense of what the game is, then it is time to analyse the game itself to determine what parts of the game are good, and what aspects could be improved.

SECTION 1 Documentation:

• Write up a quick summary of your impressions of Hopscotch. (1 paragraph)
• Write a bulleted list of 5 aspects of the game that you think are positives. Be descriptive as to why the aspect is a positive. Example “The game can be played anywhere that you have room to move and can draw a surface”
• Write a bulleted list of 5 aspects of the game that you thing are negatives. Again, be descriptive as to what the the disadvantage is. Example: “some children with physical disabilities may not be able to play”

2. Brainstorming

The best way to get a good idea is to come up with a lot of ideas and then find the good one. Your task is to let your mind wander and think up 30 different ideas for a variant of Hopscotch. The first 10 ideas will probably come easily, but you may find that it gets more difficult over time.

The trick to this section is to not spend much time fixating on a particular idea. There will be time for fixating later. When you come up with an idea, write it down on the list, set it aside in your mind, and move on to the next concept.

SECTION 2 Documentation:

• Document your 30 ideas by providing a bulleted list of all 30 ideas. Each should have a very short sentence explaining the concept quickly and succinctly. Example: “Op-Scotch – Hopscotch meets the game ‘Operation’.”

NOTE: Sections 1 & 2 are due Friday 7/3 by Noon (Eastern)

3. Ideation

Now it is time to take some of your ideas and work on developing them into fuller concepts, closer to a real game with rules and mechanics and things.

Select two (2) of your ideas from your brainstorming list and write a short game design document for each one. This document should include a summary of the game, details about how it is played, and a set of rules.

I recommend including simple illustrations or diagrams to help communicate some of these concepts. For instance, if you are changing the configuration of the hopscotch board, you should probably include a drawing of that. If people are supposed to move in a particular way that is significantly different from the current game, a quick sketch may help, even if they are just stick figures.

A good game design document is one that can be read by someone with no experience with your game, and they will understand how to set it up and play it.

SECTION 3 Documentation:

• Simple game design documents for two (2) of your ideas.

4. Experimentation

Choose one of your game designs and make it a real game. Build a simple test version (a prototype) so that you can play the game you are intending. Prototypes are not expected to be fancy or refined, usually they are quite the opposite. They are quick builds to test a concept, meant to be thrown away.

If you are creating a new board, you might want to get some chalk and draw it on your driveway. If you’re turning it into a board game, draw on a piece of paper. To put this in comic-book terms, you’re not building Iron Man’s nano-suit, you’re building the Mark I, clunky and made of scraps, to do one particular job.

Once you have constructed a prototype, test it out. You should definitely try it yourself to see if your design meets the expectations that you have. If you have other people available who can play your game, have them try it and give you their impressions. (Siblings make great test subjects, but their feedback can be brutal!)

When you play your game, you should be taking notes on your reactions. Write these down as soon as you finish playing when they are fresh in your head. When your players play your game, ask them to “think out loud” and share their thoughts. Take notes on what they are telling you. Try to avoid the urge to respond to their comments or help them out. Let them figure it out for themselves. If they cannot, that tells you something about your current design.

SECTION 4 Documentation

• Document your playtest – take photos of your prototype and your playtesting. (Be sure to get permission to share photographs of your test subjects. Some people may not be comfortable having their picture shared. Consider blurring faces or cropping photos.)
• Write up your notes and your player reactions – This is not analysis, but provide summaries of the experiences as you or your playtesters reported them.

5. Reflection

Now it is time to compile your results and consider what your playtest tells you about your original design. What about your design worked? What did not? Where did players struggle? Did they understand the rules? Were they entertained or bored? If you were going to improve it again, what would you do differently in the next prototype?

The point of this exercise is to turn a critical eye towards your design. It can be a very difficult process, because we like our ideas. We can get very attached to them. And most importantly, we are often reluctant to admit that we made a bad choice, or a wrong assumption, or missed something entirely.

The temptation in reflection is to tell the reader why you were right all along. But the secret to design is: we almost never get it right the first time, and that’s OK!

Don’t be hard on yourself, just tell me what you learned. In order to be a successful designer and build great things, you need to comfortable with admitting that you are not always right. That’s why we run these experiments – to test our assumptions and find the weaknesses hiding in our blind spots. Once we find those and identify the causes, we can address them and build stronger.

SECTION 5 Documentation

• Write your reflection document summarizing your findings. What was it about this first iteration that worked as expected? What did not? What came up that maybe surprised you? What did you learn? If you were going to refine your design further, what would you change for the next version? This portion of the document should be 1-2 pages.

This course teaches the fundamentals of designing, testing, and refining a game. We will examine the structure of games, strategies for generating game concepts, and methods to rapidly prototype and test designs.

Our class begins Monday 6/29!

Live classes will be held daily via Zoom during our regular class time (12:00-1:20pm EDT). (The link is available in the announcements and syllabus on CANVAS). This class features a significant amount of direct interaction and group activity. As such, your attendance is expected for these sessions – this is a sychronous class. Classes will be recorded and posted to the class Canvas if you need to review or are unable to make a class, but please email the instructor if you know you will be absent.

The course structure and assignments will be discussed in this initial class. See you soon!