|
Seattle-based, now Warner Bros-owned Monolith Productions, whose history dates all the way back to 1997's FPS Blood, has had a long tradition of delivering immersive and well-regarded first-person experiences -- this generation coming up with both of the
Condemned games, and F.E.A.R., one of
the most successful attempts to blend horror and first-person shooting yet
released.
Now, the developers are working on F.E.A.R. 2: Project Origin, which begins about thirty minutes before the original game's ending. Players will again battle the paranormal manifestations of a wrathful and powerful psychic girl, taking on the role of a special forces agent who will have the same superhuman reflexes seen in the first F.E.A.R. The game is scheduled to release for PC, Xbox 360, and PlayStation 3 next February in the U.S. and Europe.
To find out
more about the game's technological basis, we spoke to John O'Rorke, engine architect
and principal software engineer for Monolith, and Matthew Rice, senior software
engineer, AI, in a two-part interview.
What follows is a detailed look at the
decision-making process at Monolith when it comes to tech; how features are
decided on and become implemented, as well as a frank discussion of the future
of current-gen engine technology.
It also examines the current state of game
AI, taking in a discussion of the features of the latest iteration of
Monolith's AI technology in F.E.A.R. 2,
and what the future holds.
John
O'Rorke, engine architect and principal software engineer
It
sounds like there are a lot of pretty high level features; coming on from the prior
game, what were your priorities? Was the engine improvement driven by the
demand of what was going into F.E.A.R. 2?
And, if not, what drove them?
JO: For F.E.A.R.
2, we really wanted to just crank up the destruction, and the overall
visuals, and the environments, because that's really what made F.E.A.R. 1 unique and special. So we
just wanted to take that and bump it to the next level, and so, it was dictated
by the needs of the project.
We focused on "How do we get five to 10
times as many objects in spaces? How do we do some really cool new lighting
stuff? How can we make the environments feel more real? And also make it run
off of a console, with limited memory, and stream everything, and all that
other fun stuff?"
Obviously,
F.E.A.R. is a horror-based game, so
atmosphere is very paramount for it. But to execute on horror, a multidisciplinary
approach is required, because obviously the tech has to be ready to support
these things, but art and design have a big say in what's scary, and how it's
going to look. So how do you balance those disciplines when updating an engine,
and picking and choosing what features to concentrate on?
JO: That's a really good question; that's
something that a lot of people tend to overlook when analyzing technology. It really
doesn't matter what the cool new feature is unless there's an adequate workflow
for it. Technology development is expensive, but not nearly as expensive as
content creation.
And so, there have been techniques, and
research, and prototypes that have been done, that we've had to scrap just
because there's no way in the world that we could create a workflow that would
allow our artists to populate that and still stay within timeframe and budget
-- but, I say that, though there are also a lot that have panned out, and
resulted in some pretty cool techniques.
One of the things that we did for F.E.A.R. 2, for example, was textured
volumetric rendering, and we were able to come up with a nice workflow for
that, that was pushed by engineering -- just something that the graphics
engineer and I were playing around with, and we came up with a technique, and
we prototyped it, it turned out really well. We pushed it to the artists, and
then they started incorporating it into a lot of spaces. They really help pull
out the atmosphere.
And then there's always the converse, of
course, where the artists say, "Well, what if we can do this," and then there's back and
forth about, "Oh, okay, here's what you're really trying to do; here's a
solution that we can put in there for that, and see how you'd like it to work
for your workflow," and so it's very much a two-way street in terms of
ideas and stuff like that.
F.E.A.R., obviously, and F.E.A.R. 2 are on this technology, but
what other games from the studio have been running on this generation of your
engine?
JO: It went F.E.A.R. -- F.E.A.R. was
our kind-of new technology; new renderer, physics, and all sorts of stuff like
that; Condemned was basically our
migration onto the consoles, with the 360 launch title; Condemned 2 was an increment on the console technology and move
onto the PS3; and F.E.A.R. 2 is a
further refinement of all the graphics and performance, and a couple of new
features that we're working on, too.
When
you're talking about your engine development, obviously you guys have game projects
going; your flow is that as a project gets towards wrapping, you start working
on the engine improvements that are going to go into the next title. So, I'm
assuming that's why you are able to incrementally list the upgrades that happen
per each game title you just mentioned.
JO: Yeah, it's very much a leap-frogging of
systems; it takes longer than game project to rewrite all of these systems, so
we pick the biggest systems, or what we really want to hone for the title, or
what needs major extensions to support the game, rewrite those for that title.
Then those are usually pretty solid, so we switch to a different set of
systems, and so on.
|
MR: Yeah. I mean, one of the main problems is that it's difficult for the AI system to understand the verbs of the player, or player intent, you know? There are some games -- I feel like Rainbow Six does it particularly well, and we do too -- if you narrow the focus of the engagement, so that pretty much the only thing you can do is stand on one side of the environment and fight the AI on the other side... then it becomes very successful, because the AI really knows what the player is trying to do: he's trying to kill the bad guys. "
This completely reminds me of Chris Crawford's essay "How to Build an Inverse Parser." Limiting the possibilities and showing the player their options, is the simplest to program, and easier on the user too.