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?
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 for multi-player Figma style apps rather than games, but the coupling of server and db means you can't scale the db layer the same way you could do with literally every other db solution available s your company scales
I mean, they said they'd like to get your expert input on the matter. Why not give them a chance? Maybe you can help them do some much needed course correction—which is what I understood you're staying by reading a bit between the lines.
Maybe you can even negotiate a consultancy fee with them
You can stay sceptical, but try giving them a chance. You might end up surprising eachother!
Aside: I'm getting into indie game dev recently and love your site!
I mean, they are dogfooding their own database. If they’re making a MMO game with it presumably the game has latency masking netcode, even if it isn’t in part of the database.
"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 Engineering degree from Johns Hopkins University."
Looks like they've built stuff before.
I don't like this database product because it lacks SDK:s in languages I would touch without getting paid, but I think the idea is sound and rather attractive. For many years I've used Picolisp in a similar way, it bundles an object database with a logic engine and a small Lisp-like programming language, which makes it easy to throw in some data and relations and slap on a web page with standard library widgets.
The BEAM is similar, you push some modules into it and store stuff in ETS and don't bother with RDBMS until you need it. If your data is small or trivially shardable you can get persistence too, with Mnesia.
I'm not so sure they'll be making a lot from that game of theirs, but if their database turns out to be robust it could become competitive with things like Supabase/Firebase and such, because there will be modules for serving web and auth and dashboards and whatnot you can just push in there and you're good to go. One-click-install for applications, similar to cPanel and Wordpress rigs, but less messy on the ops side.
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 on the SpacetimeDB repo, do you notice any differences?
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.
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.
