Alpha Release

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

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. The designer presentation has been working very well all semester, so we wish to continue it.

Software Prototype

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?

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

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, we 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 (March 28)

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

Wednesday (March 30)

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

Friday (April 1)

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

Release Formats

One of the things that makes it difficult to playtest your games is that we have to build them from source. Eventually we are going to need a proper release from you, and we would like to make your first attempt at that with the alpha release. 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
  • For Mac and Windows (if you want feedback), 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 (or App Store) 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, Apr 02 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 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.