Show HN: Hathora – Multiplayer Game Development Made Easy

[hpx7]

https://docs.hathora.dev/#/

Hi HN, this is Harsh, I am the developer behind Hathora. I tried making a simple multiplayer game a few years ago and, as someone with software engineering experience but no gamedev experience, I found it to be very challenging. On top of the challenges of building a single player game, you now have to constantly battle the network and latency, find ways to prevent cheating, and figure out how to make a scalable backend architecture. With Hathora my goal was to encode best practices for online multiplayer game development into a framework so developers can simply focus on implementing their game logic.

Some technical pieces of Hathora I wanted to highlight:

- Hathora includes a system I think of as “gRPC for games”. You define your API in Hathora’s declarative format and the framework spits out typesafe data models, clients, and server endpoint stubs across multiple programming languages (although currently only Typescript is implemented). Minimal packet sizes are achieved through a binary serialization format which includes a delta encoding feature, allowing the framework to efficiently synchronize state by sending data diffs.

- Hathora includes a Swagger-like Prototype UI generated from the API definition. This allows you to view the game state and call server methods all in realtime, letting you interact with your backend logic without writing a single line of frontend code. Once you are happy with the backend logic, you can create a fully custom frontend using any framework/technology you’d like and just use the Hathora client to communicate with the backend.

- By handling generic game functionality (state synchronization, messaging, persistence, etc) for you, Hathora lets you create multiplayer games with very few lines of code. For example, see chess which is implemented in under 200 lines of user code: https://github.com/hathora/hathora/tree/develop/examples/che.... I also made (a massively simplified version of) Among Us in under 200 lines of code: https://github.com/hathora/among-us-tutorial

I am looking for developers interested in making online multiplayer games to try out Hathora and give me feedback. Additionally, if the roadmap seems interesting to you I would gladly welcome contributions: https://docs.hathora.dev/#/roadmap. I’ll be around to answer questions, let me know what you think!

[hoten]

When making the netcode for my web game, I highly valued TypeScript support so to get it by default, I defined the message types in TypeScript so they could be used directly[1]. I see that this framework defines its messages in .yml and converts it to types (stored in a folder kept out of source control).

I'm not sure which way is best, but it is very nice to have the feature support of `.d.ts` files when creating complex message types, as opposed to needing to learn a new thing. Clearly if this is going to be a cross-platform framework (not just web) then using TypeScript as the source-of-truth makes far less sense.

Anyway, very impressed with the binary format/delta encoding feature! That's been something that I know I _should_ do but am putting off until I see signs of sending raw JSON being problematic.

[1] https://github.com/connorjclark/gridia/blob/master/src/proto...

[hpx7 → hoten]

Yeah I'm curious to see where people bump up against the limits of the yml types DSL. I plan to make a UI on top of the yml to make it a bit easier to work with as well. I think the popularity of Protobuf as a format shows that people are willing to learn a new API format if it adds enough value.

Thank you for the feedback!

[jkchu]

I’ve gotten to know Harsh and we even built a game together with Hathora. We made a digital board game together in a week.

I’m a dev that makes web games (gomobo.app) but I’ve always wanted to spend more time building the game logic and UI and less on the networking and infrastructure stuff. I think Hathora is a great way to make your next game idea wayyy faster.

[hpx7 → jkchu]

Thanks Justin!

[ranguna]

Wow just wow!

I've been building a game for some time now and I've been putting off building the server logic. I had some ideas, and looking at the code examples, it's everything I wanted!

Really nice work here.

A few questions though:

1) It seems that server and frontend logic are tightly coupled into a single project. Is it possible to separate these two and simply have a channel for separately developed frontend application to listen to?

2) The deployment steps only say to start the index file with node, but from the architecture page, this project needs to setup load balancer, multiple instances of the server and a distributed file system. How does running the index file do all this?

3) This appears to be similar to some products offered by photonengine.com, how does it compare?

[hpx7 → ranguna]

1) The client and server are currently located in the same repo but I'm planning to make it so that you can run them separately. This will let you do things like write a new frontend for an existing deployed Hathora backend which you don't even own (as long as you have the hathora.yml definition for it).

2) There is a managed cloud coordinator (load balancer) which Hathora apps connect to by default, so you don't need to do anything for that. For the distributed file system I've been using https://aws.amazon.com/efs/, and each cloud provider as their own version.

3) Aren't the photon products tied to Unity?

Would love to chat in more detail in Github or in the discord: https://discord.gg/6nVdeCBffR

[ranguna → hpx7]

Thanks for replying!

Will definitely join the discord.

[thebeardisred]

