SpacetimeDB fits into a genre of tech that I want to call "universe brain reorgs" - structural re-arrangements that might unlock wild performance increases. The challenge with these is that they require devs to re-align their thinking and it's hard to disentangle if "the problem" is that the technology isn't being fully embraced or if the promises of the tech don't work for your use case.
Other techs in this category have seen a lot of success. I'd classify Elixir and Node as being similar in that you adopt a stack to get access to some rare guarantees and also accept new or exotic limits.
I think these things tend to rely on having clear-eyed visionaries out in front, able to show off their strengths in open source. Without a successful project it's hard to believe the claims. I hope clockwork labs is able to deliver their example game (it seems high risk because, even if the game is a technical wonder - what if it isn't fun?!).
Absolutely! I work in Elixir and I feel very good about its tradeoffs - and a lot of being good with the tool is knowing when to not use it. This tech is very much out of my wheelhouse but it seems very cool and I hope y'all find a nice fit!
Well, it totally gives up memory mutation. Each value is final (under the hood). So you lose an entire category of optimizations and an entire category of errors. You also gain some new optimizations you can do because values never change. In general that makes it worse at tight loops where you really want optimal machine code and better at handling heterogeneous calls like HTTP requests.
When node first came out, it was pretty revolutionary. Being able to almost instantly start a JavaScript thread from a single file that could support realtime experiences (a la socket.io et al) without a build step felt pretty paradigm shifting
Node supports realtime applications? Really? Isn't it garbage collected? Or does the term mean something different in nodejs? I've only come to know the term in the context of time guarantees (i.e. if it's scheduled to run in x, it is guaranteed to run at that time) and that shouldn't apply to nodejs I think? When you schedule something there, I believe it'll run on the first free thread after the timer relapsed - which entirely depends on the load of the system
Theres discussion distinguishing hard real-time (what you describe), firm real-time (infrequent deadline misses are problematic but managable), and soft real-time (missing deadlines aren't a big deal). Node does a pretty hood job with soft real-time.
I think we've diverged from the game context, towards discussion "universal brain reorganizing technologies", nodejs being considered one, and what real-time means in the context of node.
That said, real-time communication _is_ a soft real-time system.
Ya'all are very strict in your definitions then. My definition is "does it feel laggy" or "do I have to walk away and come back when this thing is done".
Basically like 24 FPS or higher is real-time. Even that'd be laggy for a game but not unplayable. I choose this specifically because that's what movies typically use and they're very watchable.
Hard real time (or just "real time" in firmware/hardware contexts) is effectively a term of art. One that's been increasingly watered down by the rest of the industry.
Strict definitions matter when system failure == pacemaker missing a beat or train signalling system drives a freight train into the back of 400 passengers.
In game development we still care about the distinction between soft and hard realtime. Almost all games are soft realtime, even if the gameplay itself is turned based as we're processing user input, updating UI, animating things and so on.
Realtime in this context probably just refers to the end user experience — multiple people connecting over web sockets to the same backend and seeing the same thing in “real time”.
Like, if you decide to do your backend in rust or python you can choose async or synchronous approaches - but Node locks you into async. I'm not a node developer so I can't sing the praises of what you get, but being locked into JavaScript's process model, VM, and type system is certainly a downside (for which you get the whole JS world). It's another example of...if you are architecting your service and you pick this you are picking some built in trade-offs.
IMO it's more that there is value...but the chance that any random developer (i.e. me) is going to be able to realize it is much lower. Your instincts about how do to things will be predictably wrong in this new, different paradigm. You generally want a guide or you risk foot-gun'ing any project through misunderstanding.
Could also be marketing hype! The MMO space tends to be full of this, most famously in the VC funded arena with Improbable. This also suffers from the same problem that Improbable did that there are just not that many people making MMOs but maybe it'll find a niche elsewhere.
I've been making multiplayer games professionally for twenty years from fast-paced shooters to spaceship MMOs and to me this isn't really crazy. If you wanted to make a comparison it's like having SQLite in memory but with the added infrastructure to support networking to clients and persisting state to disk. Obviously there is more work involved than that but conceptually thats where things are at. How nice it is to actually develop a game with is a pretty open question, and almost certainly the most important one when evaluating this sort of product, but you'd be surprised at the range of stacks in existence.
It's a database that emphasizes stored procedures. And if you need it to distribute computing, it has the same challenges as the eliminated "game servers".
In addition, outside of single table updates and selects, SQL has scaling limits. If you throw the computation at the db server as well, you limit the vertical scaling.
Gaming and gamers are used to sharding (and geographic tower of babel us an implicit shard as well).
> SpacetimeDB fits into a genre of tech that I want to call "universe brain reorgs" - structural re-arrangements that might unlock wild performance increases. The challenge with these is that they require devs to re-align their thinking and it's hard to disentangle if "the problem" is that the technology isn't being fully embraced or if the promises of the tech don't work for your use case.
And this is exactly why as a professional multiplayer game developer I'm quite concerned about SpacetimeDB.
If you're a game developer and choose to use it, you must accept that you will completely structurally re-arrange your game server, and gameplay and simulation code in such a way that you'll conform to a database structure and programming model developed by some people who are currently making their first game.
I'd be surprised if any professional game developers would consider this a good idea. The last time somebody suggested such a significant refactor for game servers, was when the two cofounders of Improbable walked into our office at Respawn, shortly after we shipped Titanfall 1, and told us they wanted the complete source code for Titanfall 1, and they would show us how awesome Improbable is, by porting the entire Titanfall codebase to Improbable in just a few months!
They ended up getting the source code, despite all programmers and the technical director advising the COO against it... and we never heard from them again.
> SpacetimeDB wasn't built in a vacuum. It's the system powers our own large-scale MMORPG BitCraft. We designed it specifically for the performance requirements of games. That means extremely low latency (~100 us/Tx) and extremely high throughput (~1,000,000 Tx/s).
If you are trying to build a new MMO that scales to the moon, you might want to take a look at how the existing market goes about things.
Take World of Warcraft for example. You could probably put a $20 MySQL VPS behind a realm and have it reliably persist state with how authoritative and infrequently updated the clients are.
Being clever with what you can trust the client with and how the server reconciles events is where I think you will find most of the scaling hacks.
I don't really understand how you would write a game server using this tech. Lets say you need to simulate physics, pathfinding, animation etc on server. How one would integrate all of this? In regular world you just use unreal/unity headless mode that includes all of this but using spacetimedb requires ditching the game engine and reimplementing everything from scratch?
Forgive my ignorance, but why would you implement physics and animations on the server? I feel like you can get away with basic positional data and do the rest of that on the clients.
This looks really interesting, and bitcraft looks cute.
I did hit a personal bias: when I saw "maincloud" as a phrase to do with pricing my heart sank because my brain went "they've wedged in some crypto shit!". Turns out no, it's just a naming thing for hosting credits.
There was a lot of crypto-adjacent talk in earlier versions of their marketing and product design. Without it actually being anything actually crypto-adjacent. Analogies drawn to ethereum etc concepts, I guess because they figured somehow there was an audience that would get those references and it would allow them to understand the product better?
I have no idea why. I was hired to work on very early versions of it, and left very early on in part because I wanted nothing to do with that angle. IMO it's a liability.
It had nothing to do with marketing, it was because conceptually stored procedures are similar to smart-contracts and share technical aspects. We thought engineers would find the similarities interesting. Instead they immediately assumed we were shilling tokens, so we pulled it down.
Kind of sad that people can't see past that, but I also understand. It is what it is.
Hey Tyler; looking back I think maybe a better language than "reducers" etc would have been to just something analogous to the ECS term "systems", which I understand to be "processes that operate on entities / components" and always seemed overly general and non-specific to me but at least is familiar to game programmers operating in data driven design.
You may recall I was partial to the term "verb" :-)
I think that's very fair, we've got quite a lot of momentum behind reducers at this point though. That doesn't make it a good, name but it is a sticky one.
I feel like they've been inspired by crypto for the way they handle billing. They sell you "Energy" which you use by running on their infra. Seems like a needless abstraction to me.
This is indeed interesting, but FYI this is a BSL-covered project with somewhat onerous times: only one instance per service (i.e. don't scale out, if I understand correctly) [0].
YouTube keeps recommending SpacetimeDB to me even though I have never made a videogame. Now I'm seeing it on HN too.
Are there any game devs here who can comment on how useful this actually is? The pitch seems pretty cool but I can't tell how much of it is just good marketing.
Not a developer affiliated with the project. But here's my take:
The problem is that the proof is in the pudding. Some of their claims feel outlandish. Imagine writing your game with SQL queries. Rather than crafting update packets that only contain relevant game info you just do `select * from players where abs(player.x - current_player.x) + abs(player.y - current_player.y) + abs(player.z - current_player.z) < 100^2` and it just updates automagically 60 times a second.
Running physics sim in SQL stored functions sounds insane but that's exactly what they're advertising. They say it's due to in-mem DB optimization but I'm not sure how they horizontally scale that (they allow you to run standalone but any scaling requires their cloud product)
It's in closed alpha so there's a limited number of players but I am curious to hear more about how BitCraft is scaling out. Is it a single, seamless world for all players? How much scaling is currently required? How is data replicated when horizontal scaling comes into the picture?
Given the name I was also expecting some clever SQL-like data structure/query for fast spatial lookup but I digress.
Game physics involves a lot of things (solvers, collision detection, numerical stability, etc.).
I am skeptical of their claims of being able to run physics in what I understand are stored procedures for their database.
I looked at their docs for physics https://spacetimedb.com/docs/unity/part-4
where they demonstrate the simplest form of collision check (sphere overlap). I fail to see how that is an improvement or speedup over existing methods. Some quotes:
"This may not be the most efficient way to do collision checking (building a quad tree or doing spatial hashing might be better), but SpacetimeDB is very fast so for this number of entities it'll be a breeze for SpacetimeDB."
>> Nothing is quantified with numbers.
"For every circle, we look at all other entities."
>> This is the most inefficient N^2 way you could do collision detection.
And not to mention networked physics is a whole additional layer of complexity, where you have to use some form of prediction techniques and very likely end up changing your core physics code to accommodate this.
All of this suggests to me much thought has not been put into the claim "you can also do physics with it!" and its implications. Perhaps it is enough for extremely simple physics, as demonstrated with their demo game. If the author is reading this, I suggest spending some time understanding what this claim implies and qualifying it better.
However I must mention that I applaud their courage to try something so outlandish. If you truly believe your claims are possible, I encourage you to keep working on it.
But I'll be convinced when extraordinary evidence backs extraordinary claims.
Source: I work on a commercial game physics engine and related netcode.
I believe they've done more complicated physics in their game bitcraft, but that code hasn't been released yet (no idea if it will be.) But there has been work in the discord recently and 2 member have individually implemented rapier[1] at this point. I can't say anything about the related netcode however as I don't know how much they've focused on it. At the very least work has been done.
The unity tutorial is just to get up and running as fast as possible in the simplest way possible, not to make the perfect decisions for a networked physics based game.
I however do think they should provide an actual reference to prove the claim,
Nice, that's very interesting and a commendable achievement!
If that is the case I would really like to see some internals of how the physics engine has been implemented in their pattern. I'm not asking for the rapier port source code, but it is hard to think in terms of a new advertised programming paradgim when there's no working examples.
For example I am very curious to see how a constraint solve is implemented in a SQL-like fashion. You would need various math operations and an efficient matrix representation off the top of my head, and I can't think of how that maps to a SQL-like interface.
On of the people who implemented it is from unity, from my understanding he can't actually release the code. For the other guy, this was his last comment on the matter
> Sure, my plan was to write a readme and share the code with my colleagues anyway. It should be ready by the weekend because I'm in the middle of a refactoring right now.
> The gist of it: each time a System adds a "movable" component to a StDb table, it also adds the rigid body and collider in Rapier. Then, a scheduled reducers updates the simulation then fetches resulting positions and velocities from Rapier and updates the "movable" components. I have no client prediction at this time.
So my understanding is rapier is just compiled into the wasm and run like normal while the results are stored into the table for clients to receive via subscription. I won't say it's a perfect solution, but efforts are being made by the small community to see how we can really push the db.
Note: while it's all very procedure like you can just store data normally in the rust side, you just have to push the information to the table for it to be query-able.
I see, that's extremely interesting. As mentioned earlier, I do respect efforts to push on something new, especially if it's against conventional wisdom and would be interested in poking around with an open mind. I'll join the Discord.
Thank you!
Then again looking at the FAQ for Bitcraft, we have this:
"What engine does BitCraft use?
The BitCraft client is developed using the Unity game engine. For the server, we have developed a sophisticated distributed system called SpacetimeDB, which hosts the entirety of BitCraft’s server architecture. "
Correct me if wrong, but this suggests the physics engine is Unity's, and not something implemented in SpacetimeDB.
I didn't truly know and I didn't want to just throw out a guess so I just asked. They mentioned they have a basic hand rolled system for their physics. So not using unity physics.
I guess making the claim that is was more complicated might have not been right for me to do, but it would be hard to believe that they did the degenerate case of O(n^2).
Speculation: I have only written a physics engine once during college (so please excuse my ignorance), but I think for a basic mmo a simple chunk and AABB approach would work. It would be easy to query for the surrounding chunks and just run the collision on that subset. I know one of the team members was working on porting a minecraft 1.7.3 server at one point, but I don't know if they got up to the point of moving collision off of the server and into the database.
Thank you for asking and forwarding the answer. I appreciate your comments.
Speculation as well: Looking at the trailer for Bitcraft, it looks like they have articulated characters and cloth physics. This raises more questions for me.
I am contributing to a project by a SpacetimeDB community member to get Rapier running within Unity. Instead of trying to get Unity PhyX running on the server, we just use a deterministic Rust physics engine on both client and server. It is a mostly complete drop in replacement as it stands and is deterministic (Unity's PhyX is not). We'll keep improving it!
We rely on the guarantees of Rapier's determinism. I haven't done extensive testing on the determinism claim yet, but it has held up so far.
https://rapier.rs/
It's a cool technology, but the hard thing about building an MMO is architecture, not just making the server faster / wider. If you want a good overview of the types of problems to be solved in scaling an MMO, check out https://youtu.be/-c4t3Y5l5jY.
There is a pretty big underlap between these problems, and the ones solved by SpacetimeDB. So much so that if you built a system using both SpacetimeDB and another, high-level tool to manage chunking, transitioning, server provisioning etc. it would obviously be the latter system that was more indispensable to scaling your MMO.
As a game dev I don't really see what problems this solves. Most of the work you would have in games is related to simulation - something this doesn't help you with at all. It can actually make simulation more difficult because all your state would be decoupled from a game engine (which is built for simulation). So you'd end up having game servers running the simulation syncing to SpacetimeDB... or of course you try to build the simulation inside SpacetimeDB with no help from it.
1. Server <> client sync is handled for you
2. Server <> database sync is eliminated
3. Deployment is super easy because you just upload your wasm module to the database, and SpacetimeDB schedules it (similar to Kubernetes honestly, but at a different level of the stack)
The first two problems are nothing, IMO. Server <> client sync is handled by your engine or, if you need to roll your own, it's not that hard. Syncing to a database is more tedious than difficult.
Getting rid of a game engine on the server side adds a lot more work. I don't think it would even balance out.
Having implemented the first two for a web game i absolutely guarantee you those are far from "nothing". It takes considerable diagraming & handling to coordinate FE + API on state changes.
If they in fact can solve that (haven't checked myself), it would be a massive time saving for development.
Maybe I'm just used to it having implemented it several times. But my point is that they require a relatively fixed amount of effort. Once it's implemented you shouldn't need to touch it again.
No, just say no.
Do not conflate your relational database schema with however you treat that data in your app.
You want explicit control, not annotation magic.
This sounds like a fundamental disagreement with using ORM. Are you advocating for always writing queries (not excluding the possibility of a query builder) over treating database rows as application-side entities that can have CRUD operations performed on them / persisted?
This looks to be an in memory db, with a wasm runtime to host domain logic. The hand wavy part was how do they handle scale and clustering? Are we sharding the data our selves (atm it seems so.).
This is nice and all but the hard part is replication and consistency in a distributed database. In memory has its uses, also disk backed tables can have their uses. Pretty much normal databases already do this, just writing domain logic in stored procs is kind of annoying.
I'd imagine embedding sqlite in your binary using memory tables is equivalent at the moment. Well you'd have to write code to publish table updates to clients. I suppose it has that going for it.
I've seen some hand wavy docs about clustering but nothing concrete.
Is there a place where I can read about what technologies online games use? As a terminal gamer I am ashamed to say I have no idea what goes on behind the scenes.
Assuming you're referring to the backend side of things for online/multiplayer games, working through the Hathora tutorials in the docs can be a good first introduction to general idioms related to backend systems architecture: https://docs.hathora.dev/#/builder/
From my past consulting experience though, the distributed systems side of games is all over the place. Designs tend to need to be customized for each games needs, which usually directly influences which technologies are chosen.
Does this make any sense in single-player games, where the db would run locally on the user's machine? Does it have any benefit to run all game state through a local db?
I'm not a game dev, but I'm imagining that if I'd write a custom game engine, I'd have to write just the "frontend" aka. graphics engine if I'd have a robust state manager (+tooling) as a separate piece of software.
Some algorithms are much more easily represented as SQL or that plus a little wrapper code. E.g., somebody re-wrote E-Graphs Good using SQL as their primitives, and that viewpoint made a bunch of other features and optimizations obvious.
Stated somewhat differently, do you want to write the algorithm to do a 3-connected recursive join in linear time, or do you want to slap the join into a DB and move on with your life?
For a concrete example, a DB could make the Entity-Component architecture even simpler to use than it already is (give me all the npcs in this radius who haven't attacked in the last second, have a distance attack, and are facing the right direction).
Would it have performance pitfalls if you weren't careful? Almost certainly. It could be a fun way to structure a game though.
Oh, sure, the complaint wasn't about SQL per se, but that making complicated things easy to write isn't necessarily a win. Even if a big query perfectly represents the problem, and even if you can use compiled SQL to match hand-written efficiency, it still might not be the optimal way to approach the problem in the first place. If you have experience and plan for that it needn't be bad at all, but I think it's easier to write performance footguns in SQL (the "right" data model is more prescriptive, even with some number of years of experience, and is less likely to be tuned to your actual problems) than with traditional code, so I'd be quite surprised if the majority of game developers (even those with some degree of success currently average <3 YOE) wouldn't run into major performance issues with a SQL-based engine, even a good one.
SpacetimeDB looks promising for temporal-spatial data. The compact storage format and optimized query processing could enable new analytics use cases. I'm curious about the scalability and how it compares to alternatives like TimescaleDB or KDB+. Benchmarks and open-sourcing the core would help drive adoption. Overall, exciting project!
We want to dial these numbers in, but we have to err on the side of too high, because it's easier to lower prices than to raise them. We want to bring it down as low as we possibly can.
Interesting, been tinkering on a similar project of my own. Main similarity is also combining database/server-simulation even if it seems like some parts of the design might differ. Gonna take a deeper look when I get home later.
Its areally great effort, but i would stick with PostgreSQL with PL/SQL procedure and tons of extensions.
Lowering down the TRSACTION LEVEL, Async transctions on disk backed tables and UNLOGGED Tables can help you go a long way.
Also, in next major version (v18) of PG, they are trying to implment io_uring support which will further drastically improve the random read/write performance.
This feels like very old-school java client/server architectures.
>This means that you can write your entire application in a single language and deploy it as a single binary. No more microservices, no more containers, no more Kubernetes, no more Docker, no more VMs, no more DevOps, no more infrastructure, no more ops, no more servers.
This is an abstraction layer that will end up being applied on top of most or all of those technologies. You can't hide from the fact that the database instances need to run on something.
I found the idea of polling DB queries interesting. They basically took what is done with HTTP and pushed it down the stack directly in the DB server, eliminating the extra SQL round trips one needs to make server-side in order to provide updates. Neat!
I wish you success! And hopefully you don't end up disappearing like SpatialOS. They tried very hard promoting its capacity for large scale MMO, even published a game (Scavenger IIRC?) made with it.
They had an MMO-targeted database called Spacebase, and a bunch of awesome JVM technology. Their founder actually works for Oracle now, if I'm not mistaken.
A server DB monolith that explicitly doesn't scale?
You put some of your game logic on the server and some on the client with no clear dividing line?
When PoE2 uses PostGres and Eve Online uses SQLServer?
Also doesn't tackle the main challenges of online multi-player games (physics sim rollback)?
I'm sorry but there might not be a good market for this.
It scales much the same way that Erlang/BEAM scales. Each database is an actor in a distributed actor system. That's how we operate BitCraft, however we haven't released inter-module communication (IMC) to the wider world yet.
You mention it runs in process? How does this occur? You mention running cached in memory tables. So you're caching on at the application level, not the storage level?
There's a few things with the video I find misleading. You mention 400ms at best to parse, plan and execute a query; That's not true, what about the type of query, etc.
Overall I can see it's still early, which is ok. I will review the code and see what else I can find.
One more question I have is how are you handling the cluster architecture. I don't see that on the website. You mention on the pricing a cluster and replication but scaling horizontally is rather important and we definitely want to know how you're achieving scalability.
One question I have is what is the plan on implementing full SQL? I see currently you're only implementing maybe 15% of SQL92. Are you implementing your own SQL-like language?
Seems like a neat idea, but for the love of Jesus Christ offer me a flat rate billing solution. Or at least an option of doing that. This seems like the type of thing that will accidentally burn through all of your credits if you code something wrong, and then you're going to have to beg their tech support to refund you.
I had an idea last night for an RTS like game where the units can only be controlled via radio commands which are only sent every minute or so, but this feels like a very strange way to do it. Not to mention hey it's not open source, but after 4 years will open source everything ?
Why, why wouldn't I just want to pay render or something $7 a month for a normal server versus this ? And use an actual open source stack.
SpacetimeDB is open source[1], the open source version doesn't currently have all the features of maincloud, but most of those features are solely for scalability. I've done all of my work on my own local servers. I would even suggest paying for your own server up front until you're ready to scale out. I believe the 4 years is when the license changes to a more open license. And the scalability features on local are coming, they're just not here yet.
I kept on reading expecting to see motion prediction, multiversion, or similar given the name and focus on games, but no. This is a totally normal database, designed for low latency and with support for WASM stored procedures. You can host your own server or they will rent you one.
Don't get me wrong, this looks very nice. It looks like a solid building block for persistent worlds in multiplayer games. You'll just have to do your lag masking netcode yourself.
I'm Tyler (guy in the video). In BitCraft we currently implement client-side prediction outside of SpacetimeDB.
However, we DO plan to add automatic client-side prediction as a feature for SpacetimeDB in the near-ish future! Because all your server-side logic is in Wasm modules, we plan to run an embedded version of SpacetimeDB to execute the server logic on the client. As long as the server and client agree on the changes to the data we can reconcile the transactions, otherwise we'll rollback. Notably, we can do this with only partial state on the client!
We can also do deterministic simulation if you have total knowledge of the game state with this solution as well.
How would you simulate physics, pathfinding, animation state on the server using this tech? Do you have to ditch your engine (do I have to reimplement what unity/unreal gives me for free?) ?
Cool, jumping in as a noob to multiplayer dev, so currently for BitCraft MMORPG simulation, e.g. to prevent "god-mode flying", would be done outside the server.
Q How is that coordinated with the SpacetimeDB? Is there a penalty, or perhaps a correction applied to the malicious client (and replicated to listening clients) in the case a hacker modifies their movement illegally?
Since SpacetimeDB would be your backend (game client <-> SpacetimeDB) you would need to verify the inputs to your reducers to prevent cheating. Not really different from anything else.
But that's completely different from how Unreal typically does it. Movement is client-side predicted and server authoritative out of the box. How does SpacetimeDB even know the collisions of my level?
If I were to cheat and disable all wall collisions on the client. An Unreal server would roll me back, to all other people it would look like I'm walking into the wall. How do you even get SpacetimeDB to run Unreal's runtime (because movement kind of depends on deterministic results for frames). How does SpacetimeDB get hold of the assets (collisions)?
I am also skeptical of SpacetimeDB for the same reason. There is no game engine helping you do any simulation and that makes development harder. Your (server-side) assets would somehow need to be synced to SpacetimeDB which possibly means you can't use your editor tools to design them anymore.
As a service backend+database the concept is cool and probably useful. But I don't see it being good at being a game server.
Reading/hearing talks from people doing server backends there is many half insane things being done to keep servers and persistence in check, and everyone still a different custom solution.
A common scenarios:
- "Game-server" using "regular" server+DB frameworks, often works but seldom in real-time scenarios.
- Realtime Game-servers (with in-memory state, sometimes supporting rollback,etc) that then has persistence more or less as an afterthought (duplicating state management between client<->server<->persistence)
What spacetime tries to do (and my current experiment) is to merge the server and DB to move persistence _performance_ concerns into the backend process.
We _rightfully_ moved databases out of server processes for easier management and safety in the 90s, but since f.ex. SQLite has been a bit of a resurgence because the usercode was in a managed language and wasn't as likely to cause a corruption issue.
WASM is a great enabler here because it allows the server/DB to sandbox the logic-code even in "unsafe"/realtime languages from the more precarious DB parts of the process so we don't have to risk data-safety even as we move back to co-locating server-state and persistence data within the same process.
I have also experimented in this space but came to the conclusion that it's not good for games. Not necessarily because it's a bad idea but because it's not how games are made. To make a game with something like SpacetimeDB you would need to build a game engine. You'd also need to build out tooling for managing assets for the server.
One thing about SpacetimeDB that I'm not sure about is if reducers can run concurrently or not. I would hope so but it's very possible they don't and that can be a big regression vs. current game servers.
Prediction can definitively be argued that it belongs in a layer above it, multi-version/rollback/reconciliation should be integrated however and I don't really see any mention of it from a quick skimming. (really need to take a closer look later today).
Hey, can you please make your substantive points without shallow dismissals or snark? This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html. Unfortunately you posted a few comments in this thread that have crossed that line.
If you know more than others as a professional multiplayer game developer, that's great, but in that case the thing to do is to share some of what you know, so others can learn. If you don't want to do that, that's fine, but in that case please don't post. Putdowns and swipes only degrade the discussion.
Tom I'm afraid you're misreading the tone of my posts and their character.
I could post anything objectively true in this thread like "the sky is blue", and some idiot will post a one sentence response that in fact it's not. This idiot likes to be the last person getting snark in responding to a completely reasonable statement of fact or opinion by an expert in the space.
What I do differently is that yes, I do reply to the snark with a rebuttal. Is this rebuttal snarky? Potentially, but is it earned? Definitely.
You're moderator so let me speak to you that way. If you don't let people rebut bullshit in this comment section, you'll just end up with a bunch of uninformed discourse, where the final word is made by some idiot, who doesn't even make multiplayer games and everyone ends up thinking the sky is fucking green. This has real world consequence when future game developers try to build games on poorly made technology, which ruins game studios and people's lives.
Then again, it's hacker news, and what do a bunch of wannabe startup guys know about making games in the first place. Unskilled and unaware of it. Moderate away sir!
You can "rebut bullshit" without being aggressive and nasty. If someone else is wrong, it's enough to provide correct information respectfully. Putting others down, or slamming their work in a hostile way, doesn't help and degrades this community badly.
Btw, it's quite common for commenters to underestimate the provocation in their own posts and overestimate the provocation in other people's posts. Those two factors can multiply into quite a skew in perception (https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...). I wonder whether this might be a bit of a factor here, if you really don't see how aggressively your comments were coming across.
In my experience providing detailed information in a response in the comment section on this particular topic (game development and networking) in hacker news comments simply creates more surface area for nitpicking and arguing in response, so I keep to short responses and rebuttals.
In the future, I don't feel that writing anything more here on this topic is a worthwhile use of my time.
Just want to chime in that although this comment is a bit harsh, it does hold a lot of truth. As a game netcode engineer, most of my time is spent on latency hiding techniques and its consequences (for example, we use rollback netcode and lots of efforts are spent on minimizing visual/sound glitches when mispredict, rollback and reconcile). There are lots of middleware that help with this (eg. Photon, SnapNet, etc) but in general there's no silver bullet - it's highly gameplay specific. Even for the same game, the solution can vary depending on different trade-offs (i.e. budget, correctness/anticheat).
As to how to store the game state in memory, it's usually not something that needs much thinking: it's simply done the same way (or similar) as the game's client code. After all, netcode is mostly about efficient state replication and this saves CPU time when replicating it across clients - and gives more CPU time for minimizing bandwidth (like delta encoding, quantization, etc). If you want, you can utilize some techniques like ECS to optimize for CPU cache locality, but it affect gameplay code a lot and would need to get the whole team onboard.
Also, I just noticed the username "gafferongames" - Glenn's blog[1] has been a must-read for netcode engineers. It helped me a lot when I started working on netcode in the 2010s
Well, I'm not a professional gamedev, nor did I ever do much multiplayer code, but:
1) AFAIR, the ECS patterns family[0] originally came from MMORPG world, and boiled down to designing your game state to work well with relational databases;
2) Around 6 years ago, while toying with yet another (see [0]) take on ECS for a simple game, and wondering how to query stuff efficiently, it dawned on me that the code I'm writing is basically implementing spacial indices and other such concepts from relational DB world. At that point, I thought to myself, "why continue wasting time Greenspunning[1] a database for the internal state, when I could use a real one?", and followed by "you know what I really need next? An in-memory SQLite database to store all my runtime game state!".
I didn't get very far with my experiment due to constraints of adult life, but I did prove that I can build a basic Roguelike skeleton (2D tile map, entities, walls, collisions) while storing all state in SQLite, and have it run at 60 FPS with half of the frame time to spare for other things, on moderately powerful machine (as of 6 years ago), all without too much optimization (Common Lisp with FFI bindings to libsqlite3 + a simple RLU cache in front of queries).
So it's not at all a stupid idea, IMO :). I would test it further if I had the time.
--
[0] - The term means different things to different people. I've seen at least three distinct gamedev design patterns claiming the name ECS for themselves, all conceptually incompatible with each other. More, if you also consider "whatever Unity/Unreal/Godot/... calls ECS".
We can and plan to handle the complex lag masking netcode as well. We've just focused so far on games that don't need very sophisticated lag compensation
TODO does not imply no plan or that we haven't thought deeply about the problem. Prioritization is imperative when you're building an MMORPG and a new database with a small team for both.
How can you think deeply and plan for something when you don't know what don't know. You can only really understand these things when you've taken a game using these latency hiding techniques into production, and then after this, you'll probably realize that some of your original ideas were wrong. Where does this leave SpacetimeDB then?
This company focused all it's effort in reinventing the part of multi-player games that did not need reinventing.
40 engineers for 5 years. I'm guessing at least 20 million dollars spent. 1 million trailer views... Let's say 100k wishlists, 10,000 sales at 30 LTV. 300k in revenue
This company will need to pivot if the game is not successful.
I would say the db could be pivoted for multi-player Figma style apps rather than games, but the coupling of server and db means you can't scale the db layer the same way you could do with literally every other db solution available s your company scales
I mean, they said they'd like to get your expert input on the matter. Why not give them a chance? Maybe you can help them do some much needed course correction—which is what I understood you're staying by reading a bit between the lines.
Maybe you can even negotiate a consultancy fee with them
You can stay sceptical, but try giving them a chance. You might end up surprising eachother!
Aside: I'm getting into indie game dev recently and love your site!
I mean, they are dogfooding their own database. If they’re making a MMO game with it presumably the game has latency masking netcode, even if it isn’t in part of the database.
"Tyler was a Sr. Data Science Engineer at MZ (the company behind Game of War and Mobile Strike). Prior to working at MZ he was an engineer at Apple. Tyler holds a Masters in Distributed Systems and Machine Learning from Johns Hopkins University."
"Alessandro was a Sr. Software Engineer at Bloomberg, LP where he worked on high throughput distributed pricing systems. He holds a Computer Science and a Biomedical Engineering degree from Johns Hopkins University."
Looks like they've built stuff before.
I don't like this database product because it lacks SDK:s in languages I would touch without getting paid, but I think the idea is sound and rather attractive. For many years I've used Picolisp in a similar way, it bundles an object database with a logic engine and a small Lisp-like programming language, which makes it easy to throw in some data and relations and slap on a web page with standard library widgets.
The BEAM is similar, you push some modules into it and store stuff in ETS and don't bother with RDBMS until you need it. If your data is small or trivially shardable you can get persistence too, with Mnesia.
I'm not so sure they'll be making a lot from that game of theirs, but if their database turns out to be robust it could become competitive with things like Supabase/Firebase and such, because there will be modules for serving web and auth and dashboards and whatnot you can just push in there and you're good to go. One-click-install for applications, similar to cPanel and Wordpress rigs, but less messy on the ops side.
Game of War and Mobile Strike look like games to me. Casino-like games for handheld devices rather than God of War, but still games, and likely quite latency sensitive due to the gambling-reminiscent aspects. It also seems like that company had the same idea you have, that selling dedicated networks for latency sensitive systems might be profitable.
If you compare the commit messages on your public repos with those on the SpacetimeDB repo, do you notice any differences?
Seems too biased and harsh. The best lag masking and clientside prediction systems I've experienced as a player are those that are closely integrated with the idiosyncratic gameplay mechanics. I would never expect SpacetimeDB to have a one-size-fits-all solution to this, nor for it to be the central focus of their product.
You will implement terrible lag masking and clientside prediction if you aren't looking at it from the UX perspective, because that is literally the only reason these features exist, to trick players into thinking the game signals are moving faster and with greater frequency through the network than is physically possible. Perhaps you would make better games if you considered the user perspective.
SpacetimeDB fits into a genre of tech that I want to call "universe brain reorgs" - structural re-arrangements that might unlock wild performance increases. The challenge with these is that they require devs to re-align their thinking and it's hard to disentangle if "the problem" is that the technology isn't being fully embraced or if the promises of the tech don't work for your use case.
Other techs in this category have seen a lot of success. I'd classify Elixir and Node as being similar in that you adopt a stack to get access to some rare guarantees and also accept new or exotic limits.
I think these things tend to rely on having clear-eyed visionaries out in front, able to show off their strengths in open source. Without a successful project it's hard to believe the claims. I hope clockwork labs is able to deliver their example game (it seems high risk because, even if the game is a technical wonder - what if it isn't fun?!).
We are definitely inspired by Elixir/BEAM. IMC (inter-module communication) is directly inspired by it.
It is high risk, but I think a risk worth taking.
Absolutely! I work in Elixir and I feel very good about its tradeoffs - and a lot of being good with the tool is knowing when to not use it. This tech is very much out of my wheelhouse but it seems very cool and I hope y'all find a nice fit!
Which tradeoffs does elixir have?
Well, it totally gives up memory mutation. Each value is final (under the hood). So you lose an entire category of optimizations and an entire category of errors. You also gain some new optimizations you can do because values never change. In general that makes it worse at tight loops where you really want optimal machine code and better at handling heterogeneous calls like HTTP requests.
> Node
What's your reasoning behind this? Just being able to run the same code on frontend and backend?
When node first came out, it was pretty revolutionary. Being able to almost instantly start a JavaScript thread from a single file that could support realtime experiences (a la socket.io et al) without a build step felt pretty paradigm shifting
Yeah, nah.
I worked on telco grade systems running on Rhino, in interpreted mode, in 2006. Leveraging Java to JS bindings. Responding to HTTP/JMS/etc.
How would that differ from PHP?
Websockets et al
Node launched before Chrome got WebSocket support. Soon after Google published their own PHP WebSocket server and people had been building their own.
Async io?
At the time, if you needed it, and you typically didn't due to FCGI, you'd use a threading library from PECL.
> could support realtime experiences
Node supports realtime applications? Really? Isn't it garbage collected? Or does the term mean something different in nodejs? I've only come to know the term in the context of time guarantees (i.e. if it's scheduled to run in x, it is guaranteed to run at that time) and that shouldn't apply to nodejs I think? When you schedule something there, I believe it'll run on the first free thread after the timer relapsed - which entirely depends on the load of the system
Theres discussion distinguishing hard real-time (what you describe), firm real-time (infrequent deadline misses are problematic but managable), and soft real-time (missing deadlines aren't a big deal). Node does a pretty hood job with soft real-time.
What games do you know that are hard or firm real-time?
Real-time in this context is more like real-time communication rather than process scheduling.
I think we've diverged from the game context, towards discussion "universal brain reorganizing technologies", nodejs being considered one, and what real-time means in the context of node.
That said, real-time communication _is_ a soft real-time system.
Ya'all are very strict in your definitions then. My definition is "does it feel laggy" or "do I have to walk away and come back when this thing is done".
Basically like 24 FPS or higher is real-time. Even that'd be laggy for a game but not unplayable. I choose this specifically because that's what movies typically use and they're very watchable.
https://en.wikipedia.org/wiki/Real-time_computing
Hard real time (or just "real time" in firmware/hardware contexts) is effectively a term of art. One that's been increasingly watered down by the rest of the industry.
Strict definitions matter when system failure == pacemaker missing a beat or train signalling system drives a freight train into the back of 400 passengers.
But in gaming, real time means something different: https://en.wikipedia.org/wiki/Timekeeping_in_games#Real-time
Context matters.
In game development we still care about the distinction between soft and hard realtime. Almost all games are soft realtime, even if the gameplay itself is turned based as we're processing user input, updating UI, animating things and so on.
A lot of gameplay elements are firm realtime in practice, not unlike something like video decoding.
That definition of real time is not good enough for things like pacemakers, where real time really does actually matter.
[dead]
Realtime in this context probably just refers to the end user experience — multiple people connecting over web sockets to the same backend and seeing the same thing in “real time”.
Did they simply mean "non blocking?"
you're making the common mistake of assuming js devs know anything about core concepts.
they are vibe coding since the beginning.
Like, if you decide to do your backend in rust or python you can choose async or synchronous approaches - but Node locks you into async. I'm not a node developer so I can't sing the praises of what you get, but being locked into JavaScript's process model, VM, and type system is certainly a downside (for which you get the whole JS world). It's another example of...if you are architecting your service and you pick this you are picking some built in trade-offs.
maybe I don't understand something but most if not all node methods have their sync counterparts
You're thinking about JavaScript but I am talking about Node, which fundamentally uses a single-threaded approach[1] to great effect.
[1] https://stackoverflow.com/questions/17959663/why-is-node-js-...
I feel like a lot of the "needs visionaries?, stuff has a pretty high chance of having not much real value.
That's not a judgment on SpacetimeDB, but it is kinda how it plays out with these kinds of things.
IMO it's more that there is value...but the chance that any random developer (i.e. me) is going to be able to realize it is much lower. Your instincts about how do to things will be predictably wrong in this new, different paradigm. You generally want a guide or you risk foot-gun'ing any project through misunderstanding.
Could also be marketing hype! The MMO space tends to be full of this, most famously in the VC funded arena with Improbable. This also suffers from the same problem that Improbable did that there are just not that many people making MMOs but maybe it'll find a niche elsewhere.
I've been making multiplayer games professionally for twenty years from fast-paced shooters to spaceship MMOs and to me this isn't really crazy. If you wanted to make a comparison it's like having SQLite in memory but with the added infrastructure to support networking to clients and persisting state to disk. Obviously there is more work involved than that but conceptually thats where things are at. How nice it is to actually develop a game with is a pretty open question, and almost certainly the most important one when evaluating this sort of product, but you'd be surprised at the range of stacks in existence.
It's a database that emphasizes stored procedures. And if you need it to distribute computing, it has the same challenges as the eliminated "game servers".
In addition, outside of single table updates and selects, SQL has scaling limits. If you throw the computation at the db server as well, you limit the vertical scaling.
Gaming and gamers are used to sharding (and geographic tower of babel us an implicit shard as well).
> SpacetimeDB fits into a genre of tech that I want to call "universe brain reorgs" - structural re-arrangements that might unlock wild performance increases. The challenge with these is that they require devs to re-align their thinking and it's hard to disentangle if "the problem" is that the technology isn't being fully embraced or if the promises of the tech don't work for your use case.
And this is exactly why as a professional multiplayer game developer I'm quite concerned about SpacetimeDB.
If you're a game developer and choose to use it, you must accept that you will completely structurally re-arrange your game server, and gameplay and simulation code in such a way that you'll conform to a database structure and programming model developed by some people who are currently making their first game.
I'd be surprised if any professional game developers would consider this a good idea. The last time somebody suggested such a significant refactor for game servers, was when the two cofounders of Improbable walked into our office at Respawn, shortly after we shipped Titanfall 1, and told us they wanted the complete source code for Titanfall 1, and they would show us how awesome Improbable is, by porting the entire Titanfall codebase to Improbable in just a few months!
They ended up getting the source code, despite all programmers and the technical director advising the COO against it... and we never heard from them again.
[dead]
> SpacetimeDB wasn't built in a vacuum. It's the system powers our own large-scale MMORPG BitCraft. We designed it specifically for the performance requirements of games. That means extremely low latency (~100 us/Tx) and extremely high throughput (~1,000,000 Tx/s).
If you are trying to build a new MMO that scales to the moon, you might want to take a look at how the existing market goes about things.
Take World of Warcraft for example. You could probably put a $20 MySQL VPS behind a realm and have it reliably persist state with how authoritative and infrequently updated the clients are.
Being clever with what you can trust the client with and how the server reconciles events is where I think you will find most of the scaling hacks.
I don't really understand how you would write a game server using this tech. Lets say you need to simulate physics, pathfinding, animation etc on server. How one would integrate all of this? In regular world you just use unreal/unity headless mode that includes all of this but using spacetimedb requires ditching the game engine and reimplementing everything from scratch?
Forgive my ignorance, but why would you implement physics and animations on the server? I feel like you can get away with basic positional data and do the rest of that on the clients.
Just put it all in stored procedures. What could go wrong?
This looks really interesting, and bitcraft looks cute.
I did hit a personal bias: when I saw "maincloud" as a phrase to do with pricing my heart sank because my brain went "they've wedged in some crypto shit!". Turns out no, it's just a naming thing for hosting credits.
There was a lot of crypto-adjacent talk in earlier versions of their marketing and product design. Without it actually being anything actually crypto-adjacent. Analogies drawn to ethereum etc concepts, I guess because they figured somehow there was an audience that would get those references and it would allow them to understand the product better?
I have no idea why. I was hired to work on very early versions of it, and left very early on in part because I wanted nothing to do with that angle. IMO it's a liability.
It had nothing to do with marketing, it was because conceptually stored procedures are similar to smart-contracts and share technical aspects. We thought engineers would find the similarities interesting. Instead they immediately assumed we were shilling tokens, so we pulled it down.
Kind of sad that people can't see past that, but I also understand. It is what it is.
Hey Tyler; looking back I think maybe a better language than "reducers" etc would have been to just something analogous to the ECS term "systems", which I understand to be "processes that operate on entities / components" and always seemed overly general and non-specific to me but at least is familiar to game programmers operating in data driven design.
You may recall I was partial to the term "verb" :-)
I think that's very fair, we've got quite a lot of momentum behind reducers at this point though. That doesn't make it a good, name but it is a sticky one.
"mutation" may also have been a good choice?
Oh it's you! Sorry cmrdporcupine! I didn't see.
I feel like they've been inspired by crypto for the way they handle billing. They sell you "Energy" which you use by running on their infra. Seems like a needless abstraction to me.
Doesn't Snowflake do something similar though?
And Vercel's "compute units"
They do indeed.
This is indeed interesting, but FYI this is a BSL-covered project with somewhat onerous times: only one instance per service (i.e. don't scale out, if I understand correctly) [0].
[0] https://github.com/ClockworkLabs/SpacetimeDB?tab=License-1-o...
YouTube keeps recommending SpacetimeDB to me even though I have never made a videogame. Now I'm seeing it on HN too.
Are there any game devs here who can comment on how useful this actually is? The pitch seems pretty cool but I can't tell how much of it is just good marketing.
Not a developer affiliated with the project. But here's my take:
The problem is that the proof is in the pudding. Some of their claims feel outlandish. Imagine writing your game with SQL queries. Rather than crafting update packets that only contain relevant game info you just do `select * from players where abs(player.x - current_player.x) + abs(player.y - current_player.y) + abs(player.z - current_player.z) < 100^2` and it just updates automagically 60 times a second.
Running physics sim in SQL stored functions sounds insane but that's exactly what they're advertising. They say it's due to in-mem DB optimization but I'm not sure how they horizontally scale that (they allow you to run standalone but any scaling requires their cloud product)
I mean you can download it and give it a try!
For BitCraft we scale it with IMC (inter-module communication). It works very similarly to Elixir.
It's in closed alpha so there's a limited number of players but I am curious to hear more about how BitCraft is scaling out. Is it a single, seamless world for all players? How much scaling is currently required? How is data replicated when horizontal scaling comes into the picture?
Given the name I was also expecting some clever SQL-like data structure/query for fast spatial lookup but I digress.
Game physics involves a lot of things (solvers, collision detection, numerical stability, etc.). I am skeptical of their claims of being able to run physics in what I understand are stored procedures for their database.
I looked at their docs for physics https://spacetimedb.com/docs/unity/part-4 where they demonstrate the simplest form of collision check (sphere overlap). I fail to see how that is an improvement or speedup over existing methods. Some quotes: "This may not be the most efficient way to do collision checking (building a quad tree or doing spatial hashing might be better), but SpacetimeDB is very fast so for this number of entities it'll be a breeze for SpacetimeDB." >> Nothing is quantified with numbers.
"For every circle, we look at all other entities." >> This is the most inefficient N^2 way you could do collision detection.
And not to mention networked physics is a whole additional layer of complexity, where you have to use some form of prediction techniques and very likely end up changing your core physics code to accommodate this.
All of this suggests to me much thought has not been put into the claim "you can also do physics with it!" and its implications. Perhaps it is enough for extremely simple physics, as demonstrated with their demo game. If the author is reading this, I suggest spending some time understanding what this claim implies and qualifying it better.
However I must mention that I applaud their courage to try something so outlandish. If you truly believe your claims are possible, I encourage you to keep working on it.
But I'll be convinced when extraordinary evidence backs extraordinary claims.
Source: I work on a commercial game physics engine and related netcode.
I believe they've done more complicated physics in their game bitcraft, but that code hasn't been released yet (no idea if it will be.) But there has been work in the discord recently and 2 member have individually implemented rapier[1] at this point. I can't say anything about the related netcode however as I don't know how much they've focused on it. At the very least work has been done.
The unity tutorial is just to get up and running as fast as possible in the simplest way possible, not to make the perfect decisions for a networked physics based game.
I however do think they should provide an actual reference to prove the claim,
[1] https://github.com/dimforge/rapier
Nice, that's very interesting and a commendable achievement!
If that is the case I would really like to see some internals of how the physics engine has been implemented in their pattern. I'm not asking for the rapier port source code, but it is hard to think in terms of a new advertised programming paradgim when there's no working examples.
For example I am very curious to see how a constraint solve is implemented in a SQL-like fashion. You would need various math operations and an efficient matrix representation off the top of my head, and I can't think of how that maps to a SQL-like interface.
On of the people who implemented it is from unity, from my understanding he can't actually release the code. For the other guy, this was his last comment on the matter > Sure, my plan was to write a readme and share the code with my colleagues anyway. It should be ready by the weekend because I'm in the middle of a refactoring right now. > The gist of it: each time a System adds a "movable" component to a StDb table, it also adds the rigid body and collider in Rapier. Then, a scheduled reducers updates the simulation then fetches resulting positions and velocities from Rapier and updates the "movable" components. I have no client prediction at this time.
So my understanding is rapier is just compiled into the wasm and run like normal while the results are stored into the table for clients to receive via subscription. I won't say it's a perfect solution, but efforts are being made by the small community to see how we can really push the db.
Note: while it's all very procedure like you can just store data normally in the rust side, you just have to push the information to the table for it to be query-able.
I see, that's extremely interesting. As mentioned earlier, I do respect efforts to push on something new, especially if it's against conventional wisdom and would be interested in poking around with an open mind. I'll join the Discord. Thank you!
Then again looking at the FAQ for Bitcraft, we have this:
"What engine does BitCraft use? The BitCraft client is developed using the Unity game engine. For the server, we have developed a sophisticated distributed system called SpacetimeDB, which hosts the entirety of BitCraft’s server architecture. "
Correct me if wrong, but this suggests the physics engine is Unity's, and not something implemented in SpacetimeDB.
I didn't truly know and I didn't want to just throw out a guess so I just asked. They mentioned they have a basic hand rolled system for their physics. So not using unity physics.
I guess making the claim that is was more complicated might have not been right for me to do, but it would be hard to believe that they did the degenerate case of O(n^2).
Speculation: I have only written a physics engine once during college (so please excuse my ignorance), but I think for a basic mmo a simple chunk and AABB approach would work. It would be easy to query for the surrounding chunks and just run the collision on that subset. I know one of the team members was working on porting a minecraft 1.7.3 server at one point, but I don't know if they got up to the point of moving collision off of the server and into the database.
https://www.youtube.com/watch?v=YYMEUk-tnWs
Thank you for asking and forwarding the answer. I appreciate your comments.
Speculation as well: Looking at the trailer for Bitcraft, it looks like they have articulated characters and cloth physics. This raises more questions for me.
I am contributing to a project by a SpacetimeDB community member to get Rapier running within Unity. Instead of trying to get Unity PhyX running on the server, we just use a deterministic Rust physics engine on both client and server. It is a mostly complete drop in replacement as it stands and is deterministic (Unity's PhyX is not). We'll keep improving it!
https://github.com/Daxode/rapier4unity
That's great, especially the deterministic part. Did you run into determinism problems with two different CPU architectures for server and client?
We rely on the guarantees of Rapier's determinism. I haven't done extensive testing on the determinism claim yet, but it has held up so far. https://rapier.rs/
It's a cool technology, but the hard thing about building an MMO is architecture, not just making the server faster / wider. If you want a good overview of the types of problems to be solved in scaling an MMO, check out https://youtu.be/-c4t3Y5l5jY.
There is a pretty big underlap between these problems, and the ones solved by SpacetimeDB. So much so that if you built a system using both SpacetimeDB and another, high-level tool to manage chunking, transitioning, server provisioning etc. it would obviously be the latter system that was more indispensable to scaling your MMO.
As a game dev I don't really see what problems this solves. Most of the work you would have in games is related to simulation - something this doesn't help you with at all. It can actually make simulation more difficult because all your state would be decoupled from a game engine (which is built for simulation). So you'd end up having game servers running the simulation syncing to SpacetimeDB... or of course you try to build the simulation inside SpacetimeDB with no help from it.
It solves 3 problems:
1. Server <> client sync is handled for you 2. Server <> database sync is eliminated 3. Deployment is super easy because you just upload your wasm module to the database, and SpacetimeDB schedules it (similar to Kubernetes honestly, but at a different level of the stack)
The first two problems are nothing, IMO. Server <> client sync is handled by your engine or, if you need to roll your own, it's not that hard. Syncing to a database is more tedious than difficult.
Getting rid of a game engine on the server side adds a lot more work. I don't think it would even balance out.
Having implemented the first two for a web game i absolutely guarantee you those are far from "nothing". It takes considerable diagraming & handling to coordinate FE + API on state changes.
If they in fact can solve that (haven't checked myself), it would be a massive time saving for development.
Maybe I'm just used to it having implemented it several times. But my point is that they require a relatively fixed amount of effort. Once it's implemented you shouldn't need to touch it again.
> 1. Server <> client sync is handled for you
In what sense? Is it as fast as using UDP with protobuf packets?
Professional multiplayer game developer here. I wonder what multiplayer games the SpacetimeDB folks have actually shipped?
This is theirs https://bitcraftonline.com/ - not "released" yet but they have alpha testers on it apparently.
Would you seriously consider using any technology built by people who are making their first game?
There's this other team that built an MMORPG with SpacetimeDB, in 3 months with 8 people: https://youtu.be/kzDnA_EVhTU&t=717
Seems to have paid off for them: https://play.google.com/store/apps/details?id=com.lightfoxga...
10k downloads, last app store update in November, MMO
Does not feel like it paid off for them. But SpacetimeDB might of course not be the reason for that.
You've got to start somewhere. Dogfooding makes sense.
Same! The algorithm thinks I needed to watch this.
This guy often comes here from HN, give him some Rust, Elixir, why JavaScript framework of the day sucks, and this SpacetimeDB thing!
This sounds like a fundamental disagreement with using ORM. Are you advocating for always writing queries (not excluding the possibility of a query builder) over treating database rows as application-side entities that can have CRUD operations performed on them / persisted?
This looks to be an in memory db, with a wasm runtime to host domain logic. The hand wavy part was how do they handle scale and clustering? Are we sharding the data our selves (atm it seems so.).
This is nice and all but the hard part is replication and consistency in a distributed database. In memory has its uses, also disk backed tables can have their uses. Pretty much normal databases already do this, just writing domain logic in stored procs is kind of annoying.
I'd imagine embedding sqlite in your binary using memory tables is equivalent at the moment. Well you'd have to write code to publish table updates to clients. I suppose it has that going for it.
I've seen some hand wavy docs about clustering but nothing concrete.
A relational DB + serverless compute + suspiciously fast updates
Haha, yes very suspiciously fast!
Is there a place where I can read about what technologies online games use? As a terminal gamer I am ashamed to say I have no idea what goes on behind the scenes.
Assuming you're referring to the backend side of things for online/multiplayer games, working through the Hathora tutorials in the docs can be a good first introduction to general idioms related to backend systems architecture: https://docs.hathora.dev/#/builder/
From my past consulting experience though, the distributed systems side of games is all over the place. Designs tend to need to be customized for each games needs, which usually directly influences which technologies are chosen.
Previous Discussions
https://news.ycombinator.com/item?id=43593913
Does this make any sense in single-player games, where the db would run locally on the user's machine? Does it have any benefit to run all game state through a local db?
I'm not a game dev, but I'm imagining that if I'd write a custom game engine, I'd have to write just the "frontend" aka. graphics engine if I'd have a robust state manager (+tooling) as a separate piece of software.
Some algorithms are much more easily represented as SQL or that plus a little wrapper code. E.g., somebody re-wrote E-Graphs Good using SQL as their primitives, and that viewpoint made a bunch of other features and optimizations obvious.
Stated somewhat differently, do you want to write the algorithm to do a 3-connected recursive join in linear time, or do you want to slap the join into a DB and move on with your life?
For a concrete example, a DB could make the Entity-Component architecture even simpler to use than it already is (give me all the npcs in this radius who haven't attacked in the last second, have a distance attack, and are facing the right direction).
Would it have performance pitfalls if you weren't careful? Almost certainly. It could be a fun way to structure a game though.
If you know all of your queries ahead of time, then compiling them efficiently has already been shown to be effective.
Noria
https://github.com/mit-pdos/noria
https://www.youtube.com/watch?v=kVv9Pik6QGY
https://thesquareplanet.com/research/
Materialize/TimelyDataflow
https://scholar.google.com/citations?hl=en&user=YYJ3aycAAAAJ...
Oh, sure, the complaint wasn't about SQL per se, but that making complicated things easy to write isn't necessarily a win. Even if a big query perfectly represents the problem, and even if you can use compiled SQL to match hand-written efficiency, it still might not be the optimal way to approach the problem in the first place. If you have experience and plan for that it needn't be bad at all, but I think it's easier to write performance footguns in SQL (the "right" data model is more prescriptive, even with some number of years of experience, and is less likely to be tuned to your actual problems) than with traditional code, so I'd be quite surprised if the majority of game developers (even those with some degree of success currently average <3 YOE) wouldn't run into major performance issues with a SQL-based engine, even a good one.
Discussion last week: https://news.ycombinator.com/item?id=43593913
SpacetimeDB looks promising for temporal-spatial data. The compact storage format and optimized query processing could enable new analytics use cases. I'm curious about the scalability and how it compares to alternatives like TimescaleDB or KDB+. Benchmarks and open-sourcing the core would help drive adoption. Overall, exciting project!
$0.28/gb for net traffic on the Maincloud is pretty brutal.
We want to dial these numbers in, but we have to err on the side of too high, because it's easier to lower prices than to raise them. We want to bring it down as low as we possibly can.
Yeah this alone makes this a total non-starter. Do the math at 100k CCU
YouTube suggested the video on this. It seems pretty interesting, but I'm curious how well it works in the real world.
https://www.youtube.com/watch?v=kzDnA_EVhTU&t=753s
Interesting, been tinkering on a similar project of my own. Main similarity is also combining database/server-simulation even if it seems like some parts of the design might differ. Gonna take a deeper look when I get home later.
Its areally great effort, but i would stick with PostgreSQL with PL/SQL procedure and tons of extensions.
Lowering down the TRSACTION LEVEL, Async transctions on disk backed tables and UNLOGGED Tables can help you go a long way.
Also, in next major version (v18) of PG, they are trying to implment io_uring support which will further drastically improve the random read/write performance.
This feels like very old-school java client/server architectures.
>This means that you can write your entire application in a single language and deploy it as a single binary. No more microservices, no more containers, no more Kubernetes, no more Docker, no more VMs, no more DevOps, no more infrastructure, no more ops, no more servers.
This is an abstraction layer that will end up being applied on top of most or all of those technologies. You can't hide from the fact that the database instances need to run on something.
I found the idea of polling DB queries interesting. They basically took what is done with HTTP and pushed it down the stack directly in the DB server, eliminating the extra SQL round trips one needs to make server-side in order to provide updates. Neat!
>SpacetimeDB wasn't built in a vacuum. It's the system powers our own large-scale MMORPG BitCraft.
I checked out BitCraft and it's not released yet. Don't know if I'm being unfair here, but isn't this a bit misleading?
I wish you success! And hopefully you don't end up disappearing like SpatialOS. They tried very hard promoting its capacity for large scale MMO, even published a game (Scavenger IIRC?) made with it.
Is it similar to rethinkdb, I remember using RethinkDB for similar use case for live queries running directly on database layer back in 2016.
The “server in DB” is also the Convex model, but Convex is more tailored towards JS full stack apps:
https://www.convex.dev/
The website and naming (and product space, sorta) remind me a lot of Parallel Universe. Any direct inspiration there, or shared personnel?
I haven't heard of Parallel Universe. What is it?
They were a YC company from a while back: https://techcrunch.com/2012/07/09/parallel-universe-spacebas...
They had an MMO-targeted database called Spacebase, and a bunch of awesome JVM technology. Their founder actually works for Oracle now, if I'm not mistaken.
A server DB monolith that explicitly doesn't scale? You put some of your game logic on the server and some on the client with no clear dividing line? When PoE2 uses PostGres and Eve Online uses SQLServer? Also doesn't tackle the main challenges of online multi-player games (physics sim rollback)?
I'm sorry but there might not be a good market for this.
It scales much the same way that Erlang/BEAM scales. Each database is an actor in a distributed actor system. That's how we operate BitCraft, however we haven't released inter-module communication (IMC) to the wider world yet.
Is this similar to the way HeroEngine works? IIR, that was basically a big database server (that wasn't compatible with anything else).
How do you integrate this with unreal engine 5.5
Unreal (and C++) support is coming!
Very cool, keep it up. Always good to see innovations, creativity and curiosity in the database space.
Another few pieces here listening to your video. https://www.youtube.com/watch?v=kzDnA_EVhTU
You mention it runs in process? How does this occur? You mention running cached in memory tables. So you're caching on at the application level, not the storage level?
There's a few things with the video I find misleading. You mention 400ms at best to parse, plan and execute a query; That's not true, what about the type of query, etc.
Overall I can see it's still early, which is ok. I will review the code and see what else I can find.
One more question I have is how are you handling the cluster architecture. I don't see that on the website. You mention on the pricing a cluster and replication but scaling horizontally is rather important and we definitely want to know how you're achieving scalability.
One question I have is what is the plan on implementing full SQL? I see currently you're only implementing maybe 15% of SQL92. Are you implementing your own SQL-like language?
i've tried it, it works, it's nice :) got a mini mmo running with several people at once running around
Seems like a neat idea, but for the love of Jesus Christ offer me a flat rate billing solution. Or at least an option of doing that. This seems like the type of thing that will accidentally burn through all of your credits if you code something wrong, and then you're going to have to beg their tech support to refund you.
I had an idea last night for an RTS like game where the units can only be controlled via radio commands which are only sent every minute or so, but this feels like a very strange way to do it. Not to mention hey it's not open source, but after 4 years will open source everything ?
Why, why wouldn't I just want to pay render or something $7 a month for a normal server versus this ? And use an actual open source stack.
SpacetimeDB is open source[1], the open source version doesn't currently have all the features of maincloud, but most of those features are solely for scalability. I've done all of my work on my own local servers. I would even suggest paying for your own server up front until you're ready to scale out. I believe the 4 years is when the license changes to a more open license. And the scalability features on local are coming, they're just not here yet.
[1] https://github.com/ClockworkLabs/SpacetimeDB
>I believe the 4 years is when the license changes to a more open license.
Why not use something with a vastly friendlier license. Most companies don't want to play the GPL dance when alternatives exist.
Minor critique - the logo is almost exactly the same as Grok's
Ours came first :/
am i the only one who hoped (and thought from the logo) that this was by the Spaceteam devs?
Best comment from last time this got posted:
I kept on reading expecting to see motion prediction, multiversion, or similar given the name and focus on games, but no. This is a totally normal database, designed for low latency and with support for WASM stored procedures. You can host your own server or they will rent you one. Don't get me wrong, this looks very nice. It looks like a solid building block for persistent worlds in multiplayer games. You'll just have to do your lag masking netcode yourself.
https://news.ycombinator.com/item?id=43593913
Just to copy in my response from there too:
I'm Tyler (guy in the video). In BitCraft we currently implement client-side prediction outside of SpacetimeDB.
However, we DO plan to add automatic client-side prediction as a feature for SpacetimeDB in the near-ish future! Because all your server-side logic is in Wasm modules, we plan to run an embedded version of SpacetimeDB to execute the server logic on the client. As long as the server and client agree on the changes to the data we can reconcile the transactions, otherwise we'll rollback. Notably, we can do this with only partial state on the client!
We can also do deterministic simulation if you have total knowledge of the game state with this solution as well.
How would you simulate physics, pathfinding, animation state on the server using this tech? Do you have to ditch your engine (do I have to reimplement what unity/unreal gives me for free?) ?
Cool, jumping in as a noob to multiplayer dev, so currently for BitCraft MMORPG simulation, e.g. to prevent "god-mode flying", would be done outside the server.
Q How is that coordinated with the SpacetimeDB? Is there a penalty, or perhaps a correction applied to the malicious client (and replicated to listening clients) in the case a hacker modifies their movement illegally?
Tx for sharing your time btw!
Since SpacetimeDB would be your backend (game client <-> SpacetimeDB) you would need to verify the inputs to your reducers to prevent cheating. Not really different from anything else.
But that's completely different from how Unreal typically does it. Movement is client-side predicted and server authoritative out of the box. How does SpacetimeDB even know the collisions of my level?
If I were to cheat and disable all wall collisions on the client. An Unreal server would roll me back, to all other people it would look like I'm walking into the wall. How do you even get SpacetimeDB to run Unreal's runtime (because movement kind of depends on deterministic results for frames). How does SpacetimeDB get hold of the assets (collisions)?
I am also skeptical of SpacetimeDB for the same reason. There is no game engine helping you do any simulation and that makes development harder. Your (server-side) assets would somehow need to be synced to SpacetimeDB which possibly means you can't use your editor tools to design them anymore.
As a service backend+database the concept is cool and probably useful. But I don't see it being good at being a game server.
Reading/hearing talks from people doing server backends there is many half insane things being done to keep servers and persistence in check, and everyone still a different custom solution.
A common scenarios:
- "Game-server" using "regular" server+DB frameworks, often works but seldom in real-time scenarios.
- Realtime Game-servers (with in-memory state, sometimes supporting rollback,etc) that then has persistence more or less as an afterthought (duplicating state management between client<->server<->persistence)
What spacetime tries to do (and my current experiment) is to merge the server and DB to move persistence _performance_ concerns into the backend process.
We _rightfully_ moved databases out of server processes for easier management and safety in the 90s, but since f.ex. SQLite has been a bit of a resurgence because the usercode was in a managed language and wasn't as likely to cause a corruption issue.
WASM is a great enabler here because it allows the server/DB to sandbox the logic-code even in "unsafe"/realtime languages from the more precarious DB parts of the process so we don't have to risk data-safety even as we move back to co-locating server-state and persistence data within the same process.
I have also experimented in this space but came to the conclusion that it's not good for games. Not necessarily because it's a bad idea but because it's not how games are made. To make a game with something like SpacetimeDB you would need to build a game engine. You'd also need to build out tooling for managing assets for the server.
One thing about SpacetimeDB that I'm not sure about is if reducers can run concurrently or not. I would hope so but it's very possible they don't and that can be a big regression vs. current game servers.
Prediction can definitively be argued that it belongs in a layer above it, multi-version/rollback/reconciliation should be integrated however and I don't really see any mention of it from a quick skimming. (really need to take a closer look later today).
[flagged]
Hey, can you please make your substantive points without shallow dismissals or snark? This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html. Unfortunately you posted a few comments in this thread that have crossed that line.
If you know more than others as a professional multiplayer game developer, that's great, but in that case the thing to do is to share some of what you know, so others can learn. If you don't want to do that, that's fine, but in that case please don't post. Putdowns and swipes only degrade the discussion.
Excuse me Tom, please stop with ad hominem and attack the topic not the poster.
Tom I'm afraid you're misreading the tone of my posts and their character.
I could post anything objectively true in this thread like "the sky is blue", and some idiot will post a one sentence response that in fact it's not. This idiot likes to be the last person getting snark in responding to a completely reasonable statement of fact or opinion by an expert in the space.
What I do differently is that yes, I do reply to the snark with a rebuttal. Is this rebuttal snarky? Potentially, but is it earned? Definitely.
You're moderator so let me speak to you that way. If you don't let people rebut bullshit in this comment section, you'll just end up with a bunch of uninformed discourse, where the final word is made by some idiot, who doesn't even make multiplayer games and everyone ends up thinking the sky is fucking green. This has real world consequence when future game developers try to build games on poorly made technology, which ruins game studios and people's lives.
Then again, it's hacker news, and what do a bunch of wannabe startup guys know about making games in the first place. Unskilled and unaware of it. Moderate away sir!
You can "rebut bullshit" without being aggressive and nasty. If someone else is wrong, it's enough to provide correct information respectfully. Putting others down, or slamming their work in a hostile way, doesn't help and degrades this community badly.
https://news.ycombinator.com/newsguidelines.html
Btw, it's quite common for commenters to underestimate the provocation in their own posts and overestimate the provocation in other people's posts. Those two factors can multiply into quite a skew in perception (https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...). I wonder whether this might be a bit of a factor here, if you really don't see how aggressively your comments were coming across.
In my experience providing detailed information in a response in the comment section on this particular topic (game development and networking) in hacker news comments simply creates more surface area for nitpicking and arguing in response, so I keep to short responses and rebuttals.
In the future, I don't feel that writing anything more here on this topic is a worthwhile use of my time.
Just want to chime in that although this comment is a bit harsh, it does hold a lot of truth. As a game netcode engineer, most of my time is spent on latency hiding techniques and its consequences (for example, we use rollback netcode and lots of efforts are spent on minimizing visual/sound glitches when mispredict, rollback and reconcile). There are lots of middleware that help with this (eg. Photon, SnapNet, etc) but in general there's no silver bullet - it's highly gameplay specific. Even for the same game, the solution can vary depending on different trade-offs (i.e. budget, correctness/anticheat).
As to how to store the game state in memory, it's usually not something that needs much thinking: it's simply done the same way (or similar) as the game's client code. After all, netcode is mostly about efficient state replication and this saves CPU time when replicating it across clients - and gives more CPU time for minimizing bandwidth (like delta encoding, quantization, etc). If you want, you can utilize some techniques like ECS to optimize for CPU cache locality, but it affect gameplay code a lot and would need to get the whole team onboard.
Also, I just noticed the username "gafferongames" - Glenn's blog[1] has been a must-read for netcode engineers. It helped me a lot when I started working on netcode in the 2010s
[1] https://gafferongames.com/
Well, I'm not a professional gamedev, nor did I ever do much multiplayer code, but:
1) AFAIR, the ECS patterns family[0] originally came from MMORPG world, and boiled down to designing your game state to work well with relational databases;
2) Around 6 years ago, while toying with yet another (see [0]) take on ECS for a simple game, and wondering how to query stuff efficiently, it dawned on me that the code I'm writing is basically implementing spacial indices and other such concepts from relational DB world. At that point, I thought to myself, "why continue wasting time Greenspunning[1] a database for the internal state, when I could use a real one?", and followed by "you know what I really need next? An in-memory SQLite database to store all my runtime game state!".
I didn't get very far with my experiment due to constraints of adult life, but I did prove that I can build a basic Roguelike skeleton (2D tile map, entities, walls, collisions) while storing all state in SQLite, and have it run at 60 FPS with half of the frame time to spare for other things, on moderately powerful machine (as of 6 years ago), all without too much optimization (Common Lisp with FFI bindings to libsqlite3 + a simple RLU cache in front of queries).
So it's not at all a stupid idea, IMO :). I would test it further if I had the time.
--
[0] - The term means different things to different people. I've seen at least three distinct gamedev design patterns claiming the name ECS for themselves, all conceptually incompatible with each other. More, if you also consider "whatever Unity/Unreal/Godot/... calls ECS".
We can and plan to handle the complex lag masking netcode as well. We've just focused so far on games that don't need very sophisticated lag compensation
Planning to support complex lag masking netcode as a TODO is not a good sign.
TODO does not imply no plan or that we haven't thought deeply about the problem. Prioritization is imperative when you're building an MMORPG and a new database with a small team for both.
How can you think deeply and plan for something when you don't know what don't know. You can only really understand these things when you've taken a game using these latency hiding techniques into production, and then after this, you'll probably realize that some of your original ideas were wrong. Where does this leave SpacetimeDB then?
I'd be happy to schedule a chat to talk with you about our plans if you'd like! I'd love to get your thoughts.
No thanks! Here are my thoughts. Focus on making your game fun and profitable for your company. Nothing else matters.
Ah you mean like implementing UDP and supporting complex lag masking netcode before we have to?
If a game has no players, does it really matter if it's networked with UDP or TCP?
just because someone doesn't think and plan just like you do, doesn't mean they will not succeed
[flagged]
For what it's worth, BitCraft currently ships with client-side prediction. It's just not built into SpacetimeDB yet.
It's relatively simple, but "The SpacetimeDB devs have not yet shipped a game using client-side prediction techniques", is not correct.
[flagged]
Man, cynical much? I feel like OP has been honestly trying to engage with you here, and the only thing you’ve been is snippy and abrasive.
[flagged]
This guy is blunt... but he's correct.
This company focused all it's effort in reinventing the part of multi-player games that did not need reinventing.
40 engineers for 5 years. I'm guessing at least 20 million dollars spent. 1 million trailer views... Let's say 100k wishlists, 10,000 sales at 30 LTV. 300k in revenue
This company will need to pivot if the game is not successful.
I would say the db could be pivoted for multi-player Figma style apps rather than games, but the coupling of server and db means you can't scale the db layer the same way you could do with literally every other db solution available s your company scales
Being correct doesn’t mean you get to be an asshole about it.
At least, not if you want me to not call you out on it.
I get the sentiment, I really do, but being misguided isn’t a crime that’s worth being treated like shit for. Especially when you are trying to learn.
[dead]
[flagged]
I mean, they said they'd like to get your expert input on the matter. Why not give them a chance? Maybe you can help them do some much needed course correction—which is what I understood you're staying by reading a bit between the lines.
Maybe you can even negotiate a consultancy fee with them
You can stay sceptical, but try giving them a chance. You might end up surprising eachother!
Aside: I'm getting into indie game dev recently and love your site!
[flagged]
[flagged]
harsh
[flagged]
I mean, they are dogfooding their own database. If they’re making a MMO game with it presumably the game has latency masking netcode, even if it isn’t in part of the database.
[flagged]
"Tyler was a Sr. Data Science Engineer at MZ (the company behind Game of War and Mobile Strike). Prior to working at MZ he was an engineer at Apple. Tyler holds a Masters in Distributed Systems and Machine Learning from Johns Hopkins University."
"Alessandro was a Sr. Software Engineer at Bloomberg, LP where he worked on high throughput distributed pricing systems. He holds a Computer Science and a Biomedical Engineering degree from Johns Hopkins University."
Looks like they've built stuff before.
I don't like this database product because it lacks SDK:s in languages I would touch without getting paid, but I think the idea is sound and rather attractive. For many years I've used Picolisp in a similar way, it bundles an object database with a logic engine and a small Lisp-like programming language, which makes it easy to throw in some data and relations and slap on a web page with standard library widgets.
The BEAM is similar, you push some modules into it and store stuff in ETS and don't bother with RDBMS until you need it. If your data is small or trivially shardable you can get persistence too, with Mnesia.
I'm not so sure they'll be making a lot from that game of theirs, but if their database turns out to be robust it could become competitive with things like Supabase/Firebase and such, because there will be modules for serving web and auth and dashboards and whatnot you can just push in there and you're good to go. One-click-install for applications, similar to cPanel and Wordpress rigs, but less messy on the ops side.
> Looks like they've built stuff before.
Building "stuff" != shipping games.
Game of War and Mobile Strike look like games to me. Casino-like games for handheld devices rather than God of War, but still games, and likely quite latency sensitive due to the gambling-reminiscent aspects. It also seems like that company had the same idea you have, that selling dedicated networks for latency sensitive systems might be profitable.
If you compare the commit messages on your public repos with those on the SpacetimeDB repo, do you notice any differences?
> If you compare the commit messages on your public repos with those on the SpacetimeDB repo, do you notice any differences?
Yes. The open source software that I've written is actually useful.
Seems too biased and harsh. The best lag masking and clientside prediction systems I've experienced as a player are those that are closely integrated with the idiosyncratic gameplay mechanics. I would never expect SpacetimeDB to have a one-size-fits-all solution to this, nor for it to be the central focus of their product.
Game development is not something you learn by playing games.
You will implement terrible lag masking and clientside prediction if you aren't looking at it from the UX perspective, because that is literally the only reason these features exist, to trick players into thinking the game signals are moving faster and with greater frequency through the network than is physically possible. Perhaps you would make better games if you considered the user perspective.
[flagged]
Happy to help.
[flagged]
[flagged]
This is the Internet now, is not worth it, those times are over.
[flagged]
As a gamedev, I don't understand the use-case for SpacetimeDB.
Is it simply to be able to persist the game state?
Wasm? What a great idea.
[flagged]