Project goal: to create a 3D video game with realistic physics, inspired by the 2018 game Donut County. In this game, the player controls a hole in the ground that increases in size every time an object falls into it, eventually becoming large enough to swallow entire buildings. How the game should ultimately look is here.
ATTENTION! The initial code has already been written and attached in a zip file. Complete the code as per the assignment in the src folder, in the files App.ts and RigidBody.ts, do not change the existing code unless instructed to do so. All requirements have been translated from English, there may be distortions.
ATTENTION! Use the local library, without it the game will not work!
1. Game Description
The game is developed based on similar core mechanics as Donut County, albeit with a simplified physics model. The user controls the hole using the WASD/arrow keys, mouse, or touchscreen, and the hole will grow every time an object falls into it. The following diagram shows the coordinate system used in the game. Note that we use the standard right-handed coordinate system of OpenGL, where +X is to the right, +Y is up, and -Z is forward.
2. Requirements
2.1 Hole Control
Currently, the user can move the hole infinitely in the X and Z directions. Add boundary checks that prevent the hole from leaving the game area.
2.2 Moving Spheres
Next, complete the code in the RigidBody class so that the spheres move according to the simplified physics model:
Movement: when implementing rigid body physics, the position of object p is computed using its velocity v. This occurs in each frame in the update() method of the RigidBody class, using the formula: p' = p + v * dt.
Gravity: the rigid body should accelerate downwards due to gravity, but this should be a plausible approximation of gravity. After all, this is a game where objects fall into a magical hole in the ground. The initial code includes a gravitational constant used in the instructor's example.
2.3 Boundary Collision Handling
In any collision handling procedure, there are two main steps: first, determining whether a collision has occurred, and second, resolving the collision by updating the positions and velocities of the colliding objects.
Collision Detection: Remember that in this type of simulation, we update positions and velocities once per frame, and there is a small time interval (dt) between each frame. We need to remember that the time when two moving objects collide is likely not to be exactly a multiple of dt. This means it is important not just to handle the case when two objects perfectly touch each other at first. It is also important to handle the case when they may have just touched each other a fraction of a second ago. This is illustrated below. At timestep 1, the ball has not yet touched the wall, but it is moving fast enough that if we move to dt and go to timestep 2, the ball actually breaks through the wall!
If you are updating your simulation once per frame, this means that the elapsed time (i.e., deltaTime or dt) between consecutive frames will be somewhere around 1/30–1/60 seconds. This is fast, but still not fast enough to capture the exact moment when two rigid bodies first touch.
A way to handle unrealistic behavior like this is to detect and correct it. From the perspective of your code, collision detection requires assessing the distance between two objects, and you can naturally write a check for this using an if statement, for example, "if (currentDistanceBetweenObjects == distanceWhenObjectsAreJustTouching)". In this case, it is very easy to detect a situation like Timestep 2, just change "==" in your if statement to "<=".
Updating Position: to fix these situations, you need to set the position of the sphere to a new value where it will not penetrate another object. There are several acceptable approaches depending on how precise you want to be in your calculations. For the boundaries of the game area, we recommend setting the position of the sphere to the nearest allowable position, which can be achieved by moving the sphere in the direction perpendicular to the wall that was crossed. For example, if you find that the position of the sphere along the X-axis is too large, simply set its position along the X-axis to the nearest allowable value. For collisions between two spheres, we recommend calculating the shortest distance that the spheres need to travel to no longer penetrate each other, and then moving each sphere by half of that distance. We will discuss these calculations and various alternatives in class.
Updating Velocity: when a rigid body bounces off another object, its velocity v changes, but how? It depends on the normal of the surface they are colliding with. In the following illustration, a sphere is bouncing off the ground plane. In this case, calculating the updated velocity of the sphere is very simple; we just negate v.y, leaving v.x and v.z unchanged.
Friction Approximation: to simulate friction, you can simply reduce the velocity of the rigid body when it hits something. For example, you could multiply the current velocity by 0.9 after bouncing, which would slow it down by 10% due to friction. The starter code already includes a friction damping parameter used in the example.
2.4 Sphere-Sphere Collision Handling
In summary, for the sphere-sphere case, the steps will be as follows:
1. Determine that the two spheres have collided (and likely penetrated each other).
2. "Fix" the collision by adjusting the positions of both spheres so that they no longer overlap.
3. For each sphere, compute its new velocity after the collision, remembering to use the correct collision normal and relative velocity.
Finally, slightly reduce the velocity of each sphere to account for friction.
It is worth mentioning simplifying assumptions: in addition to simplified gravity and friction, our approach assumes that these spheres have the same mass, so we do not need to solve momentum conservation equations, although you can certainly do so to create a more realistic simulation. Additionally, we do not consider cases where more than two objects collide in one frame. Sometimes due to this, you may see artifacts in your simulation. It is possible, but it goes beyond this assignment, to handle all these cases.
2.5 Create Your Own Game
In the final part, you should add code to the startNextStage() method to create your own scene that will be loaded after the user completes the test scene. You have a lot of freedom to create your own game as long as it meets these minimum requirements:
Your game must include at least 8 rigid bodies.
Each rigid body must differ in size.
To win the game, you must first capture several smaller rigid bodies so that the hole becomes large enough to capture larger rigid bodies.
Rigid bodies must move to make the game interesting. At a minimum, they can be initialized with random velocities, but you can also do something more creative here, such as building a Rube Goldberg machine or arranging them in the form of some puzzle.
