Update...

We're released an update to ROO, it fixes a couple of problems we found after we published.

The achievements were not being properly awarded and it was possible to make ROO fall forever without changing the game state.

Still, the update is pending now, so hopefully within the next few hours, it'll be ready.

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.

Review the Ancients: Trantor: The Last Stormtrooper.

Trantor: The Last Stormtrooper

Developed by Probe Software
Music: David Whittaker
Published by GO!
Written in 1987
Play it online.





A ship pierces the night sky and descends into a narrow canyon. The red walls of rock rise slowly as the ship makes it's perilous journey into the unknown depths below.

The ship's radar dish rotates rapidly, scanning the area for a signal. Eventually, the ship arrives at a landing platform - it extends the landing gear and retracting it's wings. A solitary figure emerges from the ship and beckons for his companions to disembark. He runs from the ship and is blown to the floor as the ship disintegrates. The lone survivor stands, takes a fleeting glance at where his ship and comrades once stood and looks away towards his destination.

He is alone.

The title menu appears, neatly animated - accompanied by an impressive score rendered expertly on the 48k beeper.
Quite how David Whittaker managed to get such sounds out of the beeper is entirely a mystery to me.

The music hits home as the player has just watched an awesome intro sequence... An intro sequence on the Spectrum! This was unheard of and it set the stage for a  
cinematic adventure.

The game starts, revealing a large character, taking up a third of the screen with amazing detail and colour. On command Trantor runs to the left or to the right with incredibly fluid animation - again, unheard of. An alien drone appears and flies at his head, Trantor ducks and the drone flies onward. Another drone appears on a course with his chest, no ducking this time. Trantor pulls the trigger on his weapon unleashing a jet of flame - immolating the alien and it's companion behind it. He realises that he cannot stay still and runs. The place is infested. He must escape.

The place is also littered with environmental traps. Pistons emerge from ceiling. Trantor has to carefully time his run to avoid being hit by the pistons whilst also avoiding the drones. He could fry them, but then his napalm supply is limited. With each hit from a piston or collision by an drone, Trantor's health is reduced. After a perilous few seconds, he reaches a locker. Inside is a burger. He eats it and replenishes his health. Next to it is an elevator leading down to the lower levels of the base. He decides to explore more of the base before going down and discovers a napalm stash. Further exploration reveals a computer terminal. Activating the terminal sends out a transmission. A transmission is received - and the timer is reset to 90 seconds, he is also presented with a code letter. Trantor must find more terminals within the time limit, download the letter and enter the code into the mainframe to have any chance of rescue.

He takes the elevator down. The base looks similar to before, only there are pistons rising from the floor. He knows the drill, kill anything that moves, search the lockers, find the terminal and refuel his flame thrower. Then find the elevator and descend.

The third floor looks different. Instead of the industrial platforms, he is faced with brick floors and ceilings as well as spikes intent on ruining his day. The drone presence has also intensified here who attack him from every direction.

He decodes the terminal, receives another code letter, finds fuel and food and the next elevator. This elevator goes up to an unusual set of corridors.

This level is strange, alien even, ribbed walls in green and yellow suggested that he'd entered somewhere far more hostile. However the floating robot drones which had proved so troublesome were not to be seen. Any calm which the absence of drones afforded him was quickly quashed when an alien standing at least 9 feet tall appeared, it's jaws containing sharp teeth and it's muscular body suggested that melee combat would be inadvisable. A blast from the flame thrower saw it off as another appeared behind him. Trantor ran.


In spite of the rich story which is told by the amazing visuals (for the time), the gameplay is shallow, a simple matter of run, jump, duck and fire. The aliens can only be killed by the flame thrower if at chest height meaning that most of them impact with the trooper as he runs around the level. The alien drones seem to explode on contact with Trantor, meaning that they must exist in a perpetual state of terror as any collisions would spell their doom.

Impacts with pistons and spikes also a fairly unavoidable. Both hitting aliens and moving environmental hazards drain precious health and make for a fairly frustrating journey between health stashes.

It does add tension though, especially as not all lockers contain food. Sometimes you get extra time, other times you'll get a screwdriver which offers seemingly no value to the game. Other times you'll get a shield or more napalm. There seems to be a 1 in 3 chance of getting food.

Enemy encounters are random and frequent, however they pose little threat until you reach the 9 foot tall monsters - who eat your head. The fact that it is impossible to avoid being hit by enemies is the most frustrating thing. It detracts from  the feeling of control. Surely Trantor wouldn't allow himself to be hit in the head by anything. Surely he would at least aim his flame thrower.

