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 


“You’re only as good as your tools” goes the old saying. Well, it’s not strictly true, but its pretty close. The quality - ease of use, reliability, expandability, intuitiveness and so on - and relevance of your tools is often reflected in the quality of the work got out of them. Having the correct tool for the job is essential to getting top quality work out of your artists and designers. Quite often, we will create a plug in for a commercially available tool to do something specific that we need. For instance, we would create a special plug in for 3D Max Studio to allow us to manipulate a model in a way that the original was never designed. WE need this feature, but most people out there don’t, which is why it wasn’t in 3D Max in the first place. There’s another phrase which is applicable here ‘If the only tool you have is a hammer, you tend to treat everything like a nail’. Sometimes, we will create a totally new tool ourselves when nothing off the shelf is flexible enough for us to modify it to what we need. We aren’t shy about doing that, since having the correct tools can often mean the difference between and OK title and a Great Title. Often, creating specific tools can make your game stand out from the crowd, since it makes doing something hard really easy. For instance, we created a specific tool to modify and import our motion capture data for our game SOF. And as a result, we have lots more motion & cooler looking animations than anyone else, and it’s because we have a cool tool that makes creating these animations easy for our animators.


In case you've been dead for the last 5 years, you'll know that there has been a revolution in network online gaming. The Internet is in part responsible for this, but it did come along before the Internet had made it big, witness Doom, and so on. Since the Internet became the preferred method of online play, most games support some kind of multiplayer online option, indeed, these days you are looked down on if you don't support it. At the other end of the spectrum, there are id and Epic who are basing their content around network multiplayer -ala Quake III Arena and Unreal Tournament. They may have single player elements but that is decidely not the focus with these products. At the other end there is the persistent world brigade, IE Everquest and Ultima Online.

Anyway, in supporting network play over the Internet, you inherit all of the worst part of the aspects of the Internet, and almost none of the good. Some of the problems that you can tussle with include lost or mis-ordered data packets, horribly variable latency, synchronization, and user abuse. For those with no background, I’ll give you the quick two cent guide of networking. I have a much greater and in-depth lecture on this subject, but again, it’s up your professors to decide if you’ll get to hear it :)
Networking in games is loosely defined as the ability of a game running on one machine to communicate and share data with another machine playing the same game over a network (be it a LAN, direct modem connection or the Internet), so they can share a gaming universe and responses to it. What that means is that I can sit here, play a game of Quake on my PC, and at the same time you are too, and we can see each other as we play, talk to each other, and see our responses to each other and the environment.

This is vastly simplified, but you get the idea. How the game does this is the tricky part. The game has to handle sending out its world and client information – E.g. current player position, his current activity, health and so on, as well as receiving this data from the other game. Both games have to operating on the same frame, and often, if a data packet is delayed or lost from one machine to the other, there needs to be some mechanism to cope with this. Some Network protocols – notably TCP/IP – will take care of this for you, but at a huge cost in packet latency. TCP/IP guarantees delivery of packets in the correct order. If a packet is lost, then all outgoing packets stop, until the TCP/IP driver satisfies itself that the packet was indeed lost, and then sends out another one, and waits for an acknowledgement from the destination machine that it received that packet. In some cases this waiting time can take seconds – something you just can’t have in a fast response time game like Quake.

There are other Internet protocols you can use, - UDP comes to mind here – that don’t make these assurances for you, which means dealing with them is your problem. Quake gets around it by having prediction code in the game. If you and I are playing, and all of a sudden, some packets from you get delayed (which is effectively latency – this is defined as the time it takes for the data to get from your PC to mine, this can be variable over the internet) or lost, the game attempts to predict what you were doing. It looks at your last action, maybe you were shooting at me, and then traces that activity through to the end. Did the shot hit me? When the packets finally get through, the game looks to see if it was right in its predictions, and if it wasn’t, it adjusts the world accordingly. Obviously the prediction is not always right, and in these cases, you will see glitching of characters in the world – some one that was alive in ‘your’ version of the world is dead in the real world. However, since the prediction is right more than 50% of the time, its worth the code and time to do it. One notable draw back of prediction though, is that the longer you have to do it for, the greater the deviation between ‘your’ universe on your machine, and the one in which all the other gamers are playing in. More than 3 to 4 seconds, and you will become hopelessly outdated. That sounds short, but in game terms, where you are dealing with 20 packets a second, that’s a lot.

Then there’s user abuse. When you get down to it, a network game is just the data packets that are sent back and forth. If you were particularly clever, you might write and editor that allows you simulate the game, and have your character always follow someone else, constantly gunning him down – or more realistically, make a modification to the game you are running that allows you to always see all the other players, or superimpose their locations on a Head Up Display. This of course, defies the point of playing against someone else, when you have an unfair advantage. There are ways and means of limiting this, but right now, that’s beyond the scope of this article.


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.