The Passage

The Passage Screenshot


The Passage is my final project at Full Sail University and is still in production. In this game, you play as a tribal-esque youth who must run on the back of a gigantic creature and slay it at the end. A maze of bones on the creature's back slows progress and periodically the creature will turn on its sides or fly upwards. This changes the dynamics of the level, making it what was once walls into platforms or forcing you to climb your way up. See Figure 1 for a concept on the level of rotation.

My Role

On this project, my main tasks have revolved around rendering. We had a good start on it by utilizing my DarkForge engine that I had been working on for a couple of months. By the start a number of features were already well established into the rendering pipeline and many more were on the way. For a complete break down on what my engine does, please refer to the page, but here I will discuss how it relates to The passage.

DarkForge already had built into it a user interface engine using XML and LUA scripts. Thus far mostly the XML has been utilized and has allowed for the rapid integration of user interface such as the menus without wondering if a button would highlight properly as a lot of major bugs had already been worked out. This allowed for more time to be put forth into other areas of the project and the challenges of a rotating world.

So far in the project I have expanded DarkForge to handle collision meshes, and more efficient memory management with shaders and textures. Collision detection is another thing added, with both line to triangle and sphere to triangle checks implemented and used throughout the project. Finally, some base code for supporting animations while the actual code for animations is more directly related to the game. Animations in The Passage currently utilize smooth skinning. This was implemented on top of DarkForge by me and team member Richard Nelson.

Almost no scene management is used in the game as far as limiting drawn triangles, though it will likely be added in the future to improve game speed. The reasons for this course of action are simply that draw calls are a major slowdown for the rendering pipeline and batching up all the objects by texture into one mesh would result in higher speeds. Thus far the level renders upwards of 300,000 triangles with a 10,000 triangle collision mesh. Since the scene is far from finished, it is expected that some breaking up will occur as a more robust rendering pipeline is engineered. This will include better batching of meshes with context's (such as shaders and textures) without context switches.

Beyond Rendering

My work on this team has expanded beyond just rendering as I helped design many key concepts for the code such as how to accomplish the rotation of the whale, collisions, and a function pointer state machine.

Early on it was a concern on how to rotate the whale without dynamic geometry. Knowing that games often use cheap tricks that a magician might, I looked beyond rotating the world. The implementation I proposed was to rotate the player and camera, simulating the world's rotation. While not free from issues such as collisions while rotating, issues were greatly diminished and the system integrated at a steady pace and has been working.

With the tech lead, Pablo Leon, I helped solve some of the collision issues that we experienced in early builds. Collisions for the player's movement mostly revolve around a couple of line segments and bounding spheres on the player that can help detect a variety of collision types that helped to later solve context sensitive slides (under limbo type bars) and hanging from edges. Currently a system of splitting the collision mesh into various types of collision geometry is being implemented to cull down the number of checks and reduce false positives for collision responses.

"If Statements" annoy me to some degree in that they can be a major bottleneck for code to decide what to do based on information received. Complex if statements with multiple "else if's" can hold up code far too long. State machine's are one way too help solve that issue and my favorite is function pointers. For our character, we implemented a function pointer state machine with a variety of functions representing the various states. When an action comes in to the player, it sends that action command to the function state it currently is in. That function state then processes the command and does what it should based on the state, and will change the function pointer to a new state. This method was in an effort to reduce include bloat from multiple classes and has worked extremely well for the project.

Future Work

Rendering and collisions are in need of a rework to improve performance as the scene gets more complex. After that, my job descends into shaders such as integrating depth of field and possibly lighting. Other tasks will likely crop up as major parts of the game remain unimplemented so far.



Chad Hoover


Pablo Leon

Justin Forman

Richard Nelson

Harrison Greene

Anthony Messa

Jonathan Caro


Dan Avella

Frank Mercurrio

Tom Vignola


Powered By Lua
Visual Studio 2008


Production Screenshots

Site Development and Design by <CS>

Graphic Design by Nathan Schoell