Due Process

As a developer I don’t like to focus solely on my own little corner of the industry; I try to get a view of the bigger picture, processes and business as a whole. This post is a bit of a ramble covering many obvious points and some bitterness so bear with me or ignore.

The process of creating a video game is obviously fairly complex; huge teams, complicated hardware and esoteric design issues all help make this business both interesting and frustrating. The course of a project is usually the same though; from preproduction, hopefully, through to prototype or vertical slice, milestones to the finished product. Below is my view of the perfect project, set out in a time to completion graph:

In the graph “content” means exactly that, and covers everything from art to music to front-end. In an ideal situation the code base is based on a previous project’s or an in-house engine that can be easily modified or built upon so you don’t need to reinvent the wheel every time. A preproduction phase prepares for the content creation which ideally starts a little later, giving the content creators some time to either finish a previous project, take some time off or train, in-house, to remain competitive.

“Shippable” means that the game isn’t finished to the extent it was intended but what is there is playable and, well, shippable. “Complete” means it’s finished to the extent it was planned and “Perfect” means that the game is finalized to the satisfaction of the developers, not necessarily the publishers.
The steeper a curve is, the more chance of overtime, unpaid of course.

As you can see this graph represents the impossible: no mistakes, focused design that works the very first try, no bugs, no overtime. The programmers start with a solid code base from a previous project or in-house engine, the design starts up first and works towards a prototype which hopefully establishes all the major design points of the game. Art starts work on direction and technology and can make content to fit in with the technical specs the programmers deliver. At some point design is “finished”, leaving maybe only some low-level tweaking to do, which shouldn’t impact the content and code. QA starts early and keeps the team apprised of any bugs and issues as they crop up. The game reaches a level of perfection, on time and without overtime, and gets shipped as intended. Oh, and for bonuses everyone gets their very own moon on a stick.

The reality in the west, as I experienced it however, is more like so:

The code base to build on isn’t quite as solid as it should have been because the previous project was rushed. But there is something there, at least. Design continues throughout and results in a feature creep, Content and code are constantly effected by design changes and require some overtime to get fixed. QA starts at some point and delivers stacks of bug sheets. The publisher eagerly waits until the game reaches “shippable” level and then immediately ships it.
This is not too bad a process. It’s become the standard and though it could do with some tightening up it has produced some great game in the past.

In Japan, however, the situation would seem to be more like this:

Once the idea for the project is dreamt up everyone shoots off the starting line. Due to the hard-coded nature of most Japanese games there is little or no real reusable code-base so essentially a complete reset is required. Though design has hardly had a chance to get going, content needs to be created unless you are left with half a team bored out of their minds. So the art department shoots off and gets roped back down when the inevitable design changes occur. QA starts late and the bugs brought up by it cause further design changes and masses of overtime for all concerned. Once the game reaches “shippable” level people are too tired and don't care much about getting to “complete” and the game gets stuffed in a box and released.
For the higher quality games just imagine this graph continuing on in the same manner until the converging points meet up at the “complete” line. Those great Japanese games people love have the distinction for taking a lot of time to develop, compared to most Japanese games in general.

~ ~ ~

So what lies behind this mess? There are a few problems inherent in Japanese game development that I have noticed, and commented on before:
1. No scheduling.
Scheduling consists mainly of telling the team what needs to be done by when. It is not a two way street. The team is not consulted in the matter but is expected to deliver. And if your boss says that you have two weeks to build a level, he doesn’t expect a level of “two week” quality either, he wants a playable, good looking masterpiece.
2. Reliance on the "Japanese work ethic"
The staff won’t complain, at least not openly. They may grumble about not being able to see their kids during the week or the unhealthy lifestyle of MacDonarudo meals and overnight work sessions, but they’ll still do it. As a result nobody is ever punished for bad scheduling or decision making. And so the next project will be run in pretty much the same way.
3. Japanese planners
Here I must admit a bias; Japanese planners are almost entirely responsible for my embittered state, my growing discontent with the industry. It has often been said that the Japanese avoid decision making, and this is a BAD thing when it comes to planning. Pretty much all of the planners I have personally worked with have been utterly useless; the kind that doesn’t know what he wants until he sees it, and then still changes it. This causes a LOT of rework and changes, which leads to tighter deadlines, more overwork, etc.
4. Vague and undue direction
As I’ve mentioned in previous articles the boss has way too much direct influence on the minutiae of the game. He can go weeks or months without watching development closely and then call a meeting to demand changes in art styles, play mechanics, etc. Also with the lack of focused design content creators are often relied upon to use their initiative but are then not given the responsibility over the final product. So you’ll be asked to come up with an asset of sorts but when it’s finished you’ll be told to change this and that and redo such and such.
So you may be asked to “change those textures to make them more, you know, colourful.” And when you do they’ll say “no, I meant different colours than those.” Unless you know exactly what you are changing, what to and why there will be a lot of back and forth, a lot of redoing and, eventually, a lot of overtime.

~ ~ ~

What can be done to fix this?
1. Learn to schedule
Well, duh! Check with the people making the game what is and isn’t possible by what dates before signing that contract. That’s all there really is to say on the subject.
2. Get with the times!
Jobs for life are gone. Both the employees and employers must realize this and get in line with the times. Employers must learn to not blindly rely on the respect, loyalty and private time of their employees and employees in turn must not blindly give their respect, loyalty and private time to the employer. A little bit of looking after “number 1” is called for here. Why complain that you never see your kids but still work through the night? Why not stand up for yourself and tell the boss “no, it can’t be done on time with this schedule. I’m off home now.” Otherwise he’ll come to expect it and rely on it and not try to change things for the better.
3. Educate staff better
The reliance on cheap graduates may be a money-saver on paper but in reality it slows down the whole process. Spend money and time on properly training your staff and don’t be afraid to get rid of the chaff. Find or start a proper game design school in Japan where planners are taught how to make decisions and the fact that their many changes have far reaching consequences for the rest of the team.
5. Delegate responsibilities to the relevant parties
Bosses should not be afraid to trust the judgment of their staff. If you hire a coder or artist you presume a certain level of skill and quality. If you then take responsibility away from them and make all decisions yourself you degrade your employees to work horses causing a lack of interest, loss of motivation and a personal distance from the project. The best way to create a team is to have people with personal creative investment in the title, which, in my view, brings out the best in people.

These things will be hard to change though, if not impossible. Japan has a deep-routed cultural way of doing things in an indirect and roundabout way. It’s simply the way things are done around here, so naturally that seeps into the working practices of any company. I can sit back and just accept it as is, of course, and being an outsider there is some way of defending this point of view. But on the other hand with my outsider view it’s easier to spot where things could be improved, except that in cases like these it would require retraining for the entire populace, which, let’s face it, isn’t going to happen. Still, I can think about these things and write them up on my blog. You’re not required to agree with me.

~ ~ ~

To avoid comments like “well, it’s different here” I’ll add, as per usual, the caveat that of course not all companies are run like this and some actually do a pretty good job. Also I’d like to add that I’m not claiming this to be Truth or my solutions to be written with a capital “S”, but one thing is certain: Japanese companies aren’t very efficient and could do with some streamlining. Just because there is a modicum of creativity involved doesn’t mean we can’t have fixed hours, focused design and rigid scheduling. Or so I think, anyway.