The simple answer to this question is yes; SAM can be used for both local co-op multiplayer and online multiplayer games. However, for a more detailed answer, please read the rest of this section.
First things first, we must be up front in saying that we have never worked on a multiplayer game, either local co-op or online. However, we understand some of the concepts and have built SAM to work with multiplayer in a theoretical way.
Any users building a multiplayer game are free to provide feedback on what needs to change with SAM to make those types of games work, as we are 100% committed to supporting them.
The rest of this Section covers the attempt we've made to build in support for multiplayer games, and should hopefully serve as a jumping off point for making those types of games with SAM.
For Local Co-Op games, we anticipate that all that is needed is an additional Active Grid component for each additional Player.
World's, which are responsible for loading the Streamable Cells and Asset Chunks, can be used with as many inputs (the things deciding what Cells should be loaded) as you wish, and this should naturally support local co-op.
One potential issue that may arise is deciding how Origin Cell Re-Centering should work with a multi-player setup. Should only the main player trigger re-centering, or all players? In either case, if using a floating Origin based World, you will likely wish to keep your Players relatively close together, to avoid one crossing into the unsafe area while the other is near the origin.
For online games, whether you are using a floating Origin based World or not will factor heavily into how difficult it is to get SAM working with your multiplayer game.
The reason for this is simply. If using a floating Origin based World, each player will likely have a different Origin Cell in use at any given moment, which will result in different positions for game assets.
To account for this, these types of games should make use of Cell relative positions for assets whose positions need to be communicated between the player and servers, or player to player.
For example, rather than telling the server that a Player is at World position x, y, z (i.e., a position that is scene relative), you tell the server that the Player's position is rx, ry, rz, which is relative to a specific Streamable Cell. The server can then validate that position and send it (along with the relative Cell) to another Player. That player can find out where the relative Cell is in their own scene in order to convert the position back to a raw World position (a scene relative position).
In order to support this type of system, the World class already has built in methods for translating one or more position back and forth between scene relative positions and cell relative positions, including job based methods that can batch translate positions in a very fast way. You can find these methods in our API (using the button below); all begin with the Translate keyword.