Cake DefenseA casual game about a cake.
I'm almost a bit ashamed to admit this, but Cake Defense is the first game I've actually finished. You can play the game here.
- Made with Unity 2017.2.0f3. Later switched to 2018.3.11f1.
- Sprites made with Medibang Pro.
- Audioeffects recorded with Audacity. (Special thanks to my son who provided some effects!)
- Music made with Bosca Ceoil.
- Post Processing effects are awesome. Enable them early on.
- Sprite z-ordering is a pain, which I don't yet fully understand.
- Unity Timeline is both a blessing and a curse. (More on that later)
- The combination of particle effects And 2D game objects with collision is difficult or maybe even impossible.
- It takes a while to get a stable Webassembly and WebGL game to run on a desktop browser. And only new phones and tables support it. (More on that later)
Over the Years, a considerable amount of unfinished projects have accumulated in my backlog. A bit questionable considering I've sometimes invested months or years in certain projects. It took me a long time to understand that less is often more.
The trigger for this game gave me a video of Blackthornprod, where he sets the goal to program a game within 10 minutes. Please check it out, highly recommended and exciting to the end. I wanted to try something similar, but in a longer time frame. A casual game, which also my kids could play.
And so Cake Defense came to life in just under two weeks during evening hours. I am surprised myself how much you can achieve in such a short time if you don't set your goals too high. And above all, it's so much more fun.
Webassembly and WebGL 2
Unity moved away from asm.js builds in 2018. The Webassembly output format is the state of the art in combination with WebGL 2. I'm really excited about this tech, but we're still a few steps away from a single build target which just works everywhere. Desktop browsers mostly work fine, but mobile devices still need to catch up. Webassembly seems to work on 85% of all devices which I think is crazy considering how young this tech is. WebGL 2 support is available on 70%. Additionaly, large downloads lead to long loading times and some browsers limit the maximum working memory for a page. So you need reduce the size of your build output wherever possible. I also learned, that some settings in Unity can lead to bad compatibility overall.
Here a few things to watch out for:
- Generally, test WebGL builds early on and often and keep an eye on the build size.
- Compress sound and textures files as much as possible. Crunch compression can only be used on textures with width/height being a multiple of 4, so watch out.
- Set Api Compatibility Level to .NET Standard 2.0 if possible.
- I had to disable Strip Engine Code, although it should reduce the output size.
- Memory size can be set to 16MB. Webassembly builds can dynamically allocate more memory if necessary.
- I had to set Enable Exceptions to Full Without Stacktrace. This setting is really confusing, but what it seems to do is allowing exceptions to be catched by the engine. This is good, otherwise the game just stops. I don't experience exceptions while running inside the editor. But the None setting definitely lead to problems, so maybe there is an exception somewhere outside of my scripts? Who knows...
- Definitely enable a Compression Format. I simply used Gzip. But your webserver must serve *.unityweb files compressed. Check the webserver settings and verify the compression in the dev tools of the browser.
This was the first time I also dealt with the Unity Timeline. The timeline allows you to create in-game sequences with multiple game objects being coordinated together. The potential is huge and basically it works. But there are some rough edges one needs to overcome. I guess, Ringo agrees.
- Audio tracks lead to a ton of FMOD errors, but only in WebGL builds. As a workaround I use an activation track. The activated game object plays the audio clip.
- Method calls directly from the timeline are not possible in Unity 2018. Will be introduced in Unity 2019.
- Creating your own tracks and playables seems to be a daunting task.
- For me, it makes sense to start out with recorded curves in the Timeline. However, after having multiple tracks, I haven't found an easy way to move parts of track together. I'm not sure if the conversion to "Clip Tracks" is useful, but this seems to be a one-way operation, which completely irritates me. Have lost a lot of time and work while trying to figure this out.