IPX Network game questions

Hi all!! With the recent plethora of IPX compatible games released for us to have a ball with, a couple of questions have cropped up in my mind. 1. Is it necessary to be a Novell CNE in order to be able to write these games? 2. Why is it that the maximum number of players that can participate in a network game is only eight? Is it because of some incapabilities with IPX, or is it bandwidth, or is it driving net-admins nuts, or is it something else? I think it would be fantastic being able to race against 25 other human-controlled cars in an F1 race over a network (are you reading this, Geoff?) and having 40 players running amok in ultra deathmatch DOOM, Quake, or whatever ID can think of (Are you reading Michael, John, Joseph?) Thanks in advance, Cameron..

Quoted text (7 lines)

|>Hi all!! |> |>2. Why is it that the maximum number of players that can participate in a |>network game is only eight? Is it because of some incapabilities with IPX, |>or is it bandwidth, or is it driving net-admins nuts, or is it something |>else? |>

I'm just taking a guess here. I most network type game, there would be a game server somewhere in the network. Clients would just logon to the server if they ever need to play. So what the client would do is send a move to the server and get other moves (by other players). The server do most of the processing, working out the game rules, etc. The client would do most of the display. Now I believe that with the current crop of network games, there are no servers, so the client must be the server. This places tremendous processing on your client. So instead of have 25 people in the game and change DOOM to SNORE, these games just limit the no. of players. I am not a fan of these first person type game, so I cannot cite any examples.

Quoted text (10 lines)

|>I think it would be fantastic being able to race against 25 other |>human-controlled cars in an F1 race over a network (are you reading this, |>Geoff?) and having 40 players running amok in ultra deathmatch DOOM, |>Quake, or whatever ID can think of (Are you reading Michael, John, |>Joseph?) |> |>Thanks in advance, |> |>Cameron.. |>

------------------------------------------------------------------------------- |\__/| =~==== |****| | | ###### # ####### ##### # # # ####### |o**o| (=O==O=) # # # # # # # # # # # # |-\/-| | > | # # # # # # # # # # # | | | | ###### # # # # # # # # ##### __| == |___ == |__ # # ####### # # ####### # # # **\____/***\___/::\# # # # # # # # # # # # ************\:::::###### # # # ##### # # # ####### Lee Chuk Munn SunService Division Sun Microsystems of California Limited 22/F Shui On Centre 8 Harbour Road WANCHAI HONG KONG Voice: +852 2820 0186 Email: see 'From:' -------------------------------------------------------------------------------

No. CNE's design, install, and maintain networks. You just need to be a programmer, with experience on writing network apps. I would guess bandwidth. DoomII with four players, can sloooooow a network way down, so 25 players would probably kill it. I agree. Maybe someday. Mike

>With the recent plethora of IPX compatible games released for us to have a >ball with, a couple of questions have cropped up in my mind. >1. Is it necessary to be a Novell CNE in order to be able to write these >games? I doubt it. Take a look at Actua Soccer. At my last company we regularly had a 20 player game on the go. It seems to be a self imposed limitation on the part of the softies that the majority of games only run to 8 players max. Perhaps it's limitations with the game engine coping with all those simultaneous players. Who knows? One thing I do know is that you can bet any organisation that has 20 top flight PCs so everyone can get in on the action also has a few more PCs that could act as servers for the game. Maybe it's time to do dedicated network versions ala Hawaii? It'd be great :o) I'd never go home. -- Derek James

Nope ,that's bullshit. All you need is good refernce manual. Or some example- programs. Can give refs to sites ,where you can get them. I assume , that is because of speed of the computer. Standart network bandwidth is 10 mbit/s while modems are 14400 bit/s(about the standart). It is plenty. Hmm would be nice , but drivers are slow. When pentuium 120 will become standart evrywhere, then it will go up 20-40 connections. Also games have Servers and clients. So if 50 people will connect to a single 486-66, I don't 3d game will go very smooth. Just my opinion. Pavel. --- FEAR-false evidance approves real (604)595-7289 (604)595-0948 ask for Pavel... :-)

