The title seems like an obvious statement, but I added the “right?” because well… unfortunately it’s not immediately obvious in the weirdly discipline-segregated games industry we have become, where designers sit away from the programmers and artists are outside smoking together talking about girls (and boys).

Probably the sole reason any of us joined the games industry is because we all decided at some point we “want to make games”, however somewhere along the way with the invention of the explicit role “game designer” and with the huge teams required for AAA titles (or even for some not-so-AAA titles) programmers and artists have unfortunately often found themselves distanced from the game’s design – that very thing that drove them to join the industry in the first place.

As our teams on the PixelJunk titles got larger and larger over the years I began to notice this segregation happening – and the more segregation there was the worse that efficiency and communication got, and this was further exacerbated by the fact we have not one but two or more languages to deal with (English, Japanese, etc).  Generally speaking, as things get worse in this direction, people stop participating in the title with their creative side, and simply start “working the hours”, and this produces unarguably mediocre shit work. None of us mean to fall into this pattern of course – we all joined the industry to make games and therefore are a highly self-motivated group of people, quite probably as self-motivated as they come.

We sometimes forget this, but everybody wants to make games, it’s why we’re here! So the challenge is finding a way that even on bigger teams lets people flex this creative muscle, and as a result of doing this takes people back to that raw naturally-self-motivated state they were in when they joined the industry.  This article is about one such method we have found that, so far so good, touch wood and all that, appears to be working well.

Growing Pains

First of all, a list of some of the problems that can occur with larger teams, even when everyone has the best intentions:

Someone Else’s Problem – Douglas Adams coined this phrase when he invented a cloaking device for spacecraft that made the observer consider the spacecraft to be “Someone Else’s Problem” or SEP for short; the brain would automatically not see the craft once it was classified as such.  I see this happen a lot as teams get bigger and more complex.  Programmers throw parameters and engine features at Game Designers and Artists, Game Designers throw specs and tasks at Programmers and Artists, Artists throw random geometry at Programmers and Game Designers.  As soon as you class something as SEP you stop seeing it, stop caring about it, and stop taking any responsibility for it.

Decision Bottleneck – As a team gets bigger decision-making takes on a grave importance because each decision begins to affect a lot of people.  Unfortunately, down to the creative nature of the business, this decision-making quite often all falls upon one person (or a very small group); the directors or producers on the game and this comes about because all decisions require cohesion for the game as a whole to work.

Wood for the Trees (as in not seeing) – Games are large and complex beasts, involving a large no. of people with an even larger no. of ideas.  Not everyone has the time or the capacity to be able to see things on the scale that is required to understand everything as a whole.  The bigger the game the bigger this problem becomes with everyone working in an insular fashion, each concentrating on their modules.

Voices Not Heard – Everyone wants to be involved in the game’s design, everyone’s a game designer, right?  However they feel they aren’t being heard because of the centralised nature of the important decision making.  For large teams using standard development models this problem gets worse and worse.
None of the above problems are those of the individuals themselves, they are unfortunately just natural behaviours that develop as groups grow in size.

The Case Against Sprint

Also I’d like to add a few more points based on trying Sprint for a year or so.  For those who don’t know, Sprint is a mumbo-jumbo new-age task management technique that everyone on teh interwebz seems to guarantee works brilliantly in all and every case (particularly suited to software development!), I have concluded the following:Everyone on teh interwebz is wrong. Sprint development only works in very select cases.
Perhaps because:

Work Needs Reason – in other words, creative people simply don’t like being told what to do – in fact, their work grinds to a halt when you do this!  “Sprint” methodology implicitly requires that you are solely servicing other people’s requests and needs, so where does that leave your own creativity?  This is fine for a product that doesn’t involve too much creativity; for example, a word processor, or when you are debugging in the final part of development perhaps.

Motivation Needs Room – in other words, creative people are naturally motivated when given some space for their thoughts.  This is, however, different to complete freedom because people do their best work and have their most inspired thoughts when working within set limits.

Management Overhead is Annoying – Sprint requires so much management overhead it is painful…. because Q isn’t a management heavy company, in fact there is no-one who is just a manager (we are kind of like Naughty Dog in this regard, except without the multi-million seller hits), this becomes a serious burden on the creative staff who end up having to take on the management tasks that control sprints.

A Solution?  Or the “Well, we found something that is working so far…” section of the article

So with all the above problems that naturally occur as teams get larger, I started thinking about a system that could magically fix it all (yeah right!), and then with the help of the people here at Q we slowly but surely developed a system we tentatively call the “Director Theme System” (mm.. could do with a sexier title).
Anyway, to cut to the chase, here is the general rule set that we created:

1. Break down areas of the game into distinct “themes”, for example: “stage 1”, “player’s controls”, “stage 2 enemy AI”, “game flow”, “analyse and speed up stage loading times”, “develop character A”, etc.  If a theme is too large, break it into smaller themes, but do this as you go along, there is no need to create a ton of tiny themes for the entire game right at the beginning, begin with broad themes and break them down as needed, based on some of the scope rules below.

