Assignment 13
Alpha Release

Demo: Monday, April 8th at 10:10 am
Due: Saturday, April 13th 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.

The 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 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

With the move to LibGDX, there are a lot of third-party level editors out there. Two popular options are Tiled and VisEditor. 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.

Class Presentation

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 now take place over three classes days: the Monday and Wednesday lectures and the Tuesday lab. This will allow everyone to see every game (except for when we are in section), and will not have the split presentation that we used for Gameplay and Technical. We will repeat this format for beta release.

So that know when to bring your demonstration, the presentation schedule is as follows:

Monday (April 8)

• HEDG (Roasted!)
• Ralph Studios (Starstruck)
• FXN (Loxodonta)

Tuesday (April 9)

Section 201 (11:15-12:05)

• Super Glue Studio (Tower Offense)
• One Fortune Games (Kamachi)
• LUMEN Studios (YoyoBoy)

Section 202 (12:20-1:10)

• 7Studio (Undetected)
• OneWordStudios (Flourish)
• Triton Games (Prism Break)

Wednesday (April 10)

• FlashLight Studios (Amaris: Realm of Dreams)
• The Syndicate (Perceptron)
• Snapback Studios (Clerical Error)

Submission

Due: Saturday, April 13th 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.