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.

10 Games.

I've read that you should make 10 games before you reach success in game development.
This isn't a strict value I'm guessing or any kind of hard and fast rule. However, I do feel that it's in a game developer's best interests to make as many games as possible. Partly to hone one's coding skills but mostly to understand what makes a game interesting and fun. It's also an important journey of self discovery, to understand one's talents and limitations.

I wrote many games on the spectrum, however none of them were what I would call "Finished" apart from the game I've listed here. Unfortunately, nothing remains of any of them, it was over 20 years ago. The rest of the games were for the PC platform and more recently for mobile devices..

So here's my list.

Treasure Caves

 ZX Spectrum. A platform game where you collect treasure in a scrolling maze like level to activate an exit which would appear after you'd collected enough treasure, all while avoiding traps and using teleports to move you to the next platform above. Perilous spike pits would plague your every fall.
The game included an editor where I would challenge a friend with a cunning level and he'd return the favour with an even more cunning level. This game was memorable to me because of the large levels, the large sprites. I had to write a Run Length Encoding compression system in Z80 (before I knew what RLE was) to fit the levels into memory. The game was fast and allowed for very devious traps. Even though the gameplay was simple, it was a lot of fun.

• Language: Z80 Assembler, Basic
• Status: Completed, Lost

SUOF: Subtle Use of Force

A vertically scrolling shooter where you must defeat an invading alien force using a previously mothballed fighter. You could collect weapons dropped from dead enemies, it had a variety of different aliens, each with their own abilities and tricks. There were also Bosses to defeat who also had their own patterns and abilities.

• Language: Borland C
• OS: PC MSDos. 
• Status: Completed - Unreleased

CHAOS: Battle of the Wizards - Remake.

A remake of the classic gameby Julian Gollop. Chaos pits 2 or more wizards against each-other in a last man standing battle to the death.
It was abandoned due to really difficult to track down issues in the code which would take a massive amount of work to fix. However the gameplay was faithful to the original with every spell and monster re-created.

• Language: VB6
• OS: Windows
• Status: Incomplete - Abandoned

GUNS: A DelphiX example. 

A turn based projectile warfare tank game where you control a squad of flying tanks who must fire at the opponents flying tanks on opposing mountain sides across a valley. AI behaviour aimed the turrets of the enemy tanks and raised shields. Limited fuel reserves and accurate aiming of the AI opponent meant that battles were usually quick and devastating -often needing quick reflexes and tactical uses of the shield. The terrain was fully destructible and this was the first game I'd written with a floating camera which worked independently of the player's control. It moved to focus on the selected tank and would also follow projectiles through the air to see where they landed - allowing the player to adjust their aim. All in real time. The game was published as a demonstration of how to make games using the DelphiX component set.

• Language: Object Pascal
• Framework: DelphiX
• OS: Windows
• Status: Completed - Released for free

Anomalous

 A rip in space has occurred following an unexpected situation during a science experiment trying to find a new source of energy to save our world from environmental disaster. The device causing the rip has fallen through the rift, it's up to  you to retrieve it before the earth and the alien world perishes. An entire story arc was planned involving alien civilizations and a civil war which would complicate your efforts.
It was a 2D platformer with skeletal animation - built from the ground up using a home grown engine called the CBCFoundation. An entire toolchain was developed to work alongside the engine including a level editor, skeletal animation editor and animator.
Unfortunately, a hard disk failure meant that I'd lost the source files for the majority of the art assets. It was an event which the project never recovered from.

• Language: Object Pascal.
• Framework: CBCFoundation, SDL
• OS: Windows, Linux
• Status: Incomplete - Abandoned due to hardware failure.

Lander

A variant on the old Lunar Lander game with a twist. You're in charge of a rocket which has to pickup and ferry spacemen from one part of the moon to another. Instead of using retro thrusters to control your descent, you have your main rocket which you must rotate around to move and slow down. Landing on the pad was tricky, you had to land at just the right speed and at the correct angle or Kaboom, however you could take some damage by hitting the mountains - making a horrible metal scraping sound as the rocket takes a pounding. I just couldn't get this game working as well as I wanted. The framerate suffered due to software rendering and the engine did not allow for the level of fidelity in the terrain I wanted.
I would later rebuild this in Unity as an example, however it wasn't as good or as much fun as I'd hoped and was ditched.

• Language: Object Pascal.
• Framework: CBCFoundation, SDL
• OS: Windows, Linux
• Status: Incomplete - Abandoned

Anomalous