2. Decide which “themes” are currently active and as a team, decide who on the team should be the director for each theme.

3. Choose the director primarily from the programmers and artists (although occasionally a game designer or assistant producer can also be selected but this is fairly rare).  The director should generally not be involved in the physical work required for the theme, however this is flexible and just a general rule of thumb; it depends primarily on the nature of the theme itself.  Simply put, this separation can help give perspective, so use it when necessary.

4. Choose an assistant director primarily from the pool of game designers or assistant producers.  The assistant director writes up the reports and generally “maintains” the theme, collaborating with the director throughout the week.  The director/asst director are roughly equal in standing with regards to the theme, and should make decisions together.  These decisions must be aesthetic-driven. (see previous article on aesthetics)

5. The directors and assistant directors can be involved in several active themes if necessary.

6. Set up a weekly “director’s meeting” where each director/assistant director combo presents the interesting progress within that theme, and takes suggestions and ideas for where to go next within that theme.  This is a “cabal” (see Valve’s methods) like meeting, all voices and opinions can be expressed and this meeting should never be skipped or postponed for more than a day.

7. Set up a local forum/bbs with a separate thread per theme, list up the director/asst director combo in the thread title, and the subject of the theme.  Then, only allow primarily the director/asst director to post updates to the thread (think of it is a thread for reporting progress).  If you need other discussions use another thread/forum where anyone can join in.  This helps keep the noise level down and focus the director/asst director team on their theme. We also have an area on a wiki per theme where things such as specifications and absolute results are stored – these are all linked to from within the report thread.

8. Not everyone can be a director at first; choose directors based on how picky they are – the pickier a person (people who moan are actually showing good signs of pickiness!) the better a director they will be.  Show people that by being picky and fussy they will be given control and responsibility.  If someone wants to try being a director give them a small theme to try out and attach a solid experienced assistant director.

9. Keep the presentations interesting and fun.  This is not a place to go into technical discussions or go into long boring monologues.

10. Show the game during the meeting.  Show the areas the theme involves, get some of the people in the meeting to play them and try them out.  This is a very important part of the process and helps people understand the game as a whole.

11. Keep each presentation short – the producer or overall director of the game should keep an eye on the pace.  You should keep the themes that are active down to a number that takes about an hour to get them all presented and talked about.  Use the BBS thread mentioned in 7 as a visual aid. (preferably projected or shown on a big TV so everyone can see)

12. Allow everyone/anyone to take part in that meeting (however, all active directors/assistant directors must of course be present).

13. If certain themes are “paused” or unable to make progress, make them “inactive” and drop them from the meeting until they are ready to be active again.  Don’t clutter the meeting with reports about themes that aren’t moving forward.  If a director says “well, there hasn’t been much progress but..”, stop him or her right there and drop that theme unless there is a reason there will be more progress the following week.

14. If a director/assistant director combo isn’t doing well on a theme, give them another theme to work on and perhaps swap that theme to another director/asst director combo.  Don’t let pride or ego get in the way, some people are simply better suited to certain themes, so teach people to spot that themselves; the best situation being an atmosphere where the director/asst director combos openly ask for another director or asst director to take the reins when they feel they aren’t matched or “in tune” with the theme at hand.


These rules may seem kind of arbitrary! However, the shared responsibility of having both an assistant director and a director per theme, and the reduced scope and comprehensiveness of each theme really seems to give people the confidence to push their aesthetic side to the forefront. The weekly director’s meeting acts as a peer review to help reel people in if they are going in completely the wrong direction, or to encourage them to push in another direction if they are stalled. Seeing people’s reaction to their work is a huge encouragement too.

Scheduling

A final note that is very important here; schedule the big programming and art tasks as you would normally.  These run in the background of the above system and should be dealt with in a separate “Leads” meeting every week.  Basically, the above system has nothing to do with scheduling and is entirely about maximizing creativity and quality.  Of course, the result of the Leads meeting will quite often drive how Themes are activated or deactivated. (and vice-versa)

Note that there is almost zero talk of schedules in the weekly director’s meeting, and that is by design; Schedules cripple confidence.

The Proof is in the Pudding

Within 3-4 weeks of implementing the above system on two completely separate teams, the results were phenomenal.  We inadvertently discovered that it totally replaced the previous sprint/agile system we had been using while at the same time boosting quality and production through the roof.  One of those teams is now coming to the end of a project and in just six months the pace has been breathtaking, the game has really been pushed to the max in every area and is a beautiful sight to behold.  Sure, it’s kind of unproven and anecdotal and you never know, in a year I might be posting about another system because of some unseen problem, but hey… fingers crossed!

Dylan Cuthbert runs Q-Games Ltd, in Kyoto Japan, most famous for the PixelJunk series of games on PSN, their work on the PS3′s XMB and music visualizers, and their close partnership with Nintendo on a number of projects.