Illuminate
\| Abstract | \ \|
| Game Title: | Illuminate | \
| Development Team Members: | David Kjos Jr. and Jessica Wu | \
| Game Genre: | Puzzle | \ \
| Brief Description: | Light, emitted as a beam from a single point in space, must be refracted through the various crystals on the playing field in order to illuminate space. The players cannot affect the light directly, but can create and manipulate gravity wells that will pull and bend the light. | \ \ \ \
| Overview | \ \|
| Game Story / Objective: | Light must be refracted through crystal stars to illuminate space. Players need to generate gravity wells that pull and bend the light. Light up all the crystal stars to win the level. | \ \
| Game Mechanics + Controls: | Gravity wells are generated when a player comes into contact with the multi-touch screen. The position is determined by the location of contact and can be moved along the surface of the screen. Light is then distorted using a pseudo-realistic physical model. The screen is in a table form, allowing many players to join in and create gravity wells. Cover up the source of the light to go back to the menu screen. | \ \
| Technology: | Development is done in C++ using the openFrameworks libraries with support from Intel's Integrated Performance Primitives (IPP). The multi-touch screen is built using a computer camera, a projector, and acrylic that has been lit to cause Frustrated Total Internal Reflection. | \ \
| Aesthetics: | The menu screen was created in Illustrator. And the rest of the aesthetics are designed using openGL 2D graphics. Animation was also done in openGL. Crystal stars have illuminance based on the distance it is from the light beam. Also they spin when fully lit. | \ \ \ \ \
| Media | \ \|
| Screenshots: |    | \
\
| Movie: | Movie | \ \ \ \ \
| Development Summary | \ \|
| CODE: | Openframeworks gave us the basis for an OpenGL application (which we call Moderator), complete with update and draw functions. Attached to this class we included a class InfraredCamera for computing contact points on the surface. The visual aspects of the game are divided into their two major components: menu controls and game controls. Each of these components has their own class, MenuModel and PlayModel, respectively. Moderator is in charge of delegating which one is in use at any one time. The computer vision image processing was done using Intel's Integrated Performance Primitives (IPP). It is a collection of highly optimized functions for a variety of applications, and one of the major sections of code is devoted to image processing. The student edition is only $50; I highly recommend it. All components of the MenuModel and PlayModel are hand-written. We developed our own physics algorithm for bending the light, as well as detect the existence of game states. On each frame of the program, all of the data processing is done within a series of Update() functions, of which there is one for every class in the system. After all updates are made, all of the visual aspects are drawn within a series of Draw() functions, of which there is also one for every class in the system. | \
\
| CONTENT: | All of our visual aspects were created 'in-house'. A majority of the graphics are computed at real time using OpenGL's basic polygon drawing capabilities. The background images that appear in the Menu as well as the faded-edged white glow and black void are created in Illustrator and Photoshop (semi-respectively), and are manipulated within the graphic system via scaling and alpha channel adjustment. | \ \ \ \ \
| Reflections | \ \|
| Three Greatest Challenges: | Learning computer vision from scratch and building the multi-touch surface were some of the toughest aspects in this project. We read up and researched how to build the surface. Also finding videos on the internet gave us ideas for the design. Implementing IPP did not work at first, but was fixed during the last week of development because of a very small error. | \ \
| Three things that went right: | The multi-touch surface was an overall success. The game play is fun and addicting. And we are very proud of the menu screen and transition to game play. | \ \
| Three things that went wrong: | There are issues with noise in the interface, so recognizing the touch of the player is not very accurate. We had to learn how to incorporate using both OpenFrameworks and IPP at the same time. And reading the camera data is not quite optimized to real-time. | \ \
| Other final thoughts: | We learned a lot about computer vision and IPP, and all the aspects of how to create a game. If we had more time, we would have added more animation and more advanced graphics and sound. | \