Earlier quoted context omitted.
just because someone doesn't think and plan just like you do, doesn't mean they will not succeed
[flagged]
[deleted]
SpacetimeDB
71–80 of 205 posts
Re: SpacetimeDB
#72[dead]
Re: SpacetimeDB
#73Earlier quoted context omitted.
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
> 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…
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.
Re: SpacetimeDB
#74YouTube 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.
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.
Re: SpacetimeDB
#75YouTube 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.
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…
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,
Re: SpacetimeDB
#76Earlier quoted context omitted.
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.
Re: SpacetimeDB
#77Best 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…
[flagged]
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".
Re: SpacetimeDB
#78How do you integrate this with unreal engine 5.5
Unreal (and C++) support is coming!
Re: SpacetimeDB
#79Minor critique - the logo is almost exactly the same as Grok's
Ours came first :/
Re: SpacetimeDB
#80Earlier quoted context omitted.
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.