Laval Virtual - Demo

Another one of the requirements of the capstone project at Polytechnique Montreal was that my team and I prepare a large scale virtual reality application to present during the Laval Virtual - Demos student competition. We implemented a novel pétanque simulator that would let the user throw the ball into the screen and make it continue seamlessly into the virtual world, without bouncing off the screen like regular golf simulators. We also added face tracking to modify the perspective of the user, and add real world crowd faces to the crowd in the game, therefore integrating them in the experience of the player.

We received an honorable mention for programming quality from the IVRC Tokyo (International collegiate Virtual Reality Contest). They were amazed by the overall quality and polish of our simulation, especially considering the project was done in two months’ time. I'm really happy with the result and the quality of our product. It truly is seamless, if there was something to adjust it would be the jitter in the screen after a ball is thrown as it takes something away from the experience.

To play, the user only has to place himself in front of the screen. The game detects his face, and applies it to his avatar in the upper left corner of the screen. Thanks to our calibration we can adjust the perspective off-center projection to the actual position of the users face. Furthermore, our world was built to 1:1 scale in order to effectively simulate the games physical conditions. The center camera also detects faces in the crowd which our distinct from the current players face. The game then, during play, plasters those faces onto the ragdolls sitting in the background. We also made the spectators look at the players throws to make them more dynamic. The goal of the crowd was to try and include the spectators in the simulation, to give them a sense of participating, even if they were only watching someone play. I think it worked pretty well as the crowd was often quite surprised to find their faces in the game.

To track the ball we used two high speed PlayStation eye cameras running at 185 fps, stereo calibrated using the opencv framework. I had never used OpenCV before and had a lot of fun playing around with it. I even had my own branch of OpenCV to fix a couple bugs that were holding me up during development.