Quoted text (9 lines)

>>2. Why is it that the maximum number of players that can participate in a >>network game is only eight? Is it because of some incapabilities with IPX, >>or is it bandwidth, or is it driving net-admins nuts, or is it something >>else? >Take a look at Actua Soccer. At my last company we regularly had a 20 >player game on the go. It seems to be a self imposed limitation on the part >of the softies that the majority of games only run to 8 players max. >Perhaps it's limitations with the game engine coping with all those >simultaneous players. Who knows?

The problem is how fast network transmission grows with the number of players. (I have been out of school for a long time, so please flame me if I ***this up) Suppose there are n players. If each player make a move, and send that move to *all* the other players, the amount of traffic grows at the same general rate as n * n (called n-squared)... in other words, twice as many players is 4 times the trafic, 4 times the players is 16 times the traffic... 10 times the players is 100 time the traffic. It grows pretty explosively. Then there's the handshake problem that is related. If n people walk into a room, and everyone wants to shake hands with everyone else, but only once, it turns out the number of handshakes that actually happen are ( n - 2 ) * ( n - 1 ) Which is n * n - 3 * n + 2 and still a n-squared growth. My understanding is that there are better methods of network talk that don't have n-squared growth. But I could be wrong. Rob ------------------------------------------------------------- SOON I WILL BE JAVAMASTER [link lost in import: /~roby] I don't have to be enlightened... I only have to be more enlightened than *you* -------------------------------------------------------------

Quoted text (31 lines)

>The problem is how fast network transmission grows with the number of >players. >(I have been out of school for a long time, so please flame me if I >screw this up) >Suppose there are n players. If each player make a move, and send that >move to *all* the other players, the amount of traffic grows at the >same general rate as > n * n >(called n-squared)... in other words, twice as many players is 4 times >the trafic, 4 times the players is 16 times the traffic... 10 times >the players is 100 time the traffic. It grows pretty explosively. >Then there's the handshake problem that is related. If n people walk >into a room, and everyone wants to shake hands with everyone else, but >only once, it turns out the number of handshakes that actually happen >are > ( n - 2 ) * ( n - 1 ) >Which is > n * n - 3 * n + 2 >and still a n-squared growth. >My understanding is that there are better methods of network talk that >don't have n-squared growth. But I could be wrong.

Cool, I'll take your word for it. What I do know is that Actua Soccer caused no problems on a 10Mbit/sec network and Hawaii works over a dial-up link. There seems to be no reason apart from deliberate design why any game can't be made to work the same way. I'm beta testing the (as yet very flaky) Wireplay service here in the UK and I'm itching to get involved in some multi player racing. As yet, the only thing that looks at all promising is Nascar. Who knows when (if) it'll hit our shores? -- Derek James

In a server based model that wouldn't happen, the server can do relevance filtering.

-(I have been out of school for a long time, so please flame me if I -screw this up) -Suppose there are n players. If each player make a move, and send that -move to *all* the other players, the amount of traffic grows at the -same general rate as - n * n Only if you send the move to each machine. A general broadcast of the move would only have 'n' messages. I'm not an IPX programmer, know little about it and don't know if it allows general broadcast. So flame Rob if I'm wrong (he asked for it, look up there ^). -- Ron Whittle

>-Suppose there are n players. If each player make a move, and send that >-move to *all* the other players, the amount of traffic grows at the >-same general rate as >- n * n >Only if you send the move to each machine. A general broadcast of the >move would only have 'n' messages. However, a potential problem that I see is with the Ether - you tend to get this kind of exponential slow down as you add more players because of so many more collisions happening (see Binary Exponential Backoff). It would be interesting to see how well a networked game would work on a Cambridge Ring where there are no collisions & where you could take advantage of the fact that yoyu know how long it will take for your data to circulate around the network.

sorry but it's (1/2) * n * (n - 1). Try n=2 people... there should be one handshake. However, it is still O(n^2) (n-squared growth), like you said before. -- -Jim

