Stuff

Probably blog less in the upcoming months because I'm writing articles for Gama.

Chris McEvoy points out that he also has Game Studies organized in the same way: http://www.usabilityviews.com/gas_by_date.html.

There's a cool interview with Tim Schafer high up on the list.

I owe Mike McShaffry a review of his book; that will be coming soon.

Wow. Just, Wow

UbiSoft ported Splinter Cell from the Xbox to the PS2 in four months.

This is amazing. When doing ports, there are easy ports: going from a weak machine to a strong machine (for example, when we ported Tony Hawk 2 from the PlayStation to the DreamCast). And then there are hard ports, going the other way, like when Treyarch ported Triple Play 2000 to the Nintendo 64. Splinter Cell is a game that pushes the Xbox and it's incredible that they managed to get the whole thing done in four months. If approached with that project, I would have just said no. I would have said it couldn't be done. Not with 90 people on the team, not with 180 people on the team. Reading the article, I still don't see how they did it.

On the other hand, what's wrong with simultaneous development? This is how we did our Tony Hawk 2 port, shipping it at the same time as the PlayStation version. (I pitched a post-mortem on that to Gama but they never responded.) Here's how you do it: use CVS or Perforce. Treat the primary development team as your vendor. Ideally, they'll be a shop as solid as Neversoft, and they'll set up a system so you can access their source control repository. (Neversoft used Source Offsite.) Because they're such a solid team, you can do gets straight from their source control without worrying about the build being broken. If that doesn't work, work out a system by which you get their updates on a semi-regular basis. (We would update from Neversoft weekly.) Integrate from the vendor branch in your source control to your branch on a regular basis. For Tony Hawk 2, I would spend half a day once a week doing this. It was a grueling process in those areas where our code changed dramatically - the tournament scoring system, for some reason, always generated conflicts.

We had a rule to help make the integration process easier: Do Not Change Any Code You Don't Have To. Changing the formatting of a module, or changing the name of an identifier throughout the code base (we would have loved to change CBruce - a legacy class name from Apocalypse - to CSkater. Mick tells me they finally fixed this in Hawk 3.) would have made integration very dicey. By keeping our changes small this was not a problem.

I would have said to UbiSoft: let us start the port now. Give us eight months and ten hand-picked guys.

From reading the article, it seems like they didn't even know simultaneous development is possible. It said things like they couldn't start early because the code wasn't ready yet, and they started work with an early build that still had a ton of AI bugs and the only way to fix it was to bring in the original coders. Maybe there's some unmentioned factor that prevented simultaneous development -- the Xbox team too busy to set up offsite source control or give them regular code drops? -- or maybe it's this: "European developers tended to question authority and try to find a better solution. Sometimes they managed to come up with better ideas, but sometimes they wasted time. On a project with such a compressed schedule, that hurt." Perhaps somebody on the team knew how to do simultaneous development, but was not allowed or encouraged to speak their mind, because UbiSoft Shanghai's command-and-control hierarchy did not allow for it. (On a team of ninety people, I grant you, you probably need command-and-control. But in those early days of the project, when they were a smaller prototype team; what management style did they use then?)

Still, I wish I knew how they did it.

BTW, I've got a new article in Gama, where I say the same thing I usually say: fix bugs, fix bugs, fix bugs.

And this is kind of cool: a ton of Gama articles, indexed by date and popularity.

Who the hell is Andrew Rollings?

I submitted a couple of reviews to Amazon this morning about Rollings' books, both of which I really liked, even though he dissed on Die By The Sword in the first one.

I'm not going to shut somebody out simply because they don't seem to have the experience to back up their words -- for example, I read Joel Spolsky's site religiously even though the team sizes he tends to deal with are much smaller than ours -- but I definitely give more credence to someone who has that track record. Ernest Adams I know, he's got some titles under his belt he can be proud of.

It's especially problematic for Rollings and Morris because they have a lot of advice to offer on how to run a game company that I don't believe was fully field tested when they published it. Advice that heavily contradicts Mark Cerny, but Mark Cerny is the guy with the serious track record.

Another thing that irritated me: in the beginning of On Game Design, they dis on design by consensus, saying that Half-Life's cabal process is the "exception that proves the rule," that the Half-Life guys are really talented and therefore their methods work for them but won't work for anybody else. This dovetails Game Architecture and Design, where they interview a bunch of hot-shit developers, and most of these developers give advice contrary to the advice from the book...but these guys "are from Shao-Lin" and therefore can get away with methods like these.

Rollings/Morris may have a point. Games frequently have strategies that work terribly in the hands of a mediocre player but kick ass in the hands of a strong player. (My favorite example is the Interceptor from Allegiance; learning to be effective with that ship is quite difficult, but once you've mastered it it's devastating.) The mediocre player is best off sticking with a strategy that's easier to manage. Likewise, a beginning studio could be best off working with a "safe" strategy.

But the Cerny Method is not one of those strategies. It is the way a beginning studio should do things; it's an effective strategy that will kick much ass no matter who employs it. Building a game is building a system. Unless your game is very simple, it's going to have emergent properties and complications that you cannot predict. Your plan will not survive contact with the enemy. So, although a bad plan is better than no plan, a big plan is worse than a small plan. A hundred page design document that contains "Design Decisisons" such as 'if the player walks within fifty meters of the nest, the mother monster will go into attack mode, and not leave attack mode until the player is dead or has retreated a distance of a hundred meters' rather than 'mothers protect their nests' is a waste of time and paper...and it's micromanagement to boot.

I'm not so sure about the Cabal Process; so much can go wrong with design-by-consensus (my thoughts on design-by-consensus are two-thirds of the way down the page. That's one thing I liked better about editthispage over blogspot; each article was a separate, linkable page) that it may be one of those advanced strategies best left in the hands of experts.

Still, even if Rollings/Morris are right, and these are secret Shao-Lin methods for making great games, what are you going to do? Are you going to stick with the "safe strategy" that guarantees a mediocre game, or are you going to try to learn the strategy the big dogs use, probably screw it up the first time, but the game after that: look out world!

Still, we don't have to agree with everything somebody says for some of the things they say to be very valuable. (Good thing, otherwise nothing anybody says would be valuable.) Maybe Rollings and Morris aren't that production savvy, but when it comes to game architecture and design, they know their shit.