stream of consciousness

The best place to find out what we have been up to: in the lab, on the streets, or out in the wild.  

media flow


want to collaborate?

follow my


Powered by Squarespace

Entries in thesis (6)

Tuesday
Feb012011

Thesis: digital game progression [obstacle engine]


thesis: digital game demo 2 from Thomas Kearns on Vimeo.

This video is demonstrating basic character control, camera logic, and obstacle generation.

The character control is built upon the bullet library and integrated with irrlicht based graphics and input. For the time being walking, running, and jumping are the only required character control mechanics.
most importantly what we see here is the base functionality of the obstacle engine, which manages the dynamic creation of obstacles for an ever expanding game space. The engine is overseeing the instantiation of new obstacles based on active zones within the physical game space.

Abstractly the engine allows for unique obstacles, in this case represented by simple planes or floors. each obstacle can have a number of connectors associated with it, which parametrically define the possible relationships with future obstacles, effectively controlling the location and dimensions of the gap. While subtle, in the video you can see a growing number of obstacles with their orientation being determined by the orientation of the obstacle it is connected to and on which side. Each obstacle can also define an ideal view point, which we see in the video as the camera is controlled entirely by which obstacle the player is currently engaged with. While still requiring some finessing, the camera’s dynamic quaternion based control is functional.

The engine is also managing the state of the obstacle whether its untouched, yellow, or conquered by the player green. To win in the digital game players will be racing to conquer, similar to qbert, each obstacle in the system. With the space expanding with more and more obstacles the players will be racing to be faster than the generation. The rate of generation is also tied to the status of players in the physical game.

Future additions to this system will be the telepresence representation of physical players, and what I am currently working on now, the ability for designers to create custom, animated, obstacles in 3dsmax with the ability to define connection points, conquer triggers, and ideal view angles, these custom obstacles will replace these simple boxes with creative spatial obstacles for procedural combination into an interesting, dynamic landscape for players to navigate

Monday
Nov012010

Thesis: digital game beginnings

This demo was built using the irrlicht graphics SDK, the bullet physics engine, irrKling audio library, and my simocc library for microcontroller communication.
For the past few weeks I have focused my attention (away from the physical game) at getting the foundation for the digital game working in terms of production pipeline, core systems, etc.

Specifically, as seen primitively in the demo:

the game is going to be 3rd person with a little big planet style camera, in which each obstacle can define it's own ideal view, to which the camera will smoothly slerp to (right now for testing, I have view quaternions being toggled by joystick)

the character is the demo md2 model for the irrlicht demo's controlled by a modified version of the bullet kinematic character controller, still have some orientation issues, but happy to have the player usable for testing purposes. (if someone wants to design a sweet character I’m looking for artists)

physics engine integration working pretty solidly.

and besides just having a kind of grey-box making pipeline, the crux of this demo is a not so apparent, but relatively sophisticated procedural environment system. using custom builder, factory, AI engine combo, new obstacles can be generated on the fly (right now based on time, or as in the demo, by button press).

Unlike a conventional tile based system the obstacles are nodes which possess x number of connections or edges which define variable parametric conditions, this is to allow the environment to grow in a much more organic way, not limited by a grid. At present there are only two node types, flat floors and a spawn point. This will soon be joined by fully animated, physically simulated platformer obstacles modeled in max and exported using my custom exporter. The essence of this system, which is largely in place though still buggy (overlapping obstacles aren’t eliminated yet) is an easily extensible, relatively intelligent, custom obstacle course generator.

views tied to obstacles, no overlap, and the QBert style obstacle tagging coming soon, then connectivity to the physical game ... the ultimate goal for this term (3 more weeks)

Thursday
Oct072010

spatial gameplay - aligning vs expanding

physvsdig

gameplay parti: best I can do right now for an “image of the game”, might be a bit subtle but most of the key ideas are in there.

Thursday
Oct072010

Laser Station Model

laser station v001

Here is the current working model for what the final laser station housings might be.  The objectives: ease of assembly and reduction of custom pieces, which has lead to almost entirely off the shell parts, from the steel plumbing pipe used for the structure, to the Sono-tube cast concrete base, etc.  Primary customization would be the need to weld a stud to the end of the laser shaft for the drive train attachment and the soldering of tabs onto the end of the hand wheel to trip the photo interrupter. One order from McMaster, one from Jameco and a trip to home depot should produce all necessary parts.  Custom piece fab time should be relatively quick or inexpensive.  The biggest obstacle in this design is where and how to decouple the drive train electronics from the control due to the need for continuous rotation.  To achieve this I will de-couple the crank encoder and motor control from the micro-controlled system mounted on the rotating shaft.  The photo-interrupter at the hand wheel will trigger pulses on the IR detector in the hollow of the base to communicate rotation back to the microcontroller and will independently drive the motor through a timer based circuit mounted in the base.  This will allow all other i/o (indicator, laser sensor, xbee, etc) to be housed on the rotating arm.  In the end more complex than I imagined, but the price is paid to allow the laser to be controlled by motor which opens up lots of possibilities for cross reality gameplay

Tuesday
Oct052010

laser game prototype

Here is the first working prototype of the electronics of one module for the physical game in my trans-reality game for my thesis at DePaul. 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 succesfully 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. 

thesisProto001a

thesisProto001b

The next step will be to build a second one of these and to put them both in mockup housing/mechanical assemblies so that game play can be tested.  Hopefully in a week or so we will be able to give it a go and then I can move on to the digital game.