Technical Prototype

Your second presentation is your technical prototype. Unlike the gameplay prototype, the technical prototype should be an “evolutionary” prototype. The code that you demonstrate for this prototype should find its way back into your final project. That means that a useful thing to have for this prototype would be (nearly) completed character controls with a few challenges to overcome.

Ideally, you would like your technical prototype to be a solution to a particular problem unique to your game. For example, if your technical prototype shows off the physics, what were the unique challenges that you ran into when designing the physics that differed from the gameplay prototype. Is there a graphical challenge that you are trying to solve, such as modeling water? Are you implementing networking? Whatever it is, pick something and make it the centerpiece of your presentation. And if in doubt, you can always focus on your mobile touch controls.

Because this is an evolutionary prototype, this prototype must be in CUGL. Furthermore, unless you are working with a particularly difficult problem (e.g. you need to create a custom graphics pipeline, or you need to demonstrate a networking layer), this presentation must be on a device. Finally, you should follow our rules about release formats, to make playtesting simpler.

Table of Contents

Presentation Format

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. As designers tend to be left out before alpha (which is the first time teams use assets in earnest), we want to see what they are working on.

Software Prototype

This time, we will have more breathing room, with about 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. We want this presentation to be more interactive than the last one, as we will reserve a lot of that time for questions from the TAs and the audience. As part of your presentation, you should be prepared to answer the following questions:

  • What is the technical challenge being addressed by this prototype?
  • What is unique about your game that required new, custom software?
  • Are there any other technical solutions that might have worked?
  • Why did you pick this solution over the others?
  • What are your plans for the alpha release just before Spring break?

Design Ideas

Your designers should spend no more than 5 minutes of the remaining time with their presentation. For this presentation, we want to see more concrete examples of assets for your game. This can include any or even all of the following:

There are no strict requirements for the designers. We simply want to see early concept art about the game. The presentation can include any or even all of the following.

  • Basic animations (rough sketches)
  • Basic environment assets
  • Background assets
  • Game screen mockups

You will note that this is very similar to what we asked for in the design specification. The difference there was that you included these assets in a slide presentation. This time, we really want to see the assets themselves. In particularly, you should talk about the file formats chosen, the resolution size, and why you made these decisions. If you have an animation, you should show off the animation in action (as a GIF or otherwise).

Keep in mind that you only have 18 minutes per group including the prototype presentation. Do not just display your design specification on screen.. We want a tighter, more focused presentation.

Presentation Schedule

As we said above, you will have 18 minutes for your demonstration, which includes time spent on questions. 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. However, we might playtest in class if there is time.

So that you are prepared, the presentation schedule is as follows:

Monday (March 14)

  • Low Control Mall Patrol (Pirate HR)
  • Luminance (oops)
  • No Screws Attached (Sticky Keys Studios)

Wednesday (March 16)

  • Aqualuna (First Topic)
  • Switch Witch (Nintendon’t)
  • Project Ice Age (Team Pixl)

Friday (March 18)

  • Malperdy (Humblegends)
  • Ragdoll Royale (MLF Studios)
  • Liminal Spirit (Sashimi Software)

Submission

Due: Sat, Mar 19 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 rules outlined above.

In addition, you should not forget to turn in your second 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.