J-Dev Confidential 4

In this series of posts I examine, from the unique perspective of having experience and knowledge of both Western and Japanese development practices, where, in my humble opinion, Japanese game development is going wrong. Beware that these are merely generalised opinions and do not necessarily apply to all or any specific Japanese companies, some of which are, admittedly, slowly changing their approaches and attitudes.

Part 4 - Decision making

Once, a few years ago, the company I was working for moved the entire operation to new premises. Obviously, the staff were all needed to help move and set up the new offices. Three of my colleagues were charged with setting up a large metal bookcase. They moved it to the designated location and proceeded to unpack all the books and manuals from the cardboard boxes and put them on the shelves. Not one hour later it was made clear somehow, for some reason, the location just wasn't acceptable. So my colleagues proceeded to take all the books off the shelves again and manhandled the bookcase to its new location, where they eventually refurnished the shelves with all the books. Later that day it became necessary to delve under the floorboards to reroute some cables, except, of course, that particular bookcase was in the way. So again, my colleagues took all the books off the shelves, this time depositing them on nearby desks and moved the bookcase out of the way so the programmers could spend the afternoon on their knees laying out the cables. After which, of course, the bookcase was again placed in its location and the books put back on the selves. The whole scenes could have been filmed in time-lapse to the backing of "Yakety Sax".

Though this serves as a wonderful example of planning and decision making, it would be unfair, not to mention untrue, to paint this as a uniquely Japanese problem; spurious decision making, or lack of any kind of solid decisions, retroactive planning and foreseeable last-minute changes leading to the ever irksome "feature creep" are commonplace in our industry, worldwide. However, due to cultural circumstances the problems seem, on the surface at least, somewhat exacerbated over here, despite the fact the Japanese work hierarchy would appear to be more protected from this due to their "auteur" approach. The boss generally has the last say, in everything, but the director is basically in charge. On paper this sounds great; a single vision to drive the design would seem a great way to work compared to, say, design by committee. However, in Japan, hard decisions are a bad thing, culturally. So in the end you have an auteur who directs but makes no real decisions, sometimes only implying them, sometimes just hoping things will fall into place - or to make them fall into place with long stretches of crunch.

I don't quite yet have a grasp of the cultural angle of decisions in Japan, even after these many years here. A simple "yes" or "no" are shunned in favour of implied understanding, usually. People in positions of responsibility never act on that responsibility. Decisions are pushed as high up the hierarchical chain as possible, passing the buck again and again until someone high up puts a stamp on it, to everybody's relief. Finding a consensus is usually much more important than making a decision, which is one reason why meetings in Japan take so long. It is also a reason why decisions are never set in stone.

I must add at this point there is a school of thought in video game development that shuns decisions too, not just in Japan but globally. Some people seem to be under the impression game development is a kind of unstable alchemy, a special unknowable magic that can only be harmed by sticking to early decisions. Though I agree there should be a certain flexibility in development, this abhorrence to decision making usually does more harm than good. Certain elements of development can and should be set in stone and areas of change should be anticipated and prepared for. Instead we hear horror stories of massive delays when someone somewhere decides at a very late juncture that the whole focus of a game should shift dramatically. I don't think that is good business. In Japan however, even the little things seem to work this way.

In short, my rant, my biggest personal complaint about the Japanese system, is that there is a total lack of planning on every aspect of development. Sure, there are so called "planners" here, that take on the role of a designer in the West, creating long asset lists, documents, stories, ideas, and whatnot, it's just that, well, they're not very good and are prone to change continuously over the course of a project, either due to lack of oversight, which appears the most common, or random changes mandated by management.

In an ideal world, any part of development, in this example asset creation, should follow the following graph:
The yellow line, design, starts well ahead of the creation part, blue. Once the design is strong enough, only then does the artist start the creation process, which will naturally fluctuate somewhat due to creative and technical issues. Once the creation part is done, the implementation, red, should be fairly easy, depending on the tools, and may cause some more changes when the final picture is more complete, as seeing your work in-game will pretty much always cough up some unforeseen issues. The main point is, however, that the main decisions regarding this work have been made before the work is started. Any extra time is spent on polish, making things just that little bit better than required.

In Japan however, I found the following graph to be much more common:
Everybody starts off, go, go, GO! Pre-production is usually a formality where a very slim design document is created before production detailing the story, mostly, and some major points of play, but not much else. The details and hammered out during actual development. So without planning, the creation part just starts, well, creating. While planning catches up, changes have to be made to conform to the plan. Even after implementation, changes to the plan will cause massive set backs. Random changes of direction cause further setbacks until eventually you just have to ship because you've run out of time.

