CPE 471 Final - Beat Block Barrage - Max Linsenbard


Beat Block Barrage (BBB) is a 2-player game where one player attempts to avoid an onslaught of multi-speed beat boxes launched by the opposing player. The Block player controls with the ASW keys and the Ship player controls with the JK keys.


BBB was actually meant to be a rhythm-based endless runner. However, getting an Audio library working took the backseat once other problems/features emerged. Thus, while playing around with the block spawned I thought it would be fun to leave BBB as a multiplayer game that could eventually support rhythmic timing.

Techy Details

Toying with the eye point and lookat point of the camera actually took up a good amount of my intial time working on this project. I wanted a slightly restricted view so the player wasn't presented with too bland of a scene, but I also needed to have enough space for the player to both see the block spawner and have time to prepare for faster moving blocks.
I ended up with a high camera placed above the ground looking down towards the middle of the 'track'.

The smoothness seen when the ship moves left and right is simply done using an exponential equation. As the user moves left or right, a destination is set in the corresponding lane. The ship then rotates and moves towards the lane, covering 1/4 the remaining distance each frame. When the ship gets within 0.1 world units of its destination, the destination is 'set' as the ship's current position. The camera moves the same way, but is scaled slightly less.

The Cube management system was the hardest part of the project (aside from spending 5hrs on OpenAL just to get nothing working).
Cubes are kept track of via a std::vector with a max_size that is set in the globals. When a player spawns a cube, it is added to the vector and is given an interval (at which to move). A timer is kept during the game's runtime and that timer ticks every 1/4 second (a 16th note in a 120BPM song). When a tick happens, all non-moving blocks have an interval taken away. When that interval between moves reaches 0, the cube begins animation. When it finishes the animation after interval*4 many frames, the cube is checked for being offscreen, collision with ship, and if it needs to restart its interval animation timer. Cubes that have left the screen are erased from the vector.

Since an actual UI was out of the scope of my skills, I decided to represent important player details with well placed models that help teach players what's going on as the game progresses. The UI is just 12 models placed on either side of the track.

What kind of graphics project would this be if a Stanford bunny wasn't featured? The thrusters on the back of the ship release wavering clouds of bunnies as the ship 'moves forward'. The bunnies are all managed with another vector and have an initial position, final position, and velocity. Each frame, the bunny is progressed towards its destination on a scale with its velocity. Its X position is then slightly randomized so that the bunnies kind of vibrate back and forth. This combined with their rotation gives a suuuper slight image of smoke if you look at it right!

Because this was (and still is) planned to be a rhythm game, I put together an Electronic track to be played along with game while its running. The blocks sync together with the music pretty well for the most part, the so rhythm aspect of the project was not completely thrown out.

I used none, though I did get some Rubber Ducky help from my friend Aaron Jacobs. However, we were unable to meet to get FMOD working, which is why I ended up abandoning it so abruptly.