Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's a bit dogmatic to state "never use TCP".

I was wondering about this too. Yesterday in the "WebRTC: the future of web games" post we had Matheus28, the creator of Agar.io, saying that his games are built on WebSockets, a TCP-based protocol. Agar.io is real-time and massively multiplayer, and seems to run smoothly enough. So is it completely critical to use UDP?

I am curious as someone who has recently gotten into making simple Javascript games. One of the games is a multiplayer / head-to-head Minesweeper clone that I got working with Django Channels, but did not even consider the networking aspect of TCP vs. UDP. The more recent one is inspired by the real-life game "capture the flag" -- teams of Asteroids-style space ships have to defend their own territory and flag, and capture the opposing team's flag while going around shooting at each other. It features a large game board very much like Agar.io (with the game camera following your ship around). I am using Phaser.io and Node.js, and while the game is operational and pretty fun just playing with the AIs, it's not multiplayer yet. I am approaching the multiplayer aspect carefully because minimizing lag will be crucial to making the game enjoyable.

Any general advice from anyone is appreciated, I am new to both networking and game design but it's a lot of fun.



Props that you're branching out and having fun. That's what makes software special.

Agar.io is slow and simple. There isn't much state to encode and state doesn't change drastically that a few re-sent packets here and there are going to ruin the gameplay. Granted, if you're on a terrible connection with high packet loss, even a great algorithm on top of UDP won't save you.

There are better explanations than I can provide on why TCP isn't great for (parts of) fast, complex games, but it's enough to say that there's a huge difference in the complexity of state and state updates between say Battlefield and Agar.io or the game you described. Modern TCP on modern network connections will get you very far, but there's only so much you can deal with when a split second can mean the difference between "A was under the crosshair of B" and "A actually went around a corner, sorry B".

What you described is likely not going to be so sensitive. I don't think you'll personally have to worry about implementing a custom networking protocol over UDP any time soon - maybe unless you think your game is going to be played by people on terrible connections (possible!), or you end up with some abysmally inefficient state sharing over the network.

And, from a different perspective, getting caught up in those details tends to risk getting burned out. Better to see your game through to MVP then go back and make it great.


I'd argue that Agar would run smoother on UDP. The decision was not really a decision here. WebSockets provide TCP only. One can use WebRTC data channels now but there are still issues woth compatibility.

And it's all tradeoffs. For example, Ultima Online used TCP and worked relatively fine on decent networks. In case of a packet drop, you'd observe a complete pause on the world but most animations / movement had a 100ms or more buffer area. If you wanted to move some direction, your character would start moving, if there was no ack after a single step (100ms if running) then it would stop. The world was being streamed as diffs from previous state so it depended on tcp's reliability.

Anarchy online used udp for game and tcp for chat. While the OP argues against this, I think it is a good seperation. I remember playing it on a congested network and the game state fucked up really bad. Tunneling over a tcp stream to a vps server close to game servers made it playable for my case. Maybe they should have gone with tcp. Or their networking code did not compensate for UDP's issues better.

On the other hand, anything more action packed like a fps would probably be better off with UDP as the author suggests.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: