Friday, 12 February 2016

Our top 5 Project management tips for time starved developers

We've all been there. A great idea forms in our head and we just have to build it. This often means casting aside a previous great idea which grew to a gargantuan size. An idea which grew so large that there was no hope of completing it without significant effort...

Ideas are strange things. They come when they want to and creativity isn't always on tap.

They need to be managed to keep them under control.

Well, when the ideas come, you need a strategy to make sure you make the most of them.

Here are 5 tips to help you to develop your idea into something which you can build.

You'll also need a few things.
  • A note book.
  • A pen.
  • A sketch book (optional).
  • A pencil (optional).
  • A wall or whiteboard.
  • Post-it notes. (several colours if possible).
  • A marker pen.
  • A pack of sticky stars. (the kind used when marking kids homework; do teachers give gold stars anymore?).
  • ..and that guys leg. (just kidding)

Or,  you can use an online tool like Trello. 

We use Trello for all our projects; It's free and it lets you do everything I talk about here - with the possible exception of getting your fingers covered in glue from sticky stars)

Trello lets you create lists of tasks, move those tasks between lists and add labels. If there is more than one person in your team, don't even consider a whiteboard. Not unless you're always in the same room with them when you work.

1. Write down your idea. 

Use Google docs, word or something.

The longer it stays in your head, the more it will grow into something unworkable. Either that or it'll slip your mind completely or even morph into something else. Ideas are funny like that.

By writing down your idea, you make the first conscious step on the journey to make your dream a reality.

Perhaps draw some basic concept art to help you to form the idea,

Once you've written your idea down, read it back to yourself - out loud. This is important.

If you're not comfortable reading out loud, there's a great Text to speech Extension for Google Chrome called "SpeakIt!".

You'll be amazed how much more you'll learn about your idea by just reading back what you have written out loud.

Remember; An idea not written down is just a dream. A written idea can be reviewed and amended. Most importantly, a written idea is only one step away from the next most important step...

2. Make a plan.

Your written idea can broken into pieces to determine what tasks needs you need to do. It's at this point where you're looking to identify sections of work. Break your idea down into general sections.

Start out high level with big, high level sections, things like:

  • Menu System. 
  • Game play.
  • Music.
  • Sound effects. 
  • Art.
  • Levels. 
  • Weapons.
  • Characters.
  • Physics.
  • Controllers.
  • Achievements.

The list can be long.

Create lists using Trello or "post-it notes". You can use different colours to denote your expertise in that area or apply labels.

Make sure you create one called "Done"- This is the most important list to create.

Write as many of these high level sections as you can. At this stage it doesn't matter if you have too many or if they seem to overlap.

You can always merge similar sections together later on.

If you're having difficulty working out the high level sections, you should re-read your idea and consider...

"What will it take to do that?" 

You can always change your idea if you think you've missed something,

Be careful; ideas always spawn new ideas... in fact, one of the challenges of developing your own games is controlling this.

Remember to be honest about your skills in each area. You can mark the sections with a difficulty rating if it helps.

Once you have a list of all the high level sections, you can start to flesh it out.

3. Add tasks to each section.

This is where the fun begins. In a way, this is the first part of development.

When you create tasks, you're actively considering the problems you're likely to encounter. This helps you to solve them. List as many of the things you need to do for each section as possible.

For instance in the Music section, you may have tasks for Title, In game, Game Over and Intro. Each of these would be a task to complete by someone.

In the art section, you might have tasks to draw and animate the main player sprite. This might include player walk animation, player run animation, player jump animation etc.

Note that I'm not just generalising with a single task called "Player Animations". That's too big a task and could roll on for weeks without seeing any progress.

You see the trick to keeping a project alive is to always make progress...  The only way to do this is to always have tasks you can complete.

You'll start to see a lot of tasks appearing as you break the design down into workable units of work. You'll see sets of tasks for entire features.

In some cases some tasks will be more important than others so you'll need to prioritise them as such. This is where our marking stars come in.

You see, you're trying to isolate the "MVP".  Minimum Viable Product.

It is the set of tasks you need to make the basic playable version of the game. You should focus the most on tasks which will get you to MVP.

Consider your tasks. Which of them are "absolutely essential" to get the most basic version of your game written and playable?

Put Trello labels or gold stars on each of them. They're the important ones.

As you create your tasks, you should think about breaking them down further. Can you complete each of your tasks within a reasonable amount of time or will each of them be a long slog?

To this end, you should...

4. Be honest with your time. 

and make each task something you can complete in a single sitting.

The amount of time you have will depend on several factors. Spouse,  children,  study time, day job, pets, hobbies. These all have demands on your time to some extent,  reducing your available time to spend on your game.

If you start the project believing you'll have your full allocation of time to spend then I've got news for you. Life happens.

Unless you're in a locked room without any contact with the outside world, you'll have distractions.

There is no point over estimating the amount of time you have available per sitting.  You will only be deceiving yourself and this will make you fail.

