Robert J Duncan IV


What Pit Lord Do

Core Details

  • Completion: September 2010
  • Span: 2 weeks
  • Project Type: Academic Team of 4
  • Platforms: Panda 3D, Head-Mounted-Display, Magnetic Positioning Trackers
  • Role: Programmer/Designer

Developed as my first (or "round 1") team assignment in the Building Virtual Worlds class at Carnegie Mellon University's Entertainment Technology Center, What Pit Lord Do is a 3-dimensional puzzle game that involves virtual reality, strong mechanics coupled with entertaining visuals, and plenty of violence.



As the player in What Pit Lord Do, you are the Pit Lord, a giant deity living within the earth. As the Pit Lord, it is your objective to guide a series of red and blue tribesmen from their entry gates onto worship plinths. However, as the Pit Lord you cannot directly interact with the tribesmen: instead, you must arrange a series of blocks to spiritually guide the tribesmen to their goal. Unfortunately for the tribesmen, they are all but blinded by masks, and arranging the blocks correctly is no easy task: some of the blocks are beyond your power as Pit Lord to move, whilst others still are in fact deadly traps waiting to strike out at unsuspecting tribesmen. Worse yet, should a tribesman make a wrong turn, he might end up falling into a bed of spikes, splatting from a sizable fall, dropping into the abyss, or even meeting a grizzly end at the hands of death himself. If you're quick, perhaps only a few will die...


What Pit Lord Do was designed to take full advantage of the benefits and minimize the drawbacks of its target platform: a Head-Mounted-Display (HMD) and set of Magnetic Trackers. While no formal design document was developed due to the short time-frame of the project, multiple considerations were made. Specifically, the following major advantages and disadvantages were identified for consideration regarding the HMD and trackers:

  • The HMD provides the player with a very intimate viewing experience
  • The player's hand and head position/orientation can easily be mapped onto a virtual character to create a seamless translation from player to avatar, especially if the player's head's position/orientation is mapped to that of the camera
  • The player's spatial awareness of the virtual-world can be supplemented directly by their own spatial awareness
  • Navigational movement (such as walking) must be reduced to a form of gesture or stance, as the player cannot leave the (narrow) sensor-cone; "walking in place" has proven unviable
  • The system has no means of providing haptic feedback or enforcing virtual constraints on the real-world, thus making virtual constraints regarding position/orientation artificial at best, un-enforceable at worst

In order to capitalize on the intimate viewing experience created by the HMD as well as the character-mapping capabilities provided by the magnetic trackers, it was quickly decided that the game should utilize a first-person perspective with the camera's position and orientation mapped to a tracker placed on the player's head. This setup essentially allows the player to look around in the virtual-world just as he or she would in the real-world. This mapping of the virtual-world to the real-world thus enables the player to use their spatial awareness of the real-world to supplement their spatial awareness in the virtual-world. Simply put, the player can use their own sense of balance and position in addition to the visual and audio cues that are normally the only form of spatial awareness provided by a game. To take advantage of this boon to the player's spatial awareness, it was decided to create a game that intimately surrounded the player on all four sides: a situation that can often be disorienting when only visual cues are available, particularly when quick movements are required (to exemplify, imagine attempting to navigate within a vertical tube using only visual cues: if the tube does not provide strong visual identifiers for one's orientation, such a task would be nearly impossible; even with such identifiers, one would need to memorize the relation between said identifiers in order to effectively navigate the space). Early tests showed that such navigation was indeed completely possible utilizing the HMD and tracker system, even in the absence of strong visual cues.

Given the constraint that player movement within the platform is difficult at best, it was decided that a game that required the player to be stationarily positioned (but still capable of full rotation) was the optimum design. Thus, it was decided that a game that allowed the player to manipulate their surrounding environment with his or her hands would be an ideal interaction. Based on this interaction model, it was then decided that allowing the player to freely place or arrange blocks in order to achieve some goal would be a viable mechanic. This mechanic was also chosen for the large degree of modularity and scalability it provided (two concepts that were recognized as vital given the short development time allotted for the project). Notably, while options were explored to enforce the virtual constraint of preventing blocks from colliding with or clipping through one-another, ultimately it was decided that such a constraint was out-of-scope to properly enforce, particularly given the platform's inability to provide haptic feedback. Thus, it was decided that by having the player interact in the world as a deity character with disembodied hands, situations resulting un-realistic collisions or geometry-clipping would appear less "out-of-place" due the already surreal nature of the character and interactions. These design choices, coupled with a player's natural tendency to avoid such collisions, resulted in an experience without many noticeable occurrences of geometry-clipping or inaccurate collisions.

Lastly, it was noted that due to the nature of the platform, a player is able to very easily "lean in" to obtain a closer look at their environment, and that the intended interaction model of picking up and placing blocks allowed the player to bring blocks up to their face for closer inspection. Thus, it was decided that the player's character should be gigantic (so as to encourage them to take a closer look at all of the interesting little things surrounding them), and that the environment should be developed to standards of high fidelity. With these concepts in mind, a Mayan aesthetic and theming was then chosen for its richness of palette, plausibility of involving blocks, potential for interesting texture (blocks could enjoy intricate carvings, richly-textured materials such as limestone, and even plant-growth), and compatibility with a deity character.

Given these various designs and decisions, it became clear that puzzle game mechanics could fit well into the interaction model we had developed. Thus, the game mechanics for What Pit Lord Do were then developed. It was decided that intelligently arranging blocks toward a particular goal would be an ideal gameplay objective, and that the best way to have players achieve this objective was to have them create paths. In order to create a thematic need for said blocks to form paths, it was decided that tribesmen should traverse the blocks to reach a goal (in a fashion somewhat akin to that of Lemmings). Based on this inspiration, it was also decided that a valuable thematic quality of the game would be the potential for a variety of unique tribesmen deaths to result from incorrect block placements. At this point, the basic rules and block types were developed, paper prototypes were built, and the design was iterated upon. Once a solid foundation of all major mechanics was developed, implementation began...


As was previously mentioned, modularity and scalability were recognized as absolutely vital to the project given its 2-week development timeline. Thus, in all aspects blocks were designed to behave independent of one-another, while the accompanying "world engine" was built to allow the addition of new block-types to require minimal modification. Upon completion, the system incorporated 13 unique blocks, 7 different ways for tribesmen to die, the ability to support any number of individual tribesmen attempting to reach any number of plinths, and a puzzle creation system that, while code-based, was simple and abstracted enough to enable non-programmers to develop puzzles at their leisure. Notably, due to the design of the implementation, the system can theoretically support an essentially unlimited number of blocks and deaths without interfering with the existing mechanics. Most notably, this modularity allowed the project to be dynamically scoped mid-development without any loss in quality to the base mechanics. In turn, the project became a great overall success that was well received by faculty, peers, and even outside audiences.


Return To Top