Pretty much uniformly, all the work I have ever done in Japan could have easily been done in half the time it actually took, if only people had planned things ahead a little more. I got a bad reputation for bothering the planners with my questions; "How do you need this to work?", "Have you considered that this here will fuck up that other part of the design?" or "Are you sure? I mean, sure sure?" No, you just do and when changes come, as they invariably do, you just work harder to make it fit. This partly leads to the "work ethic" approach I wrote about last time.

As a side note, I have often heard people marvel at the level of detail of Japanese games. "Individual breakable pots are individually textured, and artists spent a lot of time agonising over such details" people gush. Not to bust that dream too, but from my experience the "detail obsession" is just a way to fill the work day. Either a boss needs people to work but hasn't made any decisions yet, so just tells them there is this one pixel out of place in that one background object, or artists are so bored waiting for decisions to be made they spend their days texturing pots. All this usually to the detriment of the bigger picture. With time running out, I've been in situations where we had a wonderful set of beautifully textured props, but hardly any environment yet to speak of.

What Japan really needs is simple: change control.

Now change control is a little contentious, even in the West. What this at its most basic means is that any change has to be justified. How this is done depends on the system you use, but the most important thing is that when a change is requested people sit down and discuss its merits or demerits first before just going "ok!" and working weekends to get it done. For example, "make it more red" seems like an easy change, but with one particular set of tools, and the fact this particular red was spread over many levels, even a simple colour change would have taken a few days of work and testing and heartache. The main question is of course, "if you wanted it this red, why didn't you say so before we made it?", but the current system of "make it as I see it in my head" doesn't allow for such searching questions. The next best question then is "is it worth the extra work to change this red, respective of the benefits we could potentially achieve?" Again, in Japan the answer would be "just come in weekends and make it happen", but as soon as you start calling people on their decisions, they will actually realise those decisions have consequences and those consequences must be dealt with, not by the pit ponies, but by the people responsible for making the decisions.

Change control could help to an extent in development, but like previous posts, there is a huge underlying cultural force at work, which will be very hard to shift. Being decisive is rude, being rude is bad. Forcing people to consider their decisions can lead to embarrassment, and embarrassment must be avoided at all costs. It's a shame, though, because taken at face value, Japan's hierarchy of development, the "auteur" approach, seems to be a pretty good one. But with that one puzzle piece missing, "decision making", the whole system just flounders.

In Japan you neither have autonomy nor direction over your work. And though I may sound like a prima donna occasionally, I actually prefer to have solid direction. I have worked in this industry long enough to know if I want to do my own thing, I should do it on my own, at home, outside of work. Game development is a team effort and great direction is a Godsend. I would assume. When I started interviewing when I first came to Japan I was often asked, presumably because I was foreign and suspected of being opinionated, "how do you deal with direction?". These days my honest answer would be "I dont know, I've never really had any."

6 comments:

  1. You know... this completely explains Metal Gear Solid 4.

    ReplyDelete
  2. Hey JC, once again an excellent post that not only shed some light on Japanese social conventions but game development as well!

    I do have a question though regarding the following. "Once the design is strong enough, only then does the artist start the creation process, which will naturally fluctuate somewhat due to creative and technical issues. Once the creation part is done, the implementation, red [starts]"

    As a programmer-in-training (Computer Science student in California) I thought that programming and art was done at the same time. I guess what I'm asking is, what do you mean when you say 'creation process' and does implementation mean just coding or coding and more art?

    Thanks!

    ReplyDelete
  3. @christopher:
    That graph is the Utopian ideal, therefore it never really works that way. Also, it's looked at from an art asset creation perspective. What usually happens is that while you create your assets you occasionally implement iterations of it so coders can test new code, designers can test their design, etc. while you are still working on it.
    Changes that occur in this way I consider necessary iterations on the art; some issues only become clear once everything is stuck together. However, when coders arbitrarily change things that break the art pipeline, or designers change their mind or simply didn't think things through, which happens all too often, I consider it a waste of time and effort.
    The way I drew the Utopian version of the graph, I hoped to imply the iterative nature of the implementation, hence it's not a straight line upwards or a sudden jump from 0 to 100%. Could have been clearer, I admit.

    ReplyDelete
  4. Ahh ok, that really helped, so its a bit by bit effort with the artist creating and the coder implementing in successive layers. This makes a lot more sense to me, thanks for answering my question, I really appreciate it!

    ReplyDelete
  5. "Forcing people to consider their decisions can lead to embarrassment"

    As can a submission that totally borks the build :)

    What about at milestone time? Is perforce (or whatever program being used) not locked out to anyone other than the lead programmer/tech director?

    ReplyDelete