Design Is there a do's and dont's for stuff to avoid when planning for a game to be multiplayer (up to 4 players)?

[Crysillion]

I'm always learning new stuff with GMS2 and one thing I've like to eventually tackle is networking and allowing up to 4 players to connect to a single session. I know this is not an easy thing to learn, but none-the-less I'd like to get more into it.

That did get me thinking, though. I know some games start out as single player and then end up redoing their code in a major way to support multiplayer. There's bound to be some things you do with a single-player game in mind that makes converting it into multiplayer especially difficult. What I'm asking is if there's different ways code should be handled if multiplayer is a potential option down the road in order to make that migration easier, what one should look out for and plan for.

Then again, perhaps this varies game from game to such an extreme degree that such a "do this not that" on a more general scale just can't really exist. I wouldn't know, but I wanted to reach out regardless.

Thanks. Apologies in advance if this was described poorly.

 

[Cpaz]

Haven't handled networking in GM specifically, but the TLDR, is that all relavent information needs to be constantly send between players. Not only that, but it needs to be synchronized as well.
So just know that something as simple as a 4 player online coop game will need to be built from the ground up as a multiplayer game, since all of the individual systems need to be made with networking in mind.

My recommendation is to follow a bunch of "online multiplayer" tutorials and look for common patterns. Is player-relevant data being stored differently than normal? Is this the same with non-player-relevant data? Etc.

 

[vdweller]

Preparing your game for deterministic netcode

A post about lockstep, rollback, and what it takes to prepare your game for future netcode integration. Continue reading →

yal.cc

 

[Yal]

From my experiences, there's a lot of stumbling blocks. Here's some stuff you should think about:

• Player scalability. You should ideally allow an arbitrary number of players, using a single object (which gets a "player index" set when created and then reads all its data using that) so everything just works regardless of the number of players. The step from 1 to multiple players is massive, but increasing the number of players once you've accounted for multiples isn't as big.
• Related, you also need to rewrite all code that checks player objects (enemy AI, camera positioning, menu control, stage-clear conditions etc) to expect multiple players instead of just a single one.
• Make a centralized data structure that's easy to do batch operations on. If you need to manually add special cases for everything, you will forget something somewhere and that leads to desync bugs.
• Don't expect data to arrive, and have measures in place in case something gets lost on the way. If the game softlocks and hangs if a player drops out at the wrong time, it gives a really bad impression.
• If you're making a long-time-investment game, you might want to consider adding "action whitelists" to prevent players from cheating the game (especially by making malicious stuff happen to other players with forged packets - have a look at the scene Dark Souls 3 steam community for examples of what people are doing), this would basically be checks that ignore messages for actions that wouldn't normally happen (e.g. a player fires a projectile, but the object ID is an endgame boss instead of a bullet)
• Having PvP will make the game community more toxic, so only add it if you really need it (otherwise force all multiplayer to be cooperative)
• The more slow-paced the game is, the less effect you'll get from lag and dropped packets.
• Don't use the built-in RNG system for anything gameplay-related (visual effects are fine), it's hard to synchronize and it has different underlying engines (and thus different pseudorandom sequences) between platforms and versions of GM.