For this project, I designed a flexible game engine framework for rendering a hierarchy of objects, and created a controllable spider character with procedural IK animations. The engine and renderer were written from scratch without using any provided classes or starter code, and the IK solver was adapted from Assignment 4. The full source code can be found here.
The Spider
Leg Targets
When the spider is moving, the motion of its legs are controlled by a set of targets. These targets are aware of their neighbors and will not move at the same time as an adjacent leg. Also, leg targets will account for the current velocity of the spider, and offset their motion to make the spider 'reach' out in the direction of its movement.
IK Solving
The IK solver for the spider was adapted from the Assignment 4 starter code. The target points are transformed into the local space of each leg, then the leg's root component is rotated around the up axis to face the target. Then, the legs interpret the point as a simple 2D IK problem, with very loose tolerances for best performance.
Engine Features
File Inputs
The game reads all scene and character data from YAML configuration files, making it easy to adjust parameters and create new maps without rebuilding the project. The game reads many useful properties from these files, such as the scene geometry, physics timestep, and the number of legs to use on the spider character.
Object Hierarchy
Every object in the game is descended from a shared base class that supports parent-child relationships between any objects in the scene. This creates a flexible system of attachment that can allow any object (such as the camera) to be parented to any other object (such as the spider character) directly from the YAML configuration file.
Transformations & Shaders
When reading the objects from the YAML files, any shader can be assigned to any object. When these objects are rendered, the engine will sort them by which shader they use, and render each shader in a group (i.e. all objects that use a certain shader will be rendered in one batch).
Fixed Physics Timestep
All physics updates (like velocity adjustments and propagating parent motion to children) are calculated in a separate function from the main rendering loop. And, every physics update will use a fixed time step to avoid unstable physics when the game's framerate is low. To account for this, the game may run the physics timestep multiple times (or skip it entirely), depending on how fast the main rendering loop is running.
In the images above, note that the speed of the character is consistent, even though the framerate has been artificially reduced in the second image.