Chuckles, you've basically described precisely how co-op works in SR2 & SR3. So to answer your question, yes, that would and DOES work quite well for open world multiplayer.
You seem to be hinting at wanting to mod in 2+ player co-op into SR2 or SR3, but honestly that's in the realm of the not possible. If the source code were available, it would be a difficult but possible problem to tackle, but without it would just be an insane to attempt.
That said, since you seem interested in this topic, I can elaborate a bit more on some of the specifics you point out...
Tulip, my Question, is could you have local loading f the map? I. e, instead of the host hosting the separate maps for each person, if the person hosted the map themselves, then was synched, that would save a lot of GPU. Or, when the person is connecting, send them a file to show the map state, and then they host it themselves.
This. Loading two sections of the world for one player would be just a horrendous waste of precious system resources for very little gain for either player experience (likely 0 gain for either player). So, each player streams the world around them as they would in a single player game. Usually we refer to the world as the static geometry and collision (buildings, streets, static objects, etc). Dynamic objects like vehicles and NPCs are a bit more complicated, but I'll touch those as well below.
Loading the world once instead of twice primarily saves system memory and disk I/O bandwidth (you have to load the city into memory from somewhere). It does save some GPU as well, but the rending engine is already optimized to use low LODs for far away objects or cull them out completely - so it may not be as large of a win as you might expect.
For the multiple person co-op (3+) Would you be able to set it so player 3+ has a standardized, preset outfit, with no vehicle customizability/ purchasing of property?
As was pointed out earlier in this thread, this was proposed and investigated as a way to reduce the co-op memory usage for customization in both SR3 & again in SR4, as a compromise to enable 2+ player co-op in some game mode(s). In the end, the team decided our efforts were better spent on other new features and 2+ player co-op was abandoned early in pre-production. Remember, 2+ player co-op has great technical as well as design ramifications. Memory needed for player customization is largely cited both because it was a major technical issue and because it is easy to understand, but in reality it was only one straw the broke the 2+ player co-op's back. With that odd sentence, I think we should move on...
But to cut down on memory used, would you be able to set it, so if a player is Far off (out of sight/ loading distance) That they stay connected through a pipe, in which when another player connects the enemies/ terrain/ etc etc. Only loads in for them?
Again, this is how dynamic objects work for the most part (even in single player!!). Pretty much every dynamic object (NPC, vehicle, trash can, etc.) in the game has 3 major states: active, inactive, and destroyed. Each object type manages these states internally to suite their particular requirements, but in general the states have the following properties. ACTIVE - The object exists in the world as a "real" object - it has collision and renders on screen (if it is a physical object). INACTIVE - the object exists in the world, but is not "real" - while it still processes it's state it does not have collision or render. DESTROYED - The object no longer exists in the world. Controlling how objects move between these 3 basic states allows us to have a dense world of active objects near the player, without blowing up the system requirements to run the game for all the distant objects. In general close objects are active, and far away objects either go inactive (until they get close again) or are just destroyed if they are not important.
In order to sync all these dynamic objects in co-op, SR games use a peer-to-peer architecture utilizing the concept of object "ownership". Each object in the game is "owned" by a single player/machine. The owner is the authority on the object and manages the object's state. In addition to handling the object's state, the owner will also send state updates to the other machine in order to sync the object. If the two players are on opposite sides of the city, typically each player would own the objects near themselves and send updates to the other player. If the players are close together, any object can be owned by either player. While ownership of a specific object can transfer from one machine to another, it will only be owned by one machine at a time.
This is a gross simplification of how co-op works, but it should give you the general framework.
![[V] tulip.sniper](/forum/data/avatars/m/44/44320.jpg?1371567410){kind=avatar}
