Porting Pixels

2016 GameJam #1 - PortCrunch

So on the weekend of the 15th of January 2015 - Dean and I worked on another game with a target of getting it working on Android, iOS, Windows, MacOS in one weekend.

Anyone who follows our antics will know that typically we try to create a game or at least a prototype in a weekend. Sometimes we attend organized game jams but always, we create something new ourselves.

Apart from this time.

This time it wasn't one of ours.

Introducing Pixel-Blocked! A sweet puzzle game by Daniel Truong (of Daniel Makes Games) which oozes innocence until you realize that underneath those cute and colorful pixels beats a sinister heart.

It's one of those game which has a novel concept, well thought out controls and a nice difficulty curve - easy enough to lure you in and difficult enough to keep you coming back.

It also has a set of awards and unlockables for those who relish mastering a game instead of simply playing it.


He's also made bunch of other games which can be found on iTunes.
https://itunes.apple.com/ca/developer/daniel-truong/id915310760


We figured it would take us a weekend, so we made a GameJam out of it.  We wanted to do a good job which did the original game justice and have fun with it. We'd have our work cut out for ourselves for sure.

This wouldn't be a gamejam, it would be a ...

#portcrunch

First steps

On Friday evening we created the project structure to get us going and played the Windows Phone version to see how much work would be ahead of us.

The game was originally built using XNA with C#, which meant a port to MonoGame would be pretty straight forward.

Because Xamarin and MonoGame work really well with shared code projects, it's reasonably easy to get a cross platform game up and running.

This meant that the majority of the porting work would be dealing with the differences in hardware, not operating system.

Obviously there are a few gotchas when porting, however for the most part, it's plain sailing.

Shared Code FTW

You have a common code project which contains the bulk of the game code and individual platform specific projects which contain the platform specific stuff - usually, this is very little, just the launcher and icon sets but it also has a content pipeline file.

Building the content pipeline.

The MonoGame content pipeline allows you to compile your content for specific platform and place them into the project. They allow for platform specific conversion to be done automatically so there's less to worry about as you add content to your game and make changes. It handles audio, graphics, shaders, fonts... and a lot more, making sure the content is properly compiled and put into the right place.

Shaders 

Pixel-Blocked! uses shaders for some things, so it was important to get these compiled for the correct platform. Once again, the content pipeline to the rescue. By making a few changes to the base shader code, they could be compiled for any of the supported GPUs.

There are some gotchas with shaders which  you may need to be aware of. More on that later.

Nothing is perfect...

While porting the shaders, we found a bug in most recent Stable MonoGame - Dean has since fixed it so it should be available in a short time for everyone. It's handy having someone who's really hands on with the MonoGame code-base.

Screen Resolutions.

The game was written to support a fixed resolution. After-all, the graphics are intentionally blocky so scaling is not going to be a problem, however getting the game to look good on different screen resolutions is always painful. Coupled with the fact that the came adjusts itself for Portrait of Landscape depending on how you're holding the phone... multiply those problems.

Render Target or Scaled co-ordinates?

The initial desktop version of the game drew its graphics to a render target which could be scaled. A sensible approach and one used by many developers.

This is a great way to achieve a constant look to your game - also an approach we've taken with one of our unreleased games; unfortunately we encountered problems with the Amazon Fire device with Pixel-Blocked! so we had to change it and adopt a more traditional maths based co-ordinate scaling technique.

There are pros and cons with any scaling technique when dealing with different screen sizes.
You see the problem is of aspect ratio. You can't simply fill the screen or things start to look weird.

Aspect Ratio?

For those who don't know what that is, it's the ratio between the width and the height of the screen.
Most computer screens are based on a 4:3 ratio, so 640x480, 800x600, 1024x768. This ratio has been used by PC games for a very long time. Then came the wider screen formats 16:9 which are used for most TVs 845x480, 1280x720, 1920x1080. These have started to gain a lot of popularity with PC games as people opt for the wider screen.

That's simple right?

