Demo: Monday, April 10th at 10:10 am
Due: Saturday, April 15th at 11:59 pm
Your third presentation is your alpha presentation. This is an extremely important
presentation, and should be thought of as your midterm. Naively, alpha should be your
game completed without any content. More concretely, we expect the following two
things from you: a level editor and one (small) complete level.
By now, you should be familiar with the role of a level editor in game development. We
are not expecting a fancy GUI, but simply hand-editing XML or JSON files is not desirable
either. We want something that allows you to visualize the game layout. The features of
your level editor will be a significant portion of your presentation; we expect you to be
able to modify a level -- adding or removing challenges -- on the fly.
In addition to a demonstration of the level editor, we want one level created ahead of time.
This level should be carefully thought out. It does not need to be an introductory or
tutorial level; it can be an intermediate or more advanced level so that you can show off
a lot of features. We also are not expecting it to be particularly balanced. However,
it should have clearly identifiable challenges, and should show how your game mechanics
are used to overcome these challenges.
The Level Editor
Level editors in this class range from the fancy to the minimalistic. We only have one
requirement: the level editor must allow you to visualize your game layout. That means
you should be able to see the layout of your level, click on spot, and lay down a new
challenge or piece of terrain in that spot.
last designer lab
required the designers to create a level for the flash game PyroKid. This
game has an online level editor
for you to play with (you can also read the instructions for the designer lab).
This level editor is a good representation of what we expect in this course. There
is a button for every major gameplay element, and the designer can click to add it
to the screen.
For some of you, we have commented on the importance of AI in your level editor.
This particularly true of strategy and stealth games. See the slides on
for how to fit AI into level design. We are not expecting a complete scripting
language. But a drop-down box that allows you to chose between canned
behaviors is a very good thing.
Finally, the level editor does not have to be in Java. It can be written
in Flash, HTML (as a web application), or in whatever format you want. The only
requirement is that the level editor produces a file that can be read in by your game
engine. This is the data file that you specified in your
In presenting your level editor, the key thing that we will be looking at is the
challenges that are currently supported. While you may add new challenges to the game
later, these challenges should define the core elements of your gameplay.
Third-Party Level Editors
With the move to LibGDX, there are a lot of third-party level editors out there. There
is both Overlap2d and
VisEditor. While it has a lot less features, the
terrain editor Tiled works across multiple
platforms. You are free to use them (with an important restriction), but you may find
them a lot of more complicated to work with than you expect.
The number one rule of third-party tools is that you may not use the runtime-libraries.
Runtime-libraries automatically load the files into code for you. First of all, this
violates an important learning objective for the course. But more importantly, runtime
libraries force you to accept their software architecture over your own, which is beyond
unacceptable. So if you use a third-party level editor, you must write your own code for
reading the output files and converting the result into code.
The demonstrations for alpha are a bit more involved than the previous ones. Because
there is more to see, we limit ourselves to three presentations from class this time.
That means that we have 18 minutes per presentation, including questions.
As with previous demonstrations, 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. The designer presentation has been working very
well all semester, so we wish to continue it.
We want the bulk of your time (8-10 minutes) to be devoted to showing off the software
prototype. This includes the level editor and sample level. We suggest that you break
up your time as follows:
Level Editor Demo: You should spend 3-5 minutes showing how your level editor works.
Identify the challenges that you have made so far. Show how you can combine these challenges
to make interesting levels.
Sample Level: You should spend 3-5 minutes on a demo of someone playing on your
device. The level should be one generated by your level editor, but you can have it
preloaded on to the device.
During this part of the presentation, you should be prepared for questions from the
audience. You should at least be able to answer the following questions:
What do you consider to be the core mechanics of this game?
How does your level editor help you visualize your level layout?
What were your greatest difficulties in making it to alpha release?
What are your plans for the first beta release, particularly regarding level design?
Your designers should spend no more than 5 minutes of the remaining time with their
presentation. At this point in the semester, there should be several assets already
completed for the game. While they are hopefully on display in the software prototype,
we would like the designers to go into more detail about them.
In this presentation, we are expecting to see the following:
The main character animation (mostly complete)
Basic animations for enemies or environmental obstacles.
UI element assets
Updated game screen mockups
As you can see from looking at the
calendar, this presentation will now take place over three classes days: the Monday and Wednesday
lectures and the Tuesday lab. This is to give us enough time to cover the presentations.
Instead of the four presentations per class that we had with the prototypes, we will drop
to three presentations. We will repeat this format for beta release.
So that know when to bring your demonstration, the presentation schedule is as follows:
Monday (April 10)
Shrike Studios (Entropy)
100% Juice (Paint it Up)
Gr8 (Operation Bitwise)
Tuesday (April 11)
Section 201 (11:15-12:05)
Mantis Ink (Askew)
Fish Tank Games (Descent into Dip)
Section 202 (12:20-1:10)
SOOB Studios (The Big Friendly Oob)
S.L.A.P. Studio (Dusacryde)
Wednesday (April 12)
The Nines (Pony Up)
Syomic Games (Fridge Raiders)
Due: Saturday, April 15th at 11:59 pm
Once again for this assignment, we ask you to turn in your release. This should be a
rough snapshot of your game. In particular, we would like an executable JAR, and
not a build of the whole project.
You should gather the files for your prototype and zip them together in a file called
alpha.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. You should then
create a Release
for us, like you did with the gameplay prototype. There is nothing to turn into CMS.
In addition, you should not forget to turn in your
third two week report. This will allow us to see how you are
organizing you time, and make suggestions for future milestones.