Be honest, place a post it next to your tasks with the number of hours per sitting you can spend written clearly on it. It doesn't matter if this number seems low, that you only have a few hours per sitting. At least you know, and this can change over time.

Note: I said per sitting,  not per day. If you can't work everyday that's fine. But when you do work, you should be sure you have the time  available to work on your tasks. Without too many distractions anyway.

Once you have calculated out how much time you have per sitting, you should use that as your guide. Use this value for estimating your tasks.

5. Create tasks sized to one sitting at a maximum. 

For instance, if you know that you can draw one character per evening, then have one task per character. Then every day, you 'll have something to put into the magical Complete column.

Maybe it takes one sitting to draw and one sitting to animate. It's entirely sensible then to make two tasks for that.

If you have a task which seems difficult to break down, you can break it down based on classes or drawings if you need to.

E.g. If you need a terrain renderer: This is only one part of your game but it's a large coding challenge.  Luckily this is something you can break down. I wrote a 2d random terrain generator and renderer. I needed a fractal height algorithm. I also needed a camera system with view frustrum. I needed  a polygonal renderer and terrain detail sprites. The terrain should be generated on the fly and destroyed when off the screen. I also needed Farseer collision detection.  

All these tasks fit under the generic task of "Terrain".

So I broke it down into achievable tasks and hit them one at a time per sitting.

There is no point in trying to fit too much into a task. If it can't be completed in a normal sitting,  it should be broken down further. You must have something to complete!

If you're not sure how to do something,  create a task solely for research.

Spend your entire allocated time on learning if you need to. You'll be better for it.

Researching is a task just as much as coding or drawing is.

Write it on a note, add it to the board.

6. Nothing is cast in stone.

Everything can change. Review your plan regularly. Update it, it will keep you on track. You should aim to do this either at the end of each sitting or at the beginning before you get to work.

It's OK to make changes too, sometimes we uncover things about the design we had no idea about. You can add new tasks, remove tasks or update them to cater for the new information.

Did you make an assumption which turned out to be incorrect?  No problem. Have a think about it, review your design and alter your plan. Follow the basic principles discussed above and you'll be fine.

If an idea turns out to be too difficult,  again no problem.  Simplify your design and review the plan. This is a good thing to do anyway.

You can do this review at any point in the process.  Just make sure any team members are aware of the changes to the design as it could affect their work.

It could be that the design is fine. But after looking at the sheer number of tasks it becomes obvious that the idea will take too much time to build. Don't worry, if your design seems to be too large, Simplify it. Remove features which aren't required or replace them with a simpler alternative.

You can always tackle the full idea later. Remember : before Halo, there was doom. Doom was once the pinnacle of 3D shooters. Yes its design was constrained by the limitations of the available hardware and skills of the developers at the time. It's OK for ideas to evolve and to make more advanced version of your game later once you've proven the concept.

If it's successful, you may even have a bigger team to work on the next iteration of the game idea.

But you must complete your initial version first.

Hang on, wasn't this supposed to be 5 tips?

Well, nothing in Project Management ever goes according to the initial plan. You'll always have something which comes out of the blue. The key part of project management is actually managing and controlling change. Customers may tell you they want something only to change their minds later. Ideas may start out as one thing only to become something else later.

If we stick to the initial ideas, we'll never complete our ideas.

Accept the change.

Understand the change.

But most of all, Manage the Change.

Best of luck.

Thursday, 28 January 2016

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.

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 ...


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.


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.


Introducing our glamorous testing team.

Seulki, Jenny and Katrina - Our glamorous testers.

The girls were given all of the tools they needed:

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.

Monday, 16 November 2015

Sola|RC - Download

OK, Here it is in it's raw unadulterated awesomeness.

The aim of the game is to race around the track in your little solar powered race car. You have no battery, only a small capacitor which charges when in the sun and loses charge when load is places on it. Beware of the clouds, they will block the sun and your internal systems will quickly discharge the capacitor. Beware of hammering the accelerator, while this gives a boost, it quickly uses charge.
While at speed, using the brakes will replenish some charge with regen-braking.

You can only steer while moving, you can reverse if stuck.

Please bear in mind the following:

  • This game was made in 8 hours - expect bugs.
  • This game is unpolished - expect roughness
  • You can play this game forever, even though a winner is declared - you can still race around. This however turned out to be a lot of fun as people seem to be mostly interested in ramming each-other.

