[HN Gopher] SpacetimeDB
___________________________________________________________________
SpacetimeDB
Author : matthewfcarlson
Score : 191 points
Date : 2025-04-09 13:27 UTC (9 hours ago)
(HTM) web link (spacetimedb.com)
(TXT) w3m dump (spacetimedb.com)
| matthewfcarlson wrote:
| A relational DB + serverless compute + suspiciously fast updates
| thefourthchime wrote:
| Haha, yes very suspiciously fast!
| _huayra_ wrote:
| 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...
| weego wrote:
| 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.
| pmx wrote:
| 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.
| anentropic wrote:
| Doesn't Snowflake do something similar though?
| cloutiertyler wrote:
| They do indeed.
| cmrdporcupine wrote:
| 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.
| cloutiertyler wrote:
| 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.
| cmrdporcupine wrote:
| 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" :-)
| cloutiertyler wrote:
| 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?
| cloutiertyler wrote:
| Oh it's you! Sorry cmrdporcupine! I didn't see.
| ksynwa wrote:
| 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.
| spmurrayzzz wrote:
| 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.
| LarsDu88 wrote:
| 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.
| cloutiertyler wrote:
| 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.
| ksec wrote:
| Previous Discussions
|
| https://news.ycombinator.com/item?id=43593913
| paulluuk wrote:
| 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.
| matthewfcarlson wrote:
| 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)
| cloutiertyler wrote:
| 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.
| jackb4040 wrote:
| 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.
| gafferongames wrote:
| Professional multiplayer game developer here. I wonder what
| multiplayer games the SpacetimeDB folks have actually shipped?
| pmx wrote:
| This is theirs https://bitcraftonline.com/ - not "released"
| yet but they have alpha testers on it apparently.
| gafferongames wrote:
| Would you seriously consider using any technology built by
| people who are making their first game?
| trollied wrote:
| You've got to start somewhere. Dogfooding makes sense.
| dicytea wrote:
| 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...
| lrae wrote:
| 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.
| thefourthchime wrote:
| Same! The algorithm thinks I needed to watch this.
| bryanrasmussen wrote:
| This guy often comes here from HN, give him some Rust,
| Elixir, why JavaScript framework of the day sucks, and this
| SpacetimeDB thing!
| Rohansi wrote:
| 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.
| cloutiertyler wrote:
| 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)
| Rohansi wrote:
| 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.
| manas96 wrote:
| 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.
| Cieric wrote:
| 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
| manas96 wrote:
| 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.
| Cieric wrote:
| 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.
| manas96 wrote:
| 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!
| manas96 wrote:
| 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.
| Psyferio wrote:
| 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
| manas96 wrote:
| That's great, especially the deterministic part. Did you
| run into determinism problems with two different CPU
| architectures for server and client?
| Cieric wrote:
| 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
| manas96 wrote:
| 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.
| jackb4040 wrote:
| 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
| neuroelectron wrote:
| Wasm? What a great idea.
| gafferongames wrote:
| Things I have never thought as a professional multiplayer game
| developer:
|
| "Phew! I've just finished coding all the complex lag masking
| netcode myself, you know what I really need next? An in-memory
| SQL-like database to store my world state!"
| cloutiertyler wrote:
| 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
| gafferongames wrote:
| Planning to support complex lag masking netcode as a TODO
| is not a good sign.
| pphysch wrote:
| 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.
| gafferongames wrote:
| Game development is not something you learn by playing
| games.
| pphysch wrote:
| 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.
| gafferongames wrote:
| Thank you for explaining client-side prediction to me, a
| professional multiplayer game developer. I see the errors
| in my ways now, and will consult with the real experts,
| the people who actually play games, to see what they
| think about game development topics, before posting
| opinions of my own from now on.
| pphysch wrote:
| Happy to help.
| cloutiertyler wrote:
| 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.
| gafferongames wrote:
| 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?
| stronglikedan wrote:
| just because someone doesn't think and plan _just_ like
| you do, doesn 't mean they will not succeed
| gafferongames wrote:
| Nice strawman you have there but that's not what I said:
|
| > Things I have never thought as a professional
| multiplayer game developer: "Phew! I've just finished
| coding all the complex lag masking netcode myself, you
| know what I really need next? An in-memory SQL-like
| database to store my world state!"
|
| Transation: This is not the way multiplayer games are
| usually made. Solving for problems like latency hiding,
| competitive integrity and making the game fun are orders
| of magnitude more difficult than "how do I store my
| object state on the server".
|
| > 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?
|
| Translation: The SpacetimeDB devs have not yet shipped a
| game using client-side prediction techniques. Because of
| this the entire architecture of SpacetimeDB is suspect.
| Client-side prediction, latency compensation and delta-
| encoding over UDP are the things that most influence the
| structure of game state on the server, and the fact that
| the team doesn't have experience with these things means
| that they've almost certainly built SpacetimeDB the wrong
| way.
| cloutiertyler wrote:
| 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.
| gafferongames wrote:
| Thinking that client-side prediction is "relatively
| simple" is a bit of a red flag.
| cloutiertyler wrote:
| 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.
| gafferongames wrote:
| No thanks! Here are my thoughts. Focus on making your
| game fun and profitable for your company. Nothing else
| matters.
| cloutiertyler wrote:
| Ah you mean like implementing UDP and supporting complex
| lag masking netcode before we have to?
| gafferongames wrote:
| If a game has no players, does it really matter if it's
| networked with UDP or TCP?
| TeMPOraL wrote:
| 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".
| insraq wrote:
| 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/
| cloutiertyler wrote:
| 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.
| ncr100 wrote:
| 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!
| kriper wrote:
| 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?) ?
| ChrisArchitect wrote:
| Discussion last week:
| https://news.ycombinator.com/item?id=43593913
| hanska wrote:
| i've tried it, it works, it's nice :) got a mini mmo running with
| several people at once running around
| thefourthchime wrote:
| 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
| aeturnum wrote:
| 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?!).
| cloutiertyler wrote:
| 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.
| aeturnum wrote:
| 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!
| theLiminator wrote:
| > Node
|
| What's your reasoning behind this? Just being able to run the
| same code on frontend and backend?
| barrell wrote:
| 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
| ffsm8 wrote:
| > _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
| anon7000 wrote:
| 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".
| Jarwain wrote:
| 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.
| Rohansi wrote:
| 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.
| aeturnum wrote:
| 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.
| efilife wrote:
| maybe I don't understand something but most if not all node
| methods have their sync counterparts
| duxup wrote:
| 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.
| aeturnum wrote:
| 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.
| beders wrote:
| #[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.
| robmccoll wrote:
| 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?
| bob1029 wrote:
| > 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.
| drivingmenuts wrote:
| Is this similar to the way HeroEngine works? IIR, that was
| basically a big database server (that wasn't compatible with
| anything else).
| hesdeadjim wrote:
| $0.28/gb for net traffic on the Maincloud is pretty brutal.
| gafferongames wrote:
| Yeah this alone makes this a total non-starter. Do the math at
| 100k CCU
| cloutiertyler wrote:
| 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.
| kriper wrote:
| 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?
| nerflad wrote:
| Just put it all in stored procedures. What could go wrong?
| calebm wrote:
| Minor critique - the logo is almost exactly the same as Grok's
| cloutiertyler wrote:
| Ours came first :/
| xixixao wrote:
| The "server in DB" is also the Convex model, but Convex is more
| tailored towards JS full stack apps:
|
| https://www.convex.dev/
| vivzkestrel wrote:
| How do you integrate this with unreal engine 5.5
| cloutiertyler wrote:
| Unreal (and C++) support is coming!
| arittr wrote:
| am i the only one who hoped (and thought from the logo) that this
| was by the Spaceteam devs?
| R4tY9jQ2 wrote:
| 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!
| MPSimmons wrote:
| 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.
| wy35 wrote:
| >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?
___________________________________________________________________
(page generated 2025-04-09 23:00 UTC)