Hi,
Looking at adding multi-player to my game, must admit, never done this before but have done socket programming, webservices, restful etc. What is a simple (if possible)
way to go about adding multi-player, AppWarp looks ok or should you go about writing your own server?
Thanks
Check out Kryonet. Easiest way I know to get networking up and running in the shortest amount of time. It’s high level enough so that you’re only dealing with which clients to send packets to, which does mean you’ll have to write a small server but it’s nothing hard to do.
Kryonet handles marshaling. The hard bit is what to send and when.
Using a lib like kryonet is recommended and removes the UDP/TCP argument since the lib will make that decision for you. If not always start with TCP, if it really is a bad fit then you can change later. TCP gives you a lot out of the box (flow control, ordering, handshakes and of course resends with packet loss), and UDP is not faster as so many claim. See below for the only exception IMO to this rule.
The type of game strongly dictates architecture. ie Server client, or p2p, turn based. These days everyone is moving to Server client, even for RTS games, so not a bad place to start.
Now the what and when. Lets hope your game is small. That is the entire game state can fit in a single packet, ie about 1500bytes or less. Then every game tick the server sends the entire game state. clients send “actions” when they happen. The server constantly listens to client actions, then updates the state, and at a fix interval sends the entire state to every client. This system does in fact work well with UDP and is the only case i would recomend people use UDP. Flow control and resends are handled implicitly by the server sending a fresh update at whatever rate you deem fit (10 per sec?). Clients always ignore “older” packets. Quake/unreal uses this system. this also works really well with TCP and large states with turned based games. Think old Civ.
If you can’t fit the entire state in a single packet. Then more incremental updates with sync needs to be considered and it a bit harder to do. This is where TCP shines. I don’t need a billion special cases with unrecived packets or out of order packets. But exactly what to send when is much harder to deiced. there are many ways to skin this cat. More details are required.
But no matter what i would start small. Proper small. like a cut down version of the game or something.
Based on the state of your game, I’d say it’s extremely similar to ProjectMP (you can see the Github repo here) which is a fully multiplayer terraria-clone prototype.
Let me just say this: networking is a pain, and constituted a massive chunk of my time. Probably out of the six months I spent developing ProjectMP, only around a month’s worth was dedicated to the game itself, the rest was all networking. I don’t really want to scare you away from multiplayer as the feeling you get when you accomplishment is like no other, but it is an extremely big undertaking and will be somewhat difficult to implement along a pre-existing game. My advice is to make your current game really great and fun in singleplayer, then work your way into making a multiplayer version. I learned the hard way that the fun-factor is so much more important than multiplayer.
But if you really, really want to undertake this, I have a bit of advice:
Singleplayer is just a local version of multiplayer. Everything you do must be multiplayer compatible, and thus it will be singleplayer compatible. You will need to handle packets (KryoNet is excellent as the others have said and will serialize packets for you) such as world data (blocks), entity data (creation and deletion of entities), entity move data (where an entity has moved to), and interpolate your positions locally so you don’t get jitter between packets. If you’ve ever tried modding Minecraft you’ll see how the packet hierarchy goes.
Again, multiplayer in a sandbox game is hard. I did it for the challenge and not the fun. If you have lots of free time and want to work with debugging network-related things - go for it. Otherwise, having a solid fun singleplayer game is better than a “meh” multiplayer game, in my eyes.
Thanks guys,
Some extremely great advice here and many thanks for taking your time to comment, I really appreciate it.
Looking like getting the single player up and running first and make it a lot of fun, see how that goes.
Once again, many thanks all.
You should design for multi-player from the ground up. The essential bit is that
the game has to move forward based on discreet messages. Events in the UI
have to be transformed into messages, and then messages (both the locally generated
and those received from other players) have to be parsed and interpreted.
If your framework follows this discipline rigorously, then switching from local/fake
multiplayer to real multiplayer will be relatively painless.
I strongly disagree. The hard part of all games is finishing. Anything. The trick to that is have something playable as fast as you can. And just getting single player working is the main trick for that.
Adding networking after the fact. Which i have done, was in fact a fairly straightforward refactor. The hard part remains the networking.