Alpha Release

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.

Table of Contents


Level Editor Requirements

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.

The last designer lab required the designers to create a level for the flash game PyroKid. This game has an Flash level editor that you can run using the Flash projector. 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 video on data-driven design 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 architecture specification.

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

There are a lot of third-party level editors supported by LibGDX. Two popular options are Tiled and Overlap2d. 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.


Presentation Format

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. But everything must fit into 18 minutes (including questions), so you should only highlight the most important new ideas.

Software Prototype

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?

Design Ideas

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

Presentation Schedule

As you can see from looking at the calendar, this presentation will follow the same format as the technical prototype and 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. We will also have a playtesting session during the Friday lecture, like we did for the last deliverable.

All of the presentations will take place in Zoom. 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 (April 12)

  • Spectrophobia (Blue Lizard)
  • Lucid (Just Wanna Have Fun)
  • free him (A Disgrace)

Tuesday (April 13)

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 (April 14)

  • What the Flock! (Small Red Studios)
  • Bear with Me (Team Octave)
  • HoneyHeist (We <3 Unity)

Submission

Due: Sat, Apr 17 at 11:59 PM

As before, you are not submitting any software to CMS. Instead, we want you to create a release in your Git repository. Your release should not be a an IntelliJ project. We want a self-contained playable JAR file. This time, we would like for your release to contain quick README file to help us understand the controls. This will enable us to get you playtesting feedback sooner.

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. Remember to address any issues that we pointed out in your previous report.