Code Correctness
As always, this assignment has a particular set of design features that we expect you to focus on. This time, there is only one new one: encapsulation (hiding data from
clients of structures in the .c
files). Here’s the list of the other design features we’ve already highlighted:
- code duplication
- good variable and function names
- procedural decomposition
- “overcommenting” (e.g., the comments do not explain things that are already clear from the code itself)
- usage of whitespace
- overmodularization (e.g., modularizing into functions that actually make the code less clear)
Physics Engine
One of the facets of architecture we haven’t discussed yet is testability. The idea is that certain interfaces lend themselves better (or worse!) to being tested. Because we want all the physics engines to be compatible, we will ask you to converge on a particular architecture which will definitely be testable. The first step of this was the list interface you implemented last week
This week, we will continue this with the incorporation of two interfaces:
- You will need to have a new “body abstraction” (see
body.h
) which captures the idea of a polygon with color and mass, position, and velocity that can move around the plane. - You will need to have a new “scene abstraction” (see
scene.h
) which captures the idea of a “scene” with many bodies that move around over time.
This week you will also need to make changes to polygon.c
and list.c
, please refer the polygon.h
and list.h
.
You may not remove or edit signatures of functions in the interfaces in body.h
or scene.h
!!!!
The “body” and “scene” abstractions should incorporate most of the redundant code from the previous two weeks (e.g., the main game loop is now in sdl_render_scene
).
To do this, we also introduce the idea of a scene “tick” during which state gets updated. This is basically a wrapper around the dt
idea we’ve been using.
Next week, we will extend the body, scene, and tick abstractions to support forces and impulses acting on the bodies over time in the scene. For now, we will set the positions directly.
If your team has rotated roles correctly, you should have done the demo last week. However, the engine component is much more different from the game and demo components. Thus, before you get started, we highly encourage you to talk with your teammates to learn about what they implemented in the engine in previous weeks!
Testing
We provide tests for the physics engine files. All provided tests must pass in order to receive full credit.
Task 0. When you are done, your group should meet and complete the questions here.