the bane of a game players life. Some ISPs get all upset about
the idea of people playing games using their precious bandwidth
that they actually use Packet Sniffers. These are programs that
scan the packets going through the network looking for Quake game
packets, and when they find them, they kill them dead. What a
bunch of spoilsports. I'd be interested to know exactly how they
know these packets are Quake packets, since packets can contain
anything, but apparently there are programs like this out there.
the other big bit of bad news about ISPs is their server load.
The way that modem banks work is that all the modems tie into
one large pipe that goes into the main host machine that then
forwards these packets to the Net itself. Now, the lower the spec
machine that is used for the hosting, and the larger the bank
of modems attached to it, the longer the response time is on both
packets going in and out of the machine. Fairly obviously the
main pipe is only so wide, with the upshot that once it's full,
your modem waits. Of course this doesn't just apply to the ISP
machine, this can apply to any of the routers on the way and also
the destination machine too - we've all seen those download problems
on machines that have something popular on them. This means that
you may be connected to a 56k modem, but you're only getting 28.8
performance out of it, due to limitations beyond your control.
And this sucks. Some ISPs are worse than others, with cheap crap
modems that drop the connection and stuff like that. I won't mention
AOL here. Again, all you can do is just shop around.
coding in the game.
pretty much all we as developers can do to accommodate the intricacies
of the Internet, but there is a surprising amount that can be
done. Reading all of the other points kind of makes you wonder
how online real time gaming can ever be done at all, but it has
to be said, the net works more than it doesn't. We'll discuss
some of the cool things that can be done programming wise in a
second, but first, we'll look at some of the no-nos.
up is the use of TCP/IP as your main protocol. I've already explained
why this can be (and usually is) bad news. It is often used during
game setup to ensure all players have the correct starting data,
before we start the game data flowing.
packet bloating. You have to be careful only to transmit that
data that is required; otherwise you are just sending data for
the sake of it. The larger the packet you give to the UDP system,
the more you are asking the network to handle. This has a big
impact in client/server setups when your packet gets to the server,
since YOU are only transmitting one packet, but the SERVER is
receiving many such packets. This also impacts modem bandwidth.
If you are running a 28.8 and getting a pretty good sustained
throughput, you need to be sure that you are not allowing the
packets to exceed what it's possible to push through the modem.
Too big = packets getting shunted into a buffer while the modem
struggles with what it's got to send, and eventually the buffer
overflows and you end up at a crawl, assuming the game hasn't
packet frequency. Are you expecting packets to be sent faster
than the communications infrastructure can really handle? You
may be running at 60 frames per second, but you can bet that the
Internet will have trouble sustaining that kind of packet rate.
is handling packets that are out of order (assuming you are using
UDP) and dropped packets entirely. This is more involved and requires
you to be cleverer than you might think. However, if you don't
handle it right, you end up with missing events, missing entities,
missing effects, and sometimes, completely FUBAR'd games.
there is the aspect of online client cheating to consider. With
the CPL and other frag fests offering cash to winners, this is
more important than it used to be.