Creating Impossible Worlds

Creating Impossible Worlds by Ben Scerri

1

Creating Impossible Worlds

How NOT to start an Indie Game Development Company.

Introduction For those of you not aware, Impossible Worlds was and still is a small independent game

development studio, based in Melbourne, Australia. We began as a 25-employee strong company,

working on three separate titles: Distraxi, a comical taxi-simulator, The Experiments, a dark, gritty

mutant-platformer, and Teq, a puzzle game with a lovable magical golem.

We opened shop on the 20th of January, 2014, and were intending our first three projects to be

released as a form of “warming up” teaser by the end of March. Things started strongly, but very

quickly problems emerged and the entire company began to taste a bit sour…

What We Did Impossible Worlds was founded with one simple enough idea – a group of friends and colleagues

from QANTM College Melbourne and beyond would band together to make a single company. This

company would work on multiple concurrent projects, with employee movement between, so that

we could:

a) Avoid burn-out by having people able to change their project when necessary,

b) Protect each other, because the chances of all our projects flopping and failing was lower

than any single project being a bust,

c) And avoid the awkward release gap which tends to happen with Indie-companies (that is,

they release something, and aren’t heard of again for years until they release the next

project).

We took everyone into this company – from members who could commit no more than 3 hours a

week, to those who could commit 20 or more. Some we knew from the beginning would be working

with us between shifts of their day (or night) jobs, and others had their employment statuses change

after we began, which changed their availability.

This means that we began with 25 workers, averaging approximately 12 hours each per week, which

should have resulted in 300 hours per week, and 2400 hours over the initial two month time period.

Therefore, we planned three projects, of medium scale, to be performed over these two months, as

we expected to be able to handle around 800 hours on each (which was more than enough time to

complete the projects as they began).

Why Didn’t It Work? We had two real issues from the beginning which we should have seen and corrected, but ultimately

it was these problems that caused our first three projects to collapse.


2

Our first problem was a lack of pre-production and project management, caused unfortunately by

our enthusiasm. We wanted to jump out of the gates and hit the ground running with some early

titles to get everyone’s blood pumping. At the first, we had decided to go with very small teams with

many very small projects – three members working for two weeks at most. However, this happened

to shift, and the general decision was to go with larger teams with slightly larger scopes; which

eventually meant the three teams working on medium-sized projects.

The projects were conceived and begun on one day, which in other instances wouldn’t be a problem,

except that not enough testing and provisioning was done at the first. This eventually led to a

situation where the projects where being produced without having been fully designed, or with

whatever design had been done remaining untested. This then in turn caused the projects to either

meander and become pointless, or to become out of scope as new designs were added to patch up

the gaps.

Our second problem was a lack of availability from everyone involved. These first three projects

were scoped out with the teams we began with, and it must be honestly said that everyone grossly

overestimated their availability. For the most part, this was fine – we were able to push back

deadlines for those who were actually getting work done. But for many others, there was a clear lack

of work – caused either by a simple lack of time, or a lack of motivation.

This is ultimately what caused the projects to be put on hiatus. Some of our teams had entire

divisions simply disappear and stop doing work (divisions which were essential, such as 3D art for

one of titles). This in turn lead to the remaining members having to pick up the slack and perform

more duties, which resulted in burn-out and frustration with the projects.

In the end, these two problems created a sense of entrapment for those dedicated to the projects –

no one wanted to give up, because it would be wasting all the work that had been done. But in the

end if we didn’t start again we would be left with resentment for what didn’t go well, and three

products which wouldn’t be worth completion – as they would have been poorly designed and

scraped together to merely have them finished.

This entrapment caused in itself more problems, creating a lack of motivation in even the most

motivated beforehand, and I am not afraid to admit that my own excitement for Impossible Worlds

and game development as a whole took a massive hit during this phase. What we needed was a

decision.

Any decision…

What Were Our Choices? We were faced with only two real options:

1. Move all dedicated company members from their respective projects onto a single project,

so that that one could be completed.

2. Drop all three projects and start again from scratch.

