Graviators

This is the moment that we have been waiting for; the projects that will ultimately validate our experience in the Master’s program. The game that I have been assigned to is the “falling” game. At least that’s how it was explained to us when we were split into groups and informed what we would be working on.

I believe that our team was starting out a bit behind in the regards of what our game was about. I say this because we weren’t given a game, we were given a mechanic. Falling using the Kinect. To give ourselves a bit more focus we spent the first week coming up with pitches as to what our game should be. I presented a pitch for a game called “High Diver”. The player would go to the top of a platform that would get higher and higher each level and jump from it into a target that would progressively get smaller. On the way down the diver would collect coins and go through burning rings of fire. The target would be anything from a wooden tub to a thimble of green jello.

In the end the choice was between my idea and a gravity Jousting idea where two entities would start on opposite sides of a gravity well and fall towards each other to meet in the middle and have a physical confrontation. During the fall the opponents would throw projectiles at each other that could be blocked or dodged. The team decided on the gravity well game because it sounded more challenging, and if we pulled it off we realized that it would be really cool.

I come up with the management infrastructure for how the players health and other stats would work a along with the players inventory management for his projectile and shield management. I made it so it could be customized to have many items or just one. I also made it so it could be done based on item numbers or energy levels. Just so we would be able to test with different style for play.
Another thing I worked on was the pickup items and how they interact with the underlying management I designed. This is where I came across another obstacle. When the player collided with the items they would be gathered and added to inventory,

unless the player was moving too fast, and our character do indeed move very fast. I talked with Kevin and Pace on the other team on how they got around this and they informed me that this happens when the character is not being moved due to application of Force. In other words, you need to use Unity’s physics system. This was not a possibility for us due to the fact that we needed the opponent and the player to reach the center of the level at the exact same time.

What I ended up doing was a bit different. I created a script for the player that had a list of all collectable items in it. This list would then determine the players distance from each item. When the player is a certain distance from an item it is marked as collected. This wasn’t a very expensive algorithm as there aren’t that many items to collect in the level, so the list isn’t that long. But, this didn’t take care of collisions with other objects.

For main collisions, I decided to go a different route. I made a ray cast from the character that would look for materials that are a certain distance in front of the character. I then made it so that if the material is connected with a certain type of object then the player would react accordingly. In most cases this is bounce away from the object without losing relative position from the opponent so that they will still arrive at the center of the level at the same time.

I also went ahead and made a camera for the opponent so that the player can actually see the person they are battling against. I also fine tuned the primary camera. I think there still is something missing from the interface to help the player have better sense of urgency.

During development I also dabbled in the character controls, the UI and HUD systems, and the level setup. I imported and started the tunnel level that we now have in the game.
During all of this development I would like to give a gold star to Dan. He really set a high bar for us engineers to follow. We spent nights in the lab working on this project. I also want to give a gold star to Sterling for keeping people on task and making sure that the work done was going in the correct direction.

What happened With the Robot Game?

As I hadn't kept up with my blog after the final game was assigned, here are some details of what happened with the robot game, and where we went from there.

For the time manipulation in the game I decided to go with manipulating variables in the objects instead of messing with physics. This gave me more control over what was going on. I controlled these variables through messaging. Basically, this means I place a couple of methods in all objects that would need to be manipulated by time that would set the speed and other variables of the objects accordingly. This way I could only affect one object if I wanted to, or I could affect many. Through the messaging system I then called the method I wanted to use on the objects that had that functionality in them.

As part of the player controls I made the health and object collection scripts along with the attack functions in both the enemies and the player character. I also made collectable items that the enemies dropped when they were killed that would heal the character. This was done because we were planning on having the game battle heavy. With this in mind I also created an AI, for the enemies, which was customizable in aggression towards the player. Basically I made it so you could alter the radius the player had to be from the enemies for detection, how much damage they did, and the time between attacks.

The next task was to get environmental objects in that could be manipulated by time. Early in the planning of the game we had played through a game called Roborally. This game included conveyor belts, spinning disks, and other obstacles located in a factory building. We decided that our game was going to be taking place in a factory and therefore these obstacles would work in our environment. It was thus my job to get those things working.

I created scripts for the conveyors that would move the player when touched. I never got this working completely right. Sometimes they functioned perfectly, but sometimes they would throw the player through the ground. Other times, nothing happened. I think this was because the models used for the objects were full of many moving parts. I did try to encapsulate them into invisible squares to see if that would work better, but it didn’t work. I could have gotten them working if I didn’t have to take care of everything else, but this is life.

After many weeks, I finally got a level design and I started implementing it into the game and laying out the objects where they needed to go. I got the time manipulation working so that animations would slow down and speed up along with the variable functions.