Due: Saturday, March 11th at 11:59 pm
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 Flash 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.
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.
We will have roughly 12 minutes per group, per presentation. We want the bulk of this
time (5-8 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?
Your designers should spend no more than 5 minutes 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 (follow
the links to see examples of each).
As you can see from looking at the
calendar, this presentation
will take place over two days: the Monday lecture and the Tuesday lab. This is intended
to give you enough time to present and answer questions. Later prototypes will be spread
over even more days.
However, this does mean that we are packing four groups into each class time slot. As we
saw, that is close to the number of projects that we were able to get through in the
nondigital prototype. And that required that everyone was set-up and ready to go as
soon as we swapped stations. You need to come prepared for your presentation, ready to
set-up quickly. Time that you take setting up is taken out of your presentation time.
The projector requires either a VGA input or HDMI input, so someone on your team will
need to bring a laptop (and adapter if necessary) to present on. If that is not going
to work, the please let the instructor know ahead of time.
So that know when to bring your laptop, the presentation schedule is as follows:
Monday (March 6)
100% Juice (Paint it Up)
Fish Tank Games (Descent into Dip)
SOOB Studios (The Big Friendly Oob)
Gr8 (Operation Bitwise)
Tuesday (March 7)
Section 201 (11:15-12:05)
Mantis Ink (Askew)
Shrike Studios (Entropy)
Section 202 (12:20-1:10)
The Nines (Pony Up)
S.L.A.P. Studio (Dusacryde)
Syomic Games (Fridge Raiders)
Due: Saturday, March 11th 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.
In addition, 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.