$0.28/gb for net traffic on the Maincloud is pretty brutal.
SpacetimeDB
41–50 of 205 posts
Re: SpacetimeDB
#42SpacetimeDB 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…
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!
Re: SpacetimeDB
#43I 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?
Re: SpacetimeDB
#44#[table(name = person, public)] pub struct Person { name: String, } 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?
Re: SpacetimeDB
#45SpacetimeDB 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…
> Node
What's your reasoning behind this? Just being able to run the same code on frontend and backend?
Re: SpacetimeDB
#46Earlier quoted context omitted.
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…
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.
Re: SpacetimeDB
#47Best 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 persisten…
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…
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?) ?
Re: SpacetimeDB
#48SpacetimeDB 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…
> 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
Re: SpacetimeDB
#49SpacetimeDB 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…
> Node What's your reasoning behind this? Just being able to run the same code on frontend and backend?
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.
Re: SpacetimeDB
#50I 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?
Just put it all in stored procedures. What could go wrong?