Online and multiplayer games seemed to be a major theme at this year's CGDC (or maybe I just got that impression by concentrating on those subjects this year). Some of the foundational lessons seemed to be repeated by more speakers than last year.

1. The technical challenges of online multiplayer gaming seemed concentrated around shooting games in a three-dimensional world.
1. Constraints of the Internet environment.
1. Bandwidth
1. For most users, the slowest part of the link is their 14,400 baud or 28,800 baud connection. This places a strict limit on how much data can be exchanged per unit of time, regardless of other factors.
2. Latency
1. Latency means the time delay for the first byte in a packet to be received and available. For a message to be sent across the USA and acknowledged takes at least around 50 milliseconds, even at the speed of light.
2. Latency can vary a lot, even within the same connection. Dedicated connections (such as on Mpath, TEN, etc.) can help a lot.
3. Modems with compression or error checking enabled usually delay as they wait for a full packet to be ready for compression. Users can disable this.
4. Some socket connections perform "Nagling": saving up data for a larger packet, in order to make the most of the packet's header overhead. This can be disabled.
3. Reliability
1. If packet arrival is insured by means of a reliable transport protocol such as TCP, retries may make the transmission very slow.
2. If packets are sent by an unreliable protocol such as UDP, many packets may be lost (even well-aimed bullets).
4. Security
1. It is possible to view game data packets using other utilities, and to use this knowledge to generate fake data packets or to otherwise interfere with a participant.
2. Needs of the game genre: many independent, unpredictable players and objects in the game world. Each player needs to see the objects in his/her vicinity at all times.
3. How much data to distribute.
1. As the number of players and objects increases, the job of updating each screen becomes too large for the server to handle alone.
2. Although the clients only record a portion of the world's state, keeping them all apprised of news is still too much data to transmit.
4. Sensible (routine) optimizations.
1. Reduce the amount of data. This includes:
1. Let the server keep track of what each client system knows. Then the server need only report items that are truly news to each client.
2. Eliminate redundant data, such as player identification.
3. Compress data using standard techniques.
4. Combine data in to fewer packets, to make the most of each packet's headers and other overhead.
5. Distant objects don't need precise position information for adequate display.
2. Maintain frame rate regardless of data transmission speed.
5. Standard accommodations to the environment.
1. Security.
1. The server's copy of the data must be deemed authoritative in the event of any discrepancy. (Hackers can tamper with their computer's version of the data.)
2. The clients' IP addresses should be kept secret within the server. Otherwise a cheater could flood an enemy's modem with extra packets, temporarily immobilizing the enemy.
3. Validate crucial packets, such as bullets that force a win. These would be valuable packets to falsify.
2. Extrapolation of motion: Each client system must record some of the world's state: at least enough to update its own display. This reduces the need for the server to update everyone.
3. When a client must be informed that (because the news was slow) its view of the world is incorrect, this correction should be displayed in a way that the player can see what happened. (Otherwise sometimes an enemy can disappear when its position is corrected. Better is to move the image of the enemy quickly to the new position, so the player can see which way the enemy went.)
6. Devious compromises.
1. Slow vehicles, so there's plenty of time to keep all clients updated with everyone's position.
2. Slow projectiles.
3. Unreliable projectiles: This way, even if a player thinks he/she scored a direct hit (because of an out-of-date display) but didn't, the failure can be attributed to a faulty bullet.
7. References.
1. "Writing Multiplayer Games for the Internet," Jeff Rothschild, Mpath Interactive, 1996 CGDC Proceedings. (Mr. Rothschild spoke on the same topic in 1997 but no paper appeared in the proceedings.)
2. Online community dynamics. Interpersonal interaction is a major appeal for multiplayer games, yet it can also be a major turnoff.
1. Some principles.
1. Bullies and jerks can spoil the experience for players.
1. Offensive language.
2. Hackers and other cheaters.
3. Allow a safe setting for novices to gain expertise, instead of being killed right away.
2. Active supervision is necessary too keep things from getting out of hand.
3. Grant rewards, but don't award them too soon; save some as a motivation to continue.
4. A character's role and individuality can be an reward of a different kind from sheer power.
5. People sometimes build their own social structures. Promote this flexibility, because it makes the game world interesting.
2. References.
1. "The Lessons of Lucasfilm's Habitat" -- http://www.communities.com/paper/lessons.html.
2. Amy Jo Kim's lecture is at http://www.naima.com/cgdc/. Her principles seem thoroughly thought out. Her rough points are listed at http://www.naima.com/cgdc/pr-summary.html.
3. Miscellaneous nuggets.
1. The proceedings were much thicker than ever and the papers seem very meaty and accessible. They seem to be worth reading.
2. Michael Abrash's lecture on the Quake graphics engine is in the proceedings this year.
3. Comic Chat by Microsoft – a remarkable achievement. See http://www.microsoft.com/ie/comicchat/. Is their research paper on the Web?
4. Scott Kim's roundtable discussion on designing puzzle games. Notes and references are posted at http://www.scottkim.com/puzzles/.
5. Java optimization lecture by Bill Lee, BigByte Productions (blee@bigbyte.com). Bill mentioned most of these during his talk, and later sent the details via email.
1. General principles.
1. Don't optimize; at least put it off.
2. Synchronization consumes time.
3. Time the results on multiple systems.
4. See the event multicaster from the AWT source code.
2. Web sites.
1. Hardwick Java Optimization site: http://www.cs.cmu.edu/~jch/java/optimization.html
2. Doug Bell's benchmark applet: http://www.javaworld.com/javaworld/jw-04-1997/jw-04-optimize.html
3. Doug Bell Home page: http://www.2nu.com/Doug/index.html
4. Vladimir Bulatov's HyperProf: http://www.physics.orst.edu/~bulatov/HyperProf
5. Greg White's ProfileViewer: http://www.inetmi.com/~gwhi/ProfileViewer/ProfileViewer.html
6. Java as an intermediate language: http://www.cs.cmu.edu/~scandal/html-papers/javanesl/index.html
3. Books:
1. Concurrent Programming in Java: Design Principles and Patterns ( http://www.amazon.com/exec/obidos/ISBN=0201695812/8585-5270860-399757)
2. Tricks of the Java Programming Gurus ( http://www.amazon.com/exec/obidos/ISBN=1575211025/8585-5270860-399757)
3. The Java Virtual Machine Specification (hackers only?) (http://www.amazon.com/exec/obidos/ISBN=020163452X/8585-5270860-399757)
4. Java Network Programming http://www.ora.com/catalog/javanetwk/noframes.html ("O'Reilly has some good stuff, poke around on their site. Java in a Nutshell got me started and it's been updated to 1.1," says Bill.)
5. Object-Oriented Design Heuristics – ("This is a great book if only for the inside front and back covers," says Bill) http://www.amazon.com/exec/obidos/ats-query/2742-0219196-366709
6. Seamless Object-Oriented Software Architecture (Recommend for large projects) http://www.amazon.com/exec/obidos/ats-query/2742-0219196-366709
7. Design Patterns ("Recommend reading !!!", says Bill) http://www.amazon.com/exec/obidos/ISBN=0201633612/2742-0219196-366709

=== End of "Show and Tell from the CGDC" ===