Earlier quoted context omitted.
How would that differ from PHP?
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.
SpacetimeDB
181–190 of 205 posts
Re: SpacetimeDB
#182Interesting, 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.
Re: SpacetimeDB
#183Best 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…
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).
Re: SpacetimeDB
#184Earlier quoted context omitted.
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 ru…
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 clientserverpersistence)
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.
Re: SpacetimeDB
#185SpacetimeDB 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…
> 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.
Re: SpacetimeDB
#186Best 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]
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.
Re: SpacetimeDB
#187Earlier quoted context omitted.
[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…
Excuse me Tom, please stop with ad hominem and attack the topic not the poster.
Re: SpacetimeDB
#188Earlier quoted context omitted.
[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…
[deleted]
Re: SpacetimeDB
#189Earlier quoted context omitted.
> 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 o…
> 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.
Re: SpacetimeDB
#190Earlier quoted context omitted.
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 m…
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.