What you will need.

  1. Windows ( We may upload the mac version in the future and update this post )
  2. 2 Joypads. There is no keyboard support in this version.
  3. A friend. This is a 2 player game, designed to be played side by side for shouts like "In Your Face Loser!" to have full effect. Also, so the meta cheat codes can work (i.e. hitting your competitor with a pillow or pushing them off the sofa.

The controls are:

  • Right trigger - Accelerate.
  • Left Trigger - Brake - Reverse.
  • Left Stick - Steer.
  • (A) to start.

Have fun.

Small print

Of course, this game comes completely and utterly without warranty of any kind. Although the machines used to build the game are virus free (according to Avast) there are no guarantees in this world. All we can say is that the game does nothing intentionally malicious - unless pitting 2 competitive players against each-other in a race/fight to the finish/death can be called malicious.

Sunday, 1 November 2015

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.


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. 


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.


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!

Monday, 19 October 2015

Game Jams as a Catalyst for Busy People

...or how to build a game without p!$$ing off the missus. 

Using a Game Jam as a tool to kick an idea into action. All while being fair to those who share our lives.

Face it, we're all busy people.
Modern life is filled with distractions. Some more deserving of our time than others, some are essential and spending time on other things could be seen as neglect - but we won't dwell on those things. The distractions are there whether we like it or not.

Here's a few of the most common ones. Although it's not an exhaustive list. See if any of this rings true for you...

Most aspiring app or game developers have a day job. 

This takes between 7.5 to 8 hours a day from the pool of available hours, OK - it pays the bills, but it's not the ideal use of that time. Unfortunately, unless we catch a break, we cannot ditch the job. Most of the time the job is in a similar field as the idea (e.g. Software engineering) and when we return home after a grueling day of meetings, code and stress - there's not a lot of mojo remaining for that million dollar idea.

Some have partners.

Significant others who rightfully demand time. They too feel the hours taken by the day job and are often reluctant to allow or simply can't understand why there is a desire to put additional hours into a similar thing that their loved one was just complaining about five minutes ago - but has some idea they want to try which means more time alone. This one is the most tricky to deal with because partners are usually very forgiving and will tolerate a little time - but it's easy for this to become unbearable and they quickly put their foot down. This can lead to a lot of friction. (been there, got the tee-shirt)

Some have children. 

Similar in a way to the demands of a partner, children absolutely need time and don't like it when they don't get that time. Although, children can make good assistants if the game or app is written with them in mind. They make good testers and sometimes can provide their talents too. (Sounds, art etc)

Then there are competing hobbies.

like sports, going to the gym, the cinema, bowling with friends, parties.
These are the activities of a healthy life and a sign of a well rounded individual (apparently).
They're also a massive time sink leaving very little time to develop that killer app.

So how can we proceed? Most of these activities are essential or not easily avoided, so they take their price in hours, leaving very few hours remaining to get any work done and often leaving the developer very tired afterwards.

There are three options.

1. Abandon the idea. 

Knowing that there will never be enough time to devote to the idea to allow it to grow enough to see whether it would be worth extra development or not - may as well give up.

2. Steal a few hours from here and there. 

Hoping that a few hours will be enough to get into the zone, to focus for long enough without interruptions to make sound design ideas. Stealing a few hours makes the project take a very long time to get into a place where a clear path to completion becomes apparent.

3. Have a Jam. 

Book some time with your significant other, have a party and invite like minded friends to help - make an event of it. Brainstorm and see what you can produce in a few hours. This allows you to put the idea to the test very quickly. If you have helpers they can get parts of the application or game built while you focus on other parts. Setting goals to meet will keep you on track and at the end of the session, you'll have something to show for your efforts. Further more, you'll have had an entire day of uninterrupted work, you'll also have cleared it with your partner who will most likely use the time and have fun - all while knowing that they'll get you for the rest of the time.
It's also a great way to get the prototype ready so that you can demonstrate it - often buying more time to work on it.

Jams are worth their time investment a hundred fold.

Dean and I gave a talk about this very subject on the 1st of October 2015 at the Just Eat HQ in London.

We discussed our experiences in trying to get projects off the ground, the obstacles we'd come up against and our attempts to solve them. 

One of these attempts being the Game In a Month initiative. A very strict set of rules which if followed will produce a game in a month, but it may take several iterations before it comes out. 

Dean did produce a game using the system though, although he did stress that it was exhausting.

If you want to try it, go to

Then we discussed the tools we used during the process. Note the prominent placement of git. Having a source control system is essential in any project. We've lost far too many projects to the failings of hard drives and when working in a team, it is essential to have the ability to share and modify code without stepping on each-other's feet.

Most of the tools on the list are free or very reasonably priced.

So in summary:

A GameJam lets you focus your attention on the idea guilt free. It lets you collaborate or compete with others and gives you the opportunity to see if the idea bouncing around in your head is actually worth pursuing. Afterall, if the idea isn't worth it, it's best to know quickly before pulling all-nighters to get it polished and released.

London GameCraft 2014 Part Deux

Last year Dean and I attended the London GameCraft jam.
It was in an assisting capacity - providing video and effects support to any developer who wanted them.

This year, we're going again. Only this time, we're taking part!

We will be making a game in around 10 hours based on a brief that no-one will know until the morning.

It's going to be a blast and if last year is anything to go by, there'll be some amazing games made.

So if you want to go, there's still a little time remaining, so register by following this link.

Sunday, 17 May 2015

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


 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.


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


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


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.


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


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


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


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.


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