OK this may seem like a strange question as its not about programming but what are the actual areas which are ''problem'' areas in writing Network Computer Games? I ask this because I am looking to do a research degree in the are and am currently trying to come up with a good topic... In my experience in the area the areas are (in no particular order/rank): 1) Bandwidth Utilisation & Optimisation - Make the best use of your bandwidth: compression, streaming, sending only the required data to clients/peers. 2) Object Distribution & Synchronisation - Quickly distributing new game objects or syncing existing objects to clients/peers as quickly as possible using the minimum amount of bandwidth, memory and CPU time. 3) Server Farm Integration - Running one Game world/universe across multiple game server PC systems, moving clients between game servers. 4) Security - Techniques to make hacking of game servers/clients as hard/difficult as possible without consuming large amounts of CPU time. Please feel free to change this list as to what you think is the key problem areas. Cheers, Convict@Large "I code therefore I am" Anon

Addressing in order:

1) You can usually figure this out quickly and minimize bandwidth to within 20% of optimal before your product goes live. It doesn''t take too long to find out what information is unnecessary and only send that information when it''s absolutely needed.

2) This is really part of #1. As soon as you can implement some kind of prediction software on the client side and only update when status changes, or once per second, you''re pretty good with this. Oh yeah, don''t use TCP... too slow.

3) Hmmmm... hard to discuss this in-depth without giving away too much, there are several ways to do this, from Everquest''s method (probably one of the worst) to the methods that DAoC and UO use (multiple servers synchronizing on an intranet), to any number of other methods. Do some research and interpolate from what you read what they are probably doing. Not many people want to discuss their internal architecture.

4) In MMOGs the client should ideally be a simple display medium and the server should do most of the work. There are ways to hack the system, but the fact that it''s usually more work than it''s worth and likely to get you caught and ''banned'', it''s not usually a good idea. In normal networked games (diablo, Quake, Unreal, etc...), the chance of getting caught is much lower and won''t usually end with anything other than getting kicked. Cheating is rampant and the best way at this point in time is the method that Blizzard uses, update often to get rid of the cheats and only allow people on the latest version to connect to avoid all but the latest cheats. Since none of the actual game logic resides on any centralized servers, it''s much harder to catch people cheating in these games. Centralized servers are the best method for avoiding cheaters.

One of the larger issues for MMOGs is dealing with the databases. These are monolithic objects that require amazingly powerful machines and more powerful RAID drives. Implementing a fast database that several servers will be accessing commonly several times per second, across dozens if not hundreds of tables is more than a small task. Then you have to manage backups, ensure that if a couple of drives die on your main RAID that it will automatically kick over to a secondary RAID that is just as powerful, that you can rebuild that first RAID on the fly without killing the performance, that you can back it up consistently and reliably, that you can restore portions of the db very quickly, that you can track db objects through transaction logging without killing the performance of the server, etc...

MMOGs are basically big database games. You have to minimize access, but keep the information upto date. You have to get high performance, but add features like transaction logging and stored procedures which degrade performance. The database management for an MMOG is nothing short of a juggling act. I''m guessing that it''s why EQ uses the method that it does, for database integrity and because to increase performance to an amount that would be respectable at the time of the game''s creation would have required some things that really weren''t reasonable at the time, but have definitely come down in price recently. Remember, EQ is basically a 5+ year old game.