Gameplay Prototype
Your second presentation is your gameplay prototype. It is meant to be a “throw away” prototype. It is not necessarily going to be part of your final project. Instead it should clearly show off one game play element. The best type of thing that you could do is have a character on the screen and show how you control him in the game. If there are any challenges, they should be simple. It is even okay if your prototype is simply a “toy” and not a game, provided that you show off interesting actions. However, it must be interactive (e.g. not a prerecorded movie).
Because it is a throw-away prototype, it does not have to be written in the same language as your final product. In fact, this is the only time that I ever allow Unity to be used in this course. You are also free to borrow whatever code you want from the game labs. We simply want you to make the quickest software prototype that you can.
Table of Contents
Presentation Format
Your class presentation will consist of two parts. In addition to the software prototype, we are also expecting a (short) presentation from the designers on your team. Because gameplay prototype does not need finished art assets, we find that the designers often feel left out in this presentation. Therefore, we are asking for some deliverables from your artists as well.
The Introduction
Introductions in class have been pretty fumbly so far. We want you to improve that for this release. The lead presenter should introduce the team by its (group) name and then call on people to present themselves. That way you avoid the awkwardness of not knowing who is going to talk next.
In addition, everyone should introduce themselves and state their role on the team (programmer, designer, composer, etc.). Finally, we expect everyone presenting to have their video turned on so we can see your faces.
Software Prototype
Due to the constraints of the mid-week break, we will have roughly 10 minutes per group for the presentation (we will spread out a lot more for the next prototype). We want the bulk of this time (6-7 minutes) to be devoted to showing off the software prototype. This can be an ad-hoc presentation where one person plays the prototype while another provides running commentary. The only requirement is that you clearly show off what the prototype does, and discuss your reason for building this particular prototype.
While presenting your software prototype, you may be interrupted by the audience for questions. In particular, you should be prepared to answer the following questions:
- What has this prototype taught you about your game?
- Has the prototype forced you to change your gameplay? If so, why?
- What are your plans for the technical prototype?
Design Ideas
Design Ideas
Your designers should spend no more than 5 minutes (we are tight for time, so keep it short) of the remaining time with their presentation. All we want to see from the designers at this stage are ideas. We want to see signs that your team is thinking ahead about what this game will look like.
There are no strict requirements for the designers. We simply want to see early concept art about the game. The presentation can include any or even all of the following.
- Environmental or in-game concept art
- Basic character art
- Level-design storyboards
We are serious about the 5 minute limit. We will cut you off mid-sentence if you take too long.
Presentation Schedule
As you can see from looking at the calendar, this
presentation will take place over three days: the Monday and Wednesday lectures and
the Tuesday lab. This is intended to give you enough time to present and answer questions.
Time will still be tight, as in the nondigital prototype,
though the presentation itself will not be interactive.
All of the presentations will take place in Zoom. This is the policy for formal presentations the rest of the semester. However, the associated playtesting session on Friday will take place in Discord.
We expect everyone presenting during this session to have their video camera on if possible. So that you are prepared, the presentation schedule is as follows:
Monday (March 15)
- What the Flock! (Small Red Studios)
- Lucid (Just Wanna Have Fun)
- free him (A Disgrace)
Tuesday (March 16)
Section 201 (11:20-12:10)
- Luce (TODO Studios)
- Change in Charge (Studio Baguette)
- Unearther (Grass Jelly Games)
Section 202 (12:25-1:15)
- Graveyard Shift (Oops! All Programmers)
- Sisyphus (Squiggly Starfruit Studios)
- Somniphobia (Enigmaco)
Wednesday (March 18)
- Spectrophobia (Blue Lizard)
- Bear with Me (Team Octave)
- HoneyHeist (We <3 Unity)
Submission
Due: Sat, Mar 20 at 11:59 PM
For this assignment, we will ask you to turn in your prototype. If it is an software program, that means that we want the executable from you. If you are using LibGDX, simply send us an executable JAR, just like you did with the labs.
You should gather the files for your prototype and zip them together in a file called prototype.zip. This zip file should contain everything that is necessary to play your prototype. This usually means the executable and a quick readme explaining the controls.
With that said, the file sizes of prototypes – particularly when you add sound – make it very difficult to turn in anything in to CMS (which has a 100 MB limit). Therefore, you are not submitting any software to CMS. Instead, we want you to do to the following.
Grant the Course Staff GitHub Access
All of the course staff (including instructors and TAs) need access to your GitHub repository. In addition to allowing us access your software builds, this will help us monitor team member contributions throughout the semester. If possible, we prefer that you use an internal repository over a public GitHub repo.
Create a Release
A GitHub release allows us to download a snapshot of your project so far. This should be the file prototype.zip, which contains the JAR and the readme.
Complete the Two-Week Report
Finally, you should not forget to turn in your first two week report. This will allow us to see how you are organizing you time, and make suggestions for future milestones.