Why we ended our relationship with Lace Mamba Global

We signed with Lace Mamba Global in Feb 2012 (counter-signed by Lace Mamba Director Jason Codd) and ended the publishing agreement Nov 2012 under fundamental breach of contract and also by breach by anticipatory repudiation.

I decided to seek references on the publisher after progress ground to a halt.

We are now in the difficult situation of having been unable to promote our game for the last 9 months (by publishers instruction) and plan a big push as we self-publish. micromacro


Updates to Terrorhedron, 3D Co-op Tower Defense

Over the last 8 months, Terrorhedron has been signed by a publisher, stopping us from releasing updates when-ever we liked. Earlier this month we terminated that deal, and we are preparing to roll out about 200 hours of development to our players as we self-publish!

Here is a summary of the updates:

New game logo

New Graphical User Interface

The main menu has been redone and is now 3D, more attractive and dramatic.

New Graphics Updates

The screen is blurred and slightly darkened towards the edges of the screen, giving a cinematic, fake depth of field effect.

Anaglyph 3D

Red and blue glasses type 3D mode to play the game in 3D. Very effective, fits the game really well.


A new menu system visualizes the players achievements.

New Intro Logo

Micro Macro logo added, with fuzzy transition effect and sound effect. Improves initial impact.

Game Balancing

Turret costs have been balanced out, and some turret behaviour has been improved.

Terrorhedron Models

The target objects are shown with various numbers of sides and colors in a logical sequence to show the health of a Terrorhedron. While only cosmetic, has a big gameplay impact.

Various Bug Fixes and Other Features

Crash reporting was added which has allowed us to identify and fix all major bugs, leaving the game in a very stable state.

These changes are now live, with existing players soon to be notified that they can download the new version.


Timelapse LIMBO pumpkin carving for Halloween

I carved this pumpkin for Halloween this year, with a LIMBO theme! I absolutely love Limbo and as a game developer, Playdead are probably my biggest hero. The video is a time lapse, with a preview of the finished pumpkin at the beginning. Let me know what you think 🙂 micromacro

Creating Jellybubbles animated jellyfish

Today I released Jellybubbles Free on iOS (it is already available on Android), and had to share the making-of for the jellyfish animation, because it was so much fun to make!

The jellyfish is a highly dynamic object, with its canopy (the body bit) contracting and relaxing to push it through the water, while its soft flexible tentacles follow behind, swirling with the water currents. The jellyfish graphics and animation have worked really well, in a project that was otherwise fraught with problems such as commercial viability, that I will cover in another post.

Developing the animations was great fun, particularly because it is such a custom task that I had to figure out myself, but also really rewarding as I brought a jellyfish to life.

Here is a video showing the final graphics in game.

The process began with an idea – the motion of the jellyfish. This was central to the game, as the graphics had to provide an atmospheric experience, and be beautiful. I began by testing the animation idea, drawing a rough test in photoshop, thinking about how the motion could work.

The motion seemed to work, and I felt like I understood how to build the animation. The next stage was to build the production-grade graphic. That wasn’t much of an art pipeline, it was a huge jump from quick concept, but is just how I work.

I moved to 3D Studio Max, where I created a 5 vertex spline that represented one half of an axial cross section. I dropped in some key frames, and created a single animation loop.

After this, I lathed the spline (using a modifier in 3DS) and applied a turbo smooth. This created the jellyfish canopy, although the animation didn’t really work. Moving down the modifier stack, I edited the spline and the waypoints to the level where they animated smoothly. This was a challenging and creative process and there was much tweaking, altering and complete re-doing. The end result out of 3DS was as so:

Once I had this animation, it was simply a case of moving it into photoshop and overlaying the color layer, the end result being as so (without the alpha masking applied):

Coupled with the dynamic tail flowing behind the jellyfish, I think the visual results really worked, and was a really rewarding and enjoyable process, where there was a great mix of technical problem, artistic judgement, and creative problem solving.


Finding an art style for a hidden object puzzle game

I am currently developing a hidden object game with my friend Ceri Williams. We are concluding some art style research and looking for feedback on which direction to follow. The game takes place in a fabricated insect world. That’s probably all I will say for now, but there is a lot more to it.

Our process uses traditional drawing techniques which are developed into ink line drawings and scanned. The graphics are then combined and composited in photoshop. As well as a library of ink drawings, we have also created a lot of ink wash and hand drawn textures.

