Show HN: Hathora – Multiplayer Game Development Made Easy

Show HN: Hathora – Multiplayer Game Development Made Easy 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!

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 · 4 years ago

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 · 4 years ago

Thanks for replying!

Will definitely join the discord.

hoten · 4 years ago

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...

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 · 4 years ago

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.

Thanks Justin!

thebeardisred · 4 years ago

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 · 4 years ago

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.

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 · 4 years ago

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.

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.

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 · 4 years ago

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.

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 · 4 years ago

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.

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

Thanks, looking forward to the benchmarks!

jokethrowaway · 4 years ago

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.

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