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.

The little console that could.

A little Kickstart!

Back in January of 2013, I was procrastinating on the Escapist Magazine website and I came across an incredibly good idea. A micro console which takes advantage of the recent surge in phone processing power and the Android Operating System; all combined within a tiny stylishly designed box which wouldn't look out of place next to the nicest TV. A full HD 1080p console from the outset with it's own games market with games which must be free to try.

Kickstarter had shaken up the games industry and it seemed that the reported stranglehold publishers had over the various software houses would be weakened and it would usher in a new age of the bedroom coder.

Well, that happened somewhat; The bedroom coder did emerge and a lot of them released games; and some of them were really good. Kickstarter became the go-to place to get funding for the more adventurous or ambitious. There were a few bad apples of course but the net feeling was positive. There are debates as to whether Kickstarter has been over saturated with games and that it's become more difficult to be noticed among the crowd, but that discussion is for another day.

Mr Schafer I presume?

Anyway, I'd been following the antics of the people at Double Fine and backed their kickstarter for the game which would later be known as Broken Age.

Their kickstarter went on to demolish their originally requested amount to the tune of $3.3 million dollars. The internet went bananas.

As part of the deal, they would document everything and the documentaries would turn out to be really insightful to watch. 

It reminded me that Game developers, those people who create these amazing experiences that we love are regular people with hopes and dreams. They weren't too dissimilar to me, they had the same drive and passion as I did - just better funding. 

A large dose of gasoline was poured onto my previously thought to be extinguished candle.

So with both DoubleFine and the OUYA breaking records on Kickstarter, it seemed like the perfect time to get back into games... and the OUYA seemed to be the perfect platform to release it on with it's almost guaranteed success and it's open - yet moderated - marketplace.

I missed the Kickstarter for the OUYA however I did pre-purchase one in January and it arrived in July while I was in the USA - I wouldn't be able to get my mitts on it for another 2 weeks. The plane didn't get home faster because of tail-winds, it was by the sheer force of my will! :-)

I remember being surprised at how small and shiny it was and how the controllers felt really nice and solid. It was simple enough to set up and with it's online market and free to play nature was instantly appealing. I soon found myself purchasing many games. 

The biggest question became, what kind of game do I want to write? Platformer? RPG? Adventure? The ideas flowed fast and strong and eventually I settled on the game currently known as the Reversion Bureau, a puzzle platformer - which has had 2 years of development time spent on it. However more on that game later. 

Fast forward to now.

It's April 2015 and we now have a game released on the Android platforms. It's not the Reversion Bureau, ( that game will come ). Instead, it's a cool little endless runner where a kangaroo named ROO! must race across the Australian outback to rescue his best friend Timmy from a well he fell into. 

We've already released it onto Google Play, Amazon App store and now (pending) the OUYA. On top of this, we're putting a lot of work into preparing for the iOS release, as well as a Windows Phone release.

The OUYA is still going in spite of 2 difficult years in the industry which saw the launch of the new XBox One, the WiiU and the Playstation 4. OUYA have altered the rules a little in response to that; games no longer have to be free to try as long as they have a video to show the gameplay. So we've released our game for a very small fee.

To get this far it has taken a lot of work covering many aspects of the game development process.

• Game Design
• Lots of coding
  
  
  
• Graphics creation
• Rigging and Animation
• Assets pipelines
• Music authoring
• Sound design
• Video editing
• Storefront management
• Device Testing
• Play Testing
• Focus Testing
• Project Management
• Marketing

If it seems like a lot of work, that's because it is. 

Most of it goes unnoticed as it's mostly not fun or glamorous. 

For instance, Project Management and Marketing are incredibly taxing to do correctly and are utterly vital if the project is to have any chance of commercial success - or even being released as a product. Each market place has it's own store-front with it's own way of handling things. Marketing is hard work, even for something you love. It often feels like climbing to the top of every building in the city so you can shout from the rooftops. Those with money or sense employ others to climb the buildings for them, or employ those already positioned to shout.

So here's what I'm hoping for: That the OUYA can fulfil it's promise, that games made independently by small teams can reach those who want to have some fun, kick back on the couch and play games on their TV made by people who care. 

But no matter what happens,

 I'm grateful for that glorious moment where the stars seemed to align, the rebirth of the bedroom coder and the infinite possibilities which they could bring.. that and flappy bird, mostly flappy bird :-)

A plug for the cool little box 

