Releasing a game with Xamarin Android and Google Play (and... I'm back, again!)

It's been a year and a half since I updated my blog. The last update has me with a working prototype of my Inertia game (now 'Retro Rat Race').

During that time I have done a mixture of spare/part time game development (contract work for a business in the day times) then full time for a couple of months to get finished.

You can read my initial thoughts of Xamarin and my choice of OpenTK over Mono Framework in my previous blog post.

Just before Christmas I rounded off the first release of Retro Rat race (for Windows) and put it out there as shareware. The reception has been generally positive but it is even harder to get noticed than before. I reckon it's a good little game but just doesn't have enough of a hook to be noticed in a big way.

From watching videos that players have recorded (including the supremely helpful and enthusiastic YouTuber Seth Logan - @hayes1571), I can see the die/repeat pattern works well. It's certainly not an easy game but seems to elicit the appropriate "Arg, What, Arg, YES!" responses like the great games in the tough/short play genre such as Super Meat Boy.

It's funny with the Internet, in that I didn't know Seth until I started following him on Twitter and we established a rapport. He lives in Canada (about 3500 miles away) but somehow we've become friends and enjoyed some good banter on Twitter.

You can check out one of Seth's videos here: (if you don't mind a bit of friendly swearing!)

You can check out the Windows demo here: www.suisoft.co.uk/retroratrace/

After that I pressed on with finishing the Android version using Xamarin (Indie). That went pretty smoothly, despite a couple of hiccups with compatibility (almost resolved!)

The Android version lives here on Google Play.

Here are some hints/tips and experiences for those interested in game development.

Xamarin Game Development for Android

DO buy a good Android game development book

In order to learn about Android game development, touch controls, OpenGL ES, sound etc. it's really worth investing in a good book.

Beginning Android Games by Mario Zechner and Robert Green is excellent. It's in Java but Xamarin and OpenTK's clean wrapping of the Android API's makes conversion very easy.

DO consider 'Thunking'

Like the old days with 'DOS Extenders' allowing 32-bit applications to be used on 16-bit DOS, Xamarin Android passes control between the .NET virtual machine and the Java virtual machine. This obviously has some overhead (like passing between 32-bit and 16-bit).

This is most noticable, performance-wise when you are using Streams on top of Java objects. Every stream operation results in a 'thunk' between VM's. This caused me some trouble with map load performance, particularly on my Galaxy S3 phone. The fix is pretty simple for small files like game maps - just load it into memory then stream from there.

Don't try to create a batch build procedure with Xamarin Indie

I wasted the best part of a morning trying to get Xamarin's MSBuild to work following an example on their deployment documentation page. From what I can gather from scouring the Internet the build tools cannot be used directly with Xamarin Indie due to the licensing controls.

Instead, just use 'Project / Create Android Package...' from Xamarin studio and create a batch procedure you can run manually to sign & zip align from there. Signing and zip aligning steps are documented in the Xamarin guidance (link below).

Note that you can cancel the final dialogue box after 'Create Android Package' as the APK (Android package) files will already be in your BIN folder.

DO read the Xamarin deployment guidance

Xamarin's deployment guidance gives you a nice list of checks/tasks to perform. I recommend distilling these into a bulleted release procedure (as described below) to save time with future projects and releases.

Xamarin Deployment Guide

DO write a release procedure

This one applies to ANY software project.

I always write a release procedure when I build software with new tech. It saves so much time with future releases and projects. You won't miss things or keep thinking 'what did I do last time'.

You may need to split your procedure down into 'first release / major release' sections. The former includes the things you should only have to do once or occasionally after major changes. The latter is the tasks and checks you need to do every time, even if you're just releasing a patch (e.g. updating version numbers).

DO test with emulators as well

A trap I fell into with the first Android release, was an irksome bug where the keyboard didn't pop up, even if you pressed the 'text box' area on the screen.

I remember it took a fair bit of research and experimentation to get keyboard entry working, due to the game using its own user interface controls.

The functionality worked flawlessly on the physical devices I tested it on - several Samsung phones and tablets, a HP tablet (belong to a friend), a Kindle.

The issue was due to quirks in the behaviour of different flavours of Android. Specifically when calling 'ToggleSoftInput' I used the 'Implicit' flag, which worked fine on the test hardware. That flag needed to be 'Force' to work on some HTC/Nexus devices.

