The sun is shining, the air is warm, leaves are finally coming out. Spring is here. Time to put on my rose-colored glasses and do some armchair quarterbacking. I often find myself saying “If I owned a game company I would make sure to do such and such,” so here we go.
Be warned, this information is not organized in any particular way, it’s not comprehensive of all aspects of running a company, they’re not particularly popular views, and there might be some very good reasons why they’ll never work. But I can always dream. So without further ado…
Going ’round and ’round with the prototype.
It’s unclear whether software development can ever be as much of a rigorous engineering discipline as other fields, but game development is definitely not an exact science. Quite far from it actually. In the end, a game needs to entertain. Even if you’re going for a tried and true, formulaic approach, you still can’t guarantee you’ll have something fun in the end (not like it stops anybody from publishing games anyway, just like bad summer action flicks).
Unless you’re aiming from the start to make another tired, derivative game, you really can’t schedule and predict when you’ll have a good game in your hands. Yes, you can follow existing conventions. Yes, you can build on previous games. But in the end, you won’t know whether you have a fun game until you finally see it and see how people react to it. The last time you want to be asking yourself whether your game is fun is at the end of a $10 million project when your publisher is breathing down your neck to nail down the release date.
I would like my company to start a project by doing a gameplay prototype. Forget about technology (for the moment). Forget about doing a massive design document bible (forever). Start with a vision. Something that fits in a couple of paragraphs and everybody understands. Take whatever technology you have around (or license something, or grab an open source engine, or even use a popular game and mod it), and show me that the game we’re thinking of doing is fun. I don’t care if it looks pretty. White cubes and pink spheres might be good enough. Reusing the models from the last game is also perfectly fine. Just show me it’s fun.
You won’t get it right the first time, or the second, or the third. But eventually the magic will start happening and something will come into focus. You will have to bring new people often to try out those ideas and see how they react everybody involved in the project is too close to the prototype to have an objective opinion. Good game designers will be able to come up with good ideas in a reasonable amount of time. Other people might stumble for months without coming up with a single good idea that is not a straight rip off from another game. That’s what separates the truly creative designers from the hacks out there.
Of course, that’s easier said than done (I warned you, all this is armchair quarterbacking). Even some of the most respected designers like Sid Meier have problems coming up with good game ideas. But you know what? I have a huge amount of respect for someone who actually goes through the process and after a while decides that he couldn’t find any great game ideas there. Most people would have moved along with some half-baked idea that tries to copy the latest best-seller.
Unfortunately, this will only work if you have enough money to fund this phase without a schedulable ending and if you can manage to convince your publisher that your game with colored blobs is really fun and is going to outsell everything out there. That’s one tough job since publishers seem to care more about technology buzzwords and screenshots than anything else.
One vision to rule them all…
You’ve heard of teams where everybody has an equal voice. You’ve also heard that too many cooks spoil the broth and about the quality of designs by committee.
Sure, it’s possible to make (or stumble into) a game in any way, but I really believe the best way to go about it is to have one person responsible for the vision of the game. That’s not necessarily the person who came up with the idea. Maybe someone else suggested it, maybe the publisher contracted it. In any case, the lead game designer should hold on to that vision and have final say on how the game should be. He can (should) take input from everybody, but ideas should be filtered and processed before they make it into the game. Doing so ensures that the game never loses track of what it’s supposed to do, what adds value, and what makes it even more fun for the final user.
It might sound like a cool job, but trust me, a lead designer in that position will be under fire from everywhere. Everybody wants their own pet feature in the game. People will get mad when their ideas are shut down, and will disagree with the choices made. It is extremely important that the lead designer have a very strong personality and be someone who can convince everybody that the game is moving in the right direction. Communication is key. If people are aware of the vision and they know the reasons why ideas make it into the game or why they’re rejected, they’re a lot more likely to be understanding and continue to be highly motivated.
Separation of powers.
Starting in ancient Greece, people realized that having all the power concentrated on one person or governing body was a recipe for trouble. The United States has three separate powers: executive, legislative, and judiciary. Many other countries all over the world have similar divisions. Why go to the trouble of such an arrangement? The different powers might end up working against each other, and they’ll certainly be more inefficient than having them all combined into a single governing body. The short answer to that is absolute power corrupts absolutely.
It is the same with game development. It is too easy to let personal feelings and interests conflict with the good of the overall project, intentionally or not. That’s why I believe that an ideal arrangement for a game company also needs a division of powers. In its simplest form, I see three leads: design, art, and engineering. They each have ultimate responsibility for their departments. With this arrangement, you also prevent the engineering lead from going around telling the artists to make their textures brighter because he likes it better that way (don’t laugh, things like this have happened). That’s the responsibility of the art lead. As an additional balance, to prevent things that make no sense early on it might be useful to make it so two leads can always veto another one (Design lead: I want to have 100,000 orcs coming over the hill at once. Engineering lead: No way, not unless they’re one particle each. Art lead: No way, that would look like crap. Out with that idea. Happy ending: Engineering lead: How about we make impostors for the back and give you 100 orcs coming over the hill? The effect will be very similar).
Finally, to complete the hierarchy, on top of them is a producer, who has ultimate veto power about anything, but who has absolutely no input in the game at all. That last concept is key. The producer is in such a powerful position, that he should have zero input into the game itself. He should coordinate development, interface with the publisher, guide the project based on constraints, but have no design input at all. Repeat after me: a producer should never be a designer; a designer should never be a producer. Combining those two positions in a single person can cause too many conflicts of interest (not to mention that it’s way more work than a single person can take on and still do a good job with it).
Disclaimer: I’ve never seen such an arrangement, so I probably don’t know what I’m talking about. It sounds really good in paper, although there’s the potential for continuous deadlocks if team members don’t know how to work with each other and feel very differently about the project. Clearly, if the producer starts vetoing things for personal reasons, he should be kicked out and promptly replaced with someone who does the job properly.
Making the most out of technology.
Putting together the technology behind a game is a huge amount of work. Trust me, that’s what I do for a living. The funny thing is though, there’s nothing inherently unique in 99% of that code. Most of it is a matter of organizing things correctly and streamlining the way content finds its way into the game.
Creating all that technology is a large chunk of the total development cost for a game, so it seems wasteful to create it over and over again for every new title. Even re-using some of it still requires a lot of extra work. To make matters worse, the technology and the tools are not usually the primary concern during the development of a game, so when the project is over you’re left with a set of half-implemented technology with barely-working tools that were just good enough to finish the previous project but are not up for much else.
Personally, I love working on game technology, so I suspect I’d want my company to concentrate on that. However, I would make sure we’re not wasting our time. I would set up the game technology project totally separate from the game projects, and then I would try to have two or three simultaneous games in development leveraging our in-house technology. Either that, or take the id Software and Epic Software approach and just make one game to showcase our technology and then license it to other companies.
If technology wasn’t my thing, then the choice would be clear: license it. With mature game engines such as Renderware or Gamebryo there’s very little excuse not to do that. Yes, price is an issue, but think how much it would cost you to make and maintain a similar set of technology internally.
No overtime allowed.
The game industry grew out of a cottage industry made out of teenagers working in their bedrooms. Now it’s a full-blown industry with huge budgets, but some of the same old attitudes still prevail. There’s a very strong sentiment in the game industry that developers should only care about their projects and should spend all their waking (and sleeping sometimes) time at the office. Looking through postmortems (and this) in Gamasutra and Game Developer Magazine shows to what extent this attitude is rooted in the industry when half the postmortems boast in their positive aspects how they worked insane hours but the team pulled through to deliver the goods.
Some call it heroics. I call it cowboy coding and death march. Studies have shown that after about 50 hours of work in a week, the amount of work done actually decreases. Not only are getting people tired, they make mistakes, and they need to fix the problems they cause, but the longer they spend in the office, the more work time they have to dedicate to do other things: step out to the bank to deposit a check, stop by the post office to get a package, etc. Number of hours in the building != amount of productivity.
Fortunately, there are a few companies in the industry that are aware that people want to have lives outside their work and encourage (or allow) employees to work 40-hour weeks. Maybe people in high places are starting to realize that happy, rested employees are a lot more productive than stressed, burned-out ones (who also quit as soon as the project is over and need to be replaced).
I would like to try an experiment with my company: Not only would employees be encouraged to work 40-hour weeks, they’d be required not to work more. The catch is that people are expected to put in a serious eight hours of work every day. No screwing around, no checking the web, no wasting your time waiting for builds to complete. There’s nothing better than leaving work itching to come back the next day rather than leaving exhausted and hoping to forget all about it as soon as possible. If you’re dying to do more, work on your own project, contribute to open source software, read a technical book, or learn about something completely different. It’ll all come back and be useful in the end, the employee will be much happier and relaxed, and the company will have great employee retention. Workaholics need not apply.
Very rarely (that’s the idea anyway) we might need to speed something up to meet a deadline or make up for some lost time. Under those circumstances the company would ask people to put in overtime with the condition that for every hour they put in, they get two hours off in the very near future. That’s a good way of making sure the company doesn’t overuse overtime. I’m sure I’ll write more about this in the future.
The good of the many outweighs the good of the one.
There is a lot more to a successful game development team than a group of talented individuals. You could fill one room with superstars and you’ll be almost guaranteed to get a failing project asphyxiated by huge egos.
Putting together an effective team is a very delicate matter. While a lot of people put emphasis on technical knowledge and experience, I’m convinced that the most important requisite is the ability to work well with others. It’s no good to hire a superstar if nobody can work with him. I’d rather hire an less talented programmer who can interface very well with everybody and is eager to learn and participate in the project.
People can pick up technical knowledge and experience pretty quickly if they are eager to learn, but moody prima donnas don’t change their ways very often, and drive away everybody around them.
Totally driven… by data.
This probably goes without saying, but I’d want the games created by my company to be totally data-driven. We don’t hire programmers based on their good looks, and we don’t hire them based on their design sensibilities either (at least, I wouldn’t in my company). So they shouldn’t be creating the game. That’s up to the designers and, to a smaller degree, the artists. They’re the creative vision behind the game (it doesn’t mean that programmers can’t be creative, just creative in other areas).
That means that the content creators should be able to put together a game by themselves, without programmer intervention. To accomplish that, we need to be totally data-driven. Ideally, whole new games can be created by changing the data (which includes data definitions, scripts, sounds, art, etc). Any game-specific behaviors should be coded through the use of scripts or something similar that can be changed quickly without recompilations and requires no large-scale architecting. Those scripts can be created by technical designers (or designer/programmers if you prefer to call them that way) instead of using technology engineers whose strengths lie elsewhere.
This data-driven view fits very well with the earlier idea of separating the technology as much as possible and have multiple projects use it, or even license it to other companies so they can create their own games.
There are plenty of other things that I’d like to ideally do on my own company, but most of them are common sense and they’re not very games-specific: quality above flashiness, taking care of employees, fostering a positive company culture, etc, etc. Some of them, like using agile development or releasing the source code to all technology are probably better left for another time. Unfortunately, as I said earlier, I doubt I’ll ever own my own company where I can call the shots this way. Perhaps a more realistic article would be one on how to find your ideal company when you show up for an interview. Until then, enjoy the Spring weather.