Well, not so much - you see the phone and tablet ecosystem provides a rich and varied set of resolutions which are great for the customer giving them a lot of choice; however it's a nightmare for the developer where you have to make sure your game or app looks nice on all of them.

So you have 2 choices. Use a render target and scale to fit but keep the aspect ratio and letterbox any gaps, or manually position your elements based on some scaling factors.

It's a minefield without an easy route through. But with persistence, you'll make it. Just choose which will work best for your game.

The Windows phone version we ported used a scaled co-ordinate system, so we continued along the same lines.

As the day progressed, 

things were coming together nicely. The game ran on Android albeit with controls too small on the larger resolution devices and with a couple of issues with screen rotation. However for the most part, things were working.

Dean had a little trouble on iOS and made a change which broke the renderer... so I killed him.

Just kidding.. we've been friends for 20 years, he's not that easy to kill.

We worked through the day and most of the evening to get the game in a working state and to make sure the input systems were working correctly.

We also had some issues with screen rotation. For some reason when the orientation was switched from Landscape to Portrait and vice versa, the viewport dimensions were not reflected.

It appears that at the time of writing, this is a bug in MonoGame.
Given that MonoGame is open source, we'll probably fix it and submit a patch.

The next day

Dean re-broke the iOS build, then fixed it, the broke it again and then fixed it for good.

We had an issue which only manifested on iOS where the render state was being corrupted. So Dean went bug hunting.

Found it.

Squashed it.

Apparently calling GetData on a texture is a bad idea. Reading data back from texture memory is slow and we found that it caused corruption of the render state. Dean has promised to write an article about this shortly. When he does, I'll put a link in here.

I spent the majority of the day slogging through the screens to scale each element..
Making sure that text was scaled properly and that things lined up no matter what the resolution was.
Some screens were harder than others, a couple were quite tricky given the complexity of the UI they provided. But in the end, the screens looked good on pretty much everything.

Dean spent a little time speeding up the loading time on Android devices.
Sometimes it's OK to load everything up front however when there are lots of graphics, some of which require additional processing - not all devices were able to handle this in a timely manner.

Testing

Introducing our glamorous testing team.

Seulki, Jenny and Katrina - Our glamorous testers.

The girls were given all of the tools they needed:

Wine,
iPads,
Galaxy Tabs
and various Phones...
more wine...

They were tasked with playing the game on all of the devices to make sure everything worked. They should pay attention to the closest details and report any crashes.

Everything was going fine until things started getting competitive. It seems that they were determined to beat each other's score.

So following 2 days of solid porting, it was really good to see the game being enjoyed by the testing team.

The wine probably helped a little, but the game is a lot of fun.

There are a ridiculous amount of Android devices in existence. One of our tasks was to test the game on as many devices as we could. Although we don't have access to the entire spectrum of devices, we do have a set which covers most bases.

One of the great things about developing for the iPad and iPhone is that you're sure that the game will run on all devices (until they change the OS, but that's a post for another day)

Incidentally, Xamarin offers a service called Xamarin Test Cloud to run your app or game on a large array of devices and monitor the results. It's certainly worth considering.

Finishing up

It took a little bit longer than we anticipated - these were mostly down to strange glitches in MonoGame which we had to address, as well as strange differences in behaviour (Amazon Kindle handles rotation differently to any other devices)

But in the end, we have a working game which runs really nicely on all the platforms we've thrown at it.

Waiting for Review and an Easter treat.

So last weekend was busy...

It was Easter, so therefore in the UK, we had Friday and Monday as national holidays. So we used this time to launch ROO on the OUYA and to prepare for the iOS release.

ROO is currently (as of the 9th of April) waiting for Review. This apparently could take a little time so we all have to be patient. It will be really nice though when it's released as we've done a load of work to make it look nice on the iPad and iPhone with that lovely Retina screen.

Preparation is key

