Your third presentation is your alpha release. Naively, alpha should be your game with its code essentially complete, but missing most of the content. More concretely, we expect the following two things from you: a level editor (not necessarily on the device), and one (small) complete level.
You should be familiar with the structure of a level editor from the introductory course. 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.
You are allowed to make use of 3rd party editors like Tiled. However, you are not allowed to use the run-times; you must process the JSON or XML output yourselves. In addition, there are a lot of things this editor cannot do, so choose wisely.
Your level editor presentation can be entirely self-contained. You do not need to show us how to move a new level on to a mobile device. Last minute device loading can always go wrong and slow down the presentation. However, we do want your sample level already loaded onto a device.
Table of Contents
As with the last prototype, 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 will have roughly 18 minutes per group, per presentation. We want the bulk of this 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
The structure for this presentation is the same as the previous ones. As you can see from looking at the calendar, this presentation will take place over the entire week. This is intended to give you long enough to present and answer questions.
While we would like you to playtest, are moving playtesting to the discussion section, just as we did for the previous release. As a result, this means that you must have something to playtest (even if it is not a full alpha release) by Wednesday, no matter what day you are presenting on.
So that you are prepared, the presentation schedule is as follows:
Monday (April 5)
- Dire Deal (Catana Games)
- Phase Dash (Bite-Sized Studios)
- Core Impact (Ellipsis)
Wednesday (April 7)
- Roshamboogie (Moosey Studios)
- Ghosted (Star Soup Games)
- Sea Slanty (Humpback Whale)
Friday (April 9)
- Lab Cat (Fuzzy Kiwi Studios)
- Panic Painter (Dragon Glass Studios)
- Lumia (Coffee Powered Studios)
Due: Sat, Apr 10 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. This release should follow the same rules that you used for the technical prototype. If you are targeting iOS, we would like you to have a non-source code release this time.
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.