The visuals are fantastic though - especially considering that the game runs in 48k of memory. This means that the animation for the trooper, the flamethrower, each alien, the background graphics, the game code, the music and even the intro sequence all fit within 48k.. That's 49152 bytes.

 take a moment to think about that...

Just for comparison, the low resolution scan of the box art at the top of this review weighs in at 186k. Trantor would fit into that jpeg file almost 4 times.

The animation for the main character is fluid and conveys a sense of mass. His flame thrower shoots out fire impressively. Visually, the game was leaps ahead of the competition (even if the graphics were rendered using an xor technique instead of masking - although given the amount of graphics involved they are forgiven ). The alien movement is a little awkward and the 9 foot tall aliens pop into the side of the screen instead of appearing smoothly.

The game is also quite short, but hard and very tense. There are no lives. Once dead, you start again. No checkpoints or hand holding in any way.

On release, the game received a lot of praise in the gaming media - particularly because of the graphics, often overlooking the simplistic gameplay.

The backstory was also a little ambiguous. One spectrum magazine ran a preview for the game with a detailed backstory which included betrayal, an alien war and a 90 second timer for a bomb in Trantor's head which would explode if not constantly reset. Whereas the Amstrad case inlay reported that this was all in trantor's head as he struggled with the accidental death of a child.

In the end none of this mattered.

I fondly remember the game for the tension it caused. I certainly felt it and genuinely freaked out when the large aliens were after me.


I wonder what Trantor would look like if it was remade today - possibly it would play like Abuse, another tense and often terrifying game.

I would love to see this game re-made.

Anyway, here's the music by David Whittaker

If you can find the original tape, on the B-side, there's music from a Rock band called Resister titled "The Fight" 

Making a Game in a Weekend with MonoGame.

Early last week, I was chatting to a close friend of mine - (Dean Ellis) about Game development and we discussed the possibility of participating in a weekend GameJam. Dean and I having written games in the past, but never together (or at least those shared ventures were never completed).

We had no theme, we had no plan. Just come over to my house on Friday evening with your laptop and let's make a game.

Dean arrived around 6pm with his 8yr old Son in tow. Laptop at the ready and it was clear early on that we were going to need supplies for this adventure. We were going to need beer! Lots of Beer... and snacks.

After cleaning the local shop almost out of junk food and beer, we set to the hard task of deciding what to build - and who was going to do what.

Who does what?

It is an important step in any team to decide what role each of you is to play and to stick with it. Otherwise chaos ensues. We decided to step a little out of our comfort zones with this. We'd use a platform I wasn't familiar with and Dean would provide the artwork (normally my role).

