Hacker News new | ask | show | jobs
by njaremko 1457 days ago
What differentiates this from a more general solution like fly.io? It seems like what’s being provided is an auto-scaling docker deployment with fast cross region network links, and storage? Fly provides all of that, and isn’t focused on gaming. Why would I choose Hathora?
2 comments

Hathora Cloud provides several important features specific to multiplayer gaming. To list a few:

1) Built in authentication/identity

2) Session/room based connections (with lobbies, matchmaking, etc)

3) Handlers for various transports (websocket, TCP, UDP)

So you're competing with Azure Playfab... so are those services you mentioned just now available a-la-carte or is it an all-or-nothing approach? (as in, can you use your sessions/rooms without using your IdP / can we bring our own IdP (using OIDC? SAML?) - or is your room system built around your IdP?

Websockets are very different to BSD Sockets (TCP/UDP/etc) though (string messages vs. binary packets/datagrams) - if you're abstracting-away then that means devs are ceding a lot of control over the performance dials (TCP_NODELAY? Nagle?)

The example in the article using a Node.js-based game-server is fine, but what options do people needing to run a Quake-style game server (i.e. a ph-phat binary) have?

Hathora's auth story is basically bring your own JWT token. So you can implement your own custom auth as long as you end up with a JWT signed using your APP_SECRET in the end.

Websockets do actually support binary packets not just strings. But yes you lose control over the server side receiver part of the connection (we think most developers will be ok with this)

Hathora Cloud will be able to run anything that can be packaged into a Docker container and implement the Hathora Protocol (yet to be formally documented)

If you look at the cli screencast, it appears to be using fly under the hood.
Yep, we love Fly.io! We're building our platform-as-a-service on top of Fly and augmenting it for gaming-specific needs.
I thought fly.io like most cloud offerings was not really meant for hard-realtime applications? Especially those "serverless" runtimes, in fact.