When creating a game, what are some architectural desgin concepts I can use to be able to port my game from single to multiplayer?

Question

I am a software developer but, I mostly develop games in Unity. I have experience creating single player games as well as multiplayer games. I am at a crossroads where I am in the middle of development of a proof of concept or small demo and all of a sudden I am asked to turn it into a multiplayer game without prior knowledge of this I turn around and say it would add 50% to development time because I basically have to start over from scratch because I didn't necessarily take into account that later down the road they might want to change the experience from single to multiplayer.

So with all of that out of the way, are there any different methodologies out there that would make it easier on the developer to port a game from single player to multiplayer?

I have thought of a possible way of doing this by just setting the game up as single player, however, making my functions where they are easily able to wrap them using Commands and RPCs. But I find this may or may not help me and is only dependent on what the requirements are.

My biggest time killer when it comes to porting these PoC's is typically the UI. Most of the time my requirements are so that the UI will be the same shared UI for all clients and having to update it for each action performed on it and dealing with handling ClientAuthority. (Any tips for dealing with this would be greatly appreciated too) Think of this as something like, making something with Legos in multiplayer and having shared instructions based on the step the user is on.

Summary

What are different ways that I can design a small demo/concept where I can easily port it to multiplayer later on, or make my game where it is "multiplayer friendly" ? Or should I try to stay away from this type of thinking altogether and just develop a single player aspect and just develop a multiplayer aspect, arguments for and against this concept are sought after.

Answer 1

Depends on the size of the project.

For small projects like the ones described in the question, it's not worth the effort. Constantly worrying about large but possibly non-existent problems can slow down development speed considerably, so for a multi-day or even multi-week project the best you can do is communication. Tell the Customer/Employer/Coworker before you start what your time/price estimate is, clarify if they want single or multiplayer, and inform them that as long as they are willing to pay extra you're happy to switch it should they later change their mind - but it will be more expensive than just picking the right thing from the start.

For larger projects that take multiple months, I recommend taking half a day to figure out how you'd run multiplayer, writing it down. Then base the software design of the game on that multiplayer draft, but implement only the parts you need for single player.

In a now removed comment a specific issue was mentioned regarding who to send what from the server, and when to use local position versus remote position. In another comment P2P was mentioned. For both of these, Drafts and PoCs can be considerably simplified by always going through an authoritative hypothetical zero latency server - during the demo all players are on the same LAN to avoid latency, and you always use server position for everyone. If you only implement the single player parts you don't even need to go through sockets and messages - you simply have method calls which call your server interface directly and process an asynchronous response. For drafts in P2P settings, still use a server, unless what you want to prove isn't the gameplay but the underlying P2P technology.