A 3D version of Anomalous written using the Torque engine. This game was going to be the version of Anomalous it was meant to be. The earlier version being abandoned following a horrific hard drive failure. I created a lot of art assets however it seemed that no matter how many assets I created, I always needed more and the better I got at creating 3D assets, the worse my earlier work looked in comparison and my animation was horrible. Compared to professional offerings, I couldn't seem to compete. I needed to rethink this game. However I had a story fleshed out - just like the original attempt. It was just too big for a single person to build.

• Language: C++
• Engine: Torque Engine
• OS: Windows
• Status: Incomplete - Abandoned

Tetris

An example of how to build a tetris game, built in a weekend and offered on-line as an example. It was fully functional and surprisingly addictive, which I suppose goes to show how close I was to the original. It is an exercise that every game developer should do.

• Language: VB6
• OS: Windows
• Status: Complete - Released for free.

GUNS

A 3D version of GUNS written using the Torque engine. A fully 3D version of the original game complete with a story about aliens using the Earth as a kind of courtroom to settle petty disputes with squad based tank combat. The human race being powerless to stop them, but the aliens appear oblivious to their plight although seem to have no designs on taking over the world. Abandoned due to complexities with the Torque engine in making it do what was needed for this game and because 3D games need a lot of good art assets in order to look even nearly nice. It became obvious that alone I wouldn't be able to make this game no matter how much work I put into it.

• Language: C++ and TorqueScript
• Engine: Torque Engine.
• OS: Windows
• Status: Incomplete - Abandoned

GUNS:Reloaded.

A back to basics reboot of GUNS with the intent to turn it into a completed game for sale. As the original however with the inclusion of multiple environments, better AI, refuel dropships, different turrets, friendly AI behaviour, A roster of pilots and a plot involving rival factions who do battle on the earth as their chosen combat zone.It even had a tutorial. It was abandoned due to the realisation that the CBCFoundation's inability to use hardware rendering had made it effectively obsolete. I'd also come to the conclusion that it wasn't that much fun to play.

• Language: Object Pascal
• Framework: CBCFoundation, SDL
• OS: Windows, Linux
• Status: Incomplete - Abandoned

Crashblock

Control a person inside a game of Tetris. The person clambers and vaults over the blocks in the arena to get into positions and calls the blocks into position and rotates them. The blocks are held by a chain of increasing fragility - it will eventually snap sending the block crashing down. The player can also request the drop however in either case, it's best to be out of the way when they fall or you'll get squashed. Multiple levels, 4 environments, power-ups. Character graphics were captured from real-time video and roto-scoped. Winner of the Pascal Game Development group's 2007 competition. Published in 2008. This was the last game I wrote using the CBCFoundation and Pascal for that matter. The CBCFoundation's inability to handle hardware rendering without a massive upgrade almost killed it, but it was the advent of C# and pascal's descent into obscurity which finished it off.

• Language: Object Pascal
• Framework: CBCFoundation, SDL
• OS: Windows
• Status: Complete - Released for sale.

SUOF: Subtle Use of Force - Mobile

A conversion of the DOS based vertically scrolling shooter. I started it as an exercise in getting a mobile game developed, to understand the technical requirements as well as the development process. I hooked in the tilt controls to act as steering and on screen buttons for firing. Unfortunately, it was slow and clunky requiring far more work than I had time for at the time. It also ran differently on different phones. It served as a insightful prototyle.

• Language: Java
• OS: PC MSDos. 
• Status: Incomplete - Abandoned

Reversion Bureau

A science experiment has gone horribly wrong and you are called in to make it all better. Effectively a spiritual reboot of Anomalous. A platform puzzle game using live action footage captured against a greenscreen. Multiple characters and a story. This game is still in development but features physics as well as logical puzzles. A key feature of the game is that the main character does not resort to violence - instead solves problems using intelligence, the environment and science.

• Language: LUA
• Framework: MOAI
• OS: Windows, OSx, OUYA
• Status: In Progress

SchemeWars

Control a person inside a game of Galaga. The live action greenscreen captured person fires energy bolts from their hands at increasingly difficult waves of enemies. Complete with Boss creatures, all aliens have their own set of abilities and tricks. Completed and presented at an Insurance trade show.

• Language: LUA
• Framework: MOAI
• OS: Windows, OSx, OUYA
• Status: Complete - Released for Trade show.

ROO!

An endless runner where you have to rescue little Timmy from the well. Designed to be completely cross platform and created during a GameJam in January 2015. The game is notable for it's responsive controls, Spine animation and speed.The game was polished up over a period of 3 months and released on Android, OUYA and iOS.

• Language: C#
• Framework: Monogame
• OS: Android, iOS, OUYA, Windows
• Status: Complete - Released for sale.

Untitled Block Puzzle

We have a project on the go at the moment, which we'll announce shortly. The result of the second Songbird Creations Game Jam.

