[MUD-Dev] Is database access a bottleneck?

Robert Zubek rob at cs.northwestern.edu
Fri Dec 13 10:46:29 CET 2002


From: Koster, Raph

> Everything you so amusingly described here is definitely true in
> the game industry. There's a distaste for academia that is
> incredibly short-sighted in my opinion, and a reluctance to make
> use of tools or techniques developed elsewhere. It's all stupid.

Yes, transfer of research into the game industry is still happening
very slowly (especially in fields like AI, much less so in
graphics). But I'd like to add another reason to those you mentioned
before. There's a lack of transfer of *people* from research into
the industry.

As they say, the best way to transfer knowledge from academia is not
via publications or conferences, but by having people with advanced
degrees go work in the industry, bringing their practical
problem-solving skills with them. This, however, has not been
happening quite so much with games. Some of this is definitely due
to the novelty of the collaboration. While there are quite a few
academic groups interested in game AI problems, for example, these
programs are too recent to have produced more than a handful of
graduates. But unfortunately, even after those people graduate,
chances are pretty good that they won't go into the industry, simply
because it isn't competitive enough. Tenure-track positions tend to
make much better economic and career sense than game development (in
the general case, though there are a few notable exceptions). How to
encourage people to go into the industry instead?

> I frequently see military projects using game-like technology that
> took years to make and cost millions of dollars and probably could
> have been done in a few weeks by any competent FPS team in the
> industry. It's not uncommon to see AI solutions that work great in
> a Java applet but fail miserably when you need to apply them to
> real world scenarios, like the amount of memory in a game console
> or an actual interesting game map or whatever.

I sympathize with the sentiment. Academic AI solutions have a
history of being inapplicable to commercial development, especially
in highly resource-constrained domains like games. But the reality
of research world is that projects follow funding, not the other way
around, and have to match the needs of the funder. If a gov't agency
creates a research program in - whom shall we pick on? - action
planning systems for autonomous military vehicles, then it's no
wonder the resulting work doesn't bother about trying to fit into
the memory space of a PSOne. :)

Part of this is also that research is supposed to be general, and
it's left to the implementor to cut it down to size. Planning
systems, for example, may not worry about memory footprint or other
performance requirements, but it's expected that others will be able
to use the *insights* of the planning research, and not the code -
that the implementor will be able to remove or simplify bits that
don't matter, and build on the research to make their particular
solution fit their particular constraints.

This said, such an approach requires the implementor to already have
significant experience in building AI systems. Which brings me back
to my first point about lack of transfer of people... :)

> It cuts both ways; people on both sides of the fence need to gain
> more respect for what the other does and does well. It's the
> insularity and automatic assumption that "we know better" that is
> the problem across the board.

Yes! Fortunately, things are improving. The AAAI symposia on AI and
computer entertainment have done wonders to make AI researchers
conscious of the needs of the industry, and they've triggered a lot
of interesting game-related work. I'd be curious to find out if a
similar thing happens the other way around - has the industry been
influenced at all by contact with academia?

Rob

--
Robert Zubek
http://www.cs.northwestern.edu/~rob


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list