4 ms·

Its a constraint of the browser technology stack; not only do we have to use websockets for real-time (TCP/IP) but we also have to go over SSL/TLS as intermedia

Its a constraint of the browser technology stack; not only do we have to use websockets for real-time (TCP/IP) but we also have to go over SSL/TLS as intermediary hardware/software (routers, proxies etc) still routinely break websocket connections otherwise. (Disclaimer: Author of article)

vvanders 11y ago
I really hope your game designers know how to mask latency. If you're going over TCP/IP then expect to need to resolve a game model that can sustain at least ~750ms of latency. I totally understand the browser constraint part but you're going to hit some serious issues once you start having real-world clients that have >3% packet drop. It gets even worse when you start adding different discrete layers on a single TCP connection(chat, larger game state not related to twitch parts, etc). Each one of those channels has the chance to drop a single packet and then your whole world comes to a stop until you can roundtrip that single packet that's unrelated to the realtime info you care about. FWIW most stacks end up implemented channels over UDP with unreliable+unordered, reliable+unordered and reliable+ordered for the different latency needs of the specific channel. I've done a fair bit of this stuff in a production environment and have to echo my original comment. TCP is great for lockstep but if you're doing dead-reckoning it will fall apart on anything other than a LAN. Edit: I also don't mean this as a dig, just that I've seen many teams go through this and it's usually at a point where it's too late to make any changes.
- benaadams 11y ago
  Not saying its easy and we have discovered the reason most MMOs have long wind up animations for actions... The other layers (chat, non-space game state) are handled by discrete microservices on other connections to other hosts - to keep the space flight data slim and connection dedicated in use. Can always give it a try, our next public playtest is on Saturday 6 Feb 8pm GMT/UK | 12pm Pacific | 3pm Eastern US at http://www.ageofascent.com/ http://www.ageofascent.com/ Just don't try it on a phone; give us a chance with the latency ;-)
  - vvanders 11y ago
    I wish you the best of luck but I really think you've got a poor technology fit for what you're trying to do. Games like SubSpace/Continuum were doing 300+ player twitch based on UDP based connections over 56k dialup back in '97. Any sort of packet loss(and subsequent TCP exp backoff) is going to weak havok on your latency.
    - terry526 11y ago
      Listening to this podcast atm; interesting stuff. http://hanselminutes.com/509/inside-age-of-ascent-with-ben-adams http://hanselminutes.com/509/inside-age-of-ascent-with-ben-a...
    - Scaevolus 11y ago
      "Windows/DirectX/UDP is too well-supported and mainstream, let's build a twitch MMO using Javascript/WebGL/WebSockets!" I wonder what the intersection of "people that want to play MMOs" and "people that don't want to install anything" is. There are good game streaming technologies (e.g. Guild Wars) that minimize the patch time, so it feels like a bit of a straw-man.
    - twodave 11y ago
      Holy cow, talk about a flashback. I played the crap out of that game for about a decade.
      - vvanders 11y ago
        Yup, many fond memories. I was looking up the release date since my mind was a bit fuzzy on the year and it turns out it's been released on steam as freeware last year: http://store.steampowered.com/app/352700/ http://store.steampowered.com/app/352700/ It's taking all of my self-control to not install it and waste the rest of the day.
      - dnr 11y ago
        Add me to the HN/Subspace club: I played quite a bit of it starting from the end of beta (~'97) and also got pretty involved in the bot/modding/development scene that rose up after VIE left the picture. Some of the best gaming experiences I've ever had, and I learned a lot on the development side too.
jsprogrammer 11y ago
WebRTC can give you UDP semantics.
devit 11y ago
You can probably work around this issue by using hundreds of parallel TCP connections in a round robin fashion. Assuming you are sending a packet per frame, this setup means that you are only sending a packet every few seconds per TCP connection, which means retransmissions should have already happened by the time you send another packet.

vvanders 11y ago

I really hope your game designers know how to mask latency. If you're going over TCP/IP then expect to need to resolve a game model that can sustain at least ~750ms of latency. I totally understand the browser constraint part but you're going to hit some serious issues once you start having real-world clients that have >3% packet drop. It gets even worse when you start adding different discrete layers on a single TCP connection(chat, larger game state not related to twitch parts, etc). Each one of those channels has the chance to drop a single packet and then your whole world comes to a stop until you can roundtrip that single packet that's unrelated to the realtime info you care about. FWIW most stacks end up implemented channels over UDP with unreliable+unordered, reliable+unordered and reliable+ordered for the different latency needs of the specific channel. I've done a fair bit of this stuff in a production environment and have to echo my original comment. TCP is great for lockstep but if you're doing dead-reckoning it will fall apart on anything other than a LAN. Edit: I also don't mean this as a dig, just that I've seen many teams go through this and it's usually at a point where it's too late to make any changes.

benaadams 11y ago
Not saying its easy and we have discovered the reason most MMOs have long wind up animations for actions... The other layers (chat, non-space game state) are handled by discrete microservices on other connections to other hosts - to keep the space flight data slim and connection dedicated in use. Can always give it a try, our next public playtest is on Saturday 6 Feb 8pm GMT/UK | 12pm Pacific | 3pm Eastern US at http://www.ageofascent.com/ http://www.ageofascent.com/ Just don't try it on a phone; give us a chance with the latency ;-)
- vvanders 11y ago
  I wish you the best of luck but I really think you've got a poor technology fit for what you're trying to do. Games like SubSpace/Continuum were doing 300+ player twitch based on UDP based connections over 56k dialup back in '97. Any sort of packet loss(and subsequent TCP exp backoff) is going to weak havok on your latency.
  - terry526 11y ago
    Listening to this podcast atm; interesting stuff. http://hanselminutes.com/509/inside-age-of-ascent-with-ben-adams http://hanselminutes.com/509/inside-age-of-ascent-with-ben-a...
  - Scaevolus 11y ago
    "Windows/DirectX/UDP is too well-supported and mainstream, let's build a twitch MMO using Javascript/WebGL/WebSockets!" I wonder what the intersection of "people that want to play MMOs" and "people that don't want to install anything" is. There are good game streaming technologies (e.g. Guild Wars) that minimize the patch time, so it feels like a bit of a straw-man.
  - twodave 11y ago
    Holy cow, talk about a flashback. I played the crap out of that game for about a decade.
    - vvanders 11y ago
      Yup, many fond memories. I was looking up the release date since my mind was a bit fuzzy on the year and it turns out it's been released on steam as freeware last year: http://store.steampowered.com/app/352700/ http://store.steampowered.com/app/352700/ It's taking all of my self-control to not install it and waste the rest of the day.
    - dnr 11y ago
      Add me to the HN/Subspace club: I played quite a bit of it starting from the end of beta (~'97) and also got pretty involved in the bot/modding/development scene that rose up after VIE left the picture. Some of the best gaming experiences I've ever had, and I learned a lot on the development side too.

jsprogrammer 11y ago

WebRTC can give you UDP semantics.

devit 11y ago

You can probably work around this issue by using hundreds of parallel TCP connections in a round robin fashion. Assuming you are sending a packet per frame, this setup means that you are only sending a packet every few seconds per TCP connection, which means retransmissions should have already happened by the time you send another packet.