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.<p>Some technical pieces of Hathora I wanted to highlight:<p>- 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.<p>- 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.<p>- 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: <a href="https://github.com/hathora/hathora/tree/develop/examples/chess" rel="nofollow">https://github.com/hathora/hathora/tree/develop/examples/che...</a>. I also made (a massively simplified version of) Among Us in under 200 lines of code: <a href="https://github.com/hathora/among-us-tutorial" rel="nofollow">https://github.com/hathora/among-us-tutorial</a><p>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: <a href="https://docs.hathora.dev/#/roadmap" rel="nofollow">https://docs.hathora.dev/#/roadmap</a>. I’ll be around to answer questions, let me know what you think!
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).<p>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.<p>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.<p>[1] <a href="https://github.com/connorjclark/gridia/blob/master/src/protocol/protocol.d.ts" rel="nofollow">https://github.com/connorjclark/gridia/blob/master/src/proto...</a>
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.<p>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.
Wow just wow!<p>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!<p>Really nice work here.<p>A few questions though:<p>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?<p>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?<p>3) This appears to be similar to some products offered by photonengine.com, how does it compare?
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 (<a href="https://agones.dev" rel="nofollow">https://agones.dev</a>) and it's sub-projects Quilkin (<a href="https://github.com/googleforgames/quilkin" rel="nofollow">https://github.com/googleforgames/quilkin</a>), Open-Match (<a href="https://open-match.dev/site/" rel="nofollow">https://open-match.dev/site/</a>), and Open-Saves (<a href="https://github.com/googleforgames/open-saves" rel="nofollow">https://github.com/googleforgames/open-saves</a>).<p>Had you explored these at all?
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.
I’m really rather excited to see <i>communication protocol as code</i>, however what sort of latency does having “Hathora-in-the-middle” incur?<p>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.
Looks interesting. We've evaluating multiplayer server frameworks at the moment and have decided on Nakama (<a href="https://github.com/heroiclabs/nakama" rel="nofollow">https://github.com/heroiclabs/nakama</a>). Any thoughts on how Hathora compares? Particularly interested in the realtime multiplayer component, specifically around performance and scalability.
Very interesting!<p>I think the scope is massive, multiplayer logic can differ quite a bit depending on what needs to happen.<p>I've been using this project lately and I can recommend stealing from them.
<a href="https://github.com/johanhelsing/matchbox" rel="nofollow">https://github.com/johanhelsing/matchbox</a><p>Even then, you'd cover only some very specific use-cases of multiplayer game-making.
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.
This looks like a neat framework to build games quickly — congrats!<p>I wonder how reliable the data store is since it’s not using a traditional database. Mainly thinking about performance and consistency.
Seems interesting.<p>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.<p>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.<p>By the way, does Hathora support NAT hole punching?