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…
SpacetimeDB
151–160 of 205 posts
Re: SpacetimeDB
#152Earlier 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
How would that differ from PHP?
Re: SpacetimeDB
#153Earlier quoted context omitted.
This guy is blunt... but he's correct. This company focused all it's effort in reinventing the part of multi-player games that did not need reinventing. 40 engineers for 5 years. I'm guessing at least 20 million dollars spent. 1 million trailer views... Let's say 100k wishlists, 10,000 sales at 30 LTV. 300k in revenue This company will need to pivot if the game is not successful. I would say the db could be pivoted f…
Being correct doesn’t mean you get to be an asshole about it. At least, not if you want me to not call you out on it. I get the sentiment, I really do, but being misguided isn’t a crime that’s worth being treated like shit for. Especially when you are trying to learn.
Re: SpacetimeDB
#154Earlier quoted context omitted.
This guy is blunt... but he's correct. This company focused all it's effort in reinventing the part of multi-player games that did not need reinventing. 40 engineers for 5 years. I'm guessing at least 20 million dollars spent. 1 million trailer views... Let's say 100k wishlists, 10,000 sales at 30 LTV. 300k in revenue This company will need to pivot if the game is not successful. I would say the db could be pivoted f…
Being correct doesn’t mean you get to be an asshole about it. At least, not if you want me to not call you out on it. I get the sentiment, I really do, but being misguided isn’t a crime that’s worth being treated like shit for. Especially when you are trying to learn.
Re: SpacetimeDB
#155Re: SpacetimeDB
#156Re: SpacetimeDB
#157SpacetimeDB 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…
In addition, outside of single table updates and selects, SQL has scaling limits. If you throw the computation at the db server as well, you limit the vertical scaling.
Gaming and gamers are used to sharding (and geographic tower of babel us an implicit shard as well).
Re: SpacetimeDB
#158Earlier quoted context omitted.
[flagged]
"Tyler was a Sr. Data Science Engineer at MZ (the company behind Game of War and Mobile Strike). Prior to working at MZ he was an engineer at Apple. Tyler holds a Masters in Distributed Systems and Machine Learning from Johns Hopkins University." "Alessandro was a Sr. Software Engineer at Bloomberg, LP where he worked on high throughput distributed pricing systems. He holds a Computer Science and a Biomedical Enginee…
Building "stuff" != shipping games.
Re: SpacetimeDB
#159I'm not a game dev, but I'm imagining that if I'd write a custom game engine, I'd have to write just the "frontend" aka. graphics engine if I'd have a robust state manager (+tooling) as a separate piece of software.
Re: SpacetimeDB
#160Does this make any sense in single-player games, where the db would run locally on the user's machine? Does it have any benefit to run all game state through a local db? I'm not a game dev, but I'm imagining that if I'd write a custom game engine, I'd have to write just the "frontend" aka. graphics engine if I'd have a robust state manager (+tooling) as a separate piece of software.
Stated somewhat differently, do you want to write the algorithm to do a 3-connected recursive join in linear time, or do you want to slap the join into a DB and move on with your life?
For a concrete example, a DB could make the Entity-Component architecture even simpler to use than it already is (give me all the npcs in this radius who haven't attacked in the last second, have a distance attack, and are facing the right direction).
Would it have performance pitfalls if you weren't careful? Almost certainly. It could be a fun way to structure a game though.