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

201–205 of 205 posts

Re: SpacetimeDB

#201

Post by cess11 »

gafferongames wrote: post #189
cess11 wrote: post #179

Earlier quoted context omitted.

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.

How do you come to this conclusion based on those commit messages? Show some examples.

Re: SpacetimeDB

#202

Post by kriper »

janderland wrote: post #194
kriper wrote: post #43

I don't really understand how you would write a game server using this tech. Lets say you need to simulate physics, pathfinding, animation etc on server. How one would integrate all of this? In regular world you just use unreal/unity headless mode that includes all of this but using spacetimedb requires ditching the game engine and reimplementing everything from scratch?

Forgive my ignorance, but why would you implement physics and animations on the server? I feel like you can get away with basic positional data and do the rest of that on the clients.

You need physics in order to make movement server authoritative. Otherwise player will be able to fly around and ignore collusions. You might need animation state in server if you are making a fps shooter and want to calculate raycasts properly.

Re: SpacetimeDB

#203

Post by whizzter »

Rohansi wrote: post #190
whizzter wrote: post #184

Earlier quoted context omitted.

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

Agreed, going for a custom engine anyhow in my scenario so that's fine.

It seems that they're built to run serially to achieve reproducible simulations so my guess would be no, this is one thing my experiment does differently although formally it might just be a naming difference.

It's not a major issue though I think, the stuff I work on could shard work by area so single areas are single-threaded but world-wise it's parallel (Eve online has done this for ages).

Re: SpacetimeDB

#204

Post by Rohansi »

whizzter wrote: post #203
Rohansi wrote: post #190

Earlier quoted context omitted.

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

Agreed, going for a custom engine anyhow in my scenario so that's fine. It seems that they're built to run serially to achieve reproducible simulations so my guess would be no, this is one thing my experiment does differently although formally it might just be a naming difference. It's not a major issue though I think, the stuff I work on could shard work by area so single areas are single-threaded but world-wise it'…

Serial execution makes the most sense from a database perspective because they work off a transaction log. Parallel execution may require separate transaction logs (basically durable queues) to accomplish sharding but that introduces a whole new set of issues because tables can only be mutated from a single transaction log. Code that needs to access multiple suddenly gets a lot more complex. There was actually a post on HN the other day about this: https://news.ycombinator.com/item?id=43661181

Re: SpacetimeDB

#205

Post by whizzter »

Rohansi wrote: post #204
whizzter wrote: post #203

Earlier quoted context omitted.

Agreed, going for a custom engine anyhow in my scenario so that's fine. It seems that they're built to run serially to achieve reproducible simulations so my guess would be no, this is one thing my experiment does differently although formally it might just be a naming difference. It's not a major issue though I think, the stuff I work on could shard work by area so single areas are single-threaded but world-wise it'…

Serial execution makes the most sense from a database perspective because they work off a transaction log. Parallel execution may require separate transaction logs (basically durable queues) to accomplish sharding but that introduces a whole new set of issues because tables can only be mutated from a single transaction log. Code that needs to access multiple suddenly gets a lot more complex. There was actually a post…

It's not meant as a regular SQL database with full ACID semantics (even if that is a interesting stretch target).

Rather the main thing is mainly about coupling storage and sharding decisions with the simulation, since both a sharded simulator and sharded storage system will need logic for sharding and time-versioning, it's silly to duplicate work (or worse have out of sync semantics). In addition cohabiting simulation and storage will lessen latency and other issues w.r.t. to separating them.

Now, it's entirely possible that I'm barking up the wrong tree but considering that many are exploring this design-space means that there is interest and merits even if only the Spacetime and a few others have taken the leap yet.

Post reply on HN