For example – I'm a big proponent of local-first apps, but even those require a sync server. You can easily implement one in under 100 lines of code with actors.
512 karma · joined September 16, 2016
https://rivet.dev
> What kinds of web sites need this level of complexity?
The most common use cases are high contention & strong consistency workloads where using an OLTP database doesn't work well. A few examples:
- Collaborative docs
- Local-first & CRDT sync (e.g. Yjs)
- Stateful multiplayer games, often async multiplayer (e.g. chess)
- Agentic workflows with frequent memory updates
- Chat
- Scheduling software
- Rate limiting
Actors can also be used for stateless realtime workloads that benefit from edge computing, similar to what you would use existing serverless edge functions for.
The actor model is widely used in larger companies. The best-known example is how WhatsApp used Erlang to scale to 900 M users with 50 devs [2]. It's also widely used at Discord, LinkedIn, Microsoft, etc. Take a look at Erlang/Elixir, Akka, and Orleans for prior art.
> Does this have enough performance to solve the server cost problem of Improbable's metaverse back end?
Actors usually have a single responsibility (e.g. document or chat room) while Improbable focused on building expansive worlds without clear boundaries between entities. Our docs include tips on scoping the responsibility of actors [1].
The actor model encourages actor-actor communication, sort of similar how entities in the ECS model communicate in games.
> That's a remote object system too expensive to run 24/7.
Actors automatically go to sleep when unused. They provide the benefit of realtime workloads without the cost of keep idle compute sitting around.
[1] https://rivet.gg/docs/scaling#tips-for-architecting-actors-f...
[2] https://www.wired.com/2015/09/whatsapp-serves-900-million-us....
Godot runs using our container runtime on Rivet. The FDB API for containers is currently undocumented. I'd be happy to share early access on Discord – https://rivet.gg/discord
Games running on Rivet usually have a hybrid of actors that handle persistent storage (e.g. a matchmaker) and the game server itself.
- Rewrote Nomad from scratch with our own in-house workflow engine
- Launched Rivet Actors and isolate runtime
- Overhauled our OSS experience to make self-hosting easier
- Rewrote frontend from scratch with shadcn to be like the cool kids
- Replaced Nebula with mTLS
- Completely stripped out Redis for non-caching use cases
We've also opened up the platform to non-gaming use cases.
To this day, I still believe it's one of the best ways to learn to program:
- You're exposed to low-level primitives instead of complicated high-level frameworks (like Unity) that abstract the fun/educational code away.
- The Lua manual is arguably the best programming manual for students learning to program.
- Includes a built-in GLSL shader editor makes advanced graphics programming a small stepping stone.
- They automatically shipped in-depth examples with the app that are intentionally built for learning by reading the code.
- In-app docs encouraged discovering new APIs; I took it as a challenge to use all of the APIs they exposed and learned a lot in the process.
- No package managers, no complicated install steps, no security concerns, and a unified editor.
P.S. If you have an iPad and haven't played Two Lives Left's Crabitron [1] – it's easily the most creative game shipped for iPad.
[1] https://apps.apple.com/se/app/crabitron/id440462182?l=en
Cloudflare has a lower latency product called Argo Smart Routing [1]. When we tried Argo in 2020, we still saw 10+ ms increased latency across the board, which is unacceptable for competitive multiplayer games. That said, Discord voice still (or used to) uses Argo for voice, so there are certainly less latency-sensitive games where it would work well.
The other issue with sockets over Cloudflare (circa 2020 on business plan) is they get terminate liberally with the assumption you have a reconnection mechanism in place. I'd imagine this is acceptable for traditional WebSocket use cases, but not for games.
Services like OVH & Vultr also advertise "DDoS protection for games," but I've found these to be pretty useless in practice. We can only measure traffic that reaches our game servers, so I have no way of knowing if they're actually helping at all.
Your best bet is getting familiar with iptables and fine-tuning rules to match your game's traffic patterns. Thankfully, LLMs are pretty good at generating these rules for you nowadays if you're not already familiar with these tools. Make sure to set up something like node-exporter to be able to monitor attacks and understand where things go wrong. There have been a few other posts on HN in the past that go into more depth about game server DoS mitigation [2] [3].
I built something in the same vein for my startup (Apache 2.0 OSS, steal our code!) [4] that runs a series of load balancers in front of game servers in order to act like a mini-Cloudflare. In addition to the basics I already listed, we also have logic under the hood that (a) dynamically routes traffic to load balancers and (b) autoscales hardware based on traffic in order to absorb attacks. We're rolling out a dynamic bot attack & mitigation mechanism soon to handle more complex patterns.
[1] https://www.cloudflare.com/application-services/products/arg...
[2] https://news.ycombinator.com/item?id=35771466
We use a mix of Traefik and Envoy for complex + dynamic LB configurations. Doing anything related to custom middleware, dynamic configuration, and caching feels archaic on Traefik and requires a non-trivial amount of code on Envoy. I hope Dito becomes the next gold standard for load balancing.
One caveat — one of my biggest complaints with Traefik is the memory usage, which makes it difficult to run as an mTLS proxy between services. We use Envoy for these use cases instead. I’m curious to see how Dito compares on memory usage, despite also being written in Go.
This the demo we share: https://github.com/rivet-gg/examples/tree/main/javascript/we...
Really cool project, love to see things that touch web tech, VPLs, and creative programming. Could not find repo from the website on mobile, would love to see it in the footer or in the CTA.
Plot twist: people stop writing casual games in Unity and switch to Unreal to target low-end hardware.
Needless to say: as someone who spent my teens and early 20s working on multiplayer web games, I'm incredibly excited for this.
No one on our team had used rebasing extensively before this, but it's hard to go back. Similar to the article, the benefits we see are:
- Fast iteration with `gt m` (`git commit --amend`) and `gt s` (`git push --force`) - Using `gt restack` (`git rebase` on each parent commit) helps make merge conflicts more transparent in what happened - Commit histories are much more legible
I highly recommend giving it a go.
Related -- we also built a simple (but not production-grade) tunneling solution just for devving on our open-source project (multiplayer game server management).
We recently ran in to an issue where we need devs to be able to have a public IP with vanilla TCP+TLS sockets to hack on some parts of our software. I tried Ngrok TCP endpoints, but didn't feel comfortable requiring our maintainers to pay for SaaS just to be able to hack around with our software. Cloudflare Tunnels is awesome if you know what you're doing, but too complicated to set up.
It works by automating a Terraform plan to (a) set up a remote VM, (b) set up SSH keys, and (c) create a container that uses reverse SSH tunneling to expose a port on the host. We get the benefit of a dedicated IP + any port + no 3rd party vendors for $2.50/mo in your own cloud. All you need is a Linode access token, arguably faster and cheaper than any other reverse tunneling software.
Source: https://github.com/rivet-gg/rivet/tree/main/infra/dev-tunnel
Setup guide: https://github.com/rivet-gg/rivet/blob/main/docs/infrastruct...
- The OP's acc was created today
- The support email for their site is a Tencent email (timmerse_support@tencent.com)
- They have an old NPM package [1] which lists colleenyu@tencent.com as a contact
- "colleenyu tencent" brings up a PM at Tencent on LinkedIn [2]
I have a lot of questions, now I really want to know the story behind this project.
[1] https://www.npmjs.com/package/timmerse
[2] https://www.linkedin.com/in/ucl-kejing-yu/?original_referer=...
That said, I've met & work with _a lot_ of developers who shipped Unity for web solely because (a) they already knew Unity, (b) they could easily hire for Unity, (c) their art pipeline only worked with Unity, or (d) they aim to ship to mobile later. Built-in physics + better rendering + networking are usually just a bonus.
BSL is not OSI-approved, but it’s a much more reasonable AWS-resistant license. It’s the same license CockroachDB uses, for example.
KeyDB (BSL, acquired by Snapchat) is also an option: https://keydb.dev/
BSL is a much better license, but it’s a gamble on how long KeyDB will be supported. I don’t want to mess around with such a core part of my architecture.
Vultr has a nasty habit of forwarding these directly to the current holder of the IP address with a dire warning that your account will be shut down within 24h if no action is taken, regardless of the timestamp of the complaint. Abusers just create & destroy servers frequently frequently to acquire fresh IP addresses to host malicious content on. It became a morning routine of copy+pasta responses to these emails to keep the servers online.
My philosophy for both creating & consuming OSS: the core needs to (a) have an OSI-approved license (read: no BSL, SSPL), (b) needs to be useful without the closed source component, and (c) needs to be easy to run without the closed source component. Otherwise, see [1]. I also avoid AGPL, even though it is OSI-approved.
TC has a good take on the economics of fully open source companies [2].
[2] https://techcrunch.com/2014/02/13/please-dont-tell-me-you-wa...
Hope we cross paths at a conference at some point!
It also benefits from being easier to copy + paste configs from docs since the entire path is included in each block; users don't have to worry about setting up the correct hierarchy.
Regardless, I strongly agree with points #1-#3. I also wish there was a way to support something similar to inline YAML schemas to catch users' typos in their IDE.
I would love to use HCL or potentially Ion, but IDE support and widespread acceptance isn't strong enough yet.
> Anyways I’d just like to voice myself as a possible target audience
Local development is tricky, and we have plenty of room for improvement here.
Currently we provide a special developer token [1] which will cause API endpoints to return mock responses when used locally. This way, you can use the exact same API with no difference in production & locally, so you don't have to mess with nested prefabs.
However, this doesn't help much with exposing your local machine for testing. We've toyed around with the idea of something similar ngrok built in to our Rivet CLI and integrated in to the API.
[1]: https://rivet.gg/docs/general/concepts/dev-tokens#mock-respo...
I don't understand why this answer is buried deep in a thread & isn't included in the Rust Book, even though it's been conventional wisdom among experienced Rustaceans for a few years now.
We also use CockroachDB which uses BSL, but we're not providing a remotely competitive offering.
I'll likely continue to recommend HashiCorp products (Nomad, Consul, Terraform, and Packer) to anyone who asks my advice, but it's disappointing to hear this change.
We maintain a rudimentary SBOM for anyone curious: https://github.com/rivet-gg/rivet/blob/main/docs/infrastruct...
Naturally, the first thing I searched for was something I’ve put on the internet that is not well indexed by Google.
When I search “how to find a lobby with rivet.gg” (that’s our most basic functionality), it doesn’t come up with an answer. However, it does spit back a descent summary of relevant features we provide.
What’s odd – it always continues on to talk about an unrelated company. The first time, it started talking about top.gg as a way to add Fortnite-style bots to your game. (They’re actually a Discord bot directory.) The second time, it mentioned a completely random Reddit called Guilty Gear Strive.
Can you elaborate on how it finds these related topics?
They're usually really good at getting the job done and balancing quality + productivity. However, most things are written with a one-off mindset because chances are your next game will need things to work completely differently. Everywhere else in tech you find "scalable" and "backwards compatible" solutions; not in gaming.
Part of this is the job description. Unlike the rest of tech, you're usually building a game that will be popular for 2-3 years then disappear. It's not common to find that model anywhere else in tech.
Just my 2 cents.