I could have avoided this problem by testing on a Nexus emulator. I'm actually still (at time of writing) looking into another problem for one player where the keyboard pops up and doesn't respond to key presses. I haven't pinned that one down yet - which brings me on to the next point...

Have a workaround in place for keyboard API issues

There are so many devices, tweaked versions of the Android operating system and custom keyboards out there, it's impossible (for a small Indie) to test everything effectively on real, physical hardware. I know Google and Xamarin have test cloud functionality but on initial reads, that seems more focused on Apps than games. If/when I explore that some more, I will post about it.

With a game, getting consistent keyboard behaviour appears to be a challenge (from recent experience!) To avoid this, make sure to remove the dependency on keyboard.

A mistake I made was requiring entry of a player name upon game start. If the keyboard doesn't pop up or can't be used it's 'game over'.

"That's it, man. Game over, man. Game over!"

I attacked this from two angles with a patch:

• Skip the player entry entirely. Default to a 'Me' name that can be changed later
• When entering the first player name, have a 'Skip' option that defaults to 'Me'
  (this handles the situation where a player has deleted the default profile)

DO test with other languages

Another compatibility issue I hit was a Portuguese (speaking) player who found the game crashed at the end of the first proper level. This was due to the medal time in the level being a float (e.g. 1.5) stored as a string in the XML level file.

When C# parsed it back to a float, it expected it to be Portuguese format (i.e. comma decimal place, rather than period/full stop). "SPLAT!"

I normally consider this angle with applications, as I've encountered it before. With my games written in C++ I haven't hit any localisation issues and missed it completely. Lesson learned!

C# and the .NET framework have localisation features built in. This is great, because dates, numbers etc. are shown properly. The Portuguese speaking player saw "1,5" (1 comma 5) on the medal screen. The downside, is if you persist something into a text file under one locality (i.e. English, Great Britain in my case when creating maps) and read it back in a different locality with different number formatting rules. "SPLAT!"

Google Play Store

DO consider the application naming convention

When I first uploaded my APK (android package) to Google Play it complained about the package name being invalid. It's talking about the package name in the manifest - NOT the name of the APK file (although I have adopted the same convention for that).

The package name is in the Android Manifest:

<manifest package="co.uk.suisoft.gamename"

To get a unique name, the convention is similar to your domain + the application name.

i.e. com.company.gamename
or co.uk.company.gamename
etc...

Don't worry about age classification

Before setting up my first application on Google Play I expected to be slowed (or blocked) by a requirement to assess the age rating of my game.

Google have actually made this very easy. Just a simple questionnaire that takes a few minutes to fill out. That becomes a set of classifications for various countries / regions.

DO consider the Goole Play Beta Testing functionality

You can pre-release to a closed set of beta testers. In an uncharacteristic moment of courage, I chose to 'Just go for it' (based on the current climate meaning slow uptake).

In retrospect I would have done a beta group, as per the Windows version of Retro Rat Race.

DO reply to reviews

The first three reviews I received for the game were negative - 1 and 2 stars. Some players immediately found the keyboard bug I hadn't picked up in testing. This was pretty gutting.

I replied to the reviews, apologising and informing the players I would look into it. Within a few hours I had a workaround for the problem allowing them to play the game. Two of the reviews were changed to 4 or 5 stars with a bonus couple of reviews praising the support.

Examples:

• Respect for this developer - Ridiculously fast support update and the game is pretty awesome
• Thanks for the quick fix to the keyboard problem
• Good fun - Smooth game play and fun to play. Quick turnaround on the initial problem

I think gamers have become so accustomed to crap tech support. It's something special when you actually help them and give a damn. This is easier when you are small/solo/human without the bureaucracy of a corporation.

Summary

Overall, the process of getting a game onto both Windows and Android from the same C# codebase has been pretty smooth.

The game code doesn't contain a single line of platform specific code. The behaviour differences for devices are handled by a 'PlatformFeatures' class that I use to ask 'IsDesktop' to switch certain features on and off or adjust sizing / positioning.

The engine codebase is also mostly non-platform specific. There are specific subclasses for OpenGL, OpenGL ES and sound. Conditional compilation is used to keep them from bloating the other platforms.