We have worked up a series of quick style tests and need your feedback!

Style 1 : Flat colors and gradients fill the line shapes, using a bold color palette. Details are picked out in strong color, while the ink drawings do the hard work

Style 2 : Ink wash and depth of field create a backdrop. This was from a working drawing and the white shapes are not really intended to be used without color but the effect is interesting.

Style 3 : Flat color is used, adding detail to shapes using similar colors.

Style 4 : Flat color fills are used, blending ink and hand drawn textures into the shapes.

Style 5 : A traditional style process builds up body and color, digitally painting in photoshop.

Style 6 : Colored ink textures are used over flat color.

Depth of Field Effect – The game uses a 2d side scrolling mechanism, but depth is added through lighting and depth focus. The above is a quick test in photoshop we put together while discussing ideas.

We are looking for feedback and reviews of the various styles. Please reply in the comments or email us 🙂 micromacro

A guide to collaborative development and how to find a team mate

Collaborative design is awesome because your ideas are tested on other people who are also highly involved in the process, as well as having a greater pool of people to contribute. As I have already argued, working with others produces a better project (statistically based on revenue per developer), and working alone is not really sustainable.

A beetle from a puzzle game I am currently working on with friend Ceri Williams. We discussed ideas and concepts for a while until the opportunity came where we were both free at the same time

Of course, working with other people is a skill, and getting the most out of a group is a process. Legendary Dutch games programmer Joost van Dongen goes into this process in detail describing how his team get the most from everyone. While his team is around 16, I am more familiar with smaller teams – 2, maybe 3 core people. At this scale, the onus weights heavier on each member, the team cannot afford any dead weight, the relationships between team members become really important.

For most, team development is a necessity, where no single person has the complete range of skills to develop and market a project. Even if you do have the ability, you probably are not highly talented all across the board – it will benefit the project to have specialist people in different areas.

The problem many face is finding other people to work with or starting their own team. Most projects don’t even get off the ground, which is OK if you are a hobbyist, but if your ambition is to be a full-time professional, this is a career ender.

Recruit from your friends

The first place you should look for developers to work with is your friends and real-life contacts. These are people you already have a relationship with, and you have a better idea of what to expect. Understanding each others expectations is really important and an existing friendship will keep the team together through the rough patches (which you find in all the best projects). If you don’t know anyone who is suitable, this is really bad. It doesn’t get worse. There is only one place left to look… oh god no…

Recruit from the internet as an absolute last resort

The problem here is that the internet is dripping with scammers, time wasters, compulsive liars and a host of other issues which make most people you find completely unsuitable as development partners. Because you have no relationship with these people, you don’t know what to expect from each other and you won’t know about their issues until it inconveniences you and the project. But, I know a lot of you are stubborn and will do this anyway, so here is my guide to minimize the damage. The below also applies to working with friends.

How to pick potential targets for collaboration

The temptation is to throw out a fishing line, sit back and see who bites. Maybe make a forum post and see who replies. The problem with this is that is completely non-targeted; you don’t know who you will get, but the hope is that someone suitable will come along. Targeting is really important to get you the partner you want. If you don’t know exactly what that is, you are sure to find out what you don’t want the hard way.

How to target

You need to develop a specific profile for who you would like to work with, which is probably going to be the <programmer / artist / other skill> version of you. Be honest with yourself and develop a description of what you expect – level of experience, type of project that interests you, the amount of time you have available, the kind of tasks and work that need to be produced, etc.

Target someone with a similar level of experience and ability to yourself. There is much more difference between ‘what you can do’ and ‘what you have done’ than you think. Look at ‘what you have actually done’ and look for someone who matches that level of experience.

Research individuals who are potentially available and make a list of 4 or 5 people who you think are suitable but not over qualified, and write personal emails to them explaining what you are proposing.

Be easy to work with

It is really important to sell yourself well – show them what you can do and be as easy-going as possible. Be trusting and open, and don’t suggest a confidentiality agreement before discussing your best ideas. Approach with a ‘yes’ attitude and take the other persons ideas and opinions as seriously as possible. Focus on setting the team up to get the most you can from others; enable and facilitate them.

Are you ready to work with others?

Before starting to look for others for a project, it is great to have an existing portfolio of work and maybe even a CV to make your ability and skill level easy to understand. If you don’t have this yet, it is probably worth developing it first. micromacro

