Race(s) Across Space(s) - space to play consulting

Race(s) Across Space(s) | Capstone game prototype

About the Game
	The influences I am compelled by the technological transformation our society has undergone in the last two decades. Here we have witnessed the emergence of living in physical environments as well as in digital environments. My R+D work over the last decade and the focus of my capstone project at DePaul serves as a kind of allegory and example for this “simultaneous occupation” of physical and digital space.
	The abstract objective To create a hybrid game space which involves discrete play in both physical and digital environments while also maintaining direct real-time connectivity across the physical-digital divide. Play in one space affects play in the other space. Is it collaboration or competition? Neither space is subordinate to the other and each benefit ludicly from the other. Idealized play across spaces create a kind of self perpetuating bachelor machine.
	The concrete A “real world” action game in which players race through physical space to align a site specific network of lasers + a “digital world” platformer in which players race through a 3dimensional procedurally created obstacle course. The hook, players race not only against the space of the game, but also each other. As a zero-sum game across spaces, aligning lasers increases the rate of obstacle production and conquering an obstacle depletes the power of aligned lasers.
Gameplay
Physical Gameplay
	players race through urban spaces to align a site specific network of lasers hand cranks simultaneously add “power” to the system while also moving the lasers into alignment, this power begins to leak out of the unit once cranking ends players win when all the lasers aligned and adequately “powered”
	each deployment of the game can and should take advantage of it’s context for creating challenging arrangements of objects as well as to incorporate the public or the passerby as potential friend or foe. In this way the game operates “situationally” both as a kind of “constructed situation” and a “psychogeographic mapping”
Digital Gameplay
	not unlike the fantastically simple video game classic, Qbert, digital players race through a 3dimensional space to “conquer” spatial modules. Unlike Qbert, this space is ever expanding, with a procedural course generator that is selecting and placing new spatial modules in apparently unpredictable ways. Players win when all the obstacles have been “conquered”
Hybrid Gameplay
	aligning space vs. expanding space the initial point of departure is that there is simply a zero sum relationship between the amount of “power” in the physical system and the size of the digital world. More power in physical space (read - closer to the finish) equals more distance between the digtal player and goal and vice versa. As digital players conquer obstacles, power is more rapidly depleted from physical space.
	In physical space, multi color indicator lighting on each unit provide both a visual feedback for the players about the alignment and power but also a kind of telepresence about where the digital players are and how they are affecting the physical game space
	In digital space, the physical player influences, and is embodied by a visually represented gantry infrastructure which lets the digital player see where the next obstacle is going to be placed.
