CS 3 (Spring 2021) Project 03: Scenes

In this project, you will generalize and create a ‘scene’ abstraction for all your demos.

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:

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

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:

OpenEnded

Every group member must fill these out separately to get credit for the project.

Submit OpenEndeds For Credit