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.

Batteries Not Included - The GameCraft London 2015 event

On Saturday the 31st of October 2015 - Halloween 

Our merry group of developers took a trip to London with one purpose. To make a game in a day. We had no idea what the theme for the game would be, it's always a closely guarded secret until the morning of the event.

With no way of knowing the subject, it was impossible to predict what kind of game we would be creating. So we pondered this for a while.

We arrived in London to nice weather, the streets were dry and it wasn't cold. Just the type of weather needed for sitting inside all day and writing games.

We'd not been to the location of the GameJam before so it took a little time to get our bearings and find the place.

After a little time spent looking for the new (and amazing) SkillsMatter building "CodeNode" we arrived with a little time to spare, got ourselves signed in and joined everyone in a large room where the plan for the day was given to everyone. There were people from various sponsors there, a group from Audi were there as well as a team developing devices for an "Internet of things". It was all very cool.

GameCraft London 2015

There were actually 3 events going on on the same day, such is the massiveness of the SkillsMatter building and how much in awe I am of it and grateful for their kind hospitality - You guys rock! People were encouraged to mingle and to see what others were working on. It's great to meet people who share a passion for development, no matter what the subject is.

11:00

It came time for the brief for our event.  Batteries not included.
The irony being that the majority of the machines being used to develop needed batteries to function.


With 8 hours to go, we had to come up with a design pretty quickly. Dean came up with an idea in a eureka moment and suggested a top down racing game where the cars operate on power from the sun. I'm a big fan of alternative energy and electric cars so I was all in. I also used to love the old top down racers on the Spectrum.

Within a short amount of time we had a very detailed design on paper and coding the game could begin proper.

Detailed and comprehensive design.

Design is everything. 

We took graph paper and pens to work out our design first before touching any code. It's probably a good rule of thumb that if the design is too complex to fit on a side of paper, it probably can't be made in a single day. Skillsmatter also provided graph paper - great minds think alike, but it's always best to come prepared.

With the design agreed, I set about designing the cars while Dean put the Farseer physics system into our framework. We'd set up a git repo the evening before so we could easily share code without stepping on eachother's feet.

Once again we would use our familiar tools of MonoGame and Xamarin studio with Spine, Mixcraft, Audacity. However this time, I thought I'd try to use Adobe Illustrator and Photoshop instead of my normal Xara.


The more we use these tools, the faster we become at producing content. But also it means that with MonoGame and Xamarin studio, we don't have to worry about trivial details like Operating Systems and hardware.

Dean used a Macbook pro and I used a Windows 10 laptop. A few years ago, this would have been almost impossible to share any kind of coding tasks between us - delegating one of us to graphics while the other gets on with code... thankfully this was not the case.

Although I did do a lot of the graphics...

The game started to take shape once I got the basic graphics to Dean so that he could animate them in Spine. He's getting rather good at it too and it wasn't long before we had a working race car.

I got to work making the track. I used Illustrator and Photoshop to put the basic track together.

13:Once I had the basic track, I sent that to Dean who then placed the bounding boxes for the physics system to use to contain the cars on the track. He did this also using Spine. 

MUSIC!

While he was doing that, I got to work on the music. A racing game needs music to set the mood and to keep the adrenaline flowing, but we didn't have much time to spend writing a magnum opus. So I fired up my trusty Mixcraft and started to layer some of the samples in the library.

The results of this can be heard on our Soundcloud.

With this done, I mixed it down to an mp3 and added it to the MonoGame content pipeline for inclusion into the game. Very Easy!

Then it came time for the game's title. Dean had the track and cars loading and was working on getting the collision detection working, so we took a short break and came up with a name. Both Harvey and Dom (a visiting old friend) came up with the idea of Solar Race Cars, shortened to Solar RC and then turned into a logo.

Following that, Harvey got to reprise his role of voice actor to give us the announcer sounds which we recorded using a RockBand microphone and processed in Audacity.

For the final push, once all of the assets had been created, Dean and I shared the remainder of the programming, tweaking the physics and getting the gameplay working as it should... finally resulting in a multi-player top down racing game.

Harvey liked it, we were on to a winner.
With very little time remaining, we had to polish the game into a game which others would enjoy. A few things were required, braking and reverse - We'd not added those initially, but it became apparent once cars started ramming into walls that brakes were probably a good idea.

19:00

Finally, the time was up and we had to down tools and let people play our games.

Not all entries could be completed unfortunately, but there were some decent games on display - one of which was a card game using NFC chips as part of the game mechanics - very interesting stuff.

Play time!

Things were getting very competitive on our table, once people got the hang of managing their power levels, they quickly learned how to defeat each-other, taking advantage of the sweet-spot on the controller where power output was balanced with the energy intake from the sun. Then they did what all people do in driving games, rammed each-other out of the way to get to the finish line first.

Finally, it came time for the voting to end and the judging began.

In 3rd Place

, was a game by Ross McKinlay who single handedly wrote another racing game with a different take on things - as well as a very impressive tunnel effect made entirely using trig.

In 2nd place

 was the NFC card game, lots of people enjoyed playing that game - although I didn't personally get a chance to play :-(

and finally in 1st place....

in case you were wondering, it was SolaRC

In closing

Everyone had a great time, we played some great new games which in the morning of the day didn't even exist as an idea in the developer's heads. They were born on the day.

It's always amazing to me how much people can create in such a short amount of time and how warm and kind everyone is even while working under such time constraints..

Thanks again to Skill Matter for hosting the event and thanks to GameCraft for organizing an amazing day.

Thank You!

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 :-)

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.