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