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)
Goals and Deliverables
The main deliverable this week is a “pacman” demo which should look something like the following (the arrow keys on the bottom are an overlay to show you what is being pressed–not part of the scene):
This week’s demo is a pacman-like game in which pacman runs around the screen eating pellets. The novel SDL feature this week is keyboard events. The user should
be able to control pacman using the arrow keys. Notably, this means we have updated
sdl_wrapper to include keyboard related management. You will need to integrate this with your code.
We expect your demo to contain (at least) the following:
- pacman should move around and change direction based on the arrow keys
- pacman should accelerate proportionally to how long the key has been held down
- pellets spawn in random locations at some interval
- when pacman runs into a pellet, it should disappear
- pacman should ‘wrap around’ the screen in both directions
So far, our demos have had a lot of repeated code. One of the goals this week is to create an abstraction around the demos (we’ll call this the “scene abstraction”). You will not have to update your old demos to include the scene abstraction, but your new one should use this abstraction.
IMPORTANT: Please note that even though you don’t have to update them to use scene, you should still port forward your old demos this week and modify them such that they still work.
Project Architecture and Testability
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. This week, we will begin the convergence with three interfaces:
- You should already have a generic list; so, it should be pretty quick to conform to our
list_tinterface which requires the following aspects:
- You should
typedefthe struct definition specifically to the name “
- You will need to have
list_sizefunctions that matches our interface in
list.h. This will hopefully involve minimal refactoring.
- You should
- 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. If you are one of the groups that already created this abstraction, all you need to do is make your implementation conform to our interface.
- 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.
You may not remove or edit signatures of functions in the interfaces in
scene.h!!!! You may add functionality if you deem it necessary.
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
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 you are particularly ambitious, you could try to make the extra abstraction this week, but we recommend waiting.
Groups and Splitting Up Work
This week’s project is inherently mostly serial (as opposed to parallel), because you need body to implement scene, body and scene to implement the demo, etc. As a result,
we recommend splitting back into two subgroups of two and pair programming inside those subgroups. In particular, we recommend one subgroup work on the abstractions and the
other subgroup work on the demo. There are significant pieces of the demo that can be written before the scene is ready (such as drawing pellets and pacman).
We have chosen to not ask you to write tests this week, but please be aware that next week will heavily emphasize testing. Thus, grading this week will be:
- 20% architecture (does your code implement the two new abstractions in a clean way?)
- 50% functionality
- 30% design
Every group member must fill these out separately to get credit for the project.