Of all the stores we've released on, the App store is probably the most difficult to get going with. There are many aspects of the store which take some research in order to get right. Luckily for us, Dean knew what he was doing and was able to steer our wayward ship through any potential rocks to get us out to sea. It's also the 3rd time I've had to fill out a Tax form. As Songbird Creations is a Limited UK company, we don't pay US taxes (instead we pay UK taxes) but Uncle Sam needs to be reassured that we're not trying to get away with his money, so we fill in a W-8BEN form and sign it.

For the OUYA I had to print it, physically sign it, scan it and send it back to them. Amazon had a version online and a handy helper, which while was handy could have used a "We're a UK company, just fill it in for me" button like Google does. 

Confirmation is key

While Preparation was certainly important, I've never had to confirm as many things in my life as I did getting the more legal aspects of the store running. Phew, glad that part is over is all I can say.

Customization is key

Phones typically have a slimline aspect ratio some are 1080p others a variation of, however for a landscape game, you're typically looking at most of the action being towards the bottom of the screen, certainly for ROO this was the case. Pretty clouds, blue skies and mountains cover the top to middle and give the illusion of distance and speed while the foreground and character reside towards the bottom to ground the action. 

For the OUYA, we needed to move things up a little otherwise the player is bombarded with a TV image made entirely of sky, for iPad it was worse as the aspect ratio is different again.

So we had to work out how much space was required to keep ROO in pretty much the optimal place while filling the rest of the screen with interesting but not too distracting detail. We had to make some more graphics to place at the bottom of the level.

Once we we done however, it looked and played really nicely. We also had to add an Achievement Toast system to complement the Game Center achievements which you can see in this video.

Feedback is key

On Friday evening, I went out around Cambridge and introduced a few people to ROO, one of the bits of feedback was to do with the Perfect Landing / Resurrection system. It waited for 2 seconds after ROOs failure and used a perfect landing token to burst back into the game (basically a lives system) however it turned out that people were becoming frustrated with the way it was implemented. Often they would reappear only to hit a cactus, a rock or worse - fall directly into a ravine. So something had to be done because while funny, I don't want unhappy players. So now there's a system where you're prompted to tap the screen to reappear when you want to or wait the full 2 seconds. Play testing this feature made it obvious that it was the correct solution. It makes failure your own fault as opposed to the game punishing you randomly.

A Happy Easter

It was really nice to see ROO on the OUYA store so I documented it with a little video. So you can see me install ROO for the first time on the OUYA as well as see how to get those pesky perfect landings. Stick around to the end for a little discussion in difficulty, game dev principles and a personal message from me.



So there you have it. ROO is on the OUYA market as well as Google Play store and the Amazon App store and we're awaiting  our entry to the App store.

If you'd like to know more, why not follow me on twitter @thecacktus

Have fun.

Making a trailer

So we put a trailer together for ROO. It took a couple of days to do and was a lot of fun. But why is this news-worthy? Well, apart from the fact that Roo is a fun game and shouting about it increases the chances of someone else having some fun (which is always a good thing) - I actually used some new video editing techniques in putting the trailer together which might be interesting for some people to read about.

