I’m trying to make my first multiplayer game. Should I make a working single player game first the convert it to multiplayer or just go straight for multiplayer
Depends on the game. I’d say you need to think about multiplayer from the start though, otherwise you’ll end up with a lot of issues that could easily be avoided with a bit of forethought.
However… if you’re just trying to prove a concept and you think you can prove it with single player then it might be a good idea to do that first as a prototype. And start again when you better understand what you’re building.
Answer depends on you clearing up your question.
If this is your first game period…then aim for single player first. Get a good understanding of the entire process and then grow from there.
If this isn’t your first game, then start making it multiplayer from the get-go. You’ll end up having to change a GREAT many things if you build a single player game, and then turn the game into a multiplayer game. However, if it’s a game that you want to ADD a multiplayer MODE to…then making it single player first is just fine.
I’m kinda in same boat. Seems like getting all your interactions down first is a good idea, then convert them over to multiplayer code.
Making everything multiplayer from the outset will slow down or even hamper your game design choices as it’s long rocky road to getting everything working “right” when you don’t have a clear idea of what “right” is.
This shows a complete lack of understand in what goes into “game design”. You don’t set out to make a multiplayer game, and design it to be a single player game.
EDIT - Decided I’d elaborate more on what I mean, so I don’t sound like someone just picking a side and ranting. Let’s look into designing the aspect of passage of time. In a single player game, this would be based on some sort of variable that is saved each time the player shuts down the game. Whereas with a multiplayer game (online) the passage of time is handled by the server. How about physics? In general physics in a multiplayer game are (again) handled by the server. Whereas in a single player game, each build handles every single physic aspect in the game. These are just two of the examples that can be a major mistake if you start out making a single player game, and then try to turn it into multiplayer, when you knew it was going to be multiplayer in the first place. You will have wasted days…if not weeks…of writing code…and have to convert anywhere from 60-80% of your code to the new (multiplayer) system.
You are free to pick a side 
I guess what I mean by my point of view is that simple things like how high the player should jump, what colour shirt they are wearing, what powerup does what etc. is basic and important stuff you can do without worrying about multiplayer code troubles weighing you down. The plan for the game to be multiplayer is implied.
I’d rather work on boss routines then work it in to the multiplayer game than the other way around.
Often Pure programmers just work in assets, but if you are making the assets too, I’m of the side that you should integrate them after you are comfortable of their desired function. You could look at it like the base stuff is your base “class”, then the multiplayer stuff is you extending that base “class” - class here meaning your desired vanilla feature / object etc.
Hello,
I’m in a situation that is similar to your; I want to make a multiplayer game and I already understand enough of UNet to put some multiplayer mechanism, but there are some specific issues that I don’t know how to fix yet (some jitter when using the NetworkTransform, functionalities such as having the client download the map on connection…).
I’m thinking that I’ll try the multiplayer approach, but leaving for now some elements in a “mixed state” until I’m able to find a solution. By example, for the map download, I’ll leave that for later as I hope that changing the implementation won’t impact too many game objects. So I’ll simply generate the same map on each client, so that each one will get his own copy, and that copy won’t actually be synchronized through the network.
But for the rest, such as the fact that all the enemies and player objects will have a NetworkIdentity and that their scripts will most likely contain a lot of “isServer” or “isLocalPlayer”, I’ll directly implement them multiplayer-style, so that all the wiring up is already finished.
In the end, that makes a game where the gameplay is already multiplayer, apart for a few specific elements such as the map synchronization, but that will only leave me with one issue to fix. Plus, it will give me the possibility to already discover and hopefully tackle the issues related to the actual behaviour of the game.
It would be a bit troublesome to see that, once you finished your game in single mode and you’re converting it to multiplayer, some of your gameplay elements are too costly to be put in multiplayer mode and that you might have to rework a lot of things.
Hope it helps!
So multi-player first seem to be the more efficient way. Thanks you all for your advice!