The Darling Diaries: The productivity challenge

One of the eternal problems of game development is productivity: how to get the best possible game in the least possible number of man hours.

For instance, is a cloud that takes 20 minutes to draw twice as good as one that takes ten minutes to draw?

Obviously middleware and libraries are great productivity enhancers and, with Unity, the industry has seemingly made the quantum jump that it sorely needed. So it is interesting to look at where we are going at Kwalee with the organisation of the development process.

Bigger teams = less productivity?

When I started writing games with my brother we were a team of two. This seemed to be the fashion of the 8-bit era. Lots of the very successful developers were two people, mostly with outsourced art.

The Oliver Twins, the Stamper Brothers and Graftgold spring instantly to mind. There was something about the synergy of working with just one other person that enabled outstanding productivity.

Then came 16-bit with a corresponding increase in complexity that made larger teams inevitable to create the extra code and the extra graphics.

The biggest leap of the lot was when Sony launched the PlayStation and most games became 3D. This necessitated an immense amount of extra data which saw team sizes double overnight. Through all this productivity went down: the larger the team, the less that each person generated.

Meetings and layers of management reduced the number of real hours that were spent working. Although we always endeavoured to put together the most talented and passionate team possible, it became very easy to carry passengers who turned up for work but didn’t contribute much.

Over the years there were lots of management fashions that came along that sought to fix the productivity problem and in my experience none of them worked. The latest we tried at the beginning of Kwalee was Agile/Scrum but we aren’t using it so much anymore.

So, you may ask, what is Kwalee doing and how are we organised? The games we are making have much superficial similarity with 8-bit games, but the reality is that they are a whole lot more complex.

The social and multiplayer elements are a huge overhead. Also, we are not seeking the highest productivity on its own; we are also looking for a lot of creativity so that the games we make can stand out in a crowded market.

Maximising creativity

The big decision was to separate art out of the teams. This enabled us to build an art department of three people and to employ a very experienced game artist, James Horn, to run it. This department can then allocate its time as and when it is needed around the company giving us a big jump in productivity compared with having in team art.

To maximise creativity we let all the development staff do their own thing every Wednesday. At first this looks like we are losing 20 per cent of their time but the reality is that there are complex dynamics at work, and the net result is a balance that works very well for us because it promotes innovative and creative thought.

In addition to this we have Andrew Graham (of Micro Machines fame) as Gameplay Guru who can do his own thing 100 per cent of the time, and I am quietly confident that when the public see the results of this they will think that it was worthwhile.

Game development is done by two teams, one of three people and one of four people, each with a team leader. The leads are James Munro and Adam Philbin, both highly experienced iOS developers.

Within the teams they have settled down to very flexible working practices, each working on a couple of projects at the same time with one project getting the bulk of the attention and the other one sitting on the back burner.

This is very productive indeed because games require different amounts of effort at different stages in their gestation and, by having two projects, the teams can allocate their time accordingly.

To shake down all our working practices at Kwalee we started by making the best possible App Store iterations of two well known board games with Gobang Social and Pussy Flip.

This meant that we didn’t have to worry about the core game mechanic and could focus on building our development platforms and multiplayer systems. We learned a lot and got all sorts of development processes working a whole lot better. So now the organisation we have built is being put to the test as both teams are working on original game mechanics.

I am not suggesting that everybody imitates this, because you must structure development in a way which suits your own specific situation, taking account of the people you have and the overall way that your company addresses the market.

Also, I am sure that what we have now is not the finished article. We have to react to new development tools, new platforms, new staff and the demands of the market. It is these sorts of challenges that make my job such good fun!