4 ms·

<nostalgia> I feel like a lot has been lost since the days when I was in my parents garage making TCP/IP games to run over dialup. 1. Binary was the only choi

by throwaway2016a 9y ago

<nostalgia> I feel like a lot has been lost since the days when I was in my parents garage making TCP/IP games to run over dialup. 1. Binary was the only choice 2. You had to assume packets would get delayed (sometimes 10+ seconds) thus you had to do some fun stuff like try to use math to predict where the player would be based on what they were doing last time you got an update. 3. You had very little RAM to work with so growing memory would be immediately noticeable. #2 was the primary reason in old game you used to see other players walking into a wall for 20 seconds before jumping half way across the map. Darn n00bs who couldn't afford 56k (joking). I fondly remember the first time I played a multi-player online game I actually had to dial into my friend's modem over POTS. I then spent the next two months reading telephony documentation trying to figure out how to use the modem to do things like that myself. </nostalgia>

deleted 9y ago
[deleted]
reificator 9y ago
#2 hasn't gone away, the gaps have shrunken a lot, and we've gotten a little better at predicting actions, but it's still the exact same concept.
- zacmps 9y ago
  Definitely, but other methods, such as lockstep, are also used in some games.
  - dfox 9y ago
    That depends on the kind of game, mainly on whether it is practical to replicate whole state relevant to player at least occasionally and whether the latency of lock step is acceptable. For RTSes the whole game state is usually impractically large and latency is not that important (and can be masked) while for shooters the state is relatively small and latency is critical.
    - animal531 9y ago
      Just a side note; what you're saying is true (as in RTS vs FPS) if in general if I'm just attack moving my army into yours and then ignoring it. But if I'm micro-ing for example my single marine vs your single zergling then latency is just as important as in any FPS. The interesting part with RTS for me is that a person can only control so many entities, so only 'touched' entities need real-time syncing, if its for example off-screen a server simulation can just tell you the results afterward. I quite enjoyed this classic old article (1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond): http://www.gamasutra.com/view/feature/131503/1500_archers_on_a_288_network_.php http://www.gamasutra.com/view/feature/131503/1500_archers_on...
      - dfox 9y ago
        In RTS you can get away with latency between player input and the thing actually happening on the order of 100-200ms with visual tricks and thus serializing all the player inputs and replicating only that to independent simulations for each player running in lockstep is viable. You can't do that for games which need faster simulation updates than network round-trip.
bschwindHN 9y ago
Don't worry, it hasn't been lost by game developers in the professional space. The article is presumably from a web developer implementing their first game. No offense meant by that statement, but if you're reaching for Socket.io (or even TCP/IP) for a real-time multiplayer game then you're probably going to have a bad time. Thankfully we have free resources from professionals in the industry to keep us on the right track: https://gafferongames.com/ https://gafferongames.com/
- monsieurbanana 9y ago
  I remember reading it some time ago, and I gave it another pass, but it seems the only existing solution is WebRTC which, as the author himself admits, is extremely complex for the needs of a simple game. And netcode.io, the solution developed by the author, which has a major drawback: it needs the installation of a browser extension to work (only chrome supported at the moment). All things considered, WebSockets still seem to be way to go for most use-cases.
  - bschwindHN 9y ago
    Sure, if you're targeting the browser. But even then you probably don't want Socket.io vs just using the vanilla WebSocket API. Basically the browser isn't a good platform for real time twitch control games like this one seems to be.
- rayboy1995 9y ago
  I use Socket.io just fine for my game, though I do implement it differently and send binary packets of my own protocol instead of JSON. I can see what you mean for new people in the field using unmodified events though.
slazaro 9y ago
#2 is called Dead Reckoning [1], in case anybody wants to know more about it. [1] https://en.wikipedia.org/wiki/Dead_reckoning#Dead_reckoning_for_networked_games https://en.wikipedia.org/wiki/Dead_reckoning#Dead_reckoning_...

deleted 9y ago

[deleted]

reificator 9y ago

#2 hasn't gone away, the gaps have shrunken a lot, and we've gotten a little better at predicting actions, but it's still the exact same concept.

zacmps 9y ago
Definitely, but other methods, such as lockstep, are also used in some games.
- dfox 9y ago
  That depends on the kind of game, mainly on whether it is practical to replicate whole state relevant to player at least occasionally and whether the latency of lock step is acceptable. For RTSes the whole game state is usually impractically large and latency is not that important (and can be masked) while for shooters the state is relatively small and latency is critical.
  - animal531 9y ago
    Just a side note; what you're saying is true (as in RTS vs FPS) if in general if I'm just attack moving my army into yours and then ignoring it. But if I'm micro-ing for example my single marine vs your single zergling then latency is just as important as in any FPS. The interesting part with RTS for me is that a person can only control so many entities, so only 'touched' entities need real-time syncing, if its for example off-screen a server simulation can just tell you the results afterward. I quite enjoyed this classic old article (1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond): http://www.gamasutra.com/view/feature/131503/1500_archers_on_a_288_network_.php http://www.gamasutra.com/view/feature/131503/1500_archers_on...
    - dfox 9y ago
      In RTS you can get away with latency between player input and the thing actually happening on the order of 100-200ms with visual tricks and thus serializing all the player inputs and replicating only that to independent simulations for each player running in lockstep is viable. You can't do that for games which need faster simulation updates than network round-trip.

bschwindHN 9y ago

Don't worry, it hasn't been lost by game developers in the professional space. The article is presumably from a web developer implementing their first game. No offense meant by that statement, but if you're reaching for Socket.io (or even TCP/IP) for a real-time multiplayer game then you're probably going to have a bad time. Thankfully we have free resources from professionals in the industry to keep us on the right track: https://gafferongames.com/ https://gafferongames.com/

monsieurbanana 9y ago
I remember reading it some time ago, and I gave it another pass, but it seems the only existing solution is WebRTC which, as the author himself admits, is extremely complex for the needs of a simple game. And netcode.io, the solution developed by the author, which has a major drawback: it needs the installation of a browser extension to work (only chrome supported at the moment). All things considered, WebSockets still seem to be way to go for most use-cases.
- bschwindHN 9y ago
  Sure, if you're targeting the browser. But even then you probably don't want Socket.io vs just using the vanilla WebSocket API. Basically the browser isn't a good platform for real time twitch control games like this one seems to be.
rayboy1995 9y ago
I use Socket.io just fine for my game, though I do implement it differently and send binary packets of my own protocol instead of JSON. I can see what you mean for new people in the field using unmodified events though.

slazaro 9y ago

#2 is called Dead Reckoning [1], in case anybody wants to know more about it. [1] https://en.wikipedia.org/wiki/Dead_reckoning#Dead_reckoning_for_networked_games https://en.wikipedia.org/wiki/Dead_reckoning#Dead_reckoning_...