Header image

Submit for all the platforms!

posted by pschichtel | 02 May 2017

Hi, I'm from the team Banana4Life (we made "Where is Mommy?"). Until now, I have been the one in charge of packaging the game and making it available to the world. @jqnas in the meanwhile makes the submission post for the game.

From our previous 6 game jam submissions and a lot of hours playing other submissions, I have collected some experience when it comes to submitting the game.

When to start Exporting?

Unexpected problems during the export process can easily delay your submission process beyond the submission hour. Depending on your internet connection, uploading the files will take another chunk of your submission time. We make our games using Unity3D since the last few jams (libGDX and other Java-based frameworks before), which makes exporting to various platforms very simple, but there are still a few gotchas like stray imports that cause compilation errors due to missing references. Most of the problems can easily be googled and are fairly easy to solve, but this all takes time. Many of the problems can be detected and prevented early on. So the punch line really is: Start testing your build early as if it was already submission hour.

Which Platforms and in which Form?

Short answer: All the platforms.

Generally more supported platforms means more people can play your games. In addition to supporting platforms, it should also be as easy as possible to run the game on every supported platform. An easy to start game would be a single executable file that can be executed from a graphical desktop. An hard to start game would be a huge number of files that require various other things to be installed beforehand.

In our libGDX days, we build a multi-platform self-contained JAR and a Windows executable wrapper using Launch4J. This worked ok, but still required to install a Java runtime and usually a shell on Linux desktops. libGDX' native components also limited the support beyond the common 3 operation systems and the x86 processor architecture. While it does support a web export using GWT, it was usually too time consuming to setup and keep working for our game jam projects.

Unity3D supports a lot of platforms, usually a lot more than the game will ever be played on. The best thing however: All platforms are supported natively and are easy to export to, including the Web.

So now we usually build Windows and Linux versions for play-testers, because this are the platforms we develop the game on and they are fast to export in Unity. For the submission we go with dedicated exports for Windows, Linux, MacOS and the Web. Native versions are great because they typically run smoother and they can be stored by the users for later replaying. A Web version is great because it runs everywhere, where a WebGL-capable browser can run.

Web versions are also the easiest to play, because LD users will already using a browser and it is most likely capable to run the game. This is good, even if it performs sub-optimal. If web version can generate enough interest in the game, a player will probably download a native version (if available) to get a better experience.

So my recommendation is: Export at least for the Web, but if your game performance intensive provide native version as well. Today ther are quite a few options to get your game into the browser like GWT (Java) and emscripten (native), so get familiar with them.

Where to Host?

Hosting the game is the last step you have to figure out, since ldjam itself doesn't provide hosting space. There are a lot of options here as well, some nicer than others. As a user I prefer to download games from sources I know and trust, so more common and well known the better. I also prefer to know from what the binaries were built and the possibility to build it myself, even if I rarely do that.

We in our team heavily use Git and Github. We develop all our games in the open with the code and assets on Github and the process live on Twitch. Many people here are familiar with Github, which does provide two very valuable features: Releases and Pages.

Releases are great because they allow you to directly link a source code state with the binaries built from it. New releases will not replace old ones, will coexist with previous ones.

Pages are nice, because the hosting is free and versioned through git just as everything else. This is perfect for the web version of your game. Just create an empty branch called gh-pages and put your web version into it. As soon as it's pushed to Github, it will be available at https://.github.io//, which can be linked from your release description.

Where you host is your choice, but you should prefer places, that are fast (can take a lot of downloads) and will stay for the future. Github covers that well while being free for open source projects.

How to Post?

There is a lot to say about good and bad game posts, here just a few things about mentioning your game release. You should mention all supported platforms explicitly, so the user can directly see if he can play it and sites like Feedback Friends can determine the supported platforms for filtering purposes. You should also make it clear, if certain builds of your game are not tested, you can even ask for feedback from users on these platforms.

TL;DR: Make the game playable in the browser or at least don't forget Linux!

PS: Play our game on Windows, Linux, MaxOS or directly in your browser: Where is Mommy?