It sounds very much like your stated goals ("...battle the network and latency, find ways to prevent cheating, and figure out how to make a scalable backend architecture") are very much in alignment with Agones (https://agones.dev) and it's sub-projects Quilkin (https://github.com/googleforgames/quilkin), Open-Match (https://open-match.dev/site/), and Open-Saves (https://github.com/googleforgames/open-saves).

Had you explored these at all?

[skid_dancer → thebeardisred]

From my understanding, Hathora is a netcode, so the layer handling communications between players through the server. Agones is for orchestrating the deployment/scaling of game servers, and Open Match is for matching players together, who will then join this server. So they are all complementary. Being in the industry, not a fan of Agones, and I barely hear of anyone using it. It solves the wrong problem, it's supposed to be a solution for game studios to handle scaling, but the only studios that have the resources to spend to understand, use and manage it already have their own solution in place. Open Match on the other hand is a great tool for matchmaking.

[hpx7 → thebeardisred]

I am familiar with Agones and I had briefly looked into leveraging Open-Match as a matchmaking option for Hathora.

To me, part of the value Hathora adds is from being an integrated and easy to use solution where you don't need to figure out how to put the parts together in order to develop your game.

[CGamesPlay]

Really like what I'm seeing here! I wish instead of a YML file I could provide a `.d.ts` file and you could understand that. That would be much more natural for me to code in.

[hpx7 → CGamesPlay]

That's good feedback for me -- I've been thinking about other ways to define the API format, as manually editing the yml can be error prone. I've thought about making a simple point and click UI which generates a valid hathora.yml, but having the definition in a typesafe language also makes sense to me.

[CGamesPlay → hpx7]

To expound on this a bit, for an initial version it might not even need to actually do any type checking or even support `import`. You could literally just use a TypeScript AST in place of the YML structure. It's certainly not as nice as integrating with the actual TypeScript compiler, but since it's a code generator that generates TypeScript, it's not as if it actually needs to do the verification at that stage--it will already happen when the generated TypeScript gets compiled.

[matrixcubed]

I’m really rather excited to see communication protocol as code, however what sort of latency does having “Hathora-in-the-middle” incur?

I’m particularly interested in the proposed GDscript support (to the level that I want to contribute), but I would recommend separating “packet validation” from “everything else”, so that it could live inside a game-server without the necessary performance cost (however minimal) to an external actor.

[hpx7 → matrixcubed]

Someone on the discord server already hacked together a multiplayer Godot game using Hathora!

I'm not sure I understand the "Hathora-in-the-middle" piece -- Hathora isn't quite a Backend-as-a-Service like Firebase if that's what you were thinking. Hop on the discord server if you're interested and I would be happy to chat in more detail.

[hashamali]

Looks interesting. We've evaluating multiplayer server frameworks at the moment and have decided on Nakama (https://github.com/heroiclabs/nakama). Any thoughts on how Hathora compares? Particularly interested in the realtime multiplayer component, specifically around performance and scalability.

[hpx7 → hashamali]

I think where Hathora shines today is in its ease of use, both in getting started and in managing complexity as you add features.

That being said, there are a number of features that make Hathora performant and easy to scale for realtime multiplayer games -- you can read about some of them on the architecture page: https://docs.hathora.dev/#/architecture

I plan on adding benchmarks in the coming weeks to better quantify perf and scalability

[hashamali → hpx7]

Thanks, looking forward to the benchmarks!

[jokethrowaway]

Very interesting!

I think the scope is massive, multiplayer logic can differ quite a bit depending on what needs to happen.

I've been using this project lately and I can recommend stealing from them. https://github.com/johanhelsing/matchbox

Even then, you'd cover only some very specific use-cases of multiplayer game-making.

[hpx7 → jokethrowaway]

I agree the scope is massive. I think a lot of people struggle with figuring out how to even get started with multiplayer dev, and I hope Hathora can be a useful tool for them.

Thanks for linking matchbox - I've been looking into https://github.com/geckosio/geckos.io as a way to integrate WebRTC into Hathora

[nsriv]

I'm far removed from this area of making software but I have to say I absolutely love the name ("Hammer" in Hindi)!

[geodel → nsriv]

Just came to my mind if Hathora came from Thor or something.

[tluyben2]

Well done! Maybe this will kick me to make a game I have been wanting to make for several years already.

[hpx7 → tluyben2]

If you do end up deciding to try Hathora out, feel free to join the Discord server - we'd love to see what you come up with! https://github.com/hathora/hathora#community

[terrycody]

Since most developers/companies nowadays will choose an engine to start, I highly suggest you made this into a Unity/Unreal/Godot plugin/addon, this should be popular.

[hpx7 → terrycody]

Definitely, once I add support for C#/C++/GDScript as language targets that is the next step

[dsiddharth]

This looks like a neat framework to build games quickly — congrats!

I wonder how reliable the data store is since it’s not using a traditional database. Mainly thinking about performance and consistency.

[hpx7 → dsiddharth]

Right now Hathora writes game data locally to disk. This is nice for the local dev experience since you don't need to have a db running locally.

For production use cases I've been mounting a networked drive (AWS EFS) to provide shared storage across nodes. It should be pretty easy add additional storage adapters (like Postgres) as well.

[wsc981]

Seems interesting.

Would it be a lot of work to add a Lua interface? I think this tool could be very useful for indie devs working on LÖVE/LÖVR projects. I noticed Lua is not part of the roadmap.

I worked on a pong clone last year and it was quite a pain to get the networking reasonably right. It would have been nice if a tool like Hathora could have been used instead.

By the way, does Hathora support NAT hole punching?

[hpx7 → wsc981]

Not sure if you saw it, but I wrote a little pong demo with Hathora in under 200 lines of code: https://github.com/hathora/hathora/tree/develop/examples/pon...

Generating a Lua client should be very reasonable. If you'd be interested in contributing (or just want to follow along), feel free to jump on the discord!

[wsc981 → hpx7]

I actually did see the pong. My version does a bit more, but it was nice to see the example.

I do work on my own hobby projects (games), but I might consider working on the Lua implementation. Will at the very least join the Discord.

[continuational]

I figure latency hiding the primary challenge in networked games. Does this framework help with that?

[hpx7 → continuational]

I've had decent results with just using client interpolation so far, you can try out pong, ship-battle, or among-us to get a feel for the latency.

The latency will be even further improved once I add UDP support, and I also plan to write a library to make client prediction easier with Hathora.

[StopDarkPattern]

Are they integrating with Easy Anti-Cheat?

[hpx7 → StopDarkPattern]

The way I've thought about preventing cheating with Hathora is to make it server authoritative, and make it as simple as possible to validate client actions in the server.