Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SpacetimeDB

spacetimedb.com

Post reply on HN
Print view View original

171–180 of 205 posts

Re: SpacetimeDB

#171

Post by hansvm »

sitkack wrote: post #161
hansvm wrote: post #160

Earlier quoted context omitted.

Some algorithms are much more easily represented as SQL or that plus a little wrapper code. E.g., somebody re-wrote E-Graphs Good using SQL as their primitives, and that viewpoint made a bunch of other features and optimizations obvious. 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 lif…

If you know all of your queries ahead of time, then compiling them efficiently has already been shown to be effective. Noria https://github.com/mit-pdos/noria https://www.youtube.com/watch?v=kVv9Pik6QGY https://thesquareplanet.com/research/ Materialize/TimelyDataflow https://scholar.google.com/citations?hl=en&user=YYJ3aycAAAAJ...

Oh, sure, the complaint wasn't about SQL per se, but that making complicated things easy to write isn't necessarily a win. Even if a big query perfectly represents the problem, and even if you can use compiled SQL to match hand-written efficiency, it still might not be the optimal way to approach the problem in the first place. If you have experience and plan for that it needn't be bad at all, but I think it's easier to write performance footguns in SQL (the "right" data model is more prescriptive, even with some number of years of experience, and is less likely to be tuned to your actual problems) than with traditional code, so I'd be quite surprised if the majority of game developers (even those with some degree of success currently average <3 YOE) wouldn't run into major performance issues with a SQL-based engine, even a good one.

Re: SpacetimeDB

#172

Post by Rohansi »

zinlencer wrote: post #166
Rohansi wrote: post #133

Earlier quoted context omitted.

Since SpacetimeDB would be your backend (game client SpacetimeDB) you would need to verify the inputs to your reducers to prevent cheating. Not really different from anything else.

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.

Re: SpacetimeDB

#173

Post by 999900000999 »

Cieric wrote: post #169
999900000999 wrote: post #164

Seems like a neat idea, but for the love of Jesus Christ offer me a flat rate billing solution. Or at least an option of doing that. This seems like the type of thing that will accidentally burn through all of your credits if you code something wrong, and then you're going to have to beg their tech support to refund you. I had an idea last night for an RTS like game where the units can only be controlled via radio co…

SpacetimeDB is open source[1], the open source version doesn't currently have all the features of maincloud, but most of those features are solely for scalability. I've done all of my work on my own local servers. I would even suggest paying for your own server up front until you're ready to scale out. I believe the 4 years is when the license changes to a more open license. And the scalability features on local are…

>I believe the 4 years is when the license changes to a more open license.

Why not use something with a vastly friendlier license. Most companies don't want to play the GPL dance when alternatives exist.

Re: SpacetimeDB

#174

Post by aeturnum »

MasterYoda wrote: post #168
aeturnum wrote: post #42

Earlier quoted context omitted.

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!

Which tradeoffs does elixir have?

Well, it totally gives up memory mutation. Each value is final (under the hood). So you lose an entire category of optimizations and an entire category of errors. You also gain some new optimizations you can do because values never change. In general that makes it worse at tight loops where you really want optimal machine code and better at handling heterogeneous calls like HTTP requests.

Re: SpacetimeDB

#175

Post by Rohansi »

flockonus wrote: post #131
Rohansi wrote: post #46

Earlier quoted context omitted.

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.

Having implemented the first two for a web game i absolutely guarantee you those are far from "nothing". It takes considerable diagraming & handling to coordinate FE + API on state changes. If they in fact can solve that (haven't checked myself), it would be a massive time saving for development.

Maybe I'm just used to it having implemented it several times. But my point is that they require a relatively fixed amount of effort. Once it's implemented you shouldn't need to touch it again.

Re: SpacetimeDB

#176

Post by dontlaugh »

meheleventyone wrote: post #150
hansworst wrote: post #149

Earlier quoted context omitted.

But in gaming, real time means something different: https://en.wikipedia.org/wiki/Timekeeping_in_games#Real-time Context matters.

In game development we still care about the distinction between soft and hard realtime. Almost all games are soft realtime, even if the gameplay itself is turned based as we're processing user input, updating UI, animating things and so on.

A lot of gameplay elements are firm realtime in practice, not unlike something like video decoding.

Re: SpacetimeDB

#177

Post by truth_seeker »

Its areally great effort, but i would stick with PostgreSQL with PL/SQL procedure and tons of extensions.

Lowering down the TRSACTION LEVEL, Async transctions on disk backed tables and UNLOGGED Tables can help you go a long way.

Also, in next major version (v18) of PG, they are trying to implment io_uring support which will further drastically improve the random read/write performance.

Re: SpacetimeDB

#178

Post by [deleted] »

Rohansi wrote: post #136
cloutiertyler wrote: post #32

Earlier quoted context omitted.

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.

It's in closed alpha so there's a limited number of players but I am curious to hear more about how BitCraft is scaling out. Is it a single, seamless world for all players? How much scaling is currently required? How is data replicated when horizontal scaling comes into the picture?

[deleted]

Re: SpacetimeDB

#179

Post by cess11 »

gafferongames wrote: post #158
cess11 wrote: post #147

Earlier quoted context omitted.

"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…

> 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 on the SpacetimeDB repo, do you notice any differences?

Re: SpacetimeDB

#180

Post by cess11 »

sroussey wrote: post #165
cess11 wrote: post #146

Earlier quoted context omitted.

How would that differ from PHP?

Websockets et al

Node launched before Chrome got WebSocket support. Soon after Google published their own PHP WebSocket server and people had been building their own.
Post reply on HN