Lastly,
on the networking topic, theres the networking approach
to deal with. There are currently two major networking paradigms
out there, the Client/Server way, or the Peer-to-peer approach.
Client/Server architectures work like mainframe/terminals do.
The server is actually playing the game, taking the input from
your machine and dishing out the current state of the universe
to each client in turn. All your machine is doing is handling
the keyboard input, displaying what the server says you see, and
playing sounds. Thats about it. The Server is where all
the action is. The problems here revolved around having a large
capacity machine to actually run the game on. There is a reason
why Everquest, and Ultima Online, massive multiplayer
games with persistent universes are run on huge specially designed
machines.
The Peer-to-Peer
approach is a bit different. Every machine is actually playing
the game, all they do is share keyboard input and synchronization
data. I press a key, and it gets to sent out to everyone else,
and then I wait for everyone else key press, and then process
a universe frame. As you can imagine, this approach gives you
more problems with latency, but it has the great advantage of
not requiring a massively overpowered machine to run the game
on.
You can
imagine there is a ton more to this, Ive barely begun to
cover the problems in creating a fast multiplayer online game,
or the techniques we use to over come these problems.
Differences
between PC, Arcade & console development.
Firstly
Ill contrast PC verses Arcade and Console, since they are
so similar, then Ill contrast Arcade and Console.
Well,
there certainly are differences here. There are several immediate
levels of difference at first glance. The first is the most obvious
no networking. Most consoles dont have networking
capabilities, so you are only developing single player games.
No worry about all that we just discussed. There are some Client/Server
implementations though, of games that allow multiplayer on-screen
play. Racing games are a case in point. Its worth noting
though that with the introduction of the new Consoles, namely
Segas Dreamcast and the new Sony Playstation 2, this will
not always be the case. Both are being touted as Internet ready
machines, so you can not only play games on them, but do the whole
WebTV thing on them too. At that point, you know network gaming
is only a year away. I, for one, will be watching with interest
at the way that field develops.
The second
difference is scale. With a PC, you are supporting several scales
of CPU power. Look at Quake III Arena. It works on everything
from a Pentium 166 right up to Pentium III 550s. Obviously,
they want to get as much bang for their buck CPU wise, so the
game tends to scale itself to whatever machine it is running on.
Only got a P166? Fine, then all the models tend to be reduced
polygon sets, so as to keep the frame rate up. Looks like crap,
but at least you can play. Scalability tends to be mainly in the
visual effects area, since thats the area of code you spend
most of your time in. Reducing model poly complexity and reducing
out the number of particles you bang out when a crate explodes
as cheap ways to reduce load on the CPU, to enable faster frame
rates. But on a console, you dont need to worry about this.
Its the same CPU every time, which helps.
Similarly,
having a whole host of potential hardware configurations is also
a burden that PC developers must cope with. We already discussed
the different graphics APIs we have to deal with, as well
as sound systems. On a Console or an arcade machine, you know
your hardware, and its the same every time. No worrying
about whether this card supports 32bit z buffering or not. No
concerns about whether 3dfxs OpenGL graphics driver is fast
or slow, or buggy or not. its worth mentioning here that
Id say about 25% of the bugs that PC games ship with come
from manufacturer driver code that we cant do anything about.
On a console, thats a major worry lifted.
On the
plus side though, PCs do offer a couple of bonuses. They
are constantly evolving with new hardware that enables
you to do bigger and better things each time out. A console is
a console, and doesnt change from one machine to the next.
Your limits are your limits. And another thing thats nice
is the virtual resources. Running under windows means never having
to run out of memory :) When all youve got is 2 meg to fit
your code, your samples, your graphics and everything else in,
something has to suffer, and its normally graphical and sound
FX quality. On a PC, that worry goes away, which is nice :)
One other
thing the PC offers thats nice is the chance to patch and
upgrade an already shipping product. With a console release, if
theres a bug there, then thats tough. You cant
upgrade a CD. With a PC though, you can patch and upgrade to your
hearts content though files made available on the Internet (Although,
to be honest, this does tend to get a bit abused at times, with
companies shipping products they know to be flawed, with the attitude
of Oh, well patch that later). And that leads
us on to community upgrading. Quake has an enormous community
out there that constantly provides homegrown modifications to
the existing Quake games, due mainly to the fact that its
a PC, and the fact that id has an open source policy. Cant
do that on a console or an arcade machine.