Here''s the loose ideas I was having.
The idea for how gameplay could present itself came from Dungeon Siege. It''s not a very entertaining game :\ but it has a ''seamless world'' - you have to walk everywhere and the system only bothers with what''s around you. (Teleporters are few and take several seconds to use, giving time for game state to be determined.) It also has ''fire and forget'' play - click on an enemy and it will automatically keep attacking, rather than you having to swing and aim each blow.
The main influence on architecture is being open source.
You''ll get a lot of modifications, extra equipment, and so on. Ideally, the client should have an extremely modular design, so that if someone produces code to, say, ride horses, this could either be included in the client very easily, or better yet downloadable through the network.
I have the idea of a background file-sharing service, similar to that in eDonkey, etc. All content has a hash which is used to uniquely ID it. Upon finding, that, say, model HumanMale3 is invoking a ''cry'' animation, the hash is given to the client, who then proceeds to download it from nearby clients. How the system would cope with updated content - the model possessing the cry anim in the first place - not sure
Security becomes the main concern. Open source will lead to rapid dev but also wide open for exploits. The only way to do it, as others have noted, is to farm out all game-critical processing to another client, preferably as unrelated to the first client as possible (to avoid a party of defecting clients sticking together and handling functions for each other).
The content system will require a lightweight hashing mechanism. If you include a signing/encrypting mechanism too, you can have the client safely store backup data about itself and current state data about the world/other players without tampering. Messages can be piped through the system by use of public/private keys.
Nodes would take on primary redundant data storage for player/game state. Say current state in two adjacent nodes, with backups to randomly chosen leaves every few seconds. Computation (eg. hit/damage) is sent from leaf client to node, which then farms it out to more than one leaf (maybe dedicated to processing?) and confirms that both results are the same. (Although it may be simpler to just assume that if the node is legit to process the results correctly, you may as well trust it to do the calculations in the first place). Whatever, the task is calculated, game state updated, and client informed.
Rather than having many clients all trying to keep tabs on each other, you''re only dealing with an ad-hoc server, which is just receiving state updates and propagating its own. State updates would only exist for the local cluster (architecture stresses ''seamless local world'') rather than hundreds of spam updates. Once a node determines that a state update is too far away in the game world, it simply drops it. (Content distribution is not subject to this, though hopefully local leaves will be enough to get it.)
Each node keeps list of which node is handling which game area, laid out similar to network topology. It may work best as an interconnected set of small areas- similar to Ravenloft in D&D.
Each area is derived from a seed in a deterministic process. In principle, enough state data is redundant so that if a node goes offline before it can ensure its state data is mirrored, other clients can seamlessly (yeah, right!) take up the slack.
As for game balance, what''s to stop someone creating an uber weapon? Well, there could be pre-defined formulas, that works out minimum level depending upon game effects, or hardcoded client factors. Perhaps the best way is to update the main client with knowledge of all the mods and how to price/set requirements as needed. Imagine seeing in your inventory an item drop only for it to say ''Unrecognised Item - please upgrade client'' - that would help get version consistency!
Disjointed I know, but I''m not in the best of health.
Comments?