Putting a trailer together looks really simple - and ROO being a very simple game, appears that it should be a very easy thing to do. Well, in a way it was a lot easier than putting a trailer for perhaps a movie or a show. (I've not edited a movie or show trailer - but after editing the London Part Deux game jam video, I can only imagine the difficulty involved).

Even though ROO is a simple and fun game, it's not enough to just capture footage and slap it into a video. When you consider it, you have more time in-game to enjoy the everything the game has to offer but only a tiny amount of time in a trailer video to show the goods and hook a potential player.

Before I start, I'll admit - I'm not an expert (watching the trailer will attest to that) but as with most Indy developers, I don't have a marketing department (or a budget for that matter) to give the task to, who can spend their considerable skills and experience putting something amazing together.

Unfortunately, until Songbird-Creations becomes somewhat bigger, everything is in-house by those who wear many many hats.

So this Trailer, how was it made?

Well, just like any other task in game development, you need to have the right tools for the job. I'll be putting some articles together over the coming months describing the tools we use and why we use them. But for video editing, we use Adobe After Effects.

Now, Adobe After Effects is a professional level tool which can accomplish a devastatingly overwhelming number of things. It's so powerful that most people will only ever scratch the surface of its potential and it used to have a price tag to match - which was normally sidestepped by pirates - however, through some amazing vision, Adobe have licensed their entire suite of software on a subscription basis, so it's not expensive any more. So there's no longer any justification in pirating (to learn it) and you get the added bonus of Photoshop and Illustrator (amongst others) included too.

The trailer is broken down into 4 main sections.

• Introduction,
• Story hook
• Gameplay 
• Call to Action.

Introduction

The introduction shows our company logo and the Game's title. This is important to get right as it's the first thing the viewer sees. It has to get them interested enough to want to watch the rest. Viewers have a lot of content they can watch instead, so a video has to be worth it and someone making a video has to respect that time.

So I open up with the Songbird creations logo, some clouds and a Balloon. This is supposed to set up the viewer with the company signature and they follow the balloon towards the game's title when it appears. The balloon appears in the game in the distance. The balloon itself is from a game which was never completed which starred a cartoon version of my Wife, meaning that She's in every game I make in some way - kind-of like Stan Lee in all Marvel movies.

The screen then changes to show something similar to the in-game titles. All of this should only take a few seconds.

Story Hook

Then we need to get the viewer right into the story. ROO! has a very simple story where little Timmy has fallen down a well (again!) and it's up to Roo to get help. To do this, I wanted to have a scene I could move around in. This meant setting up a 3D scene so that I could have proper Parallax backgrounds to add a sense of depth to it. I could have done this by panning from left to right in a 2D scene, but it would have actually meant more work. After Effects has everything you need to manipulate a 3D scene; you can place cameras, manipulate them with dummy objects, alter their positions, rotations (and pretty much any property they have) all smoothly using key frames.

So I built the scene using real assets from the game and animated the camera to tell the story. 

Roo and Timmy are in the outback (although Timmy is never shown) Timmy sees a well, and falls in - the camera pans and zooms in on the well. Following the splash, the camera quickly pans to Roo who looks suitably concerned.

Cue the game!

Gameplay

This is the part where we let the potential player know what the game is all about, what to expect and why they should play the game. ROO! is a very simple game, it starts out easy enough and gets progressively more difficult as it becomes faster and have less time to react. Eventually the player will succumb as their reactions become less able to dodge the oncoming obstacles - ROO moves at a fair lick of speed when he gets going.

The game is a mobile game for the most part, so to get the footage, I recorded the PC version using Fraps and ran through the game many times. My hope was to get a high enough score to show the game running a breakneck speed as well as record some amusing failures. The resulting movie file was 7.8gb - I'd have to edit it... a lot.

Roo is a game which can't really be shown off in static images, they don't do it any justice so hopefully the video does the trick. I cut several failures back to back for laughs, then did a run as far as I could get. The entire section is about 50 seconds long and basically shows the game in it's entirety. It sounds a little sad when said like that, but it's strange how something so simple can keep people engrossed for so long.

At the end of the gameplay section, is the Noooo section which normally greets every failure.

Call to Action

A trailer is after-all a marketing video so there needs to be something which informs the potential customer where to go next to find out more and potentially buy the game. 

On this part of the video I wanted to show where the customer could get the game from - in this case the Google Play store as well as the Amazon App store. Later we'll have the App Store, Windows store and quite probably the OUYA market place. As these become available, we'll have to upload other videos - potentially replacing this one.

I didn't want to put a Coming Soon part on the video as I wanted it to be Factual, to 'close the deal' right now. When we're on the other stores, we'll be factual about that too.

The entire video is just short of 1:27 and is accompanied with the opening titles music for the game.

Although it is tricky, I tried to keep as much of the video in time with the music to keep them from feeling disconnected. I even make the Google Play and Amazon store logos dance to the music towards the end of the video.

As I said, putting a trailer together is Marketing, you have to try to get people interested in your product. Without marketing, a game is a fun programming exercise. If you want people to play your game, you need to let them know about it and a trailer is a good starting point.

Have fun

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.