Assignment 13
Pre-Beta Release

Demo: Monday, April 13th at 10:10 am
Due: Thursday, April 16th at 11:59 pm

We are calling the first presentation coming back the pre-beta release. This is to reflect that we need something a little more than alpha to make sure we finish by the end of the semester (assuming they do not extend the semester). But we do not need too much more. Historically, we asked for a level editor and one (small) complete level. This time we are going to ask for three levels.

The levels do not have to be fun or complicated. We just want to see that your game can have more than one difficult setting. Level design will be the push for the next release. With that said, this is an extremely important presentation, and should be thought of as your midterm.

The Level Editor

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.

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.

The Sample Levels

In addition to a demonstration of the level editor, we want three levels created ahead of time. These levels should be carefully thought out. We would like to see an easy, medium, and hard level for your game. The easy level can be a tutorial level if you so wish, but this is not required.

We also are not expecting your levels to be particularly balanced. However, they should have clearly identifiable challenges, and should show how your game mechanics are used to overcome these challenges.

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 Levels: You should spend 3-5 minutes on a demo of someone playing on your device. The levels should be one generated by your level editor, but you do not have to show us how it was created by the level editor.

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

This is the first release to test our online presentations. To have some normalcy, we will adhere to the normal class times for presentations. That means we will hold them over three class days: the Monday and Wednesday "lectures" and the Tuesday "lab". Attendance is mandatory for the lectures and your lab section. You are welcome to attend the other lab section if you wish.

Obviously attendance will be online via Zoom. When we get near the presentation data, we will include secure Zoom links below. You will need to use your netid to access these links. The presentation schedule is as follows.

Monday (April 13) [Zoom Recording]

• Zenith Games (Fallen Flame)
• Nonstop Soup (Octoplasm)
• Octave Games (Astrobeat)

Tuesday (April 14) [Zoom Recording]

Section 201 (11:15-12:05)

• TeamOne (Tempus)
• Overplayed (Low On Ink)
• Team Waypoint (Parole in On)

Section 202 (12:20-1:10)

• Glassbox Games (Rubato)
• Snip Snip Studios (No Strings Attached)
• Lucid8 (Modosu)

Wednesday (April 15) [Zoom Recording]

• Unclear Studio (Rekindle)
• SOYA Studios (Night Bite)
• Duodecimal Games (The Night Watch)

Submission

Due: Thursday, April 16th 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 something that requires you to build any software. You should also create a quick readme explaining the controls. Zip this together with your JAR and create an official a GitHub release for us, like you did with the gameplay prototype. There is nothing to turn into CMS.

This time we are asking for the release a little early. We want the release before class-time on Friday (hence the Thursday deadline). That way, we can have your release for the associated playtest session. Playtesting is going to be one of the trickier parts of thew new class-format, so it is important that we have these on time.

In addition, you should not forget to turn in your second two week report (which is due on Saturday). This will allow us to see how you are organizing you time, and make suggestions for future milestones.