8 comments

[ 14.8 ms ] story [ 377 ms ] thread
This is really cool. If you've never seen it before BitCraft is quite a lot like Runescape. Great art style and very crunchy gathering/crafting gameplay.

The developer open sourcing all of this is awesome.

Here's an blog post from them last year covering their open source plans: https://bitcraftonline.com/news/open-sourcing-bitcraft-onlin...

SpacetimeDB looks interesting as a concept (the tech behind this server) but I could never sus out how could it would be in actual practice. I’ve always been interested in some post-mortems or reflections on the tech from other companies besides the founders
> You cannot:

> Operate official, unofficial, private or any otherwise competing BitCraft servers

Doesn't this contradict the Apache license? Isn't this "source-available"?

This is really cool, I don't really recall another MMO server written in Rust like this.
Old man here shaking his fist. While I acknowledge and appreciate the technical effort and let’s face it, an exemplary example in preserving games long after they are maintained by the original creators. But this is not an “rpg”, it’s a gathering, crafting, and hanging out simulator. That’s fine by its own definition, but I don’t see any mechanisms which allow for actual roleplay? Please prove me wrong
I guess that’s one way to deal with a mixed review score on steam.
I had some design questions about the server here if anyone is familiar with the answer.

Specifically, `spawn_enemy` here: https://github.com/clockworklabs/BitCraftPublic/blob/master/...

It makes many db calls interspersed throughout synchronous code inside the application. Normally I would assume this is super slow and has many round trips (unless it's transparently committed to memory and batched to db later). I also don't see anything about connection pool management eg acquire and release.

Does this code work efficiently because it essentially gets compiled into a type of pseudo "stored procedure" that runs all the application code on the db and as such avoids those problems?

If yes, is that a scalability issue to have so much going on in a heavy infrastructure unit such as a db?

If no, then is there a perf issue here based on my initial assumption?