How to develop for mobile, tablet and desktop using the same source code

I’m currently developing a hidden object puzzle game with a friend for mobile, tablet and desktop. That’s Android, iOS (iPhone + iPad), a bunch of other mobile type platforms, Windows, Mac OSX, Linux. Targeting all these platforms at the same time, and from the same source code is tough, and I am going to discuss the method that worked for me.


With Terrorhedron, I have been getting frequent emails, tweets and messages from Mac and Linux users asking if Terrorhedron supports their platform. The answer is no, and that really sucks. A bunch of my friends have Mac Books too, and I regret they can’t play it. But more than this, these platforms have really tight communities with a huge appetite for that kind of game.

There are several cooperative gaming communities that really drove the success of Terrorhedron due to their very enthusiastic and loyal support. For these communities, Terrorhedron was a desperately needed game and they really valued it. This niche appeal is a real driver and was very important in generating general interest in the game. I feel as if niche interest could have been easily generated from Linux and Mac communities who have a much lower supply of games.

Selected APIs

Marmalade is a c++ API and make-file system for building and deploying to mobile devices. It has a really impressive supported platforms list and is really easy to get started with if you are a c++ programmer. It takes almost all the pain out of developing for mobile, and especially for developing for more than one platform at once. I love working with it because it is such a simple system and has a really powerful and well organized API. You build your program up from a main() function, just like any c++ program.

To extend support for your program to support other platforms, the process is simple. You must group and abstract the Marmalade API calls that you are making to an interface, and implement that interface for both Marmalade and your desktop API. In this case, I am using GLFW, an OpenGL library for Windows, Mac OSX and Linux.

Programming for multiple platforms

This is a typical multi-platform set-up; a common interface, with that interface implemented per platform or per group of platforms. The important point here is keeping it manageable and fast. In this case, I am using two multi-platform API’s to reach all my platforms, with my set of features minimized.

The abstraction of the API is simple, allowing you to create platform non-specific engine and application code

My interface is a pure virtual class, while my implementations inherit from this, providing functionality through virtual function calls. An alternative method would be to use #ifdef #endif to perform compile-time implementation selection which would also be easy and tidy to program, and remove the virtual function calls which will have a small performance impact. I personally favour virtual function calls with inheritance for design reasons, and because I doubt 100 virtual calls or so per frame will have any impact on performance.

The differences between mobile and desktop

I am developing for very different types of platform – mobile and tablet, and then the vastly more powerful desktop. The desktop is feature rich while mobile is much more limited, so the overlap is the mobile platforms features. For this reason, and because desktop has much more processing power compared to mobile, it makes sense for the interface to match Marmalade as closely as possible, and allow desktop to emulate mobile functions.

Will the same game work on mobile AND desktop?

It is important to consider why you are targeting the platforms you have chosen – there is no point targeting desktop if the game doesn’t really work with a keyboard and mouse. The counter argument is – if you can deploy to more platforms, why not? Surely the more the better, as long as a platforms deployment does not constitutive a “bad game”.

Using the above system, I can target those platforms discussed without too much effort, using a couple of hundred lines of code on top of the API’s discussed. I have chosen to use this for one game, while keeping another mobile only, for the reason that I do not want people playing those games on a desktop – because it detracts from the qualities of the game.

For a game to work across so many platforms, it has to be simple in terms of interface and mechanic. For me, that is great because it is kind of what I am about anyway. For more complex games, the effect may be that it works well on mobile but leaves a disappointingly average experience on desktop.

Variance between platforms

For desktop, you can easily add extra graphical effects using #ifdef DESKTOP etc. My intentions are not to deviate any more than this between versions in order to keep the design and implementations as simple and uniform as possible. Keeping the design manageable  is of key importance.

Use caution

A more experienced developer than myself would probably tell you not to underestimate the importance of testing on each platform. I don’t really understand this and don’t expect to until I have actually released a product across the above platforms but remain optimistic. I plan to send my various internal releases out to friends to cover the full range of platforms to avoid any major surprises but am unsure how testing will work out. With such a narrow API interface, surely the majority of platform specific bugs will be glaringly obvious?


Keep your setup as simple as you can, make sure you are familiar with your API’s and understand what you expect from them. Design your game with the distance between mobile and desktop in mind and analyse the effect and value of what you are achieving. micromacro