I'm rooting for you guys, truly. Congrats on the launch and thanks for offering a free trial.
However... personally I clicked around looking for pricing, found nothing. I understand it's early and you don't have it figured out yet, that's fine. I get it will cost more than if I tried to roll my own solution on bare metal, sure. But how much more? AFAIK it will be somewhere between ten cents and a billion dollars a month, or per player, or cats per donut, who knows.
I'm starting to think that new services silently loose far more users through the uncertainty of opaque or nonexistent pricing ("contact us!") than they will gain with free trials.
Hathora Cloud is still very young and iterating quickly. We've been in a private beta with select design partners and we're onboarding users slowly via signups.
When we make it generally available, we will definitely make pricing front and center!
Simple - For semi-auto vertical scale only; turn based & single instance low tick-effort central servers (can provide less bill shock for bursts for same set up effort as rolling your own)
Complex - For large horizontal scale of high-tick effort games with full session pinned websockets by geo
both can easily be billed in the wholesale standard RAM GB-hours (say 1.5x cost) as you will be moved up or fanned out to beefier or more systems right when ticks are not being completed well enough within the desired tickrate.
I expect they'll suggest a max of 10,000 players and 100 rooms @ 50ms ticks taking avg. 5ms tick compute on the smallest VM (~50% util which on a 512MB 1x-shared-CPU costs $3.24 p.m on fly)
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?
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)
Is Hathora a product? The blog post mentions a free tier, which is great, but I can't find any references to any pricing or tier information at all, or even a link to buy something. There's documentation showing how to run a dev server locally, but, like...what happens then?
Does Hathora have any customers? It says "scale to millions." Has anyone ever used Hathora to scale to millions of something?
Not dsiddharth, but for what it's worth I am using Hathora for my upcoming game (it's almost complete!). Their product still very new, but they have been extremely helpful with every step of the process building with Hathora.
They have two products - an open-source dev framework (free) and a cloud-hosting product (paid).
My games will likely never reach millions players, but my first two games led to over 1,000 sign-ups and I've made over $1k in revenue (which I'm super proud of). I can report back with how my newest game does after it launches.
My first two games were built with my own hacky web sockets implementation. From a software perspective it's pretty messy, but it gets the job done haha.
I actually had built an alpha version of my 3rd game with my own networking code, but because it is more of a real-time game, there were tons of bugs. Switching to use Hathora for the back-end logic has made the game much more stable so I can finally work to release the game.
You can check out my first two games here: https://gomobo.app/. They play kind of similar to Jackbox games, but with more strategy board game elements. Would love to hear what you think!
So this is basically a fancy game-specific VPN isn't it? How is it different from Steam Networking which lets players connect to their closest endpoint and routes traffic through Valve's backbone? The only way this service could offer any benefit over Valve's is if you can run edge processing right at the gateway for a Matrix.org-esq protocol for a distributed-authority netcode so that the gameclient's physics/hit-prediction length is only the latency to its gateway rather than all the way to the central authoritative server. But then this would need gamedevs to actually know what they're doing regarding how to re-architect netcode, which, given the quality of Riot's Valorant supposedly being the shining beacon of engineering among gamedevs, is not a very auspicious prospect.
I'm not too familiar with Steam Networking, but at a glance here are some differences:
- Steam Networking seems mostly for peer-to-peer messaging, so it's closer to a STUN server (used by WebRTC for sending UDP datagrams). It's excellent for sending messages over high-quality links, but if you want to run server side logic, it doesn't seem like Steam Networking will help much.
- On the flip side Hathora is a server-authoritative framework, which can run arbitrary game code on our infrastructure. This is closer to a cloud provider. The difference between us and just using AWS or DO is that we're providing the "Steam Networking"-like edge network out of the box and tailoring our use case to the needs of game devs.
- Lastly, we can actually spin up compute infra at the edge if enough of your users are originating from a ___location far from the rest of your servers. Let's say your game starts to go popular in Asia today, our routing layer is smart enough to launch a server in Singapore instead of connecting users to far away game servers.
You're missing the external requirements a game might have. Multiplatform? Multiplatform with shared online play? Publisher wants certain services? Publisher already has its own services? Service sucks to actually work with?
Well, matchmaking and lobby is at least as important as connectivity ; not every multiplayer game requires absolutely flawless connectivity and pings in tens of ms, but every multiplayer game requires some kind of a player profile , and many of those games have a notion of "match", and "players participating in a match", thus requiring a matchmaking based on some rules, most often those are player level and user ___location. Almost every game I, as an ops engineer, took part in launching and running, was implementing those two parts, with varying degrees of success and finesse
Can you enable ShowDead and answer XeonMC's question? Seems like a normal question, not sure how the user got in the spam filter. Happens a lot these days to otherwise normal questions.
Hathora actually supports raw TCP connections in addition to Websockets, and we're very close to shipping raw UDP support as well!
For the web, we're deciding between using WebRTC or leapfrogging straight to WebTransport[0]. Either solution would be a thin layer on top of the raw UDP work
Interesting article! Congrats on the launch. But as an ocassional gamer I thought the way online games work was different.
For example, I play FIFA online and I believed that once a match making had place, Player A (me) synced a seed with Player B, and then the only thing that had to go over the network was the input, and every device could generate the game since they shared the same seed (which makes it deterministic).
Isn't much more complicated to have the engine on the server and send the state to the device?
The vast majority of games don't work the way you're talking about. I think the only ones that do are fighting games where latency is crucial.
It's much more complicated to only share input because to avoid desync the game engine has to be able to either rollback the state to accept inputs from other players sent over a slow connection, or alternatively just pause the game until it receives the next tick's inputs. See this article: https://arstechnica.com/gaming/2019/10/explaining-how-fighti...
It's easier to prevent cheating if the engine is on the server. Could you elaborate on what you mean by
> they shared the same seed (which makes it deterministic)
In addition to game init params (like random seeds), the game state is also a function of time, which cannot be synchronized the same way that seeds can.
You'll find many interesting videos and articles if you search "netcode". It is easy to underestimate the complexity of domains you're not familiar with, but that just means more fun when you find out how unexpected problems crop up and the innovative ways they are solved.
Your middle paragraph is works fine for LAN, and is how games were programmed. send controller input over the network, compute the next state, send controller input over the network, repeat.
But, things get complicated as network delay goes up.
Imagine you put two consoles next to each other with a 150ms delay Ethernet cable between them.
If you always have to wait for your opponent's inputs, a 150ms delay makes the maximum tick rate drops to less than 7 ticks per second.
You can't just start the game at the same time, with the same seed and apply inputs as soon as they arrive. The games would instantly desync, because your inputs from frame 1 apply on frame 15 for your opponent, and your opponent's inputs from frame 1 don't get to you until your frame 15.
ok so just update the engine so that local inputs are processed 15 frames later. that works, but it makes players nauseous. and what if there is a lag spike?
Modern netcode can gracefully deal with network delay, lag spikes, dropped packets, faulty client hardware, and more, while being computationally and network efficient, and can't be exploited for an unfair advantage. A proper explanation of rollback code involves special relativity and time travel. It's so cool. I'm working on my own article and I'll try to send it to you when I'm done.
I get that this is a marketing piece, but given the title I was hoping for something a bit more specific to gaming. This is just basic web server architecture.
Deceptive title. Almost triggered me but this looks like a cool project. Hosting game servers isn't as trivial as it used to be.
Back in the day all you had to do was execute a command with a given config. Man, hosting Quake 3 servers was stupid easy. These days I need middlewere such as LinuxGSM in order to deploy an instance of Quake Live. Just one, though... because reasons.
I know why things are complicated these days. I really do. But it sucks
I am a bit worried by "Dropped or lost input packets are also not handled in this example.", as I would have hoped handling dropped + lost packets would be a framework issue, not a "me" issue.
I'm not the author of the game so not sure exactly what they meant by that, but that game uses Websockets which are built on top of TCP, so developers shouldn't have to deal with dropped packets (and our UDP implementation will have automatic retry built in as well)
Thank you for the informative and well-article (despite the fact that it is an ad). I'm wondering what difference between Hathora and SpatialOS. As I understand it, they both offer similar benefits.
However... personally I clicked around looking for pricing, found nothing. I understand it's early and you don't have it figured out yet, that's fine. I get it will cost more than if I tried to roll my own solution on bare metal, sure. But how much more? AFAIK it will be somewhere between ten cents and a billion dollars a month, or per player, or cats per donut, who knows.
I'm starting to think that new services silently loose far more users through the uncertainty of opaque or nonexistent pricing ("contact us!") than they will gain with free trials.