As a Roblox developer, it is currently too hard to predict and control when parts will wake up from a sleeping state for physics interactions to occur.
Right now, developers have to reverse engineer the waking parts logic, using hacky, unreliable workarounds, or create their own physics engine (at lower framerate and higher latency than Roblox’s) - i.e. they have to reinvent the wheel.
Case Study - Ten Pin Bowling
Ten Pin Bowling game
In my bowling game, the pins like to fall asleep. This makes sense, is expected, and desired to some extent - they see no velocity for a while, nothing to collide with them, they sleep. But they should wake up fully in time for the bowling ball (arriving anywhere from 40 to 80 studs per second) to collide with them and cause the right stuff to happen.
However, occasionally the pins don’t wake up in time, and either act as if they are anchored, deflecting the ball despite the ball being far denser, or allowing the ball to pass right through them with the pin just shaking slightly.
Here is a clip of someone streaming the game which shows the issue well:
Twitch
In this particular clip, the client-side prediction begins to deflect the pins in the directions you’d expect, but when they catch up with what the server believe happened, the pins are shown to have barely moved at all. The sounds played are played from the server and indicate that multiple pins received touch events from the ball.
Our bowling happens server-side, and therefore shouldn’t be affected by client latency or any of that stuff. The actual collisions can appear slightly delayed, which is fine and acceptable so long as they are consistent and correct.
And one where the pins may as well be anchored:
Feature Request
A possible solution to the problem is to have the ability to wake up the pins for a given duration of time, either via an API through PhysicsService or another service, or a method directly on BaseParts themselves (or any other suitable solution).
This has more uses beyond just ten pin bowling. Any situation where a projectile is about to hit a group of objects of similar size that are currently stationary can result in this behaviour. Situations like shooting a stack of cans with a bullet like a carnival game, or crashing a high speed vehicle into a bunch of obstacles.
If we, as the developers, know exactly when something will happen, and know exactly what should be ready to simulate that, then we should be able to control the physics engine to ensure that event has priority and is simulated correctly.
Current Workaround
After many attempts doing many silly things to the ball, like adding a longer profile that follows behind in its wake, and trying to do mini explosions and all sorts, ultimately I settled for what seems to be the consensus workaround: soft pushing the body into the ground. (Thanks to @boatbomber for this one, including this lovely wrapper to neaten it up).
I don’t need this to be happening all the time, so I’m hooking to .Stepped when I want this to happen, and disconnecting afterwards - this is exactly where the feature request comes in, as I’d perform a method on the parts or call an API and tell it to wake the 10 pins for the next 3 seconds.
Summary
Ultimately, the cleanest, most useful and seemingly obvious solution is to provide a method of waking parts for a length of time, allowing greater control over the physics engine and avoiding the need for workarounds or custom physics systems.
Fast projectiles are an edge case, but I believe the edge case is large enough to warrant the feature of duration-based part awakening.