Code Correctness
As always, this assignment has a particular set of design features that we expect you to focus on:
- 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)
Deliverable
This week’s demo 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.
Update 4/17/24: Note that our ref files implement gravity for you in polygon_move, so you don’t have to implement gravity yourselves. Also keep in mind that your polygons will probably move much faster than those shown in the video; don’t worry about that!
Additionally, this week you will be using the generic list_t interface in the provided list.h file, which is effectively replacing the vec_list_t interface that your team implemented last week. Make sure you are creating/modifying lists with list.h and not vec_list_t!
Helpful Tip for Debugging: Run your game in Chrome! Other browsers may have issues with emscripten, and you can also debug and see what you print in Chrome by right-clicking and clicking “Inspect” and “Console”.
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 grade you individually based on:
- functionality
- architecture
- design
Here’s a bit more detail about architecture:
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.
Task 0. When you are done, your group should meet and complete the questions here.