Code Correctness

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_t interface which requires the following aspects:
  • You should typedef the struct definition specifically to the name “list_t”.
  • You will need to have list_init, list_free, list_get, list_add, list_remove and list_size functions that matches our interface in list.h. This will hopefully involve minimal refactoring.
• 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 list.h, body.h or scene.h!!!! You may add functionality if you deem it necessary. You may also modify functions and function signatures in sdl_wrapper and emscripten.

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

Grading

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 based on:

• architecture (does your code implement the two new abstractions in a clean way?)
• functionality
• design