Merging multiplayer code with single player code using a local host,
Members - Reputation: 115
Posted 28 January 2014 - 04:16 AM
Gameplay is supposed to be the same for both instances. So I'm essentially thinking I could program multiplayer and also get single player. I figured this might be a way of reducing workload and killing two birds with one stone.
Crossbones+ - Reputation: 8876
Posted 28 January 2014 - 05:39 AM
Is it bad practice to merge single player code with multiplayer code by making single player a client connecting to a private, automatically started, local server?
Afaik its standard practice. Coding a single player game from the start and then turning it into multi player is really hard, on the other hand, going from multi player to a single player game (in the way you proposed) would be easier to do.
"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"
GDNet+ - Reputation: 1726
Posted 28 January 2014 - 07:47 AM
Minecraft indeed does that since one of the more recent versions afaiu. It's great to structure your game around multiplayer if you intend to have it. It is a good thing to abstract the networking logic in such a way so that you can bypass it when in single player. For example, instead of sending a packet over UDP to yourself, receiving it and passing it on to the game logic, you should try to pass it directly to the game logic when in single player mode. Otherwise it may alert firewalls and stuff that can be annoying to the user.
Crossbones+ - Reputation: 2194
Posted 11 March 2014 - 06:21 PM
Quake, Quake 3, Unreal Engine games, Crytek's, even some source games, these work on the principle of a single player game on a loop-back / virtual local network.
Usually, the client / server separation is very strong. Quake 3 is an example of that. The server part is basically a renderless dedicated server, the client part handling the rendering, audio and inputs. Both completely separate contexts, if you will (code-wise, two seperate projects / dll / libraries). It also means, seperate contexts for each entity types, server-side entities that handles logic, and client side entities that handles audio and graphics with virtually no logic of their own (apart for stuff like client-side prediction and particle physics). Plus the networking, messaging and serialsation gubbins in the middle mediating between the two.
Edited by papalazaru, 11 March 2014 - 06:21 PM.
Everything is better with Metal.