• Language: C#
• Framework: Monogame
• OS: Android, iOS
• Status: In Progress - Prototype

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

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.

Building MOAI for Android and OUYA - all in one.

Building MOAI for Android.

Some things you’ll need before you start.

Patience and Attention to Detail - There are a lot of steps, thankfully once you’ve completed the earlier steps, you won’t need to repeat them. The steps have to be carried out accurately and while you can repeat them, they delete and recreate directories in some cases, so be sure you’re following the correct steps..

An existing runnable MOAI project. There are example projects to use, but as you’re at the point of building for Android, it is probably safe to assume that you have a project ready to at least test on Android.

It’s quite simple once you’ve got the hang of it.

Installing the Environment

Install CYGWIN (Install everything, MOAI uses a bunch of modules, be safe and get them all)

Install adt (Eclipse IDE with built in Android SDK and plugins)

(install to c:\adt-bundle-windows-x86_64)

Install android NDK (copy into subdirectory of adt-bundle-windows-x86_64)

Install Apache ANT (install to c:\apache-ant )

Add ant directory to your path

Add ndk directory to your path

You can use the [Start]->[Control Panel]->[System]->[Admin System Settings]->[Advanced]->[Environment Variables] and edit the value of the path variable.

(Make a copy of the previous path first before you edit as it’s hard to repair if you break it)

or you can use the command line

It’s important to get these 2 directories added to your path otherwise all sorts of things will go wrong as the build process won’t be able to find things it depends on.

Start cygwin

The Cygwin terminal places you in your user’s home directory on your the virtual linux.

To get access to your filesystem you need to:

cd /cygdrive/c

This places you at the root of your hard drive (C:\ in DOS speak)

Optional: If you already have a MOAI source codebase you want to work from,
you can use that instead.

Get the most stable MOAI from the git repo into c:\moai-dev

git clone git://github.com/moai/moai-dev.git

Once the source code for MOAI has been retrieved to moai-dev

cd /cygdrive/c/moai-dev/ant   

(remember in cygwin / takes you to the root of cygwin - not the root of C: )

Run the script to compile MOAI and generate the project structure.

(this will trash any previous projects - be warned)

Pay attention to any errors, this part will fail if anything is wrong with your environment settings.

./make-host.sh -p com.yourdomain.moai  

