What do I have to take into consideration when developing both singleplayer and multiplayer coop without dedicated servers?

Question

The premise is simple - a game that can be played in singleplayer mode and that allows seamless partying for coop without dedicated servers. This would of course require server and client components and a singleplayer session would be nothing other than a client joining a (local) server (running in the background). Such a local server would in turn allow others to connect seamless and join a friends session without the need of restarting in a multiplayer game session. And eventually it would make development slightly "easier" since I would not need to work on two different game modes (that behave the same in this setting). I was curious about the workflow during development and some questions came to my mind I'd like to get some input on:

1. At first I'd be tempted to develop everything in the game client itself and not bother about the server since testing the gameplay and game elements themselves would be straightaway easier. With this mindset though I might have trouble moving the game logic that worked locally in the game to the server component and might end up tweaking something. I'd like to know whether it is feasible/reasonable to develop the core elements of the singleplayer and afterwards migrating to a server/client structure or should I plan on working on both ends simultaneously?
2. With regards to networking I don't have any experience with it in C++ and appropriate libraries (although I am fairly fluent in C++ and my game will be written using it) and was considering to take a bold approach by ignoring performance at first and sticking to something I am familiar with. Basically I'd write the server using C# or Node and the client networking code in C# (and possibly some library for shared components between the two) and would need a C++/CLI wrapper to call the client network code in my game itself. I'd have extra work to implement the bridge but ultimately I'd be able to get the basics going no matter how patchwerk they might be. At some point of course I'll probably have to translate all three of them (server, client, shared codebase) to native C++ not only for performance but for compatibility. So do you have suggestions on whether I should be going for something "patchy" using familiar tools and libraries and then migrating it later or should I invest the time to start "properly" with the same codebase and language on both sides?
3. Finally I have a question that boils down to the design of partying / matchmaking. Usually in multiplayer games you join via directly entering an IP address or using features like the Steam friend list. I'd really like to include a way to connect to specific games without having to mess around with ip addresses and using something like a lobby or even better a friend list. In this case though I'd need a small dedicated server for managing users and such friend lists. Is there any other design or way to connect besides using raw IP addresses?

Answer 1

OK, so in regards to programming the game itself, there's no real difference. You have to program the server and client. The host connects to his own server, the other players connect to the server which happens to be running on one of the players computers rather than a server somewhere.

Your main problems come in two flavours.

1. Networking. Most people connect to the internet through a dynamically allocated IP address which is inaccessible to other end users.

If I type in the IP address your computer thinks it has on mine. I wont be able to send you any data.

2. Server discovery/Matchmaking etc

Even If you have a public IP address I can connect to, I still need to write you a letter or something to find out what it is. You really need a central server everyone can connect to to check for available games, match making and the like.

Both of these problems tend to be solved by having a server on the internet which everyone connects to and has their game traffic routed though. Cheaper than running the game server yourself, but still you need something.

This is the classic approach. You might be able to do something clever if you only care about local players on the same network, or bluetooth, or if your messages are low bandwidth enough to go over another network, email or twitter or something.