Hello! I am working on a game called “Turing Plays Table Tennis”. As a part of it, I'm developing a physics simulation engine.Short summary of the game:

It's a 2D web game for both computers and mobile devices. Player completes series physics-based challenges revolving around table tennis racket and ball. So, it's a "timing/hand-eye coordination test" kind of a game.

Here is the twist: the gameplay sessions are recorded; and the player (call him X) is periodically presented with a screen with several anonymous replays. These videos show other players completing levels just finished by X. But, some recordings are of RL bots playing the game (trained to mimic players, behavior-cloning style).

So, the goals of X are:

1) figure out which replays are authored by bots, and

2) play in a way to disguise himself as a bot. In other words, produce replays that other players will mark as bot-produced.

Hence, the "Turing" part of the name of the game.

Requirements for the physics simulation are atypical, so I decided to make my own.

Key features:

• Faithful physics: for fine control over object simulation and how game works / "feels", real physics laws are used for the simulation (instead of typical proxies or hacks).
  For example: quickly rotating ball falls on a horizontal surface. It will bounce to the side; and few engines handle that properly. There are almost no "unphysical"/"hard-to-explain"/"magic" constants (such as "drag" in Unity).
  To give a feel of that "physicality": the roadmap includes Magnus_effect​​, as it enables sick trick shot levels.
• Client-server architecture: runs on both client (Typescript) and server (Python), with real-time sync between. It's required for anti-cheat and client correction (+the sync needed for bots). But, it's possible to extend it to handle several players interacting with the same physics world (think of a multiplayer browser shooter)
• Stable simulation: running it with the same inputs produce the same outputs. That's good for training bots, but also nice for multiplayer client-side prediction

The limitation is that the system is designed to handle relatively low number of objects due to the nature of the game (dozens, up to ~hundreds)

So, I'm writing the post here to gauge the interest towards the game and the physics engine.

How does it looks? ? If it all sounds interesting, I'll be more than glad to receive 'thumb-ups' :)

Making game in a team is more fun, so I'm looking for level designers and front developers. And I am going to extract the physics engine in a standalone library if it finds other uses (do not want to put effort in a stuff no one needs).