The first had its merits, and I maintain that it might not have been the worse idea – however, it

certainly had its pitfalls. It wasn’t fair to make members from that team who were themselves burnt-


3

out to continue working for a project they no longer loved as they should. Further, even if we did

continue to work on the project, we would be left with a product which, in all likelihood, wouldn’t

have been very fun.

The second, again, wasn’t by any means anyone’s desire. We didn’t want to see the work of the last

three months collapse, not by a long shot. But it would mean a fresh slate for everyone, and would

give us the ability to take the lessons learnt and prevent them from happening again.

Those few who were still coming to the weekly meets convened at our usual time and we discussed

this choice at length. Ultimately, we went with Option 2.

Our Decision One of the first tenants of the decision was that it was ours. Everyone who deserved a voice (those

who were putting in the hours and being torn apart by the entrapment) were given the chance to air

that voice and truly debate about the choices. And debate we did, with no one person sticking to any

one side. This in turn has bred a lot looser hierarchy when it comes to decision-making, which is

something I feel very strongly about.

Next we decided to divide the company into two pools of workers, because we still do believe that

any amount of time someone can give to the cause is valuable and worthy of respect. However,

we’ve learnt enough to know that such open workflows don’t actually flow!

The two pools are the Core Team and the Bounty Team. The Core Team will work on our next

project and will cover everything that is essential to the scope of the project. Everything that simply

must be in the final product will be the purview of the Core Team. The Bounty Team, on the other

hand, will work through an Out-Of-Scope “Bounty Board”, which will contain additional systems,

levels, and assets which will help polish the game. For our final product to be great, we will need

both working hard, but the Bounty Team has the leeway in that none of their work remaining

undone will prevent others from doing work.

Thirdly, we decided that we would pull back completely and start our project scopes from the

ground up, beginning with little more than 2 week game jams, and slowly building our confidence,

skill set, and asset/system base so that we can eventually go onto larger projects. Whilst this means

that we will be slower going into our “money making” stages, it, in our opinion, makes such stages

more realistic.

And finally, despite our open hierarchy in business terms, we have collectively decided that a far

stricter project hierarchy is needed. Previously we had design by committee, which was fantastic for

idea generation, but ultimately led to never ending iteration. Now instead we will have a Lead

Designer, Lead Artist, Lead Programmer and Project Manager for each individual project we create,

all with clear veto powers. This is not to form a tyranny, but to create some order to prevent the

needless work wasted by constant iteration.


4

It Wasn’t All Bad I’ve said a lot about what we did wrong, but I would be remiss to omit everything we did right, and

the fantastic lessons we learnt. Because, and I want to emphasis this:

Impossible Worlds didn’t fail; we just learnt things the hard way.

Some of the things that went well are below:

The quality and consistency of the work produced was indeed of a high caliber, with each

project producing some amazing assets, interesting and clever systems, and tough design

choices and hurdles which stretched our understanding of Game Design.

We learnt which team members worked really well together and new friendships and work

patterns emerged which will serve us really well.

The core group of workers who will form the Core Team showed themselves to be highly

skilled, and willing to learn new software packages which will enable us to benefit from the

newer and more powerful engines which are emerging.

Technically speaking we functioned very well as a company, and with a proper project

structure we will have little trouble meeting deadlines and maintaining quality of work.

We learnt the key importance of a high rate of communication between team members, and

we learnt which team members are better at communicating and instructing than others.

The core partnership was able to dissolve a lot of its duties into general operations with the

rest of the company, which was as initially intended.

Conclusion In all, the lessons learnt will create a stronger, better Impossible Worlds than could have ever been

achieved without them. It is sad that we had to go through such a cataclysm to learn them, but it

was inevitable that something had to change or come to light.

I freely accept that my initial design for Impossible Worlds was highly ambitious and unrealistic – a

point I made over a year ago when the concept for the company first arose. I don’t know if it could

ever work, or if indeed it should ever work. All I know is that I couldn’t be more excited about the

restructuring, and that I know we’re going to do amazing, nay impossible things.

Documents

Creating Impossible Worlds