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: code duplication. We strongly expect that you will be tempted to copy entire files of code or files with a significant resemblance to each other. Don’t do it. You’ve been warned. Here’s the list of the other design features we’ve already highlighted:

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)

Goals and Deliverables

The main deliverable this week is a “gravity” demo which should look something like the following:

Conceptually, this demo is a strict generalization of the “bounce” demo from last week. Instead of one star, we’ll have \(n\). Instead of one color, we’ll switch through many.

We expect your demo to contain (at least) the following:

Stars should pop in from the top left corner.
The stars should have varied colors and numbers of sides.
The stars should bounce off the “ground” and rotate as they go. These collisions should have a variable amount of elasticity.
Each star should have a realistic “arc” as it travels to the right side of the screen.
Once a star is off-screen, it should be removed from the scene.
You must be able to handle \(n\) stars where \(n\) is a variable number that does not depend on hard-coded numbers in your code.

You will need slightly better abstractions (in particular, you will need some kind of resizing for your list) than you did last week, and we expect you to spend a significant amount of the project time on improving them. Your bounce demo from the previous week should still compile and run correctly despite any changes you might make. This means that gravity should be a separate demo. This week, we will also ask you to write some tests for the list(s) you create. You are allowed to edit any and all files we have provided to you.

If you find yourself spending very little time on this project other than writing the demo, something about your architecture probably needs to be modified.

Groups and Splitting Up Work

As you are likely aware, this week, you will be working in groups of four. Importantly, this means you will need to choose one of the subgroups’ work to start off of. We will ask in the code review why you chose that group’s code–so, please be prepared to answer that question.

All coding must be done in (at least) pairs via pair programming this week. Nobody is allowed to code without another group member present. This is because the design decisions are the major goal this week, and you must justify them amongst yourselves before actually coding.

Grading

As the project gets bigger, the architecture of the individual pieces and how they fit together becomes more and more important. Since this is such an important focus of this week, we will break up your grade into four pieces (rather than the usual three):

functionality
architecture
design
testing

Here’s a bit more detail about the two new categories:

Project Architecture

We believe the current size of the project is a good size for you to experiment a little bit; so, this week, we will provide basically no guidance of how to actually break up your code. (However, we will discuss this in great detail with you at the code review.) Next week, we will require your architecture to fit with where we’re eventually going (generalized forces acting on bodies, testing for collisions, etc.). You are encouraged to discuss your design at office hours. You can (and should) modify the Makefile to include your new targets. If you do not have at least one new module, you are doing something wrong.

Testing

Since this is the first week we are actually requiring you to write your own tests, we will grade these very leniently. At the very least, you must copy our tests from the previous week and modify them to fit your new architecture to get these points. Note this week there are no tests to pass on gitlab.