   Noob question on MMO data flow
  Hi All, in preperation for my Uni course in Computer Science in September, I've been looking into game development in Java. I'm using JMonkeyEngine, and considering having a play with Darkstar (when I understand enough).I've got a load of game programming books which I'm reading through, but only one MMO orientated publication. I have a question that's not covered, that is if I wanted to have a changing and persistent world, where objects could be created in-game with an editor, how would I go about updating the client when new game content is available?I had a thought of loading the world in areas, and passing all the 3D info to the client straight from the server in lists and arrays, all that's really needed is vertex lists and texture values as far as I can see it, would this take up too much bandwidth? I want to avoid long loadup times, and thought a streaming model where data is loaded dynamically and built on the fly dependent to proximity to the camera would be good. I want to keep all 3D model info on the server, and not within the client or the client terminal basically.If anybody knows ways this is currently achieved then please enlighten me, I'm a keen noob and nothing more at the mo so don't know much at all :)   
  I've seen a number of MMOs that bring down and patch the servers. Afterwards, the servers refuse connections from the old client version, so you end up having to patch the client, too. This is often done automatically - the game client starts the patching process when it connects to the server and is told that it's out of date.Guild Wars seems to do something similar to what you're thinking about - although all the data (about 4 GB, iirc) is kept locally, there is often a long download (5-20 MB or so) when entering a new area, so I'm guessing that it's getting updated area information from the server.   ;  Some MMO (I forget which it was) employs a hybrid method in which the client is patched while the game is being played. That is, new content that is relevant to the user is  streamed based on proximity. As for storing all the 3D models on the game server, I find it hard to see why doing so would be necessary. Most of your artwork is unlikely to change after being uploaded and put into the game anyway -- why not store it in the client and save expensive bandwidth?If you also intended to stream terrain this way (vertices and texture data) you might want to consider using height maps instead. A typical height map will use much less space than if you were to stream the same terrain converted to a real mesh.   ;  There are a few different ways. In the Second Life system, all the data is server side (including animations!) and data is streamed to the client as it becomes visible. This is very bandwidth intensive, but the "general case" and the "dynamic case" are handled the same.In most other systems, there is some set of "base" data, and changes to the agreed-on base data are streamed to the client as the client comes within range of the area in question. Thus, there may be a park and a grove of trees in the pre-installed data, but if a user builds a house, the house is sent when you get within visibility range; if some player has cut down the trees, a "delete object" command is sent for the treeswhen the viewer gets within range.In traditional MMO systems, changes are only updated in offline patches. This does not allow easy used edited things.;  Yeah I was wondering how the Second Life system worked, and I'd guessed right. I do want to make things editable, but I find Second Life's system to have too many failings, and if I ever do make a game (hopefully), I want some degree of editability in it, but a little more regulated than Second Life.I think sending patches when new objects come into view is the best bet, and keeping bandwidth down to an acceptable level by using this system would be good. I don't mind having models on the client terminal I suppose after all, just as long as I can edit and add stuff in-game from and on the server.Thanks for your answers guys, very helpful, and much appreciated :)   ;  Eventually the games will have to do some kind of terrain/scenery/assets push 'on the fly' (with some kind of client storage building to prevent needless resending).Future games (someday over the rainbow maybe) will leaverage on continually added player created content OR even just generated on the fly content.   And it wont be just terrain meshes/textures but 3D models/animations,  music/particle effects/video clips, and possibly AI scripting for in_client use  (client runs AI of 'pets'...)Keeping the content loaded ahead of the players movement of course, but also having adaquate LOD placeholders for those situations when the bandwidth has to lag the currently needed previously unseen assets (sucks too much to artificially prevent crowds as they do in many games...).[Edited by - wodinoneeye on May 9, 2009 5:30:19 AM]