The OUYA is being sold online at http://shop.ouya.tv/ as well as on Amazon and in Target stores in the USA. If you don't have one already, you should pick one up. There's a lot to be said for the games available and playing with the controller is great.

A note to travelling executives:

The OUYA packs away nicely into a travel bag and given that most hotel TVs have a HDMI socket, and there's rarely anything on the TV anyway, it makes a great travel gaming system. Something else to do on those long business trips.

Also, a note to parents: 

There are no disks, so no expensive games to break or scratch or leave cluttered all over the place. Kids can start the game they want, they're mostly for free and those which aren't are inexpensive. It supports up to 4 controllers, it's cheaper than an XBox, a Playstation and a Wii and it's still totally worth the money.

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

Roo's getting an update soon.

ROO has only been out for a week

and we're already getting a serious update ready. This isn't to fix bugs in the code, this is to improve the graphics.

ROO's graphics are nice and cute and simple, but compared to some other games out there, they could do with a bit of a refresh.

So we've given Roo a bit of an update with new textures all round. Even Roo himself has had the artist's brush with some nicer shading and even different facial expressions.

We've updated the way the ground looked because, the outback doesn't look that green - but it's also not a barren desert.

We haven't finished completely on the graphical update, there's still testing to do - we need to make sure that it looks good across a variety of form factors and resolutions.

Depending on testing, we should have this update ready for the weekend. So look out for that.

Before that though, You can still check out ROO on the Google play store and support us :-)

In other news...

Soon...

We submitted ROO to the Amazon App store today. So we should have ROO available on your Kindle Fire soon. This is exciting news as it opens an entirely different store front to us.

We may have to tweak a few things to get through their testing/approval process, so it may be that the Amazon build contains the new updates off the bat.

Finally, 

ROO is still as fun to play as it was when we first made it. This to me is a great sign, the game has a soul and this shows through in the gameplay.

Roo is on the loose.

Watch out everyone, there's a Roo on the loose.

So late last night, Dean and I released our endless runner game "ROO" to an unsuspecting Google Play store. The world held it's breath as the app went from pending to published and then continued to breath normally, as it had done previously - oblivious to the event which had occurred. Apparently it wasn't the world holding it's breath, it was us.

The next morning with the world much in the same state as it was the night before, I worked on a patch to correct some defects in the achievement award system and to fix a scenario where Roo could fall into a ravine and not die. I uploaded the patch, went to my phone to get the update and...  no update!

Eek! Google informed me on the screen that the update is pending and could take several hours; Which got me wondering.. what happens if the update is urgent? I'm guessing that this delay is partly down to whatever CDN system they have to support the world's app demands and partly as a measure to ensure that developers go through the alpha, beta and prod development cycles - only promoting to the next level when the testing merits it - which is fair enough.

Eventually, the update became available and I felt confident enough to tell people about the game. The last thing I wanted was that people downloaded the game to their device only to find that it didn't work for them. Thankfully it works well on everything it's come across so far.

After making the public announcement, the installs began to trickle in. Hopefully, this will enable us to put more time into the game later on because nothing tells a developer that their time is well spent updating something than happy customers telling them so.

We've had some feedback too about the game and the gameplay, all of it useful.

However I'm going to hold off implementing any feedback for the time being though, it's far too tempting to dive right in and make changes quickly without first considering how it will impact the game. It carries a massive risk of changing something which alters the fun. I could end up making it a less fun experience while trying to improve something.

So far the word is that the game is fun and addictive, I'm going to leave it there.. and in any case, someone's getting close to beating my score - I can't have that now can I? :-D

Good old Roo! Click his little face to get the game :-)

And We're up! Roo is Live... the world goes crazy

Roo is on the play store.

It's been a lot of work, and I wager that there'll be more work ahead once the public get their hands on the game; but it's live on the Google Play store.

From that Friday evening where we didn't even have a concept to finished and published game has been a journey of surprises. Some good, some less so - but all of them part of the learning experience.

You can check out ROO on the Google play store go buy it for £1 and support us :-)

So what's next? 

Well, we're going to see how ROO! is received and if it gets any traction, ROO may get some more love - if it gets a lot of interest, we may even make a sequel. One thing is for sure though, we'll be making more games this year.

We have another game jam coming up this month. Just like last time, we have no idea what the concept will be; Only this time around, we have another programmer and a graphical designer.

The other programmer is also a certified pilot and the artist works in fashion - so it should be an interesting mixture.



My best score is around 1700 meters. If you can get further than that, I'd love to hear about it.
I'll be putting a video up on Youtube soon, stay tuned.

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.