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 22)

  • Lab Cat (Fuzzy Kiwi Studios)
  • Panic Painter (Dragon Glass Studios)
  • Lumia (Coffee Powered Studios)

Wednesday (March 24)

  • Dire Deal (Catana Games)
  • Phase Dash (Bite-Sized Studios)
  • Core Impact (Ellipsis)

Friday (March 26)

  • Roshamboogie (Moosey Studios)
  • Ghosted (Star Soup Games)
  • Sea Slanty (Humpback Whale)

Release Formats

As we learned from the playtesting session for the gameplay prototype, it does not really work to ask playtesters to build your game. We spend far too much time building and not enough time playing. So for this release, we have some additional rules.

  • It is only acceptable to ask people to build your game on iPhone
  • For Android, you should have an ready to install APK
  • You should have a Mac and Windows version of your game (in addition to mobile)
  • For Mac and Windows, you should have ready to run executables

Each of these platforms has different rules for creating a release.

iPhone

The iPhone is the trickiest, as there is no ready-to-install format for your game without having a paid Apple Developer account (at $100 a year). So for now, this is the one platform were it is okay to distribute code. With that said, you should only include the XCode project, and not include the Windows or Android projects.

However, if your goal is to make iPhone the grading platform, then you will need to create a paid account. In that case, you will be able to make either a TestFlight or a Firebase release. In fact, for groups targeting the iPhone we expect one of these types of releases by Closed Beta. Furthermore, a TestFlight release is mandatory for Showcase.

TestFlight

TestFlight is the standard way of distributing iOS applications for testing. It has the advantage that it can be done with anyone. You just create a link, and they sign up through the TestFlight app in iOS. If you are not quite ready for releasing your app on the App Store, this is the ideal way to distribute your app for Showcase.

The problem is that, in addition to needed the paid account, all TestFlight releases have to go through an approval process. This process is less rigorous than the final app store approval process, but it can delay distribution up to 48 hours. So while this is okay for Showcase, it is not great for fast iterations between sprints.

Firebase

The Firebase option does not require approval, so it is ideal for getting feedback between sprints. However, it has another drawback. Everyone who downloads your app via Firebase must register their iDevice with you. So they count against the 200 device limit that you have for your account (and which you can only reset once a year). So this approach only makes sense to limit to this course. Otherwise, you could exceed your device limit.

Android

For Android, you should create a release APK for your prototype. This is potentially different than the APK that you created for your personal device. It needs to support all four chipsets (arm-32, arm-64, x86, x86-64). In addition, it may need to be digitally signed.

If in doubt, have someone on your team try to install the APK without going through Android studio. If they can successfully install the app that way, your distribution is likely fine.

MacOS

MacOS executables are the easiest to run. You just have to find them. First of all, you need to find the Library folder in your home directory (not the top level folder called Library; the one specific to your account). This is a hidden folder. To reach this folder, select Finder > Go > Library.

Inside of that library folder is Developer > XCode > DerivedData. Look for a folder that starts with the same name as your project, followed by some random characters. For example, if you are using the HelloWorld project, it might look like this:

HelloWorld-aithlxtrehouomhgknykfkmbrziz

Inside that find Build > Debug (unless you archived it as a release). And now you finally have your executable. You can safely pull that out of the folder and distribute it.

If you have compiled a lot of different XCode projects (especially ones with the same name), it can be hard to find the correct build folder. Fortunately, it is always safe to delete the contents of DerivedData. Just compile your application again and the folder will appear.

Finally, note that Mac applications are folders and not files. They are just folders that you can double-click. This means you will need to ZIP a Mac application before distributing it over the Internet, even though it just looks like one file.

Windows

There are a couple of issues with Windows. First of all, there are multiple Windows builds, depending on the exact chipset that you are going to support. There is x86 (32-bit) and x64 (64-bit), as well as the release and debug versions of both. For this release, it is safe to just release an x64 debug version. However, at Showcase, you should consider a 32-bit version as well.

When you compile this Windows application in Visual Studio, it will generate a .exe file in x64 > Debug. However, you cannot run this file by itself. You must package it together with the resources that it needs to run. Indeed this is exactly what MacOS does, except that MacOS creates an illusion that the packaged folder is the executable file.

To package a Windows executable, create a folder for the game and put the .exe file in that folder. Remember which platform you built it for (in this case x64), and copy all of the dll files for that platform into the same folder as the .exe. In addition, take all of the contents of assets folder and put that into the game folder as well.

For example, if you were going to distribute the HelloWorld application, then this folder would need to contain all of the following files

  • HelloWord.exe
  • glew32.dll
  • libFLAC_dynamic.dll
  • libFLAC++_dynamic.dll
  • libfreetype-6.dll
  • libjpeg-9.dll
  • libpng16-16.dll
  • libtiff-5.dll
  • libwebp-7.dll
  • zlib1.dll
  • json (the folder from assets)
  • textures (the folder from assets)

One you do that, then you will be able to run the executable by double clicking on it.

This by the way is why Windows applications always install shortcuts. It is so that no one ever has to look at the contents of the actual folder.

Submission

Due: Sat, Mar 27 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.