| ||||||||||||||||||||||||||||
|
(Page 1/11) Next 
Early last year, Vivendi Universal's burgeoning Vivendi Games division acquired Darkwatch developer High Moon Studios. The developer began its life as the development arm of Japanese pachinko behemoth Sammy before its merger with Sega, transitioned to an independent studio and finally found its home with Vivendi. Earlier this year, Gamasutra toured the studio, gaining insight into the tools, techniques, strategy and inspirations that fuel the company, as the studio works on titles including The Bourne Conspiracy, due mid-next year. First, we spoke with Clinton Keith, who currently heads High Moon's technical department, overseeing research and development of next-generation game engines. A seasoned veteran of both the video game and graphics technology industries, Keith's career has taken him from programming avionics for advanced fighter jets to working for such studios as Angel Studios, now renamed Rockstar San Diego, where he worked as both the director of product development and lead programmer. What third-party tools do you use?
Clinton Keith: We're pretty
much an Unreal 3 house, so we use all the tools associated with that:
Maya, Max, and a number of plug-ins like Face Effects, AI Implant, SpeedTree,
and tons of smaller things like MotionBuilder. We have about a dozen
people on what we call a stability and tools team. Their focus is on
making the engine, keeping it stable, and building tools on top of Unreal
3 that make the job of the content creators easier. Did you have a proprietary engine previously? CK: Yes. It was called Score, which stood for the Sammy Core Engine. Rather than just a complete engine, it was more of a framework with this behavioral layer on top that controlled how objects in the world operated. It was all data driven through tools. You could change the behavior of the game very quickly, much as you can do with Unreal 3. Underneath that, we just bought parts off the shelf. That's what kind of drew me here -- we kept spending a lot of money on physics engines at Angel Studios [now Rockstar San Diego.] It's kind of hard to break away from that once you spend millions of dollars, but then you look at the cost of something like Havok off the shelf, and it's less than what you spend on one engineer a year, and they've got 35 people working on it. I really wanted to take the company in that direction, but there was a lot of inertia against that. I saw Sammy [Studios, High Moon's previous incarnation] as an opportunity to say, "Let's see if we can give more control to the content creators. Let's take that money [spent] on the programmers doing physics and instead put that into tools." 
High Moon's California studio
How important is it to be up on the latest versions of tools?
CK: This is the problem --
one of the things that I like to have for tools is the source code,
so that we can modify it for our own particular needs. This is one of
the biggest lessons we learned in going to Unreal 3. I like Unreal 3
-- it's gone through a lot of changes, and it's now stabilized -- but
any kind of tool or engine that you buy off the shelf has some assumptions
built in, in terms of the workflow. Unreal 3's power is in its tools,
but those tools are built based on the philosophy of how their level
designers and artists build levels. If you go into that with a different
approach... you'll have a learning curve to overcome. Now that we're getting close to the final year of our game, we're not upgrading. The problem with upgrading is that it keeps you back on the vendors' path. For the first year and a half of using Unreal 3, we couldn't deviate, because there were so many changes going on it would be disastrous for us. Now it's all about diverging and doing things that we need, to put icing on the cake. There's some problems with that. In my last year at Angel Studios, we were working on an entirely data driven approach -- giving content creators entire control over behavior, and making tools to allow that to happen quicker. Two of us came over to Sammy to continue that. The problem is that you can never create a perfect system that can anticipate all contingencies. The path it can take from an obvious piece of data to the game not behaving correctly is really long. When we finished Darkwatch, we had something like 13,000 bugs, most of which were caused by bad data matching, and all the stuff that built up because of this ideal we had of giving total freedom.
Do you wind up having to
clean up a lot of code? Giving designers control over that level of
specification tends to wind up with a lot of spaghetti.
CK: It's true. Technical designers
often haven't learned some of the techniques that programmers have learned
in writing self-testing code, and we get bit by doing it in C++. They
don't pay as much attention to the underlying performance issues, because
you still have to use some of the tools. We try to encourage technical
designers to work shoulder-to-shoulder with the programmers, rather
than coming to the programmer with a bunch of code that they've written.
They'll prototype something out, or invite the programmer over to talk
about the problem, and maybe on a day-to-day basis, we get something
in the game that works that the programmer can verify. (Page 1/11) Next
|
||||||||||||||||||||||
|
|
Comments
Login to Comment