The platform we decided on was Monogame. For those who may not know, Monogame is the opensource cross platform implementation of the Microsoft XNA framework (now sadly discontinued by the big M - but lives on with an incedibly strong community thanks in no small part to Monogame, especially with it's cross platform capability (more on that later).

I'm used to using the MOAI framework, but if there were any parallels - It shouldn't be too hard.

The language of choice would be C#. I'm familiar with C# - Many years of ASP.net and Windows Mobile development have given me those skills, however I will admit a little rust, what better way to polish my metal than with an intensive game development session?. 

Dean on the other hand works at Xamarin and is a C# guru - which is handy when said polishing was needed. Thanks Dean :-)

Dean was in charge of Art. He wasn't to take an active role in coding, Instead, he'd be providing a suit of assets needed for the game. His tool chain was Inkscape, Textturepacker and Spine.

To help out and save time however, Dean did provide a library and example class to handle the Spine animation.

So began the evening. We ordered a curry from my local Indian and began the brainstorming process.

We'd need a game we could handle in the weekend - preferably something we could get to "first light"* in the evening.

*First light is the point when you first see something on screen resembling the thing you're trying to make - it's the first piece of visual progress after what can seem like an eternity of coding. It may be as rough as a bears back end, but it's a thing of beauty.

We decided on an endless runner - similar to Canabalt - in which you play a Kangaroo named ROO! (upper case deliberate, and pronounced in a death metal voice). The story being a parody on the old Skippy the bush kangaroo TV show from the 1960's - in which little Timmy has fallen down the well (again) and ROO must race across the outback to inform ranger Bruce - Crikey!

A very simple story, simple game play requiring a single key-press, button or screen touch. Hold down the control to increase the jump height up to a maximum and clear any obstacles.

The curry arrived, we had our idea - it was time to load up with Curry Power and get to work.

Installing Tools

I installed Xamarin Studio and the Monogame framework. Dean created a Git repo on BitBucket so we could collaborate effectively. I used SourceTree by Atlassian as my Git manager - Dean used the command line.  

It was time to create the project. Thankfully Dean had access to a project template for Xamarin to create Monogame projects. That was easy.

Now faced with a blank canvas - no game, no menu system, just an empty XNA game class.

...and we're off!

It was now around 9pm - Installing tools and setting up environments had taken it's toll.

So the first thing we were going to need was a Kangaroo. Dean set about drawing a Kangaroo which he could then break into pieces and animate using Spine.

He built a skeleton for the marsupial and made a decent hop animation.

In the meantime, I created a state stack to allow us to have different game screens. e.g. a Splash Screen and Menu as well as a gameplay screen. This would allow us to separate the game code out into other classes as we needed to and have the main game code control them as if they were the main game code.

This meant creating an object oriented structure of game objects which catered for everything, states which inherited from game objects, an animated sprite class which would handle the spine animation and a level manager to provide the endless running level... which at this time I had no idea how to accomplish.

I had an idea, an endless runner doesn't care about what was past and what's to come, only what is now. This meant that we could have a queue of only the details needed to display the map queuing and de-queuing items as the player moved through it. 

The levels would be random so there would be no level data to store, only a set of rules which would govern the pieces to place in front of the player as they progressed.

By 2am, we had a level being rendered and an animated ROO! 5 Hours of coding and several beers had brought us to first light. We could see where we needed to go from this point on.

The next morning,

I cooked a breakfast of bratwursts, bacon, eggs and beans - we were going to need the energy. We had a lot to do. The game ran in a demonstration capacity, but there was no gameplay and no level.

So after breakfast we continued. Dean created death animations for the kangaroo and I set about implementing a collision detection system against the level. Normally, collision detection is done against objects with position and size within a level. These items are normally loaded and are generally treated as real things according to the game engine. This game had no physical objects created within the game world. Objects would exist for at most a few seconds before being deleted. This meant that we needed to make sure that the objects were as simple as possible. To that end, I created a class which held the texture names for 4 rows and a height to position the entire column on the screen in relation to the rest of the level. This meant that we could draw challenging levels, but there was no level geometry to test. However as the data was predictable, it did mean that we could perform bounds tests on rectangles which were near to the kangaroo. We'd generate the bounding rectangles for each of the levels near-by tiles on the fly, but it would be fast enough.

I progressed on making the kangaroo collide with the level accurately, ensuring that he stayed on the top of the level's terrain. I've feel so spoiled lately using Box2d to handle all of this stuff properly for me.

As Dean made more animations, I put them into the game. ROO can trip on rocks, faceplant, hit sheer cliffs or even just run into a wall - each needed their own animation. Thanks to Spine, Dean was able to build all of them.

At lunchtime, we took a break and went to the local pub - for a post morning debrief and to gather our thoughts on the remaining work.

And with that in mind, we played the Artemis Bridge Simulator for an hour - Awesome game.

After Lunch

This was mostly putting things into place. Animations, Jumping and the all important Level generation.

With Dean busy tweaking animations, drawing backgrounds and recording some initial game audio, I had to figure out how to make a responsive jump action. In endless runners, the player has to judge how high to make the player jump. He has a maximum height beyond which, he'll fall to the ground. The player must feel like they are in control of the character at all times and that any failure in the game is entirely the fault of the player. This is how addictive gameplay is born. If you make the game feel unresponsive, the player will blame the game and will not become as engaged. Making the player feel completely in control adds to the immersion and therefore into the addictiveness of the game. 

To do this, I'd need to know whether it was possible for ROO to jump. If so, then he'd pay attention to the jump command. However, as soon as the command was halted, he'd ignore any further requests to jump until he was eligible to jump once more - basically, when he was on the ground and hadn't hit anything.

Another decision I made was to place all of ROO's jump logic before anything else in the update methods. So you'd always get to jump. It may not seem like much, but if the update loop runs every 60th of a second, that means that there's an entire 60th of a second where you may have pressed the jump button - but if the level is allowed to move before you've had your command registered, you could hit something instead. The player has to come first, so the controls need to be processed first.

ROO is very responsive.

The day wore on and we made more and more progress on the game and consumed quite a lot of tea. The animations improved, Dean worked hard on the tile set and ROO himself to make gaps in the sprite from being shown. He also built clouds and mountains to act as parallax  backgrounds to add depth.

I wrestled with the level generator - I'd made an assumption about the peek method of the queue in that it would give me the first element in the queue, in fact it gave the element about to be dequeued. On retrospect, it was sensible, however I really wanted the most recent addition to the queue. Afterwards the level generation was working great.

By about midnight, we'd got the game running nicely.

The Next Day

So very tired. Dean and Myself were pulling from resources we didn't know we had. Late nights, beer and game development does not make for happy mornings. Still, we got on with the work of polishing the game. We only had a few hours to make a difference, Dean would have to leave in a few hours so we'd have to make the most of it.

I recorded some additional sounds for Roo while Dean made more animations - basically ROO would be able to run at two faster speeds to keep up with the ever increasing level speed. This coupled with shouts from Timmy in the well to boost ROO's resolve added to the atmosphere. I used BFXR to make simple bounding and jumping sounds while recording the voice of Dean's son for the voice of Timmy.

I altered the generation code to make the later levels harder while in the meantime, Dean took a hiatus from the pure graphical side and worked on the high score table. He'd held out for 2 days without coding anything, an amazing feat.

He also worked on the additional build targets so that the game would compile on other platforms.

By the end of the day. Dean had iOS, OSx, OUYA, Android and Windows via OpenGL and DirectX working. With a little luck the Android version would be relatively simple to put onto the market.

Testing on a few different android devices revealed some graphical bugs which were quickly resolved.

I worked on the music for the game. I only had a couple of hours to spend, so I used a tried and trusted tool Mixcraft. Mixcraft has a vast library of samples as well as virtual instruments to call upon. So I made a piece of music which became more intense as time went on. I feel it complements the mood. But then I wrote it.

So in the end,
We have a completed game with a failure state, sound effects, music and animation. It's fun, addictive and accessible.

It took us about 20 hours from nothing to game.
The tools we used were:

Xamarin Studio
Source Tree
Inkscape
Spine
Audacity
Mixcraft
BFXR

London Gamecraft 2014 : Part Deux - The Movie

OK, that's probably a little grandiose, but at 23 mins long, it sure felt like I was editing an epic. I feel that I know how Peter Jackson must feel. 1 day to shoot, many many hours to edit.

Cards on the table: This was my first attempt at making a video production, so it's a little rough around the edges and it's probably a little too long and could use some cutting - But I didn't want to lose any of the interview footage, some of it is golden. It's also taught me a lot. After Effects is an incredible piece of software, I could probably dedicate months of training time and still only barely scratch the surface.

We arrived early, after getting up incredibly early to get the train to London. We arrived before any of the developers to give us time to set up the greenscreen rig.

After that, and after coffee and breakfast, we set about capturing footage for a potential game. We took a load of props with us, from Nerf guns to teddy bears. The teddy bears would be animated with the assistance of the chroma-key suit.

Unfortunately, we didn't make a game with this footage, but it was a good test to see if we'd got everything set up properly - and we were hoping to inspire the developers in some way.

So instead, we made images of clouds using cotton wool. This worked well and they were useful in one of the games.

We also filmed planes for use as sprites. If you can't draw it, film a real one (or a model)

We filmed a bunch of planes, even recorded rotations for a game which I think Dean will make as soon as I get the processed footage to him.

On the day we were mostly expecting to capture footage for the game developers to use. We did that, and provide special effects for those who needed them. We also introduced a few people to the amazing BFXR online sound generator.

As the hours passed and the developers had gotten used to the idea that they could call upon us for assistance - They're typically a self sufficient lot, and demonstrated amazing skills in their craft.

The special effects (mostly explosions) were created as assets for the developers using the amazing TimelineFx.

At the end of the day, those developers who'd completed their games got an interview against the greenscreen where their game would be played in the background.



Thanks to Global Game Craft for organising the event, SkillsMatter for hosting it and providing sodas,beer and pizza and to .mpegasus and _ensnare_ for the music for the video. Go check out their stuff. It's brilliant programming music.

A good time was had by all and Games we born.

London Game Craft

On the 29th of November, Songbird Creations will be attending the London GameCraft Jam at The Skills Matter eXchange.

We won't be working on a game however we will be providing green-screen and image processing facilities for the developers there so they can quickly get some nice real-life graphics made without worrying about it. We'll be taking care of the capture, chromakey and processing - the end result being a nice texture file and plist using texture packer.

We'll be bringing some props with us although, the theme for the day hasn't been announced - so that'll be interesting.

So if you're attending the Jam, pop over and say Hi. I'll probably be decked out in a green-screen suit, so I'll be invisible.... :-)

https://skillsmatter.com/conferences/6610-london-gamecraft-2014-part-trois