Code Correctness
Throughout this course, we also want you to focus on your code quality in addition to the functionality of your code. For the complete list of code quality items we’ll look at throughout the quarter, please consult the code quality document. If we see code quality issues during code reviews, we will ask your group to resubmit the project with those issues fixed.
We will take off points if your code has memory leaks, so be sure to check for them before you submit your code!
Implementing the engine is a prerequisite for implementing the demo!
Deliverables
This week’s demo uses destructive collision handling to create a version of the Space Invaders game.
Demo
The demo this week is a simple version of Space Invaders. Note that the last video has been sped up 2x.
Your game demo must have the following features (but feel free to play around and implement anything you want otherwise):
- There must be several rows of enemies that move in approximately the same way as our demo (that is, across the screen, then down a “row” repeatedly)
- Both the player and the enemies must shoot projectiles at each other (the enemies automatically, and the player when the space bar is pressed)
- The player must move back and forth based on presses of the arrow keys
- The demo should stop when (1) the player is shot, (2) the player clears all space invaders, or (3) the space invaders ‘fall’ below the ground.
This demo may run particularly slowly if compiled with asan. If you want to run it without asan, please run the command make NO_ASAN=true demo, instead of the regular make demo, or else you may experience demo slowdown.
Important Changes
Several important and relevant changes to the physics engine are highlighted below:
Collisions
This week, one of your teammates will implement collision detection. Take a look at collision.h to see what the find_collision method should do.
For your demo, you will also have to use some sort of destructive collision. We have defined two destructive collision methods for you in forces.h and implemented them in forces.c that you should use.
Body “info” field
Different applications will need to use different extra information about bodies. For example, for Space Invaders, you will need to be able to differentiate between the player
and enemies. Thus, we will add auxilliary data to the body as a void *. Take a look at body.h to see how to use the new “info” field and
your teammate’s implementation of it in body.c. Again, we encourage you to talk with your teammate who implemented the engine to get
a better sense of how the code works!
We’ve also given you an example of how to do so in make_bullet, but feel free to change your info to whatever makes the most sense for you.
emscripten_main
emscripten_main returns a bool now that tells the game loop if the game has ended.
If it has, SDL quits. Look at emscripten.c to see how it’s being used.
This will be relevant to your win/loss conditions this week.
color_compare
We’ve implemented a a new method color_compare for you to see if two colors are equal. Depending on how you implement the demo, it may or may not be used, but we wanted to let you know for future weeks as well.
sdl_wrapper
We’ve defined a new enum for arrow_key_t, called SPACE_BAR, in sdl_wrapper.h. Note that it is set to 6, not 5 (since esc is mapped to 5).
You’ll have to make another change in order for the player to be able to use the space bar.
The teammates working on the game portion of this week’s project may have modified sdl_wrapper.c.
If they already made these changes, make sure not to override them!
Once all your group members have finished, work with them to complete the extension (more information in the main project page).