If you run into Makefile/compilation errors, you can run the script cs3-check-files to check that you’ve ported over all required files. The script will tell you which files are missing in the terminal, or you can check the .required-files file in your repo. If all required files are present, the terminal will not print anything.

Code Correctness

As always, this assignment has a particular set of design features that we expect you to focus on. This time, we will focus on testing; so, there are no new design features. Here’s the list of the other design features we’ve already highlighted:

encapsulation
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)

Deliverables

This week there are four deliverables: a force abstraction, two demos, and integration tests.

Force Abstraction

This week, our scene abstraction also needs to support “registering” force and impulses (in a similar way to how sdl_wrapper supports registering key handlers). To do this, you will need to implement some new functionality in body and scene. The idea is, during each tick, the scene runs all attached forces. The forces can be “registered” using the scene_add_force_creator function. We have declared a force_creator_t typedef which takes in a piece of auxillary state to be used by the actual implementation of the force.

Additionally, you will be required to implement force creators for gravity between two bodies, a spring force between two bodies, and drag on a single body. For gravity, note that you will want to implement a minimum distance between the bodies so the force doesn’t blow up (as specified in the h file) - you can play around with this, but using 5 as the minimum distance passes the tests on our implementation.

We have provided you with new versions of the relevant interfaces to finish implementing. Remember, as always, you may add extra functionality, but you must implement at least what we’ve specified.

Demos

The demos are an “n-bodies” demo and a spring damping demo. Here are the video examples:

Both of these demos must use the scene, body, and (new) force creator abstractions. Feel free to change them to make them more interesting if you feel like it. Our implementation uses gravity in the n-bodies demo and spring forces and drag in the damping demo.

Note that you should also port forward all your old demos as usual, but you do not have to change them to use forces. As long as they still run as they are expected to, you are set.

Note that starting this week, your demos may run particularly slowly if compiled with asan. When you wish to run your demo, please run the command make NO_ASAN=true all, instead of the regular make all, or else you may experience demo slowdown.

Tests

This week, you will need to implement three physics-based tests of forces in the tests/student_tests.c file. We have provided examples of the sort of thing we’re looking for in tests/test_suite_forces.c. These tests must run on any valid implementation of the physics engine so far. When you submit your code, your tests will automatically run on our reference solution. We will consider them “valid tests” if they pass on the reference solution. However, your tests must also pass on your own implementation of the physics engine. To run your tests locally, type make bin/student_tests and ./bin/student_tests in your terminal which will compile and run your tests against your own implementation.

Groups and Splitting Up Work

You should be in the same group as the previous week as discussed in last week’s specification.

This week’s project is pretty parallelizable. The force creator abstraction needs to be finished first, but the demos and tests are all mostly independent. We recommend one team member work on each demo, one team member work on the force abstraction and the two required force creators, and one team member write the tests.

Grading

Grading this week will be based on:

functionality
design
tests

Task 0. When you are done, each member of the group should fill out this survey by the project deadline on Thursday at 11:30 PM: https://caltech.az1.qualtrics.com/jfe/form/SV_6imPeo1nHVGhSK2. Your response will be kept confidential and will not have any impact on your grade in this course whatsoever. You will not be able to have your code review if you do not fill this out on time!