How to make a cheap multiplayer online game in 48H

Posted by (twitter: @caribouloche)
December 18th, 2013 10:47 am

Network libraries banner

Assuming you know almost nothing about networking.

  1. Don’t make a MMO – it had to be in this list of course but more as a “keep it simple” rule
  2. You can actually make a MMO – honestly in a jam environment, mmo doesn’t mean much, so yeah you can make a game with mechanics revolving around unlimited number of players – if your server can’t handle it, you probably already won Ludum Dare anyway.
  3. Dont make an online game – unless you’ve got a good reason to, you’re going to lose a lot of time no matter what.
  4. Know your tools – If you can play with the network stuff beforehand, it’s better.
  5. Use a network library – ENet, Lidgren, Twisted… are great, if your game framework offers some network capabilities don’t bother and use that but avoid raw sockets ಠ益ಠ
  6. Unity networking is great for jamming – RPC & Component synchronization are fun things to play with; maybe less approachable than a simple simple send(x, y) though but this depends on the library and how you like to approach code.
  7. Consider using a game networking service – This is actually highly recommended, it wasn’t in this list at first because there wasn’t point 4. but things like SmartFoxServerPhotonCloudPlayer.ioFirebase are really great, they basically offer you an API client-side and handle all the server stuff themselves. It makes a lot of points disappear (like 5.); try the Firebase online tutorial, it’s damn simple. If you’re in a strange setting or if you don’t want to go this path try to estimate the time of handling the server hosting, port forwarding, firewall surprises and policy servers in some cases.
  8. Don’t make a dedicated server – aka don’t put all the logic on the server. Unless you’re comfortable with it, just make a simple server relaying messages between clients. If you’re using point 7. it’s already done for you.
  9. Client-side logic is alright – this is a jam.
  10. Cheaters are fine – The logic is on the player side, anyone can break things, but you don’t care.
  11. Don’t mind serialization – strings/JSON are probably fine too (don’t think in bits, obviously).
  12. Use reliable messages – If you’re using TCP you’re set, and for UDP libs, any decent one should have this option. You probably don’t want the hassle of handling unordered and missing packets for a jam. If you’re using point 7. it’s probably abstracted.
  13. Think networking / organize your code – this is probably the most important. Every line of code you write you should think about what message you will send and how you will consume it at the other end, so present your datas correctly. This is probably less significant when you’re not in a dedicated server setting but this is a good rule to separate your logic from your rendering anyway.
  14. Starting your project with network code is not a good idea YMMV – i used to make networking work before any game-related code but this is actually a real drag when tweaking & playtesting. It seems a bit idiotic to playtest a multiplayer game without players so you probably don’t want to do that (◑◡◑) but do as much as possible in local : art, game feel, rules (keep in mind point 13.) and then switch to the netcode. Having to start a server + client instance to tweak something while noticing this little network bug that prevents you from fixing this other thing is really annoying.
  15. Finish your game in the first 24H – Spend the first day making your game, spend the other one with network code, tweaking & playtesting. Try to give the right amount of YOLO-coding, be a bad coder when you can be bad (there’s a lot of room for this), be a tad less bad when it matters : game crashes. Don’t underestimate the productivity gained by time pressure aka the last hours : you probably don’t want to handle unexplored areas (networking) under too much time constraints, keep the constraints for what you know best so code it early, but not too much.
  16. The Jam (72H) is probably more realistic.
  17. Turn-based games are good for a jam.
  18. Real-time games are fun, but probably not a super idea for a first multiplayer game.
  19. Don’t dive into all the Gafferon Games / Valve / Quakeworld / Quake3 articles that you bookmarked a while ago.
  20. Send your player position to the server is simpler than inputs – remember jam.
  21. Keep your lag compensation really simple – when receiving a player position don’t do any dead reckoning, extrapolation… make a simple interpolation : player.x += (net.x – player.x) * 0.3
  22. Variable-timestep loops are ok
  23. You might need a physical server of some sort – use your computer, a raspberry or the free amazon vps tier (Credit Card needed) or use point 7. and you’re set.
  24. Don’t be overwhelmed by the amount of points – PhotonCloud/FireBase/Player.IO/SmartFoxServer make things really simple, forget this list and play with their API. “The secret to writing a networked game for Ludum Dare is to avoid writing networking code” as a redditor said and those services try to do just that.
  25. Be highly suspicious of do’s and don’ts lists
  26. Those lists often make the author sound pretentious – what legitimacy does he have ? All those do this and do that :3 There’s not only one way to do stuff, what if i want to tunnel a UDP packet into a TCP packet into a UDP packet ?
  27. All those rules are probably not applied by the author himself – i feel like most of those rules are mostly reaction rules to what people doesn’t succeed at. It’s a kind of never reached nirvana for the author, something that you frame in your room and stare at while working out, naked.
  28. It will never work as planned – You’ll probably end up doing netcode in the laSOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOFSOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF SOCKET EOF

How to become a horrible network programmer in only 48H

Soldiers banner

Good job, you’re now a horrible network programmer.. but what makes you different from 99% of the world is that you actually finished a multiplayer online game while people are still struggling to pack as much datas as they can into one byte. And the good news is that nothing prevents you to improve your network code with proper design.

How to improve

I feel bad for some of those points so i want to correct a few things.

  • A dedicated server is generally a better way to separate your network code from your rendering code, it’s also a good training for organizing your code.
  • Use a fixed timestep loop, it makes synchronization way better and lag compensation easier.
  • Don’t actually send your player position to the server, send inputs (you can even pack this into one single byte !!!)
  • Use UDP for realtime games, and don’t use reliable messages as stated above. UDP by its nature doesn’t guarantee much when sending a message and you probably don’t want the hassle to handle this in a jam. Otherwise, UDP is great, use it, whenever you can. TCP is perfectly fine for more slow-paced games, it doesn’t mean TCP doesn’t work for realtime games, it’s just a weird choice when you have UDP standing there, waiting for a hug. But World of Warcraft is TCP blablabla… ಠ益ಠ
  • Actually read the Gafferon Games / Valve / Quakeworld / Quake3 articles; this is still a drag to actual productivity if you’re falling into all these optimizations. Keep it simple but not necessarily at JAM-quality.

Note that you might question my legitimacy and i have no answer, most of my LD games are mostly crap, the last one is bad or probably average at best but this is not a game-design post, this is a “netcode takes time, here some tips to give you more time for game-designing while being a worse network programmer than you were before even starting” post.

multi2

You can click the GIF to have a look at my average (jam) entry.

I’m also using this post to make a list of multiplayer online LD games, if you happen to have made one, tell me in the comments or @caribouloche.


3 Responses to “How to make a cheap multiplayer online game in 48H”

  1. The biggest challenge for multi-player game is to either:
    A: Get to have a game fun enough so you will always find someone to play with.
    B: Make it so that if you’re trying the game alone, you’re still playing with someone.

    • caribou says:

      This is indeed great advices, i admit i always imagined the games i made played by one person bringing his friends but yes if you can make it work alone + with friends it’s even better.

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]