Engineering
SDK integration Initially I was excited by the idea of utilizing the custom game engine I had been developing in my engine development courses to create my capstone game. However, weighing the issues of completing the already ambitious project as a solo project and the ramifications of time spent developing the engine vs. time spent developing the game I decided to use a third party game engine. With a small amount of experience using the source sdk it was my first consideration, along with XNA and the incre asingly popular Unity engine. Ultimately I chose to use the Irrlicht open source graphic engine as it was the closest in stripped down sensibilities to my own engine. Unlike XNA it would allow me to continue honing my c++ abilities and unlike unity it would both force and allow me to build more from scratch. In addition to irrlicht I wanted to gain some experience integrating middleware into the system. To that end I decided to use the open source Bullet Physics Engine for rigid body physics simulation. In my early project development I had also integrated the RakNet networking middleware though subsequently have opted pull RakNet and multi player support out, simply due to the limited time frame of development. For the content creation pipeline I utilized the AutoDesk FBX platform and SDK.
Simocc Library To facilitate creating mixed reality games or alternative input devices for games, namely my capstone game, I created a communication library I refer to as the “Simocc library” for communicating serially with microcontrollers. Using the library, developers can create game objects which inherit the ability to track data from physical objects, and/or to be tracked. The manager component of the library handles the socket connections, uses an observer pattern to allow objects to subscribe to each other’s accessible data, then to be notified of data accordingly, and oversees the serialization/deserialization of data packets and endian conversion. Currently the library has specific components which are used for the Arduino platform on an Atmel processor and conventional PC’s
Obstacle Editing/Integration from Thomas Kearns on Vimeo.	Editing in 3dsMax In my history of working with publicly available game development tools I have always been frustrated by the need to use intermediate tools to bridge between applications like 3dsmax and the game. These tools have always seemed like terribly limited, poorly designed cousins of the more robust modeling environments that preceded it.
For my game and tool development it was important to me to be able to create a pipeline that allowed my colleagues in the architecture world to participate in development using tools they were familiar with. To achieve this I am using the FBX file format and the FBX sdk to integrate the design of obstacles into the game engine. In short designers may model and map the graphic meshes and maps, create and link physics proxy meshes, define obstacle connections (range of gap length and drop, orientation of connection, and parent dock location) trigger volumes, ideal viewing angle (influences the dynamic camera control), etc within the 3d modeler using the native tools. In the game, an XML file list of desired obstacles exported in the fbx format is read and obstacles are loaded upon startup, from here the procedural obstacle engine takes over for the dynamic creation of the digital game space.
Procedural course generator The core of the game is the procedural course generator. Here the on-the fly creation of the gamespace is also the primary objective. Explore or “conquer” every obstacle in the system before the engine creates another obstacle and you win. The course engine communicates with the microcontroller to determine the number of nodes in the system, creates a procedurally generated starting platform and a single startup obstacle for each zone. Each zone has generation rate which is connected in real time to physical interaction nodes. As players in physical space “crank” power into the node the corresponding rate of generation is increased and the placement selection redirected.
	Each obstacle is designed with a minimum of 2 and up to N, number of connection parameters, which define potential locations for new obstacles to be placed. The “connectors” establish a 3dimensional direction vector as well as maximum horizontal and vertical gap/spacing dimensions.
	After an obstacle has been placed, the next location within the active region is determined. To do this an obstacle candidate is selected from the pool of pre-loaded obstacles, the system then test places the chosen obstacle’s bounding volume with orientation proper to the connector definitions of available connections. If there is no collision of bounding volumes the transformation and identification information is stored for use by the generator.
If the obstacle won’t fit, another available location is tried and/or another obstacle In addition to procedural course generation, the obstacle engine is also managing the core gameplay. Tracking the status of each obstacle, which characters can “conquer” by entering designer specified trigger volumes. When players are utilizing the “designer” cam mode of camera control, the obstacle engine’s player to obstacle tracking updates the cameras orientation and zoom using view specifications defined by the obstacle’s designer and owned by each obstacle.
Procedural Environment Generator from Thomas Kearns on Vimeo.	The outcome of this system is a completely data driven, full 3d, procedural obstacle course generator that is guided by alternative physical input devices for a relatively infinite amount of gamespace possibilities.
Physical Game Its clear with the physical interface developments on all three major consoles that exploring new modes of input and output are very important to the development of the industry. Hence, I am both interested in and have experience designing physical interaction systems.
Laser Game Prototype #1 from Thomas Kearns on Vimeo.	The game mechanics of the physical game are implemented by programming microcontrollers and building i/o circuits connected to the microcontrollers Shown is the photo-transistor based sensing of a standard laser pointer. Sensitivity is controlled by a potentiometer.
Visual feedback is by way of a tri-color LED variably throbbed by 555 based timer circuits, modulated by digital potentiometers, green when laser is aligned, red when not. An IR detector is used for monitoring the "cranking" up of power, and controlling the rotation of a motor that will be used for alignment. As power is added, the throbbing slows down once the player stops cranking (to run off to the next laser station). The “drip” of power is sped up when not successfully aligned. This project is running on an Arduino microcontroller utilizing Zigbee based wireless communication which allows ad-hoc mesh networks of these stations to form scalable site specific instances of the games.

SPACE TO PLAY

Race(s) Across Space(s) | Capstone game prototype