Thursday 12 February 2015

Android games are easy to make! right?

So a couple of weeks ago, Dean Ellis and myself wrote a game in a weekend. It's a great game actually, loads of fun, addictive and has that one more go quality we were hoping for.

How did we make this? Well we used Monogame and Xamarin. We poured our combined 35+ years of experience into a 20 hour window; writing a fun game using C# without a pre-built game engine.

As I mentioned previously, we managed to get the game running on Android and iOS relatively quickly once the game was functionally complete. But it wasn't quite ready for the market.

What do we mean without a pre-built game engine?
Monogame is a framework, not an engine. Unity is an engine, Unreal is an engine.

I'm sure there's a better description to clarify the differences between the two, but to me a framework provides the tools to draw things, play sounds and to capture input on command, but you're effectively left to implement everything else yourself how you see fit. Everything from actors, physics, triggers, collision detection - every aspect of the game needs to be coded from scratch. And notice that I said "on command" this means that you have to tell your game to draw your textures, play your sounds and read the status of inputs with object methods in code.

This provides a great amount of flexibility in terms of what games you can write - in the same way as a word processor provides great flexibility in what documents you can create, it will provide the spelling and grammar checker, allow you to maintain versions of the file and even track changes. But it won't provide any further assistance when you want to write that book you have in you.

An engine on the other hand provides pretty much everything for you in a controlled way. You provide the assets and the ideas. You still have to code your game, but this is mostly done by hooking engine events to scripts. The rendering, input and sound are handled at a much higher level - mostly outside of your direct control - which allows you to create games very quickly because you can focus more on what you want instead of how it will happen; But you're more restricted in the types of games you want to produce - depending on the engine.

Engines are great and an entire industry has developed around them; after-all, why reinvent the wheel if you're making a different bicycle.

Why am I talking so much about the difference between a framework and an engine? Well, I suppose it's to highlight additional programming work required if an Framework is chosen over an Engine.

Choosing a framework over an engine allows you to choose how aspects of the game are implemented and enables you to write games with a much smaller memory footprint. But you do have to implement things which you would  normally take for granted if you were to use an engine.

It's a balancing act. If you want a lean codebase with a small memory footprint, a framework is probably the way to go - but it will mean a lot more code than building something in Unity.

So the game was completed, why isn't it in the store yet?
Well,  there's a bit more to consider than just putting the game into the store - even a game which appears to run on a developer's devices.

Sure, you can upload an APK to your store once you've set up your Google Play Developer account
and signed your app; But does it work on all devices? Or even the majority of devices on the market today? Will it be fun for all customers?

For Android developers, this poses quite a problem. The Android landscape is filled with a vast multitude of different configurations of hardware and software.

There are so many android devices on the market all with different screen resolutions, amounts of memory, processors and video hardware. On top of that, they often have different versions of Android and sometimes even custom builds of the operating system.

All of this makes guaranteeing that your game will run on all devices equally almost impossible.

Some of these differences are more of a concern than others.

  • Processor isn't a massive problem, but could be if the game compiles to native code and the processor can't support the compiled code ( Unlikely - the low level compiler includes code for various chipsets ). However the biggest concern is the speed of it. A slow processor might not be able to handle your game at the framerate you need.
  • Memory could be a problem if it's particularly low. Be sure to clear up after yourself and use object caching wherever possible to minimise the need for garbage collection.
  • The Screen resolution - in particular the aspect ratio (the ratio between width and height) will mean that your game will look different on different devices. Will that affect gameplay, giving a different play experience?
  • The video hardware may support different types of texture compression. This is important if you use a lot of art assets on screen at any given time. There isn't a 'one standard format' which everyone adheres to, it's dependant on chipsets for the most part.
    • GLES 2.0 ETC1 - (Supported on most devices - No Alpha, RGB only)
    • GLES 3.0 ETC2 - (Small percentage of market - RGBA)
    • PVRTC - Power VR - (Only supported on PowerVR chips / iOS - RGBA)
    • ATITC - ATI Compression - (Only supported on ATI chips - RGBA ) 
    • S3TC (DXT) - (DirectX Texture format, NVidia and others - Default for Monogame on Android)
  • The version of the O/S may throw unexpected spanners in the works. Different versions of Android may behave in slightly different ways and given that Android is open-source, there is always the chance that there are implementations of features which differ enormously from device to device.

The fact is that once on the market, the end customer will feel cheated if the game doesn't run properly on their device - and so they should, after-all the game was marketed to them and made available for purchase for their device and the vendor was happy enough to take their money.

It's not all bad though, understanding the problems only illuminates possible solutions.

The Google Play store offers tools to narrow down the sale to known devices or to restrict poorly preforming devices you can see metrics on how your app is performing (crashes and so on). It also offers the ability to roll out a staged release with Alpha and Beta testers being given access to install the game and report their findings.

Google also provide some fun things like achievements, leaderboards and events. These can be built into a game by accessing the Google Play API.

So back at Songbird HQ, we put more time into ROO!, more time than it took to create initially.

We've put in some more time to make sure that the game runs smoothly on different devices and that it supports various forms of texture compression - which means that we've had to alter the asset generation pipeline and that we have to publish 3 different APKs to the store.

To accomplish this, we modified the Monogame framework itself. One of the awesome benefits of using an Open Source framework over a closed source Engine is that you can make changes to it if you need to.

 Of course open source engines exist, however most people consider Unity before researching alternatives.

We've overhauled the UI to include buttons instead of the very simple menu we had before.

We've built in the Google Play API component to allow for achievements and leaderboards.

We've also been pepping up the graphics a little after getting feedback from players. Players who of their own volition wanted "just another go..." - very encouraging.

Get ready for the weekend!
We'll be working on the game some more on this weekend for a final push with the view to get it onto the Play store ready for Valentines evening.
Hopefully though this won't cause any rifts in relationships when partners are playing ROO! over a romantic Valentine's dinner.

We're not entirely settled on a price point yet, but it's going to be low - like a can of soda low. Cheaper than a burger or a game of pool at the local pub.

So in closing...
Games are easy to make if you know what you're trying to build and you have the experience to put them together.

If you don't have the experience, they'll take a bit longer while you obtain it and if you don't know what you're trying to build - well, that could take a while longer still, but keep trying anyway.

Understanding the obstacles in your way is the first step to overcoming them.

No comments:

Post a Comment