"A game engine that allows players to make persistent changes to terrain may require a lot of data download before a particular place in the world can be correctly displayed. I would like to minimize the time it takes from a player deciding to teleport to a spot, to the player being able to enter and walk around that area in the client in a shared instance."
This one is an aspect that would have to be handled (for teleport or just a login at that location). The term 'instance' I suppose would also cover a one copy world state bubble. Instance = 'realized' = expanded to working data...
The feature I did mentioned was having on-the-fly generation of these world locations (so a huge world can be stored in template IDs+coefficients and not as fully realized data) -- not so much having multiple instances of the same quest in the same world location so other players dont interfere with choreographed scenes -- which in some games is what they mean by 'instance')
Obvious solution is predownloaded (to client) of templated (bulk) data and smaller (near immediate)transmission of template mutation data(modifying factors/parameters/coefficients) with the full data being realization on the client for rendering/pre-collisiontest,etc. I mentioned additional cumulative delta patching of that 'base' realization being sent to change the final full data to reflect historic modification (player effectiong the world - causing deviation from the initial 'base' data ) to sync correctly with the state in the server.
The servers master data itself may be 'rolled' out of memory when vacated and collapsed back to the template+coefficients+deltas (maybe with additional ones accumulated via further player(s) actions) OR perhaps eventually deciding to just save it verbatum (full realized data image) once all those deltas get to be too many and there is little compression effected.
(I actually thought of game mechanics eventually 'healing' those player caused deltas so that it could again be reduced to the template+coefficient compressed storage -- especially is a HUGE world where its possible no player may ever visit it again and the full data storage is wasteful) Often there are also 'insignificant' changes that can be ignored and purposefully lost by the re-compression (only significant deltas would be saved)
"A game engine that allows players to make persistent changes to terrain will run into degenerate terrain edits, where players will attempt to tunnel infinitely deeply, build elaborate sculptures with evacuation masses and debris, and use terrain modification for griefing. I would like to minimize the impact of these problems without giving up player editable terrain."
"degenerating terrain edits"?? hmm distortions of the mechanics that cause problemaitc situations. Minecraftisms. Well the system I would design wouldnt allow such things. The server arbitrates all compound modifications and cases of hitting limits handled logically (crossing zone boundries and such covered). So is solved with proper game mechanics and not really part of the data replication and update transmission mechanism.
World state Deltas conversions/compressions are run on locked down/settled data when 'rollout'/collapsing takes place (no players present, no unresolved modifcations pending).
Server on-the-fly sync 'save' images though -- use briefly locked down zone for snapshot or somesuch (compression from second buffer).
"A game engine that allows players to make persistent changes to terrain may have players on high-end hardware make changes that are very detailed and render/simulate fine on their hardware, but a player connecting through a mobile phone will not have the same rendering or simulation fidelity; I'd like to support cooperative play without unnecessarily limiting the higher-powered hardware to the lowest common denominator; how can I do that?"
Mismatched hardware target for client machine problem. Solution dont allow(or disuade attempts to) play on systems below minimum requirments.
Simulation on server goes thru as normal (full detail), sub-par hardware client may choke on mass of data thruput (heh, may not fit the dictionary/atlas disk space needed for the templates or load them fast enough) or have enough CPU for client realization/expansion processing or even proper/timely rendering --- as they fail already on many MMORPG games.
Simplification of data features already on some existing engines.but if 'very detailed' game data being presented are important to game (faces in LA Noire??) are LOD'd/simplified out then again sup-par hardware has to be identified by developers and user told up front that it wont be workable.
Part of a MMORPG (of this kind Im asking about) actually could have RTS elements which would have 'views' into the game with tablets/palmtops for certain (non-3D FPS) aspects and would provide a suitably simpler RTS 2D interface for monitoring/controlling NPCs tasks/projects and minigame puzzles and ingame mail/AH -- while the player is not on their highpowered client box.
That brings up a whole other issue of (advanced AI driven) NPCs running sometimes in full 'realized' detail (when players are near) and other times in an 'abstract' simplified manner (still carrying out tasks/projects but not needing the full world detail where they are - server zone's simulation may be running in generalized/abstract mode to lower processing load)