All in all, after the competition we got onto the showroom floor, and seeing the crowd line up to play our game was amazing. We might not have won the grand prize, but we definitely won the crowds love, and that made the hard work and dedication it took to create this awesome product worth it. (The winner's kiosk was empty the entire weekend ;) )

Laval Virtual - Limited Time 30h Competition Winner

In the context of my capstone project at Polytechnique Montreal, I participated in the Laval Virtual - Limited Time 30h competition in Laval, France with 3 other students. As the name implies, we developed an application in a non stop 30h window using the Leap Motion and the Tobii REX Eye Tracker. Furthermore, we had to integrate a mystery object in our project to qualify. Our team's object was a shoehorn if you can believe it :).

We were one of two teams who used both technologies in our application out of the 14. 

The story of our game was of an individual who, late for work, has to jump out of the shower and walk on his shoes to avoid slipping on the tile floor with his wet feet to get out the door and to work before his alarm clock goes off. (Lets forgo the fact that he doesn't get dressed between the moment he steps out of the shower and leaves for work.)

Judges during the demo evaluation.

The eye tracker was used to let the player move from left to right in the scene by looking to the left or the right. The Leap Motion was used to control the shoehorns and select the next shoe. If the player misses a shoe and hits the tile floor he falls and if he doesn't select a shoe before the shadows under the shoehorns disappear he also falls. If he reaches the end of the corridor before the alarm is elapsed he wins, or else he loses. Exhausting as this event was, I had a great deal of fun playing with the eye tracking. The feeling of actually having control over something with your eyes, an organ which previously had no actual consequences in the real world when moved around, was really special.

Closing ceremony

Rocketman - Best Game Of 2012

One of the funnest courses at École Polytechnique is definitely INF4715. Our goal for the semester was to design and implement our very own game based on a very open specification document. Also, this project was done in collaboration with the music departement of the University of Montreal.

Being with 3 other people who weren't very experienced in game development and had a much heavier course load than myself was quite the challenge. But all in all, I think I was able to lead my team well. We all learnt a lot in the process and ended up winning the grand prize. During said course, we had to implement a 2.5D Platformer (a 3D game that is played on a single plane). At first I was a little bummed out by the topic, but soon realized that with the amount of freedom we had, I could go ahead and give myself interesting challenges. Another constraint was that we had to use a specific, in-house engine (Vicuna) which had bugs and was far from being feature complete. This requirement was to replicate situations found in the industry where one can't necessarily choose or be familiar with the tools available. Due to my prior experience in much larger engines (at Ubisoft), getting familiar with this one wasn't much of a problem. During the first day of class, the teacher gave an example of technical achievements one could try and implement to distinguish our game from the others (as this was a competition). One of these was skinning, which he also said a lot of teams in the past had tried to implement, but none had succeeded. Challenge Accepted! After the first week I had a functional prototype with hardware skinning :) . During said project I implemented the following technical feats:

• Volumetric Cloud Rendering
• Hardware Skinning
• Data-driven entity-component System with Reflection (used for instantiation)
• Rebuilt the shader pipeline to support data-driven shaders and hot reloading
• C++0x event system with lambda functions
• Black-hole deformation shader
• Parallax space background with infinite blinking stars (using simplex noise)
• FMOD event-system integration
• PhysX 3.1 Integration
• updated Awesomium integration

As you can see, I'm quite passionate about systems engineering. I think I actually appreciated working on the engine more than on the game itself. It was a lot of fun having so much freedom.

Rocketman - Volumetric Clouds

Rocketman needed to have cool clouds. We were going to be on the edge of planets the whole time, there had to be a little bit of atmosphere around them! After quite a bit of searching, I felt as though the most bang for my buck was going to come from volumetric rendering. The ability to go into said clouds and see that they were actually variable density volumes and not just splatted textures was something I just couldn't get out of my head.

I started off by integrating a simplex noise algorithm in the given engine and using it to generate a VolumeTexture filled with said noise. After playing around with it in a small XNA Renderer I implemented just for toying around with the shader I was amazed by what noise could do! No wonder Ken Perlin got an academy award.

The cloud renderer worked as follows:

1. Render the back faces of a simple cube mapped with uvw texcoords into a rendertarget

1. Render the front faces of the same cube into another rendertarget

1. Use those rendertargets in the next pass to cast rays from the front of the cube to the back specifying the iteration count with which to sample your cube texture and calculate the total density the ray traverses on said pixel.

I found a wonderful description of the previous steps on: Volume Rendering 101

Now for clouds that project shadows it's a little different.

To accomplish my cloud rendering I started by splitting the rendered cube into two halves to then be able to render my planets and characters inside of them. Also as the camera can enter the volume (which would cull the front faces of the cube and destroy our ray), I had to dynamically update the cube halves and texcoords so they would always stay in front of the camera clip plane, while never changing the look of the clouds.

Then using simplex noise harmonics, some simple transforms in time and space to make the clouds evolve and the equation of a sphere, I had some pretty cool clouds!

Also, since the engine already had shadow mapping implemented, I wanted my clouds to project shadows at a very low cost (since they were already quite expensive to render). I decided to do what any self respecting game developer would do! Cheat!

By projecting the noise found in the densest part of my clouds on my cube during the shadow pass I was able to approximate the shadows that my clouds would generate without actually calculating the density of said clouds. My technique was pretty raw, but it was dirt cheap, and gave great results.

We also used the clouds to add fog to our planet of death.

NextgenRacer 2, the revival - Intro

The objective of our third year term project was to add networking and integrate a mobile platform. The basic goals were to be able to race with your friends on LAN, have an administrative and chat interface on an iPAQ, and port the interface from Java and JNI to C# and P/Invoke (or C++ CLI).

We as a team decided to turn it up a notch with the following features:

• a web client with real time player progress in races
• full online play
• data-driven entity component architecture
• revamped rendering with Ogre3D (shadows, real time reflections, bump mapping, custom car colors, skid marks)
• revamped physics with Bullet Physics
• Python integration for scripting entities
• Persistent player statistics.
• Online gambling system in the web ui
• 3D WPF ui blended with Native Rendering. (Using D3DImage)
• and a couple more.

In the following posts I will describe most of these features in detail, but for now I will leave you with a set of cool screen shots :).

Global Game Jam 2011

48 hours have past, very little sleep has been gained, but I have a game to show for it. This was the first time I participated in the Global Game Jam, and I have to say it was quite thrilling.

One of my buddies came up with our games idea; it’s sort of like the impossible game but with extinction as its theme (imposed by the game jam). The name of our game is Dodgecube. Its primary goal is to survive an onslaught of growing walls and dangerous red cubes whilst mating with your fellow cubes to bring your buddies into your game and survive as a team. Our game could be played by up to 6 players, two on the keyboard and 4 Xbox 360 controllers where each player controls two independent cubes simultaneously (which is quite a challenge in its own right).

During the 48 hours, I implemented the main architecture of our game, simple collision detection and resolution, rendering, growing trees, bullet time and a couple other things I can`t really remember due mostly to my eyes glazing over from fatigue.

The collision resolution system was the first time I had the chance to try out something I read from the book Scott Meyers’ Effective C++. The problem was exactly like one stated in the book. To know who is colliding with who can easily be found out using a double dispatch mechanism (the visitor pattern), but where does that code go? Now in his book, out of many solutions he mentioned the visitor pattern to figure out the types, but then when he asked this exact question he used an emulated virtual function table which would find the proper non-member function with respect to the names in the type_info of the objects that collided. Considering, I already had all the information I needed in the double dispatch and that I had access to the code of the classes in question, I found it wiser to simply call my non-member functions (it was in C# so a singletons member functions), which would apply the proper collision handling with respect to both my objects types. By the way, if you haven’t read this book, I would highly recommend it. It was an interesting read through and through, and I think it taught me a lot.

The Game Jam was quite a fun experience as I got the chance to work and manage a team of people that I never had the chance to work with in the past. I instated an agile workflow where we would have stand ups every so often and created a task board to keep track of each other’s tasks. I also spent a lot of time briefing my team mates on the architecture and the threaded screen management and UI library I implemented with Jean-Rémi (the UI lib was a personal project we brought along with us to add some extra polish for very little effort).

All in all it was a lot of fun, I learnt a lot about team building and team management, and got to meet some really cool people.

GGJ11 - Dodge Cube

NextGenRacer - Friction

Another cool feature was the friction map I implemented. The requirement was that the cars wheels would have to behave differently on oil, grass and the road, independently.

Every other team decided to go the bounding radius way, which bogged down their programs considerably. Since we had a continuous customizable track rather than a given track comprised of sections (a requirement we decided to boost also), we couldn’t use bounding radiuses, also bounding radiuses weren’t ideal considering the oil slicks sphere would be in a tracks bounding sphere.
I designed a system very similar to a height map in the sense that for a given resolution, we would have the friction values for every point in the world (using interpolation). Now to build this map, I would render the custom track and the oil slicks separately in the stencil buffer with given values, and then save that buffer into a 2D array with given min and max world coordinates in order to map table indices to world coordinate. This would let us query our friction data in O(1) time, let us create wacky and wonderful tracks at runtime in our editor, and have very high resolution friction data.

The image that follows with the green and red dots all over the map show the data in a very low resolution way for debug purposes.

NextGenRacer - Physics

One of the requirements at about halfway through the project was to have implemented our games physics. Now after doing that, we were sort of bummed of the results. First off, well it was 2D physics in a 3D game se we would have barrels, but they would just slide around which was less than ideal.

After a short discussion with my team mates, I decided to branch our project and set out on a journey to integrate a physics engine. I did some research and considering the short timespan I had to get things up and running, I quickly forgot about the full featured engines like PhysX and Newton and grabbed a simple engine called Tokamak. The api was really simple and since our architecture was component based meaning that every game entity could have components that could act upon it, much like the unity engine, it was really simple to integrate. I had some problems at first with the lack of documentation, but after some trial and error we could add stacks of tires and ram them!

Tokamak Physics

NextGenRacer - Particles

One of the first extras I added to our game was implementing a particle engine to add a little razzle-dazzle. What I found most surprising was the effort to results ratio of adding particles to a game. I mean, a particle engine is quite simple; you update particles with positions, speeds, and orientations and then you billboard them all over your scene towards the camera with some alpha blending. It seems as though that was the most talked about feature of our game, and yet I really didn’t feel as though this was the coolest feature we added. Especially considering the next feature, which I spent so much time on!

NextGenRacer - Rendering

What I am most proud of is the OpenGL rendering engine I implemented for our game. I implemented a per pixel Blinn-Phong GLSL Shader for the lighting that could calculate the effect of up to 8 lights (Point, Directional and Spot) per Game Object, which meant I could pretty much have as many lights as I wanted in my scene. Not having written any GLSL Shaders before, and being it was 4th year notions, I’m really happy with the fact that I implemented it in the last week before the final deadline and that it worked. The rendering pipeline also supported transparency, billboards, animated textures and a skybox with moving clouds.