Or in other words, should I take care of the multiplayer part from the very beginning?
If I ignore it, will it be too hard to implement in a later stage?
In general terms obviously, I know every case is different.
If you ignore it then later you basically build an entire new game.
I find I save myself a lot of work if I work not only on multiplayer overall from the start, but every individual system as well. There have been a few game systems I have worked on where I didn’t pay much attention to multiplayer during initial design, and when I had to revisit the system to implement multiplayer correctly, I ended up scrapping a fair bit of work, which becomes an even larger problem with interconnected systems.
What I’ve described is best-case scenario. I have some hobby projects that I have abandoned as a result of poor planning when it comes to multiplayer.
Almost every variable and function call that sets or gets those variables will have to be refactored and you will have to insert a lot of extra events and solve all the ownership issues with a complete restructure of classes… in other words… it is a nightmare and will be far quicker to just recreate the game.
Thanks for all the feedback.
What I am planning is a 3rd person survival with just cooperative multiplayer.
So far I have 3 months of work where if mostly focused in UI, inventory/storage/crafting stuff.
Do you think it will be that bad even for this case if I don’t address it right now?
And also, any reading material you guys can suggest for the multiplayer part (C++)?
It depends on how intertwined your classes are. UI only exists on the clients so if it is well encapsulated you probably don’t need to change much there. Back end systems like Inventory, storage and crafting is a different story and might be very difficult to convert to multiplayer.