SpacetimeDB ThreeJS Support(discourse.threejs.org)
discourse.threejs.org
SpacetimeDB ThreeJS Support
https://discourse.threejs.org/t/spacetimedb-threejs-support-and-free-tier/90052
19 コメント
I hadn't heard of SpacetimeDB but this tech looks genuinely interesting.
I'm tech lead of UGC at Rec Room and had to do similar work to support live synchronization of UGC content. We essentially built a database in our game engine (Unity) with similar capabilities.
Since it grew out of our production needs, we ended up with a lot of bespoke solutions specific to our game. I'd love to try this out and see if I could make a small UGC personal project with it or exchange notes with the people who built it.
I'm tech lead of UGC at Rec Room and had to do similar work to support live synchronization of UGC content. We essentially built a database in our game engine (Unity) with similar capabilities.
Since it grew out of our production needs, we ended up with a lot of bespoke solutions specific to our game. I'd love to try this out and see if I could make a small UGC personal project with it or exchange notes with the people who built it.
From a technological risk perspective I would never tie myself to a vendor like that. I know people do it all the time, but you are totally at the mercy of the vendor increasing price and having no choice but pay since you are so tightly integrated.
Always add an interface is my moto.
One of the troubles with games is that you don't know if your product will be successful up front. You can go down the route of building everything (engine, multiplayer server, game DB), but if you frontload the tech and your game isn't fun 5 years out, you're in a bad spot.
My experience has been that it's critical to frontload "fun discovery" which means taking concessions on 3rd-party technology. If you make something successful you earn the chance to replace 3rd parties with custom solutions. Often they're fine if your margins are high enough. If you fail, you won't be paying those monthly subscriptions long anyways.
My experience has been that it's critical to frontload "fun discovery" which means taking concessions on 3rd-party technology. If you make something successful you earn the chance to replace 3rd parties with custom solutions. Often they're fine if your margins are high enough. If you fail, you won't be paying those monthly subscriptions long anyways.
I think the DB itself is open-source, and you can self-host if you want. Biggest risk is if the company goes under and stops maintaining it.
It's a BUSL license - you can self host so long as your application uses at most a single SpacetimeDB instance (i.e. no replication) and isn't a database service... or you are running a 5+ year old version of the server (and since this DB hasn't existed for 5+ years...).
Damn, I missed that. That's a shame.
This looks very promising. There's a need for persisting game state in a central place, but also have that data streaming in.
I'm wondering about temporary gamestate that doesn't need to persist. Things like terrain or destructible voxels, where the size could be prohibitive to keep in a databases, but would work well in memory or with a cache.
I'm wondering about temporary gamestate that doesn't need to persist. Things like terrain or destructible voxels, where the size could be prohibitive to keep in a databases, but would work well in memory or with a cache.
The company that is building SpacetimeDB is also making a voxel MMO with it, so it looks like it works well enough. But I am still a bit skeptical at how scalable this is.
I took a look into it and it looks like a really cool MMO but it doesn't look voxel-based: https://bitcraftonline.com
My bad, but it supports persistent changes to a shared game world.
Great question about the non-persistent game state — Implementing a custom setup on your own server is likely the best approach paired with CDN if alot of people are downloading.
this is pretty cool! what I do for my project (3d voxel web page platform) is treat the scene as a document and push updates to the server when things change. this works well for distribution and simplicity, but does mean multi-player is "difficult". using spacetime to manage and track that info and have threejs render would be cool and enable a lot of things.
I may explore spacetimedb as a project sometime, although i am reluctant to be tied into a platform that my project cannot work without, that i cannot host myself, that can change their pricing/limits/terms of at any time and for which there is no alternative.
I may explore spacetimedb as a project sometime, although i am reluctant to be tied into a platform that my project cannot work without, that i cannot host myself, that can change their pricing/limits/terms of at any time and for which there is no alternative.
You can host one instance yourself and that instance can handle thousands of ccu if your server is coded efficiently and if your server is fast probably even more. They hve a rolling open source scheme so their releases becomes open source after some time (already source available). Wish as well it was free, but understandable they need some defence against Amazon etc. SpacetimeDB has worked very well in my game so far.
We have been experimenting with adding Spacetime multi-player to our current threejs app. It was surprisingly easy to build the standalone demo but the full integration obviously is not as straightforward.
hmmmm i am working on a threejs project i'll try this out perfect timing
You run game logic “inside” the DB, model world state as tables, and expose moves/damage/spawns as reducers. Clients (like Three.js) subscribe over WebSockets and get fine‑grained diffs instead of polling, so the server stays authoritative and the client just renders and interpolates. Generous free tier, paid starts at $25/month.
https://discourse.threejs.org/t/spacetimedb-threejs-support-...