Aspiring Game Programmer Extraordinaire

WPI – April, 2008

PC, Mac, Web

Official Website

Summary

Notebook runner is a reverse 2D platformer where the computer controls the character and you create the level.  It takes place on a sheet of notebook paper. The computer plays as the character as if it is a platformer game, while the player adds elements to the level, attempting to steer the character to the goal. The player does this by drawing symbols with the mouse which create either a platform, wall, ladder or spring.

Notebook Runner uses Java Monkey Engine with a basic proprietary physics engine. The game has minimal art development, using mostly stick figures and lines, giving the game a “notebook” feel.  The focus of this project was on technical design and implementation, so a minimalistic art style was chosen (also, there were no artists on our team ).

My role and lessons learned

I created the character AI, collision detection and physics systems and additionally helped with the initial game design and theme.  Our goal with Notebook Runner was to prototype something unique.  Designing the game to require minimal art assets helped expose technical and gameplay issues while creating a more satisfying final product.  I gained valuable experience designing a unique game from scratch as well as working in a team following structured development cycles.  This was my first experience creating a physics and collision system, as well as creating a character AI that was essential to the gameplay.  The following are descriptions of my contributions to the project (from the project website)

Collision Detection and Physics

For Notebook Runner, we specifically decided to create our own physics engine. Using a 3rd party physics engine seemed a little overkill and would bloat the game with unnecessary code and complexity. Because we were only dealing in the 2d space and staying true to the platformer feel, we could get away with using only 2d projectile motion. Collision detection is done through bounding boxes that exist in 3 dimensions, all aligned to relatively the same z value. Because we have very slight offsets in the geometry positions, we extrude the bounding boxes along the Z axis to work with this design. Every type of object has its own bounding box associated with it, and some objects have multiple types of boxes to add certain effects. Platforms, for instance, have “jump” bounding boxes at each end to signal the character to jump, while walls and ladders both have “springs” at the top to cause the player to jump if they should land on the top of one. Each bounding box also has a priority. This priority is used to determine which bounding box the player should react to when it collides with more than one. The type of bounding box (with the highest priority) that the player collides with is passed along with the time since the last frame to an update method in the character object. This method update the Finite State Machine and moves the player a certain distance. The update method is called for the player’s position approximately every 10th of a second to decouple framerate and physics calculations.

Artificial Intelligence

Notebook Runner’s character uses an object-oriented hierarchical finite state machine to determine what actions the character will take. Around 10 times per second, an update method is called which sends any collision data to the FSM. The FSM check if any of the transitions between states have been achieved, and determines which state the FSM should transition to. Each state has its own velocity vector and acceleration vector that determine the character’s movement. There are a few special instances where the player’s actions are determined differently. For example, when the character collides with a wall while walking, there is no state change, but the player’s x velocity is reversed. Also, when the character collides with a wall in the midst of jumping, the player’s x velocity is set to zero.

Gameplay Demo

Team Gravity Pole

• Ryan Lasante (Tech)
• Tim Volpe (Tech)
• Myself