Zhenjing (Jerry) Yu
Ace Breakers (under development)
Unity, Oculus Quest
Ace Breakers is a student project at Carnegie Mellon University, Entertainment Technology Center (ETC). By creating a multiplayer VR pickleball game, we aim to bring the excitement and competition of pickleball to life in an immersive and engaging way.
The game will combine realistic physics and motion with fantastical elements to give players a party-style experience.
​
I worked as a producer, programmer, and technical designer on the team. My responsibilities include designing, implementing, and testing ball physics and player interactions.
​
The project is still under development.
More information: https://projects.etc.cmu.edu/ace-breakers/
​
Collisions in VR
The collision between the paddle and the ball is the first challenge I faced. Simply adding a collider box for both the paddle and the ball and hoping that the built-in physics engine in Unity will do everything for us obviously doesn't work well enough in VR.
​
Since players swing their paddles really quickly in real life when they hit the ball, the paddle and the ball might sometimes penetrate each other without collision due to the high moving speed.
Also, solely using Unity's PhysX engine will make it hard for us to implement customed ball physics like topspin/backspin to account for the advanced skills used by pro players.
​
Given the context, we decided to use a distance-based rule to detect collisions between paddles and balls. Paddles check their distances to the ball every frame. If the distance is smaller than a preset threshold and also the ball's relative position to the current paddle meets some angle requirements, we say that a hit just happened.
​
To avoid 'double hits', I added a cooldown time as a minimum time gap between two hits.
New Problem
Although the distance-based rule works well for detecting collisions, it introduces a new problem at the same time.
​
When designing the ball movement after the hits, it's natural for us to take the paddle's angle into the equation. And that means, we really need to know which face of the paddle is colliding with the ball.
​
To simplify the question, we want to know which side of the space the point (the ball) is on which is separated by a given plane (the paddle's face). This can be easily done by doing some projections and dot products.
​
However, when combining the face determination algorithm with collision detection, something might go terribly wrong under some specific conditions.
As shown in the image above, the ball comes from underneath the paddle and should be colliding with the left face of the paddle. However, because we are using distance to trigger the hit event, and when the distance is closer than the threshold, the ball has already moved across the face. In this particular condition, we will end up using the wrong normal for physics computation and result in a weird ball trajectory.
​
My solution to this problem is also quite simple and straightforward. Since the threshold we set is usually quite small, that means when the hit happens, the ball can't stray too far away from the other side. So I kept a list recording the positions for both the paddle and the ball for the past 5 frames. When a hit is detected, use the position 5 frames ago to determine which face is actually colliding with the ball.