Lately I've worked mainly on creating a tutorial level for the game. As part of this I worked on making a little intro that showed a clear day become dark and stormy. I wanted to have the skybox change for this and after searching the web i found this tutorial. http://www.burgzergarcade.com/tutorials/game-engines/unity3d/074-unity3d-tutorial-day-night-cycle-part-3.
This was great! I got the shader and made two skyboxes using the packages that are included in Unity. I then scripted the texture change, and the tutorial now has a nice conversion from cleat skies to stormy skies. I also wanted some realistic looking clouds to converge on each other. I found several particle effects that could do this. I ended up using the ones that one of our artist found. I implemented these affects and the clouds were added into the level.
A major part of the tutorial is to teach the player how to move.I added in messaging and strict controls so that the player goes through the level collecting drops. Pictures appear to show the player how to move in any given direction. It also instructs that drops make you bigger (they no longer have colors) and that globule will change your color (hence the reason why drops don't do it anymore).
The creation of the tutorial also involved main system bugs, such as a problem we were having with collision, splatting, and the camera. I ended up having two cameras in the tutorial. One for the intro and the gameplay camera. I've also created a first person camera earlier that is there but not really in use since the game change.
I also created a loading level for loading between the levels so that weird images weren't appearing on the screen. For this I also implemented a static method for the loading of the levels. This way we didn't have to write multiple lines of code every time we wanted to go from one scene to another. Instead, we just needed to make one line call to the static method, and that took care of the extra work using the load scene transition.
I also added an ambient raindrop particle effect that shows rain falling all around the player. These aren't collectable, but they sure do help you feel like rain.
One thing that has been plaguing this game has been the menu system. I finally went in and changed the functionality of the selection process so that it would actually detect when you selected things on the menu.
After many other bug fixes we were able to submit our game to IGF. Since then I have worked on fine tuning play, changing color pallets for the game so that they follow the standard that was decided by our art lead. I also added analytics to the game so that we can know what is going on when the game is played. I made it so we can see if the player gets stuck at certain locations and how far they are able to progress through the game. We can also see how long it takes them to finish different controls in the tutorial so we can know if it is too hard to master. I've also worked on getting the frames up on the scenes, because they suddenly spiked down to 7 frames per second. Unacceptable. I removed may models from the level and downgraded the level of detail on the trees to get the framerate back up to an acceptable level.
Monday, December 17, 2012
Sunday, September 30, 2012
Drop Drop
Due to some conflicts within the group and the desire to have a better chance at IGF, the game was once again changed. We have let the zombies die and are now making our game about a raindrop. Yes, we are experiencing the life of a raindrop as it falls through the skies. For this iteration of the game I have redone the controls. I also replaced the zombie character with a raindrop.
As the raindrop falls it collects other drops and grows bigger. I used a lerp between the raindrops current size and the collected drops size to make the growth gradual and dependent on the size of the collected drops. I've also made the other drops different colors. As the drops are absorbed the character changes color as well. This is also done with a lerp, so that the color of the drop is a true mix between its previous color and the collected drop's color.
When the drop falls there are some shader effects involved. I added a fish-eye effect to the camera to give it the sense of looking out of a water drop. I also added a blurring effect, so that it gives the player a better sense of falling.
Later we actually added the skeleton to the drop to mimic the player's movements. I worked with our technical artist to get a good skeleton for the drop, and to determine how to weight the maodel to the skeleton.
For the collectable drops I created spawners that will spawn drops in the level when the player triggers them. This way the drops are in view and they take their speed from the player's speed so that they are not impossible to collect. Their speed varies from slow to fast, but not impossible fast.
When the drop hits the ground it splats. I implemented a script that will make the splats match the raindrop's color. I've added these spawners throughout the level.
As the raindrop falls it collects other drops and grows bigger. I used a lerp between the raindrops current size and the collected drops size to make the growth gradual and dependent on the size of the collected drops. I've also made the other drops different colors. As the drops are absorbed the character changes color as well. This is also done with a lerp, so that the color of the drop is a true mix between its previous color and the collected drop's color.
When the drop falls there are some shader effects involved. I added a fish-eye effect to the camera to give it the sense of looking out of a water drop. I also added a blurring effect, so that it gives the player a better sense of falling.
Later we actually added the skeleton to the drop to mimic the player's movements. I worked with our technical artist to get a good skeleton for the drop, and to determine how to weight the maodel to the skeleton.
For the collectable drops I created spawners that will spawn drops in the level when the player triggers them. This way the drops are in view and they take their speed from the player's speed so that they are not impossible to collect. Their speed varies from slow to fast, but not impossible fast.
When the drop hits the ground it splats. I implemented a script that will make the splats match the raindrop's color. I've added these spawners throughout the level.
Thursday, August 30, 2012
Zombies!!
There were quite a few changes made to the game since we were doing Graviators. In fact, we are doing an entirely new game altogether. This change has come for the better. There are quite a few reasons that Graviators wasn't really working. For one, There wasn't the falling affect that we wanted. The player was moving, but there just wasn't the sense of falling. I think that this was due partly to the fact that the world was too open, and because the player was not falling towards the ground, but towards another player. Another thing, was that we couldn't get the battles to really work well... I guess you'd sya that there was no sense of urgency. It was difficult to determine when the other player had fired at you or not. We also never got the center battles working. There were other reasons, but in the end it was decided that the game just wasn't doing what we wanted it to do. That being, giving the player a sense of falling.
As a result of this, we got together over the summer and began to build this game anew. The new game is. . . Zombie Drop (or something akin to that). In this iteration the player is a zombie that is dropped from the top of a building and guides itself as it plummets to the ground. As part of this we have started over the game completely.
I've been working mainly on the controls. This involved getting the Kinect to work in the game, and to translate the players movements from the Kinect to the character in the game so that it will respond accordingly.
To make the controls work we started with the Zigfu (OpenNI drivers) for the Kinect. With these drivers in place I worked on the steering of the character and the special movements (dive, rotate, drift up, down, left, and right). In the dive I also made it so that the character on the screen actually rotates and moves faster when diving, then goes back to the normal position when the dive is finished.
As part of my task I was keeping a close eye on the Kinect world for drivers. This is because with the drivers we sere using we couldn't release the game commercially if we decided to do so in the future. The other team was using a wrapper to for the Microsoft Kinect Beta SDK, but this is also not available for commercial release. It was, however a step in the right direction. So I downloaded and installed that package following these instructions http://wiki.etc.cmu.edu/unity3d/index.php/Microsoft_Kinect_-_Microsoft_SDK. The only thing I didn't do was install the Bets driver like it told me to. I instead hit the internet to see if there was a way to use this wrapper with the Microsoft Kinect release SDK. I came across this page https://channel9.msdn.com/coding4fun/kinect/Unity-and-the-Kinect-SDK, which told me to go to the other page that i had already done.
this was a bit frustrating, but after reading through many comments I was eventually directed to this page http://www.rozengain.com/blog/2012/05/10/microsoft-kinect-sdk-wrapper-for-unity-crash-bug-fix/. This was the answer I was looking for. Imade the changes in the wrapper and was able to get the release SDK working in Unity!
After that was working I had to convert all of our controls from the OpenNI configuration to the Microsoft SDK. This involved restructuring the skeletons for the characters (remapping mostly) and changing all of the controls I had previously implemented. But now, the controls are working for the Kinect SDK.
As a result of this, we got together over the summer and began to build this game anew. The new game is. . . Zombie Drop (or something akin to that). In this iteration the player is a zombie that is dropped from the top of a building and guides itself as it plummets to the ground. As part of this we have started over the game completely.
I've been working mainly on the controls. This involved getting the Kinect to work in the game, and to translate the players movements from the Kinect to the character in the game so that it will respond accordingly.
To make the controls work we started with the Zigfu (OpenNI drivers) for the Kinect. With these drivers in place I worked on the steering of the character and the special movements (dive, rotate, drift up, down, left, and right). In the dive I also made it so that the character on the screen actually rotates and moves faster when diving, then goes back to the normal position when the dive is finished.
As part of my task I was keeping a close eye on the Kinect world for drivers. This is because with the drivers we sere using we couldn't release the game commercially if we decided to do so in the future. The other team was using a wrapper to for the Microsoft Kinect Beta SDK, but this is also not available for commercial release. It was, however a step in the right direction. So I downloaded and installed that package following these instructions http://wiki.etc.cmu.edu/unity3d/index.php/Microsoft_Kinect_-_Microsoft_SDK. The only thing I didn't do was install the Bets driver like it told me to. I instead hit the internet to see if there was a way to use this wrapper with the Microsoft Kinect release SDK. I came across this page https://channel9.msdn.com/coding4fun/kinect/Unity-and-the-Kinect-SDK, which told me to go to the other page that i had already done.
this was a bit frustrating, but after reading through many comments I was eventually directed to this page http://www.rozengain.com/blog/2012/05/10/microsoft-kinect-sdk-wrapper-for-unity-crash-bug-fix/. This was the answer I was looking for. Imade the changes in the wrapper and was able to get the release SDK working in Unity!
After that was working I had to convert all of our controls from the OpenNI configuration to the Microsoft SDK. This involved restructuring the skeletons for the characters (remapping mostly) and changing all of the controls I had previously implemented. But now, the controls are working for the Kinect SDK.
Thursday, May 17, 2012
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.
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.
Monday, May 14, 2012
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.
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.
Friday, January 27, 2012
And So it Begins
We started this week off with a bit of research. On Monday we played Roborally to get some ideas of our game and its world. It was a fun game where you are racing with other robots in order to get to a "goal". The environment you are working through has obstacles such as spinning tiles, conveyor belts, and holes. It was a fun game and gave us some ideas on how we can make our environment be a bit more interactive. This will be well with some of the other changes we are making with the game.
We are taking out the puzzles (at least for now) and focusing mainly on the combat against other robots. Our protagonist will be fighting in a factory that has conveyor belts, pits, etc. against the other robots. This will make it so that the player will need to pay closer attention to his surroundings. This will also do some interesting thing with the time mechanic.
For this week, I've got a box that is taking the player's commands and responding appropriately. As a placeholder for the enemy bots I have a sphere. The sphere has a simple "AI" where it wanders around until it gets within a certain distance of the player at which point it closes in for an attack. The player can also attack the enemy. Damage is taken and one or the other will successfully die. I also have it so that the enemy will drop and item which the player will pick up. I also have it so that the player can slowdown and speedup time. The way we depict this is by having the player always moving the same while everything else will go slower or faster. I ended on just adjusting velocities of the other items in order to get the speed changes to work.
So far I have written seven scripts. The enemy controller, enemy status, player controller, player attack control, player status, item script for picking up, and the camera control that follows the player so that he remains in view. This amounts to about 700 lines of code (many more if you count the lines that have been cleaned out from failed attempts).
Next I'm going to work on getting the level in place. This will involve scripts for conveyor belts, pits, turning areas, and crushers for now. If I get a design I can build the level, otherwise I will just work on the functionality so that it can be put in.
We are taking out the puzzles (at least for now) and focusing mainly on the combat against other robots. Our protagonist will be fighting in a factory that has conveyor belts, pits, etc. against the other robots. This will make it so that the player will need to pay closer attention to his surroundings. This will also do some interesting thing with the time mechanic.
For this week, I've got a box that is taking the player's commands and responding appropriately. As a placeholder for the enemy bots I have a sphere. The sphere has a simple "AI" where it wanders around until it gets within a certain distance of the player at which point it closes in for an attack. The player can also attack the enemy. Damage is taken and one or the other will successfully die. I also have it so that the enemy will drop and item which the player will pick up. I also have it so that the player can slowdown and speedup time. The way we depict this is by having the player always moving the same while everything else will go slower or faster. I ended on just adjusting velocities of the other items in order to get the speed changes to work.
So far I have written seven scripts. The enemy controller, enemy status, player controller, player attack control, player status, item script for picking up, and the camera control that follows the player so that he remains in view. This amounts to about 700 lines of code (many more if you count the lines that have been cleaned out from failed attempts).
Next I'm going to work on getting the level in place. This will involve scripts for conveyor belts, pits, turning areas, and crushers for now. If I get a design I can build the level, otherwise I will just work on the functionality so that it can be put in.
Friday, January 20, 2012
Group and Game Assignments
My game was not chosen as one of the lucky seven to be created in class. Downer. In other news I'm playing musical chairs as far as groups go. First I was assigned to a group with one other programmer, an artist, and a producer. Then one of my instructors asked if I would switch to a group with only one programmer because that programmer didn't think they could keep up by themselves. That is, trade places with that programmer.
Before I continue, let describe some of my view points about this class. These projects and assignments are to prepare us to design games professionally. It is practice for a job, and therefore I treat it as if it were a job. That means, if the boss wants me to do something, I do it. I told my instructors that I would be willing to make the switch if that is what they wanted, and it happened. So now I am in a group with a producer, two artist, and myself (the sole programmer). Let's hope I didn't bite off more than I can chew. :)
That said, our game is about battle and time manipulation, with puzzles. The player is a robot in a factory that is battling other robots in order to turn off the malfunctioning Main-Frame computer. The robot also has time capabilities that allow it to speedup and slowdown time. This manipulation takes up some energy. Puzzles will be set up in certain places that will need different speeds of time in order to solve. The robot can also change the time of certain other Bots for a certain amount of... well, time.
The scope of the game seems to be a bit big and I'm sure we will cut it down a bit, but this is where we are starting. My first task is to figure out all that I need to get done and then make myself a schedule. I'm also going to see different ways I can do the time manipulation in Unity.
Before I continue, let describe some of my view points about this class. These projects and assignments are to prepare us to design games professionally. It is practice for a job, and therefore I treat it as if it were a job. That means, if the boss wants me to do something, I do it. I told my instructors that I would be willing to make the switch if that is what they wanted, and it happened. So now I am in a group with a producer, two artist, and myself (the sole programmer). Let's hope I didn't bite off more than I can chew. :)
That said, our game is about battle and time manipulation, with puzzles. The player is a robot in a factory that is battling other robots in order to turn off the malfunctioning Main-Frame computer. The robot also has time capabilities that allow it to speedup and slowdown time. This manipulation takes up some energy. Puzzles will be set up in certain places that will need different speeds of time in order to solve. The robot can also change the time of certain other Bots for a certain amount of... well, time.
The scope of the game seems to be a bit big and I'm sure we will cut it down a bit, but this is where we are starting. My first task is to figure out all that I need to get done and then make myself a schedule. I'm also going to see different ways I can do the time manipulation in Unity.
Tuesday, January 10, 2012
The New Semester Starts
The beginning of a new semester with new projects. Our first week back we are setting up appointment to pitch a game we would like to create in class. I've got a game and I've got an appointment. Let's hope the pitch goes well.
Subscribe to:
Comments (Atom)