I believe they've done more complicated physics in their game bitcraft, but that code hasn't been released yet (no idea if it will be.) But there has been work in the discord recently and 2 member have individually implemented rapier[1] at this point. I can't say anything about the related netcode however as I don't know how much they've focused on it. At the very least work has been done.
The unity tutorial is just to get up and running as fast as possible in the simplest way possible, not to make the perfect decisions for a networked physics based game.
I however do think they should provide an actual reference to prove the claim,
Nice, that's very interesting and a commendable achievement!
If that is the case I would really like to see some internals of how the physics engine has been implemented in their pattern. I'm not asking for the rapier port source code, but it is hard to think in terms of a new advertised programming paradgim when there's no working examples.
For example I am very curious to see how a constraint solve is implemented in a SQL-like fashion. You would need various math operations and an efficient matrix representation off the top of my head, and I can't think of how that maps to a SQL-like interface.
On of the people who implemented it is from unity, from my understanding he can't actually release the code. For the other guy, this was his last comment on the matter
> Sure, my plan was to write a readme and share the code with my colleagues anyway. It should be ready by the weekend because I'm in the middle of a refactoring right now.
> The gist of it: each time a System adds a "movable" component to a StDb table, it also adds the rigid body and collider in Rapier. Then, a scheduled reducers updates the simulation then fetches resulting positions and velocities from Rapier and updates the "movable" components. I have no client prediction at this time.
So my understanding is rapier is just compiled into the wasm and run like normal while the results are stored into the table for clients to receive via subscription. I won't say it's a perfect solution, but efforts are being made by the small community to see how we can really push the db.
Note: while it's all very procedure like you can just store data normally in the rust side, you just have to push the information to the table for it to be query-able.
I see, that's extremely interesting. As mentioned earlier, I do respect efforts to push on something new, especially if it's against conventional wisdom and would be interested in poking around with an open mind. I'll join the Discord.
Thank you!
Then again looking at the FAQ for Bitcraft, we have this:
"What engine does BitCraft use?
The BitCraft client is developed using the Unity game engine. For the server, we have developed a sophisticated distributed system called SpacetimeDB, which hosts the entirety of BitCraft’s server architecture. "
Correct me if wrong, but this suggests the physics engine is Unity's, and not something implemented in SpacetimeDB.
I didn't truly know and I didn't want to just throw out a guess so I just asked. They mentioned they have a basic hand rolled system for their physics. So not using unity physics.
I guess making the claim that is was more complicated might have not been right for me to do, but it would be hard to believe that they did the degenerate case of O(n^2).
Speculation: I have only written a physics engine once during college (so please excuse my ignorance), but I think for a basic mmo a simple chunk and AABB approach would work. It would be easy to query for the surrounding chunks and just run the collision on that subset. I know one of the team members was working on porting a minecraft 1.7.3 server at one point, but I don't know if they got up to the point of moving collision off of the server and into the database.
Thank you for asking and forwarding the answer. I appreciate your comments.
Speculation as well: Looking at the trailer for Bitcraft, it looks like they have articulated characters and cloth physics. This raises more questions for me.
I am contributing to a project by a SpacetimeDB community member to get Rapier running within Unity. Instead of trying to get Unity PhyX running on the server, we just use a deterministic Rust physics engine on both client and server. It is a mostly complete drop in replacement as it stands and is deterministic (Unity's PhyX is not). We'll keep improving it!
We rely on the guarantees of Rapier's determinism. I haven't done extensive testing on the determinism claim yet, but it has held up so far.
https://rapier.rs/
The unity tutorial is just to get up and running as fast as possible in the simplest way possible, not to make the perfect decisions for a networked physics based game.
I however do think they should provide an actual reference to prove the claim,
[1] https://github.com/dimforge/rapier