about feedback archives submissions

//loonygames://issue 2.8://Anatomy of a Video Game://1, 2, 3, 4, 5, 6, 7, 8
switch to printer-friendly version

What's new today:

The archives have been cleaned up, dead links fixed, and the printable versions restored! Also, don't miss the new comments on the main page!

Livin' With The Sims
theAntiELVIS explores the wild and wacky world that is Will Wright's The Sims, asking the inevitable quesiton, "is The Sims the first step toward a virtual life where everyone is Swedish?"

Pixel Obscura
Josh Vasquez on Omikron: The Nomad Soul.

Real Life
Check out our newest comic strip, Real Life! Updated daily!

User Friendly
Updated daily!

Random Feature:

Search the Archives!

Anatomy of a Video Game

Vol. 2, Issue 8
January 10, 2000 


Lastly, on the networking topic, there’s 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. That’s 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, I’ve 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 I’ll contrast PC verses Arcade and Console, since they are so similar, then I’ll 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 don’t 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. It’s worth noting though that with the introduction of the new Consoles, namely Sega’s 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 550’s. 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 that’s 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 don’t need to worry about this. It’s 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 API’s we have to deal with, as well as sound systems. On a Console or an arcade machine, you know your hardware, and it’s the same every time. No worrying about whether this card supports 32bit z buffering or not. No concerns about whether 3dfx’s OpenGL graphics driver is fast or slow, or buggy or not. – its worth mentioning here that I’d say about 25% of the bugs that PC games ship with come from manufacturer driver code that we can’t do anything about. On a console, that’s a major worry lifted.

On the plus side though, PC’s 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 doesn’t change from one machine to the next. Your limits are your limits. And another thing that’s nice is the virtual resources. Running under windows means never having to run out of memory :) When all you’ve 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 that’s nice is the chance to patch and upgrade an already shipping product. With a console release, if there’s a bug there, then that’s tough. You can’t 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, we’ll 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 it’s a PC, and the fact that id has an open source policy. Can’t do that on a console or an arcade machine.


Next >>

about feedback archives submissions

Credits: Illustration © 2000 Durrenberger David (dines). This article is © 2000 Jake Simpson. All other content is © 2000 loonyboi productions. Unauthorized reproduction is prohibited. So don't do it, or we'll dissect you.