112 lines
6.6 KiB
Markdown
112 lines
6.6 KiB
Markdown
Also, the moving sky texture will probably be gone or will change. One
|
|
likely replacement is an enclosing texture-mapped box around the world,
|
|
at a virtually infinite distance; this will allow open vistas, much like
|
|
Doom, a welcome change from the claustrophobic feel of Quake.
|
|
|
|
Another likely change in Quake 2 is a shift from interpreted Quake-C
|
|
code for game logic to compiled DLLs. Part of the incentive here is
|
|
performance—interpretation isn't cheap—and part is debugging, because
|
|
the standard debugger can be used with DLLs. The drawback, of course, is
|
|
portability; Quake-C program files are completely portable to any
|
|
platform Quake runs on, with no modification or recompilation, but DLLs
|
|
compiled for Win32 require a real porting effort to run anywhere else.
|
|
Our thinking here is that there are almost no non-console platforms
|
|
other than the PC that matter that much anymore, and for those few that
|
|
do (notably the Mac and Linux), the DLLs can be ported along with the
|
|
core engine code. It just doesn't make sense for easy portability to
|
|
tiny markets to impose a significant development and performance cost on
|
|
the one huge market. Consoles will always require serious porting effort
|
|
anyway, so going to Win32-specific DLLs for the PC version won't make
|
|
much difference in the ease of doing console ports.
|
|
|
|
Finally, Internet support will improve in Quake 2. Some of the
|
|
QuakeWorld latency improvements will doubtless be added, but more
|
|
important, there will be a new interface, especially for monitoring and
|
|
joining net games, in the form of an HTML page. John has always been
|
|
interested in moving as much code as possible out of the game core, and
|
|
letting the browser take care of most of the UI makes it possible to
|
|
eliminate menuing and such from the Quake 2 engine. Think of being able
|
|
to browse hundreds of Quake servers from a single Web page (much as you
|
|
can today with QSpy, but with the advantage of a standard, familiar
|
|
interface and easy extensibility), and I think you'll see why John
|
|
considers this the game interface of the future.
|
|
|
|
By the way, Quake 2 is currently being developed as a native Win32 app
|
|
only; no DOS version is planned.
|
|
|
|
### Looking Forward {#Heading21}
|
|
|
|
In my address to the Computer Game Developer's Conference in 1996, I
|
|
said that it wasn't a bad time to start up a game company aimed at
|
|
hardware-only rasterization, and trying to make a game that leapfrogged
|
|
the competition. It looks like I was probably a year early, because
|
|
hardware took longer to ship than I expected, although there was a good
|
|
living to be made writing games that hardware vendors could bundle with
|
|
their boards. Now, though, it clearly is time. By Christmas 1997, there
|
|
will be several million fast accelerators out there, and by Christmas
|
|
1998, there will be tens of millions. At the same time, vastly more
|
|
people are getting access to the Internet, and it's from the convergence
|
|
of these two trends that I think the technology for the next generation
|
|
of breakthrough real-time games will emerge.
|
|
|
|
John is already working on id's next graphics engine, code-named Trinity
|
|
and targeted around Christmas of 1998. Trinity is not only a
|
|
hardware-only engine, its baseline system is a Pentium Pro 200-plus with
|
|
MMX, 32 MB, and an accelerator capable of at least 50 megapixels and 300
|
|
K triangles per second with alpha blending and z-buffering. The goals of
|
|
Trinity are quite different from those of Quake. Quake's primary
|
|
technical goals were to do high-quality, well-lit, complex indoor scenes
|
|
with 6 degrees of freedom, and to support client-server Internet play.
|
|
That was a good start, but only that. Trinity's goals are to have much
|
|
less-constrained, better-connected worlds than Quake. Imagine seeing
|
|
through open landscape from one server to the next, and seeing the
|
|
action on adjacent servers in detail, in real time, and you'll have an
|
|
idea of where things are heading in the near future.
|
|
|
|
A huge graphics challenge for the next generation of games is level of
|
|
detail (LOD) management. If we're to have larger, more open worlds,
|
|
there will inevitably be more geometry visible at one time. At the same
|
|
time, the push for greater detail that's been in progress for the past
|
|
four years or so will continue; people will start expecting to see real
|
|
cracks and bumps when they get close to a wall, not just a picture of
|
|
cracks and bumps painted on a flat wall. Without LOD, these two trends
|
|
are in direct opposition; there's no way you can make the world larger
|
|
and make all its surfaces more detailed at the same time, without
|
|
bringing the renderer to its knees.
|
|
|
|
The solution is to draw nearer surfaces with more detail than farther
|
|
surfaces. In itself, that's not so hard, but doing it without popping
|
|
and snapping being visible as you move about is quite a challenge. John
|
|
has implemented fractal landscapes with constantly adjustable level of
|
|
detail, and has made it so new vertices appear as needed and gradually
|
|
morph to their final positions, so there is no popping. Trinity is
|
|
already capable of displaying oval pillars that have four sides when
|
|
viewed from a distance, and add vertices and polygons smoothly as you
|
|
get closer, such that the change is never visible, and the pillars look
|
|
oval at all times.
|
|
|
|
Similarly, polygon models, which maxed out at about 5,000 polygon-model
|
|
polygons total—for all models—per scene in Quake, will probably reach
|
|
6,000 or 7,000 per scene in Quake 2 in the absence of LOD. Trinity will
|
|
surely have many more moving objects, and those objects will look far
|
|
more detailed when viewed up close, so LOD for moving polygon models
|
|
will definitely be needed.
|
|
|
|
One interesting side effect of morphing vertices as part of LOD is that
|
|
Gouraud shading doesn't work very well with this approach. The problem
|
|
is that adding a new vertex causes a major shift in Gouraud shading,
|
|
which is, after all, based on lighting at vertices. Consequently,
|
|
two-pass alpha lighting and surface caching seem to be much better
|
|
matches for smoothly changing LOD.
|
|
|
|
Some people worry that the widespread use of hardware acceleration will
|
|
mean that 3-D programs will all look the same, and that there will no
|
|
longer be much challenge in 3-D programming. I hope that this brief
|
|
discussion of the tightly interconnected, highly detailed worlds toward
|
|
which we're rapidly heading will help you realize that both the
|
|
challenge and the potential of 3-D programming are in fact greater than
|
|
they've ever been. The trick is that rather than getting stuck in the
|
|
rut of established techniques, you must constantly strive to "do better
|
|
with less, in a different way"; keep learning and changing and trying
|
|
new approaches—and working your rear end off—and odds are you'll be part
|
|
of the wave of the future.
|