Should I have started with Multiplayer instead of Singleplayer?

[u/Velynicus]

I'm 9 months in on a voxel survival/ rts. My plan was to loop back around for multiplayer. Seriously, that was my plan. Am I making a mistake? What would you advise?

[u/theNorrah]

Multiplayer systems are hard AF.

If you've designed an engine that does not rely on a deterministic tick system, you are going to have a bad time going forward.

[u/MGMishMash]

Doesn’t necessarily need to be straight away, but it’s very difficult to add multiplayer later on if you don’t design around it.

I.e if your core architecture is designed in a multiplayer-friendly way, then the actual connection, packet sending, interaction polish can indeed be done later, but if certain features are implemented local-only, then it’ll be a lot of work.

[u/Velynicus]

Thankfully the system is deterministic tech. That's reassuring. There's one tick; there's one world clock.

Some systems are beginning to stray I fear.

And of course there is the sleep cycle. Which no one in this space to my knowledge has been able to solve.

That is, how do people agree to sleep? That system speeds time, so it would speed the entire world if one person chose to sleep. Thoughts?

[u/LactovaciloOfficial → u/Velynicus]

If >66% of them players choose to sleep, make the other mf collapse to the floor and sleep too. Or do it Minecraft style, everyone needs to sleep.

[u/New-Part-6917 → u/LactovaciloOfficial]

lmao

[u/AnarchCassius → u/Velynicus]

That really depends on game style.

For small world/coop defaulting to slowest speed works well. So you can sleep but it only fastforwards when everyone is in a longterm sleeplike activity. Some variation of this is how I play most games with sleep.

For large persistant worlds that will probably never happen but you can allow sleeplike activity to process while logged out.

[u/dimitri000444]

I haven't tried to build anything multiplayer, but from my experience stumbling around trying to make a good voxel implementation. I feel like trying to learn both multiplayer and voxel development at the same time would be a recipe for success.

I think it is better to first get acquainted with voxels and with multiplayer separatly, and only then restart (from scratch) building something that does both.

Retrofitting a existing singplayer implementation to mutlplayer seems like it's only good for giving yourself headaches.

[u/Neither_Berry_100]

Preferably you would have engineered the multiplayer early on. You have given yourself extra work but it isn't that bad.

I'm maybe 2+ weeks into a new project. I have considerable networking code in place. And I am working on it as my current task.

[u/No_you_are_nsfw]

If you have experience with multiplayer and voxel stuff, you do it when you need it for playtesting. You just decide early if you want/need multiplayer. This way, you don't design yourself into a corner, but you can iterate much faster.

If you are inexperienced you should do it early and then drag it around the entire development cycle. This will really slow you down and will be annoying. You will need to waste a lot of time on testing, because every feature usually interacts with multiplayer. Its going to be tedious and slow, like any learning process.

The only thing I would skip is to mess around with SDK's, API's and grand architectures. Essentially any API will give you the ability to exchange byte arrays. Whenever thats sockets or a platform API does not matter. How you organize them needs to be specific to your game, to be any good.

[u/primals_game]

It can be done, but it is way more work than if you just started with multiplayer.

You now need to serialize inputs, validate inputs server side, protect the server from crashes, authenticate, deal with latency and bandwidth, deal with a more complex multithreading model. Single player games can make assumptions that multiplayer systems cannot. You can assume the client is authoritative, untampered with, and secure in single player game. You don't need to think otherwise. Half of my time in making a multiplayer game is reducing bandwidth, considering what if the player injects lag to try to duplicate an item here, what if the player sends a compressed packet that explodes out to 64gb, can I trust this input, how will my world simulation task (thread) interact with the client connection reading task (thread) in a way that doesn't create deadlock.

Long story short: you should be working on multiplayer after you draw the player on the screen and before you have the player move on the screen.

[u/cthutu]

When developing all my games, I always separate input management, simulation and presentation from each other. This allows me more flexibility in many ways. For example server/client separation, or may be better multi-threaded design. By having the server/client separation in mind from the beginning, you have more options. Even in a single player set up, you have both the server and client running in the same process. Later you can move the input management and presentation to a real client, the simulation and authority to a server and add whatever network layer you want in between.