CS184: Unnamed 3D Multiplayer Game

Problem

Game engines make creating games a lot easier. The Godot Game Engine is one such engine, and on Februrary 18th (a little less than two months before this proposal) Calvin started working on a 3D game in it (because why not, haha). We plan to expand this game, using some of the animation and visual techniques we’ve learned in the course (details in deliverables).

The major challenges of this project are that the engine is a bit lacking in terms of networking physics. This is because the physics engine for Godot (along with other engines such as Unity) are non-deterministic, so you’d have to send the position/velocity/etc. of each physics object every single frame for it to sync properly, for every object, which is terribly inefficient and also introduces visual jitter due to packet loss/corruption.

To avoid this, for any physics we want to be synced across all players, we need to write the physics ourselves. This poses a lot of work, but a lot of opportunity to learn about physics and the tricks that produce the relatively realistic yet fast physics simulations needed for real-time games.

Additionally, the 3D graphics engine is currently very scant; the current lighting/style is not as developed as we would like. To improve this, we would either need to write shaders or dive into the (mostly) C++ source code and change the rendering engine.

Goals/Deliverables

What we currently have (on top of a somewhat working game):

1. Physics Engine (handles collision testing)
2. Graphics Engine (rendering, lighting, post processing, basic geometry like cubes, spheres)
3. Networking API (avoids having to do low level networking)
4. Basic map, sounds

What we hope to deliver:

1. Shaders that will stylize the game, for example cel or watercolor shading
2. Procedurally generated environments (eg: asteroid fields, buildings, ground)
3. (Networked) relatively accurate physics interactions (eg: player or projectiles pushing boxes)
4. Procedural/Physically based animations. (eg: creating cool animated bosses, such as a flying worm, or being able to slice through meshes using a sword)

For the character:

1. Physics-based movement
2. Ability to attach grapple hook and grapple to physics objects, relatively realistically
3. “Gravity snapping” to surfaces (ie: running into surface will flip your up direction to be the surface normal)

As for performance, of course we can measure framerate of the game to ensure we keep the game playable, but also number of draw calls, function calls, etc. using the Godot profiler (the less, the better).

What we plan to deliver:

It may not be feasible to deliver on all of this, especially physics interactions since we’d essentially be rewriting the physics engine, and procedural/physically based animations in general may take a long time to first figure out how to manipulate meshes in the engine, then to do all the physics/math to get it working.

However, at a baseline we should do networked physics for the player, shaders, procedurally generated environments, and at least a single boss with some procedurally animations. Below is our planned schedule:

Schedule

Week:

1. Learning Godot Engine/working on shaders (probably overall style shader)
2. Wrap up overall shader, procedural terrain, custom physics for player
3. Shaders (if needed for custom meshes, or for example mesh deformation for slicing objects), procedural animation, custom physics for other objects
4. More shaders, custom physics and procedural animations (bosses, such as worm)

Resources

1. Godot Engine website
2. Godot Docs
3. KidsCanCode (Godot Videos)
4. Intro to Rigid Body Dynamics
5. FABRIK Inverse Kinematics
6. Realtime Terrain Generation