: However, a potential problem that I see is with the Ether - you tend : to get this kind of exponential slow down as you add more players : because of so many more collisions happening (see Binary Exponential : Backoff). It would be interesting to see how well a networked game : would work on a Cambridge Ring where there are no collisions & where : you could take advantage of the fact that yoyu know how long it will : take for your data to circulate around the network. But since Ethernet uses a carrier sense, you ONLY get collisions when two stations begin to transmit simultaneously. While this certainly happens, it has been shown that ethernet is capable to delivering 95% of line speed, or 9.5 Mbit/s, at least. More than enough for a game. However, let's look at the real issue, latency. Games aren't the type of application that traditionally have large bandwidth requirements. They are very picky about packet turn-around tho. So, let's see... An ethernet packet is 64-1500 bytes. Most games don't even use 64 bytes per packet (DOOM for example). But, let's be conservative and split the difference, 700 bytes (way too much, but this is just to prove a point). If we do the math, we get a theoretical limit of 1785 packets/sec for 700 bytes packets. If each host needs 20 packets/sec each way (which is ridiculous because most good dead reconning algorithms don't use constant 2-way traffic), that still leaves us enough bandwidth to support ~45 hosts. And this isn't even considering 100BaseT or the new 1Gbit/sec ethernet. Ethernet is up to almost any game anyone will care to play for a while. By then, we'll all have ATM to our houses anyway ;) Steve

Quoted text (10 lines)

>>-Suppose there are n players. If each player make a move, and send that >>-move to *all* the other players, the amount of traffic grows at the >>-same general rate as >>- n * n >>Only if you send the move to each machine. A general broadcast of the >>move would only have 'n' messages. >However, a potential problem that I see is with the Ether - you tend >to get this kind of exponential slow down as you add more players >because of so many more collisions happening (see Binary Exponential >Backoff).

As the guy the wrote the first interrupt driven driver for a PC Ethernet Card (in the world) for the Advanced Technology Group of the New York Stock Exchange, I was specifically asked to address this issue in reference to Token Ring networks for the NYSE. Ethernet is more deterministic than Token Ring is, and it loads cleanly, without any Binary Exponential Backoff of the application level of the protocol. The Binary Exportional Backoff is only used in the case where an actual PACKET collision occurs, which would require that the carrier sense part of the protocol had actually failed. (CS/CDMA) This would only occur when the packet preamble collides with another preamble from another card, which by the nature of signal propagation and the definined maximum length of the wire in Ethernet, given a scenario of no packet switches or other devices, you have a possible window of opportunity of about 10 e-6 seconds for a Carrier Sense failure to actually occur. What this means is that once a card has established the preamble on the wire, the packet is typically guarenteed to be fully transmitted, unless there are cards that are misfunctioning or the wire has some sort of transmission problem. What that breaks down to is that with the interfame spacing, that the network will actually load up to about 9.6 Mb, with even sharing of the load and even access. There are not more collisions, since the cards will not attempt to transmit where a carrier signal is on the wire. The only time that the cards may actually have a collision is in a single phase of a single 20 M/cycle wave (manchester encoding is used to get to 10 Mbit.) unencoded wave transmission down the 1000 foot length of the wire. Since electricity travels at about 60% of the speed of light, Ethernet is VERY stable. So where a collision occurs is where a two cards transmit the preamble exactly at the same time onto the wire, (not very likely, since they see the end of the previous packet at slightly different times anyway). Of course, when a card fails, or isn't up to specification, or the wire is not within specification, there are other issues, but a clean Ethernet runs very, very well. That's what CS/CDMA is the access method used in the higher speed fiber optic networks. Token ring on the other hand requires that the token circulate and be free in order to add data to the token, and each card clocks the data off the wire and then back onto the wire. (At least the standard 4 MBit style..) So the latency is higher and the throughput is lower for Token Ring. (Which has been borne out in test after test of server performance on Token Ring and Ethernet) Given the actual fluctuation of Ethernet latency and the actual number of collisions that exist in a properly wired Ethernet network. There would be no discernable difference. Wilbur

Is there a specialized group to discuss this kind of stuff? Or we just stick to crowded rec.games.programmer?