The challenges of making a web game ​

This is the part where I look into compatibility and technical feasibility of the webgl platform.

AstroCappy's first fan art. Done by a friend.

Never making a web game again ​

Turns out making a web game has more challenges than I expected.

Sharing the game without having to install anything and supporting both desktop and mobile browsers were great selling points for me. But the reality is a bit different. I thought I was being smart by choosing the WebGL platform in Unity.

Compatibility ​

Unity's WebGL target stopped supporting WebGL 1 last year, so browsers require being WebGL 2 capable. This is not that big of a deal as apparently all modern browsers and even android and iOS browsers support WebGL 2.

Size ​

Unity's WebGL builds are a bit large.

So big that I've decided not to include them in the WPA version of the site, they are only available if you are online. The first build was around 10MB adding all the files, and that included pretty much no assets of my own.

Users with slow internet speeds will have a long time to wait before they can play the game.

If when adding assets and improving the game size increases considerably, I will have to look into streaming data once the game has loaded. This adds a lot of complexity and is not something that I want to be looking at.

Compilation ​

The previous playable "demo" took more than 30 minutes to compile.

I can't imagine how much more this can take with actual assets like sprites, sound, music, levels, etc.

While compiling, the entire editor is unusable. Testing small changes is a pain, unless I use the player in the editor, which is not always representative of the final build.

This alone is already a big turn off. Fast iteration is key to making a good game.

Other issues ​

Unity's web player spits shit into the console and there is no way to disable that. Really, open the console of the browser and load the game and you'll see. I tried changing lots of settings to disable that and couldn't. This makes me thing Unity treats this platform as a developer experiment but not as a professional product.

Controller support is surprisingly good in desktop, but I've experienced some crashes on mobile as soon as I connect some usb controllers to my phone.

Communicating with the browser ​

Although not essential, it could be useful to communicate with the actual webpage from the unity player itself. For example, the game could send the save data so that the browser downloads it as a blob, allowing the user to preserve their save file. Tracking data could also be sent to leverage web analytics tools for the game, without having to bundle those with the compiled game itself.

Saving ​

Unity's built in saving does not work from one build to another. So I need to make my own by getting the data from the game and storing it in the browser's local storage. I also need to find a way to offer people to download their save, in case they clean their browser's data.

What if people manually edit the save game? ​

I could look into encrypting the data or adding extra checks to make it hard but not impossible for people to modify their save games. But I don't really care. This is a single player game. If you want to modify anything you are just changing your experience, if it's better then great, if not then you are only hurting yourself.