David Perry
Game Developers Conference, 1998
David spoke at the 1998 Game Developers Conference of Shiny’s experiences in moving from a 2D company to a 3D company and investing very heavily into 3D engine technology.
(Editor’s Note: You can order this speech on Audio Tape
from the Game Developers Conference 1998 by calling: (858)
483 4300 and ask to buy Tape #43, or purchase it online at
http://www.tsok.net)
INTRODUCTION
Here today to talk about a new 3D engine technology, we have
David Perry.
David was born in Northern Ireland and sold his first game
about 16 years ago. To date, he has written books and has
programmed about 37 published games so far. They include ‘Aladdin’,
‘Earthworm Jim’ & ‘Teenage Mutant Ninja
Turtles’ to name a few. Now he is the President of Shiny
Entertainment, who are based by the Ocean in Sunny Laguna
Beach, California.
Last year at C.G.D.C., he shared his experiences as Shiny
invested into the field of character licensing, by explaining
how to exploit your games to get Television shows, comic books
and toylines from your video game characters.
This year he will share some interesting experiences in moving
from a 2D company to a 3D company and investing very heavily
into 3D engine technology.
Also
on the stage is "Saxs", he is the lead programmer
of Messiah and will explain in great detail how he has overcome
the major hurdles in getting this exciting new technology
working at Shiny. We welcome David Perry & "Saxs".
THE SPEECH
Hi everyone!
Last year I spoke about character licensing. I talked about
how to milk your characters for all they are worth. I explained
how to close difficult deals that sometimes seem impossible.
My goal was to save you money and more importantly, to help
you spend as little time as possible with attorneys. I did
not try to sell anything, I just provided information. That
is why they have invited me back again.
Today, we will show you some of our work. But I can promise
you, this in no way will become a sales pitch.
As everyone here is not a low level 3D Engine programmer,
I will attempt to explain the concepts behind what we are
up to. Then Saxs here, is going to give a very detailed, very
technical demonstration of the Messiah technology. Then at
the end we will answer any questions you have. So hopefully
this speech will have something for everyone here.
There are teams here today that are working on similar projects
right now. The good thing is that we all seem to be identifying
the same problems. The funny thing is, that seems like we
are all finding very different solutions to those problems.
So to be clear, this is not a discussion on the BEST or the
ONLY way to do things, we are just willing to reveal OUR solutions.
So my goal is to share ideas that might save you some time
or frustration. My other goal is to draw your attention to
characters. I care passionately about characters. Yet, like
most other developers we found ourselves focused on backgrounds
and lighting.
Then we realized how little attention our character technology
was actually getting.
The Messiah engine created that attention.
OK, SO WHY IS THE SPEECH CALLED "MESSIAH – WHAT YOU
MAY OR MAY NOT BELIEVE?"
The reason is simple. I did private demonstrations to worldwide
magazine editors during the 1997 E3 show. After my demo, I
challenged them to find any better technology. They could
not. This created hype in the press.
Now at the same time, I happened to mention that I was thinking
about PATENTING this technology. The word spread like wildfire.
And PATENTS amongst programmers are like SWEARWORDS.
So the result was that I got flamed left and right. I had
programmers saying "That Dave Perry, he’s gonna
Patent FARTING next and then we won’t be able to fart
anymore."
Just for the record… I did NOT file a Patent. I have
been telling people this every chance I get. But today, I
still hear about companies telling the press, "We can’t
have infinite levels of detail in our game because that bastard
Dave Perry patented it."
So just to be clear, I did not apply for a PATENT!
That said, I did learn a lot about Patents in the process.
I also learned that Patents should not be ignored. It can
be very worrying when you see some guy patent concepts like
"Shadows in 3D worlds." As a result of all this,
I wrote an article in this month’s Game Developer magazine
to share my experiences on this subject too.
TO EXPLAIN WHY THE TECHNOLOGY WAS NEEDED …
I
WILL EXPLAIN THE BASIC GAME PREMISE.
We picked the name MESSIAH because in the Oxford English
dictionary it means the "Expected Saviour of the Oppressed".
In the Messiah game, you control a little overweight cherub
Angel called Bob. He was been sent down from heaven to clean
up the disgusting world of the future.
Being
a baby, he is kinda chubby and delicate, just about everything
hurts him.
But he has two neat abilities:
- He can fly and glide around with his stubby little wings.
- He can dive into the souls of his enemies or even animals
in the game.
This means that you can actually play anyone in the game.
Every time you play, you can choose a different route through
the bodies.
Giving
people choices means that the strategy evolves for free. When
Bob is inside their souls he can use and ABUSE their bodies
as armor or as camouflage. However if they die whilst he is
still inside, then he dies!
SO WHY NOT JUST USE A REGULAR 3D ENGINE?
Here is an example: if Bob needs to get past a huge raging
fire, he can jump into someone’s body, by entering through
their back, and then just walk on through the fire, dumping
their screaming, burning body on the other side. If Bob needs
to disable a guard, he could jump into his body, walk up onto
a high catwalk, then step off into space. The guard would
fall and break his legs when he hits the ground. Bob would
jump out and just leave him there rolling around the floor
in agony.
Imagine disabling a guy by blinding him, and then continuing
to play in that room whilst he is staggering around the room
trying to find a door.
So basically, our goal was to get away from games where the
place is empty when you shoot everyone. Instead, we want to
make a game that feels really chilling.
So basically the concept for Messiah is DISABLING some of
your enemies… Not just shooting everything and clearing
out a map.
OK, SO THAT’S THE GAME CONCEPT, HOW DOES THAT AFFECT
THE ENGINE?
- You get VERY close to characters. In certain parts of
the game you actually hide in groups of people as you pretend
to be one of them. - A common technical hurdle in game design today is trying
to stop the gamer from shooting everyone on the same spot.
If the game keeps bodies laying around, the pile of bodies
would quickly bring an engine to its knees. That’s the
main reason shooter games make the enemy explode and disappear.
Or in some games like Turok, they melt into the floor and
disappear.
Our problem is that we need characters in groups, some might
be burning and some might be crawling around the floor. We
also want you to be able to drag these bodies around so that
you can hide them. We even want the police in the game to
carry these bodies away from crime scenes.
So basically for this Messiah game to exist, and by forcing
all these problems, a new engine just HAD to be created.
WHAT WAS THE GOAL OF THE ENGINE?
Our overall strategy for the Messiah engine was to bridge
the gap between slow and very fast machines. Shiny has many
European staff and as a company goal, we absolutely focus
on the world market. Our first PC and also our first 3D game,
MDK was a good example, as it hit No. 1 in ten different foreign
countries.
That said, when I travel to some countries I hear some very
scary conversations. Things like, "I’m thinking
of upgrading my Sega Master System … I am going to buy a
Sega Genesis." Or, "I am thinking of upgrading my
PC … by getting a CD-ROM drive." Some of these countries
are very behind in hardware.
Then recently, I was totally convinced that a problem existed
when Shiny ran some focus tests. When asked what machines
they had, the response would be "133… 166…"
And only 1 in 8, even in high income areas actually had a
3D card in their PC.
It sounds kinda funny until you realize that some teams here
today have publicly stated that the games they are working
on now, will only run on machines that are 200Mhz or faster,
WITH an installed 3D accelerator card.
This decision tends to be based as a response to the incredible
PR from 3D Chip manufacturers, and from microprocessor companies.
Because, after all, they need your games to sell their new
hardware.
The problem is, that in America, we hear their hype so often,
and because they are so aggressive in advertising, we naturally
start to believe it.
So until all countries have 3D cards, and all laptops have
3D cards, and all companies cannot buy their employees machines
without 3D cards, Shiny will continue to support 3D engines
in software also.
NOW THAT SOUNDS GOOD, BUT DOES THAT MEAN THAT THE GAME
WILL SUCK IN SOFTWARE?
The answer is NO as the core structure of the Messiah engine
is 100% SCALEABLE.
 |
 |
 |
The word SCALEABLE is something you are gonna hear a lot
of in the next few years. When the microprocessor companies
saw our demo, they all revealed that this was the holy grail
for them. Same for the 3D card companies.
Now the funny thing is, that all veteran game programmers
have been writing scaleable code for years. Back then they
did it because they had so little horsepower to work with.
A good example would be if an explosion occurred, the number
of fragments they would generate would be based on how stressed
the processor is at that time. This is still a good procedure,
but the biggest savings today can come from handling every
polygon in the game, using exactly that same principle.
This
scaleable changing of polygon detail is called Tessellation.
Today, most games store just a few different versions of
each character in the game. Each version is much less detailed
than the one before so if the character is far away, the game
will use the least detailed version.
The perfect solution would be to make these adjustments in
real-time. Then as characters move in and out of the screen,
they would do it perfectly smoothly by adding one or two polygons
each time they step towards you. This would stop that "graphical
pop" that currently happens as the more detailed versions
suddenly get used. Smooth scaling also means, that at any
instant, the game is only doing the minimum amount of work,
to make a character look its best.
This method also means, that you would just have to make,
and store, ONE version of each character.
Now here’s the problem. It’s easy to divide polygons
into two to make more. But to actually improve the shape of
the person as you divide up the polygons is very complicated.
The same problem occurs going the other way.
SO
HOW DO YOU CARE ABOUT THE SHAPE OF THE BODY?
First thing is to stop storing characters as polygons.
The engine must come up with real-time generated geometry,
but also caring about the person’s anatomy. This is not
a mathematical equation, this is a realistic solution. We
really do have to worry about someone’s body structure.
Imagine if the equation suddenly decides to lop off a shoulder
or the person’s nose. The ‘damage control’
tweaking you would have to do to your equation would NEVER
end. So to be more clear — the first hurdle is not to dive
to equations, it’s to know that equations will NEVER
get it right.
You need a REAL solution. And that means a storage format
where you describe how important every part of the body is.
Basically,
you need anatomy rules and regulations. The final engine has
to fight to save that nose by stealing polygons from under
arms, behind the back, until the last possible instant. When
you don’t worry about anatomy, the result of these equations
tends to be a character that seems to boil as they move in
and out of the screen.
Using our method, each of the characters in Messiah are modelled
in about 500,000 polygons in 3D Studio Max 2 before they are
anatomically compressed.
The exciting thing is that the Messiah compressed format
regenerates the number of polygons that the game requests
each frame. So if you were to suddenly produce some drop dead
PC with a drop dead 3D card combo, Messiah would immediately
push it at 100%.
This means that you would be playing with new polygons that
we at Shiny have never seen during gameplay. Actually, we
will be proving this point later on today, as Intel actually
have put a liquid-cooled 650Mhz Pentium machine on their booth.
Frankly, pushing the hardware always at its limit, really
is a beautiful concept. If the machine thinks it could handle
another 50 polygons this frame, the engine will generate them.
The reality is that most old video games, are tuned to run
at a decent rate, taking into account the worst case scenario.
For example, in an old game when a BIG explosion happens after
maybe, two minutes into the game, the designer is forced to
cut everything back to anticipate it.
That means that during a lot of gameplay the machine is not
pushed to it’s limit until that big explosion occurs.
Even then when it does occur, often the game actually slows
down.
The concept of the Messiah engine is that it is monitoring
it’s progress all of the time. It’s always trying
to squeeze that last polygon out of the hardware. This is
a really nice thing to know. It also works on other machines.
Messiah on the Sony Playstation always has the maximum possible
hardware output on the screen, every frame of the game also.
If it needs more work to do, the engine serves up more polys.
If the big explosion happens, it steals polygons from all
the characters, but does not slow the game down.
That NO SLOW-DOWN translates to a great "Feeling"
game, and "Feel" is a very important aspect that
this engine gives back.
SO WHAT OTHER BENEFITS ARE THERE?
If you install a new video driver that has been optimized
maybe for MMX or K6, then again that extra bandwith is instantly
taken advantage of by the Messiah Engine.
What else?
Well, the good news is, that the day you stop storing your
characters as polygons… You give your animators new toys
to play with.
Because every polygon in the character is being re-generated
every frame, they can be stretched & modified, with little
overhead.
So what can you do with that???
You can make skin move, muscles bulge, faces distort, cloth
stretch, objects morph.
You
can EVEN make similar characters have different anatomical
characteristics, like a taller body or bigger nose than the
other guy. This dynamic re-generation every frame is called
Real-Time Deformation. I can tell you, It’s a lot more
work for the animators, but it really breathes life into characters.
We couple this with real time interpolation, this means that
the game can make up new animation frames whenever it wants
to. This is important because polygon characters tend to look
an awful lot better when they are moving. In real life, people
are always twitching, moving or at least swaying. So do plants
and animals. That is why subtle interpolation can also generate
a lot of life at little animation costs.
A good example in Messiah, is that when the baby notices
somebody he will look at them. This head turn is done by the
interpolation. It has actually improved the game because it
somehow opened up the field of view. By turning his head he
lets you know that somebody is out there without needing a
super widescreen monitor. So this is another freebie that
you get when you move to real-time deformation.
Something else. In the storage format, as Saxs will show
you, the body is stored in parts. This allows you to control
and interpolate the separate parts. It also makes tearing
an enemy’s body to pieces very easy. So basically, one
part of a character can be doing one thing whilst another
part is doing another thing. A good example is the wings on
Bob. We don’t have to store Bob’s wings animating
along with every frame of his other moves. It’s all done
in software.
Now before the animators in the audience vomit because they
hate the concept of software messing up their animation, don’t
worry. We key-frame very heavily and keep it very controlled.
Animators will NEVER be out of a job. But that’s a separate
topic.
OTHER FEATURES SAXS WILL DEMONSTRATE…
Volumetric
Lighting. Here we do not just have model lighting, but true
volumetric lighting. For example, if you stick your hand into
a beam of light, just your hand becomes lit. We also have
projected lights so you can cast symbols on walls, etc. The
exciting thing about true lighting is that you can drag bodies
around and hide them in dark corners, or you can hide in dark
corners and then ambush your opponent.
We also have Texture video streaming. This means that we
can change textures in real time using the hard drive as storage
memory. The first thing we have done with this unlimited texture
memory is to show movies playing in real-time within the 3D
worlds.
SO WHAT ARE THE BIGGEST HURDLES?
The
big problem is that once you walk down this road, there are
no tools to help you. It makes you realize that with a technology
like this, the tools become the bottleneck. They are so important.
Saxs will show you the tools we are using today. As you will
see, they are already quite complex. Another problem is that
as our typical game model has gone from 700 to half a million
polygons.
Sure, we have happy artists, but our equipment purchasing
staff had heart palpitations as one day we had to replace
half the machines at Shiny.
Then, worse than that, all of a sudden, some low polygon
artists did not have the artistic ability to take such a great
step. Which meant we needed some new staff also! Our standard
artist’s machine is now a Dual 400Mhz Pentium with a
FireGL 4000 card and 512 megs of RAM.
The in-house custom tools are also built from scaleable technology.
This real-time simplification allows the editing of these
extremely high polygon characters.
OK, THAT WAS THE REASONING, NOW ON TO THE TECHNOLOGY DEMO…
We are not showing gameplay until E3. But the engine is
pretty solid now. I am going to run an overview video first.
Then Saxs can get technical.
FINALE
So basically, we are just touching on the beginning of scaleable
technology. Shiny is currently investing heavily into this
future. I also urge you all to consider the world market as
you code. And I urge you to share your solutions to these
problems with us all next year at CGDC.
On behalf of Saxs and myself, thank you.