(make sure yourdomain does not contain [-] characters, it breaks java when compiled as it can’t be used in a namespace..

Changing Settings files.

modify settings-local.sh file.

Set the android_sdk_root to point to your android SDK.

modify the src_dirs to point to your game code.

(note that the path is to be visible to cygwin e.g. “cygdrive/c/gamedev/awesomegame/” )

Modify settings-global.sh file

change the requires=( … ) line to read just

requires=( “miscellaneous” )

Save the changes to the files.

Run the script to build the project file.

./run-host.sh

If this works properly, you’ll have the files you need to start a project.

Bear in mind that cygwin may not have created the directories with the correct permissions. So to save yourself a lot of heartache, set the permissions on the untitled-host folder to give yourself permissions to add to it modify etc. You can also rename it to something more suitable.

Once you’ve completed this section without any issues, you shouldn’t have to repeat this unless you’re re-compiling the MOAI source.

Compiling the Android Project

Start ADT and click the file menu, choose Import.

Then navigate to the directory c:\moai-dev\ant\untitled-host/Host/build/project

If you moved your host to somewhere else, then use that directory.

At this point, your game files should be in the Host/build/project/assets folder.

Once you have the project imported into ADT, you should be able to run it as an Android application.

Note: I’ve noticed a permissions issue when I try to build  the APK, if you get messages saying that you can’t add to the apk, then you need to set the permissions on the folders again as the permissions didn’t inherit when the new build folders were created.

Building Moai for OUYA

To build for the OUYA console, you follow the exact procedure for a standard Android build but with source code (for now until MOAI includes OUYA code in it’s standard host) .

Bear in mind that this is an unofficial Fork of the MOAI engine and may not have newer fixes or features.

The git repo is at: https://github.com/krusmir/LionK1tty-based-moai-dev

krusmir/LionK1tty-based-moai-dev

Once you’ve grabbed the repo either with git or by downloading the ZIP and saving it to c:\moai-dev

(or anything you need, personally mine is called c:\moai-dev-ouya so I can have both Android and OUYA builds )

You can build the project using the steps above. The only change being that instead setting

requires=( “miscellaneous” )

instead you need

requires=( “miscellaneous” “ouya” )

OUYA Specific development

Deploying to an OUYA

Take a micro-USB cable and connect the OUYA to your PC.

Windows will not be able to install the driver initially - so you’ll have to follow instructions on the OUYA web site on how to connect it.

You’ll need to make sure your Android SDK has the Google USB driver installed.

In the directory ( atdbundle/sdk/extras/google/usb_driver/android_winusb.inf), make sure you add

;OUYA Console  

%SingleAdbInterface% = USB_Install, USB\VID_2836&PID_0010  

%CompositeAdbInterface% = USB_Install, USB\VID_2836&PID_0010&MI_01

to the [Google.NTx86] and [Google.NTamd64] sections and save it.

This video explains the steps http://www.youtube.com/watch?v=454JFvFTxww

Handling Controllers.

Here’s a handy table of controls and how they’re mapped along with a brief description.

The icons are from the OUYA Dev kit. https://devs.ouya.tv/developers/docs/interface-guidelines

There are listeners which have to be defined to see the OUYA events.

MOAIOuyaAndroid.setListener ( MOAIOuyaAndroid.OUYA_MOTION_EVENT, onGenericMotionEvent )

MOAIOuyaAndroid.setListener ( MOAIOuyaAndroid.OUYA_MOTION_EVENT_TOUCHPAD, onGenericMotionEventTouchpad )

MOAIOuyaAndroid.setListener ( MOAIOuyaAndroid.OUYA_BUTTON_DOWN, onOuyaButtonDown )

MOAIOuyaAndroid.setListener ( MOAIOuyaAndroid.OUYA_BUTTON_UP, onOuyaButtonUp )

The event handlers are defined as:

function onGenericMotionEventTouchpad(touchpadX, touchpadY, player)

…

end

function onGenericMotionEvent(leftAxisX, leftAxisY, rightAxisX, rightAxisY, l2Axis, r2Axis , player)

…

end

function onOuyaButtonDown (keyCode, player)

…

end

function onOuyaButtonUp (keyCode, player)

…

end

You’ll note that the player number is passed as the last parameter. This is 1 to 4.

Also, there is no way to directly query the state of the sticks or buttons, instead you get the events when something happens.

Also note that the Java code handling the sticks takes the deadzone into account. So you need only check for values in the -1 to +1 range in either axis.

Button	OUYA Name	Typical Use	Maps to MOAI
	O	The OK/Select button	Button code 96
	U	The Secondary OK button	Button code 99
	Y	The Tertiary OK button	Button code 14
	A	A - The Cancel / Back button	Button code 97
	D-Pad	Used for accurate directional control.
			Button code 21
			Button code 22
			Button code 19
			Button code 20
	L1	Left Shoulder Top	Button code 102
	L2	Left Shoulder Bottom	General motion l2axis
	L3	Left Analog Pressed.	button code 107
	LS	Left Analog Stick	General motion leftAxisX leftAcisY
	R1	Right Shoulder Top	Button code 103
	R2	Right Shoulder Bottom	General motion r2axis
	R3	Right Analog Pressed	Button code 107
	RS	Right Analog Stick	general motion rightAxisX rightAxisY
	Touchpad	The Touch Pad. Acts as a touch screen.	motion event touchpad touchpadX touchpadY
	System	The System button - Used for pause menus, be aware that pressing this button for more than a couple of seconds quits the game	Button code 82

Here’s a handy list of constants:

AXIS_L2 = 17

AXIS_LS_X = 0

AXIS_LS_Y = 1

AXIS_R2 = 18

AXIS_RS_X = 11

AXIS_RS_Y = 14

BUTTON_A = 97

BUTTON_DPAD_DOWN = 20

BUTTON_DPAD_LEFT = 21

BUTTON_DPAD_RIGHT = 22

BUTTON_DPAD_UP = 19

BUTTON_L1 = 102

BUTTON_L2 = 104

BUTTON_L3 = 106

BUTTON_MENU = 82

BUTTON_O = 96

BUTTON_R1 = 103

BUTTON_R2 = 105

BUTTON_R3 = 107

BUTTON_U = 99

BUTTON_Y = 100

In App Purchases

The business model for OUYA has always been Free to Play. This doesn’t mean Free games however, it is perfectly fine to offer a Free to play Demo of a game which requires payment in order to continue or even a Free-To-Play game which offers in app purchases for in-game-items.

Purchases and card details are handled through OUYA’s market place. All the game has to do is talk to it.

Checking purchases

When the game runs, after a purchase has been made - it’s important to check to see if the game has been purchased or not. Part of the ODK deals with this.

Sources and Thanks

Thanks to gamesfromscratch for getting me through the build process so I could create this document. http://www.gamefromscratch.com/post/2012/08/28/Setting-up-a-Moai-Android-host-build-environment.aspx

Thanks to Krusmir for putting the OUYA MOAI branch together