Hopefully porting to iOS should be straightforward due to game code being 100% platform agnostic and the engine using the OpenTK OpenGL ES interfaces that should be compatible. The majority of the porting time will be the main game loop, storage and possibly sound (although I'm hoping my Windows OpenAL code may be OK).

Xamarin (and I'm back!)

Skip to the End...

I originally started writing this post chronologically. Since the most interesting stuff is from this week, I will start at the end. The history behind it is at the bottom if you want to use it as an alternative to counting sheep.

Onward...

I spent most of this week installing and setting up Xamarin (plus the Android Software Development Kit) and coding up touch and graphics functionality (OpenGLES - the baby sibling of OpenGL used by most mobile devices).

I now have a working prototype of the game running on Kindle with touch controls, albeit with placeholder boxes for the sprites (that bit of OpenGL ES code not done yet).

Pretty pleased. I honestly didn't expect to get this far so quickly, particular as it took me almost a full day of downloading to get Xamarin and the Android SDK installed (5-6 hours).

Screenshot below.

The game is now working on PC and Android (on our Kindle Fire at least!) I have yet to crash headlong into PC style driver compatibility issues as yet.

The PC version looks like this currently: (i.e. with proper graphics, rather than temporary coloured boxes)

It's very early days with this game. I do plan to stick with the vector style but a ton of visual effects and level complexities are still to be added.

My next job is to finish the graphics code then get sound working. The latter will hopefully be quite simple.

Xamarin - First Experiences

This part is only of interest if you're a game programmer (aspiring or investigating .NET / Xamarin).

Starter Edition

I downloaded the free starter edition from Xamarin in January. This enabled me to evaluate the tools and have a play around. The starter edition only allows small, trivial applications to be compiled due to a size restriction on the compiled binary.

I compiled a few test versions and ran them on my little lad's Kindle then set about building my prototype game in C# (via Visual Studio on PC).

Shortly after downloading the Xamarin starter, I received an email from one of their development team (James). He was extremely helpful and answered my initial questions. I found this to be a good approach from Xamarin as it cleared a few things up for me.

Indie Edition

This week (May 2014) I purchased the Indie license for Xamarin (Android, iOS and Mac). Initially I'm targeting Android as that's a natural fit with my PC development. When I have everything working satisfactorily on Android I'll port to iOS.

Again, like the starter edition, getting everything set up was pretty easy.

Thoughts on Xamarin Studio

Because I bought the cheaper Indie version (which fits my requirements for now), I am using Xamarin Studio for Android development. Visual Studio plug-ins are available with the Business and Enterprise editions.

As a Visual Studio (2010) user, getting into Xamarin Studio was extremely easy. I created a project in a subfolder of my Visual Studio project and added in the files. There's an option to link instead of copy which makes code sharing very easy and simple.

A book I found most helpful in getting started was 'Xamarin Cross-platform Application Development' by Jonathan Peppers (available on Amazon). It's short and straightforward book that gets you started on Android and iOS.

I had already designed the codebase so that platform-specific code (OpenGL, Sound, Window handling) lives in separate subclasses that can be excluded from the project (in my case via #if).

Before long I had all of the code compiling, albeit with lots of TODO comments and empty functions.

Unlike the C++ projects I have worked on, I encountered practically zero compiler differences. C# seems to be much more consistent across Microsoft .NET and Mono than the various dialects of C++. Also, I had no need to drop into Objective-C(++) as with my 'Starfire Ares Assault' project that used C++/SFML.

Android Development Thoughts

After getting the codebase to compile I gradually converted my OpenGL (via OpenTK library) code over to OpenGLES (1.1). This was pretty easy - just some subtle differences in syntax and the necessity to get rid of GL.Begin and GL.End blocks, replacing them with vertex lists. That's the main difference between OpenGL and OpenGLES for straightforward applications.

Another extremely useful book is 'Beginning Android Games (Second Edition)' by Mario Zechner and Robert Green. It's an Android/Java book but figuring out the Android way of doing things and OpenGLES coding is easy enough to switch to Xamarin.

Finally, I added a bunch of touch handling code to my engine. Again, with help from the Android Games book this was pretty easy. The main thing that tripped me up initially is the fact that events contain the current location of every pointer (finger) in an array. For example for a 'Down' event indicating a finger first touch, the coordinates and other information are provided for the 'Down' along with coordinates for every other finger that's already down.

In addition, the array of pointers contains an Id that identifies the individual finger, i.e. every event related that finger includes the Id. That's one to watch out for!

Summary

In summary, coming from a C# and OpenGL background, using Xamarin tools to build a game that works on PC (Windows) and Android has been very easy. I haven't investigated deployment or deeper subjects yet but my experiences so far are good.

Xamarin have created a set of tools that are very easy to get along with, particular if you're familiar with .NET already. I look forward to using the tools to build some apps in addition to games.

Background / History (zzzzzzzzzzzzz)

My blog has suffered rather badly for more than a year, largely due to a 15 month contract to develop business software for a client.

In the meantime, I have been investigating technologies to build cross-platform games and applications (i.e. PC, Mac, Android, iOS in the first instance).

I played around with Monkey and had a decent prototype of my current game working, however I began to realise that my skills were being too diluted by the use of another language and Monkey is only suitable for games. I would like to port my kits database application to multiple platforms and don't want to have to learn two cross-platform technologies. Also there's no synergy between Monkey and my business development (predominantly .NET - C#, Visual Basic, SQL etc).

The final nail in the coffin was the main advantage of Monkey over other technologies is the HTML5 support. Unfortunately, the sound doesn't work on iOS due Apple's restrictions.

The logical conclusion is to use .NET (C#). I looked into MonoGame but that seemed too heavyweight and I read mixed reviews of its reliability. Under the hood of Mono, it sits on top of OpenTK (a cross-platform wrapper around OpenGL, OpenGLES, OpenAL and various O/S bits) and SharpDX (a Direct-X wrapper).

Thus, I decided to investigate OpenTK (SharpDX maybe later) and Xamarin. Xamarin is required to code against Android and iOS using .NET (even if you use MonoGame).

In January, I downloaded the free Starter edition of Xamarin and had a play around. I managed to get a demo OpenGL application onto our Kindle Fire, but that was about it. In the meantime, I've been porting my game prototype from Monkey to .NET (C#) using Visual Studio on my PC with a view to using Xamarin.

Anyhoo...

Having finished my contract work, I bought an Indie license for Xamarin iOS/Android/Mac and set about porting. My C# codebase was set up to be cross platform, therefore adapting it to interface with Android functionality (OpenGL ES - the embedded systems version).

... and the rest is at the top

Windows 8 Initial Impressions

Shortly before Christmas, I installed Windows 8 on the compact Sony PC in our lounge (known as 'the biscuit tin').

It is one of these things: http://www.amazon.co.uk/Sony-VAIO-VGX-TP3Z-Cylindrical-DVD-RAM/dp/B001CNT99M

My primary motivation for this was to give me a test machine for games and KitBase (scale model database). A few people have started asking about Windows 8. As it turns out, both work OK (except for a driver-caused bug in Starfire full screen).

I used Microsoft's Upgrade Assistant and downloaded the ISO DVD image (Windows 8 Pro 32-bit). This was all pretty painless and only cost 25 quid, which isn't bad value.

I completely wiped the machine and re-installed. Installation was pretty painless and the O/S was up and running in no time.

The fun really started when I tried to get hold of some video drivers. I already had a record of the video card type and headed over to nvidia's website to get the appropriate installer. This is where the fun started. The drivers would not recognise the video adapter. After much headbutting the keyboard and reading forums it turns out Sony have twiddled the hardware ID's so that you can only use their tweaked drivers.

Off to the Sony website then. Windows 8 drivers - nada. The only drivers are for Windows Vista. As some folks on forums recommended installing these I did so. They installed OK but they are clearly not 100% compatible as Steam crashes in 'Big Picture Mode' (their gamepad friendly interface) and Starfire has a weird scaling problem when run full screen.

Thanks Sony! Very helpful using standard video hardware then crippling it by preventing the installation of the latest standard drivers. Apparently, the same problem occurs with various Sony laptops. I won't be going to Sony for a PC again.

Anyhoo... Sony idiocy aside, here's my summary of the Windows 8 experience. Bear in mind this is from the perspective of use with a TV for internet browsing, gamepad gaming and NetFlix. I suspect I will have more confusion and niggles using it as a main development O/S.

Pros

• *Extremely fast boot up. Much faster than Vista.
• *Extremely fast log in.
• Start screen with tiles works well on a TV

Cons

• Desktop and Metro switching can be confusing, e.g. accessing a PDF through desktop Internet Explorer causes a switch to full screen Metro
• Having two Internet Explorers is a bit odd (one is traditional desktop, the other Metro)
• Pop-up side bars are not very intuitive initially. Watching Microsoft's short introductory videos is recommended. This seems a bit poor design-wise as you don't need to watch videos to figure out Apple devices running iOS. I can't imagine the swipe on touch screens is any more intuitive.
• Driver horrors (largely due to Sony's dumb tinkering)

* I appreciate boot time and login time are dependent on installed applications and config. Both the Vista and Windows 8 configurations had minimal software. Just drivers and Open Office.

So, in summary, I quite like it. The chunky new Start screen works well on a TV and the lack of Start menu isn't really a problem if you pin applications to the desktop taskbar and get used to the pop-up sidebars.

I have already bought a license for my current development box. I will be upgrading it and will most likely connect it to the older TV we're keeping in the study/office.

Edit: This post doesn't express any of my thoughts on the whole App Store / Lock Down mentality that Microsoft are drifting towards (in line with Apple and their money making machine). As with other developers, I do worry about the openness of Windows being eroded and Microsoft's ability to censor and control software that is developed for their platform. That's for another day...

Synology Part II

The new Synology NAS box has been ticking over for the last few weeks.

On the whole, I'm pretty pleased with it. Having docouments and files centralised is a boon, even with a single user business.

A few of the good things I've found:

• Playback of music through the iTunes interface is pretty easy. The Audio Station application is OK but I prefer iTunes on the whole.
• Having PHP and mySQL on the network is very handy for testing websites and PHP functionality.
• The Wiki (Media Wiki - the basis for Wikipedia) is great for tasks lists and notes, as it can be accessed easily from any machine with a web browser. Having it centralised means I can bob on and write down an idea from the iPad/iPod or lounge PC.
• Setting up automated mySQL backups is a bit of a pain. I will need to get my hands dirty with config files and the Linux command prompt to get this working.

I few problems I've encountered:

• Copying photos onto the DiskStation directly is a bad idea. The thumbnail process is hideously slow. Make sure you install and use the Synology Assistant on your PC. Your PC is much faster at converting images.
• Moving folders around from Windows Explorer can cause them to lose permissions and become inaccessible. The workaround for this is to move them from the DiskStation web interface. I haven't yet tracked down the pattern of behaviour for this or found a solution online.

NAS Box Setup

My Synology DS213 arrived yesterday afternoon (yay!)

Installation Notes:
(If you are easily bored or don't want to read the gory details, skip to Summary at the bottom of the page and see the spoiler of how it went).

It's now unboxed and I am setting about fitting the drives. I opted for two 2TB Western Digital Red drives (WD20EFRX) as these are aimed at NAS boxes and about half the price of 'Enterprise' (server) drives. I checked compatibility on the Synology website before ordering.

The front cover comes off easily enough allowing the drive caddies to be removed. Fitting the drives is very straightforward using the screws provided. The screw holes in the caddies have rubber washers built in, presumably to reduce vibration.

The caddies slide back into the box with a satisfying 'clunk'. So far so good.

Following the very short quick start leaflet I switch on the box and navigate to http://find.synology.com/

The first step is to download the Operating System (DiskStation Manager). You can choose to do this automatically from the web or use a PAT file downloaded from the website. I'm not using the files from the CD-ROM as they may be out of date.

In a fit of paranoia I have downloaded the latest installation file and burned it straight onto a DVD. I'll use the download file to install.

After setting up an Admin password, the next step is to configure the storage. The default is to 'Create a Synology Hybrid RAID (SHR) volume'. After a bit of Googling and a play with the RAID Calculator on Synology's website I concluded that this is the simplest and best option for my needs as my main concern is redundancy. If a drive fails, I don't want to lose my data.

After proceeding from the final installation step, the box only takes about 5 minutes to configure and reach the login screen. After login, a status screen is displayed indicating that the drive volume is still being created. The web interface is very slick.

After another five minutes the box is ready to use, although the verification process is still going on in the background.

While doing this, something I've noticed (or not noticed) is the sound made by the box. It is very quiet. Just an occasionally whispered chunter. My main PC (which has quiet components) covers the noise almost completely. +1 for WD Red drives and the fans in the DS213.

As an initial test I have dumped some files onto the drive into a new share. I also set up some users and permissions. This was very easy using the Control Panel.

Accessing the shares worked fine from Windows and Mac. A good start!

Summary:

• Very easy to install drives and software.
• Administration is very slick through the web interface.
• Very quiet operation due to Western Digital Red discs and quiet onboard fan.

So far so good. When I have tried out the music and photo functions I'll post again.

Rounding Off

Along side my DIY activities, I have been working my way through a list of fixes and enhancements to Starfire. Most of the changes are engine-related and will be useful for the next game.

To aid with cross-platform development, I am investing in a NAS (network-attached storage) box. This is fundamentally two hard drives attached to a low powered box running a Linux based O/S (called DSM). This will allow me to centralise my development files (source code, images, sounds, documents etc) so that development from Mac/PC and ultimately Linux is easier.

As I work more on iOS code, I will spend more time using the Mac. I have found that accessing Windows 7 shares from the Mac is troublesome and there are various discussions/blog entries about this but no real solution.

Additionally, having a Linux based NAS gives the following other benefits:

• Website development server environment (PHP / mySQL)
• RAID for important files
• Access to documents and files from mobile devices (if PC is switched off)

I could do some of these things on my main PC or a secondary PC but having them central is a boon.

I'm sure some other benefits will be discovered as I familiarise myself with the box. I would probably have the box in my sweaty paws by now if not for my bank's anti-fraud measures blocking my order. Should be sorted now...

Another avenue I'm exploring is an alternative version control solution. Currently I use SourceSafe which is:

a) awful

b) Windows only

c) awful

I've read about various alternatives including Subversion, GIT and Mercurial. I am swaying towards Mercurial at the moment as it seems to be the most cross-platform (being mostly Python) and supposedly has a relatively easy learning curve. GIT seems to have poor Windows support and Subversion seems like overkill for a single developer scenario.

Next steps - finish next Starfire version for PC/Mac and get it released, then polish up the website.

Strategy

Wow, I didn't realise that I hadn't blogged for a whole month. Things around our house have been crazy with our conservatory being fitted and tiled then bathroom replacement. Currently the kitchen is being ripped out and tiled, ready for new units. It's pretty hard to concentrate on development or anything else when your house is being destroyed and rebuilt around your home office.

I have managed some game development work, along with marketing of my other product KitBase.

The main focus of my gamedev activities has been performance options in Starfire. I had set out to fix the screen resolution the same as desktop but this leaves little video memory and results in poor performance on machines without gaming-oriented graphics cards. So... I've had to relent and add a choice of resolutions.

The other niggle has been Vertical Sync. Some video card drivers kindly ignore the request to switch this on, leading to horrible jerky/shimmering video (known as tearing). To remedy this there's now a Vertical Retrace option in the Video menu. The options are On (use OpenGL if video card allows), Off (yuck but helps performance) or Force (uses Direct-X to wait for the monitor sync for those OpenGL drivers that ignore the request.

I've also added some sliders for the nebula effect, starfield and particles. Again, this allows smoother play on slower machines. The nebula consists of 100 layers of sprites all moving at different speeds. Looks pretty but can tax some graphics cards.



All of this should be released in the next few weeks.


Another thing I have been pondering is my next game. Like most developers I have a ton of ideas and a limited amount of development time.

The game I would really love to make is a First Person Shooter. If I have any hope of achieving this, I'll need to buy in some models/media and use an engine. I will be investigating Unity for this purpose initially and creating some prototypes.

Now that our little boy (nearly 2) is taking an interest in bashing keyboards and twiddling thumbsticks I would like to make a few little games for him. My SFML based engine should be good for the PC versions but I would also like to add code to support iOS. Unity would be an option here also, but I would like to keep a C++ codebase going for total flexibility and so that every game product isn't tied to commercial third party software (SFML is OpenSource with an nonrestrictive license). If I can make these polished but casual they might also provide welcome further income.

Hopefully the next blog post will arrive in less than 30 days!