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.
Thursday, December 15, 2011
Impulse Post-Mortem
We presented Impulse to the makers of the Haptic controller yesterday, and it went pretty well. I was a little bummed that I wasn't able to get all of the puzzles in that I wanted, like boxes that you had to push around, and little robots that moved around the level that you had to avoid. Regardless of the lack of these objects, the main feature was there. The consoles and the doors.
This group started off pretty well, and I think that had something to do with the fact that three of us had worked together before in previous projects. I worked with George in prototype 1 and Ashley in prototype 2. Ashley and George worked together in prototype 3. We already had a feel for how we each worked. We had our regular stand up meetings whenever we got together and a sit down meeting at least once a week at see our progress thus far and discuss obstacles if needed. It always helps out when we know what we need from each other and Josh provided a way for us to do so. Another thing that helped was having some filler art from the start that was in the same dimensions as the "final" art would be. With that in hand George and I were able to make the levels and test out the motion and flow of the player. George and I got together and discussed what the game flow would be, and how we could break up the assignments so that we weren't stepping on each others feet too much. This helped a bit at the beginning so that we could get the program moving.
As far as set backs go, there were a few that mostly involved testing the code with the actual Game Controller instead of with our xbox controllers. Some of this was due to the fact that we only had one controller in the lab and we had to wait for it to be available in order to test it out. It's also very apparent that it is a new technology. We also had to compensate for a lot of "noise" that the controller had. For example if you pushed up, left, down, or right, the value of the thumbstick would still fluctuate anywhere from .7 to 2.0. Once one accounted for this variance the program would act appropriately.
I consider this project a success and I am very grateful for my team. We did well.
This group started off pretty well, and I think that had something to do with the fact that three of us had worked together before in previous projects. I worked with George in prototype 1 and Ashley in prototype 2. Ashley and George worked together in prototype 3. We already had a feel for how we each worked. We had our regular stand up meetings whenever we got together and a sit down meeting at least once a week at see our progress thus far and discuss obstacles if needed. It always helps out when we know what we need from each other and Josh provided a way for us to do so. Another thing that helped was having some filler art from the start that was in the same dimensions as the "final" art would be. With that in hand George and I were able to make the levels and test out the motion and flow of the player. George and I got together and discussed what the game flow would be, and how we could break up the assignments so that we weren't stepping on each others feet too much. This helped a bit at the beginning so that we could get the program moving.
As far as set backs go, there were a few that mostly involved testing the code with the actual Game Controller instead of with our xbox controllers. Some of this was due to the fact that we only had one controller in the lab and we had to wait for it to be available in order to test it out. It's also very apparent that it is a new technology. We also had to compensate for a lot of "noise" that the controller had. For example if you pushed up, left, down, or right, the value of the thumbstick would still fluctuate anywhere from .7 to 2.0. Once one accounted for this variance the program would act appropriately.
I consider this project a success and I am very grateful for my team. We did well.
Tuesday, November 29, 2011
Tuesday, November 22, 2011
The Next Big Thing
Our new groups have been decided and we have been presented with what we need to do for our next Prototype. Essentially we are going to be making a game using a new type of controller that has Haptic feedback called "flesh stretching technology" or "tactors". There are little nubs on the joy sticks of the controller that move under the thumbs, giving the players a new output from games. We are to utilize this technology. One thing different in this prototype is that there will be a specific person in the group that will be the official game designer. The choice of designer was made by each person pitching a game that would use the "tactors". After each person in our group made a pitch it we decided to use my pitch.
The game we will be making is a puzzle game. A person is trying to breakout of a facility by bypassing several locked doors. The doors can only be opened when the player "inputs" the correct code using the thumbsticks of the controller. The code is found in consoles throughout the level and given to the player through the tactors. So if the player feels the "tactor" under their left thumb go right then up, the code for the door is right then up using the left thumbstick. As the player progresses through the game the codes become more complex and even broken up into different parts in separate consoles. The consoles are color coded and the door has a pattern of colors depicting the order in which the codes need to be displayed.
I'm really excited to work with this group of people. I've worked with our Artist Ashley previously on the Repelzul project and the other Engineer George on the Germinators project. The only person we haven't worked with before is Josh the Producer.
The game we will be making is a puzzle game. A person is trying to breakout of a facility by bypassing several locked doors. The doors can only be opened when the player "inputs" the correct code using the thumbsticks of the controller. The code is found in consoles throughout the level and given to the player through the tactors. So if the player feels the "tactor" under their left thumb go right then up, the code for the door is right then up using the left thumbstick. As the player progresses through the game the codes become more complex and even broken up into different parts in separate consoles. The consoles are color coded and the door has a pattern of colors depicting the order in which the codes need to be displayed.
I'm really excited to work with this group of people. I've worked with our Artist Ashley previously on the Repelzul project and the other Engineer George on the Germinators project. The only person we haven't worked with before is Josh the Producer.
Friday, November 18, 2011
Prototype 3 Post-Mortem
Before I get into the actual Post-Mortem I'll describe a bit more about the work that was done on the project itself. We were scheduled to present the project to our "clients" on Tuesday at 1:00PM. This later changed to be Wednesday, Much to our relief. Before the presentation Felix was able to get music added and I mae a countdown for the game. I also added Sparkles to the main menu so that it wouldn't be so static and lifeless. When we finally presented the game the "client" seemed to be fairly pleased as they realized that we had a pretty difficult IP to work with and they were wondering how we would be able to turn it into a game.
Now for the Post-Mortem
When the group was first put together and we were told that we were going to be making an app on Unity I was very excited. This excitment was stunted a bit when we were given our IP. It was for an audience that we didn't really relate to in any way. The agony in turning the idea into a game was very long, and we went through days of not knowing where we were going. We knew that there were some thing that would be needed regardless of the game and worked on those in the meantime. Felix, and I worked on making the menus, configuring the objects for texture changing, and getting familiar with Unity. Michelle started to make art assets of for the character and the environment. Charlie shot us with his NERF gun. There came a point where we had to know what the game would be before we could go further. We got the "Simon Says " idea and went with it. After that had been decided the game came together pretty smoothly. I had to take the reigns and Lead the design in the end in order to get things really progressing.
If we were to do this over again, I would definitely take the reigns earlier. We were stumbling a bit there. I think that we did extremely well with the obstacles that we had and the game turned out good. I am actually proud of it and I think it's kinda fun.
Now for the Post-Mortem
When the group was first put together and we were told that we were going to be making an app on Unity I was very excited. This excitment was stunted a bit when we were given our IP. It was for an audience that we didn't really relate to in any way. The agony in turning the idea into a game was very long, and we went through days of not knowing where we were going. We knew that there were some thing that would be needed regardless of the game and worked on those in the meantime. Felix, and I worked on making the menus, configuring the objects for texture changing, and getting familiar with Unity. Michelle started to make art assets of for the character and the environment. Charlie shot us with his NERF gun. There came a point where we had to know what the game would be before we could go further. We got the "Simon Says " idea and went with it. After that had been decided the game came together pretty smoothly. I had to take the reigns and Lead the design in the end in order to get things really progressing.
If we were to do this over again, I would definitely take the reigns earlier. We were stumbling a bit there. I think that we did extremely well with the obstacles that we had and the game turned out good. I am actually proud of it and I think it's kinda fun.
Thursday, November 10, 2011
The Working Model
We needed to have a working system to show to our EP's this week. This was a bit of a challenge because we had changed the game so many times. From the beginning Felix had been working on the side bar (where clothes are selected) of the game and I had been working on the actual visuals (menus, models and texture changing, randomization of the outfits, etc..).
In preparation both Felix and I got our specific parts of the engineering done, and then we worked a bit on combining them. We both had a working version of the game that we then integrated together. The outcome turned out pretty good. We just need to add music, and some things to make it "sparkle".
In preparation both Felix and I got our specific parts of the engineering done, and then we worked a bit on combining them. We both had a working version of the game that we then integrated together. The outcome turned out pretty good. We just need to add music, and some things to make it "sparkle".
Friday, November 4, 2011
The Dynamic Game
So, this week after further discussion with our group and the Executive Producers it has been determined that we will have only one mini-game. At first we were trying to add a "I Spy" type game to the closet so that the player would need to find articles of clothing in order to have it available for the dress up portion of the game. That idea fell through. It is proving difficult to put the game in this toy.
We came up with the idea of having a roulette spin and show an outfit for a few seconds that the player would need to memorize and then match. The time would for matching and seeing the goal outfit would decrease after every level making it harder to complete the task. After talking with our EP's yet again we have changed this to be a "Simon Says" type dress up game.
It sounds good. We'll see how it goes.
We came up with the idea of having a roulette spin and show an outfit for a few seconds that the player would need to memorize and then match. The time would for matching and seeing the goal outfit would decrease after every level making it harder to complete the task. After talking with our EP's yet again we have changed this to be a "Simon Says" type dress up game.
It sounds good. We'll see how it goes.
Friday, October 28, 2011
Dress up Madness
So our new groups for our next prototype have been made, and our prototype has been selected. This time we are going to be developing a game for Siena Entertainment. They mostly specialize in ebooks (try them out, they're pretty entertaining) in the Apple app store and they want to branch out into gaming. WE are to use one their IP (Intellectual Properties) to develop a game. There are four groups working on this and they have four IP's. This where we hit our first glitch. There was one IP that was targeted for toddlers ( 1 - 5), one for preteen girls (8 - 10), and the other two were pretty open in there age demographic. We ended up being assigned the preteen girl game. Our other constraint is that we need to use Unity to develop the game.
So what we have decided is that we are going to be developing a dress up game using the IP we are working on. There are some other elements we are working into the game, but it is mainly dress up. We'll get more into the other parts later.
The main obstacles I see in this game are that the two programmers involved both have full-time jobs (this wasn't too bad for me before because I was very familiar with Power Game Factory and XNA, which brings us to the next part of that obstacle) and they neither of them have ever used Unity before. The other main obstacle I see being a problem is moral. Some people on the team aren't very excited about the project and it kind of affects the rest of the group. I think this will go away as we get more element worked into the project... minigames!
Yes we are trying to fit in some minigames. Charlie our producer and I sat with one of our Executive Producers and 'brainstormed' some ideas on what we can do to make this app less of a toy and more of a game. Hopefully this will excite the team a bit more.
As for the programmer obstacle, Felix and I are both looking at Unity and implementing things that we know we will be using in the project. That is menus, UI, and tap and move. I've also been making a list of what needs to be done by the Engineers (programmers) and how to divide that work up between us most efficiently. That will be fleshed out by our next meeting.
Our Artist (Michelle) in the meantime is starting to create assets for us.
Well keep your fingers crossed for us.
So what we have decided is that we are going to be developing a dress up game using the IP we are working on. There are some other elements we are working into the game, but it is mainly dress up. We'll get more into the other parts later.
The main obstacles I see in this game are that the two programmers involved both have full-time jobs (this wasn't too bad for me before because I was very familiar with Power Game Factory and XNA, which brings us to the next part of that obstacle) and they neither of them have ever used Unity before. The other main obstacle I see being a problem is moral. Some people on the team aren't very excited about the project and it kind of affects the rest of the group. I think this will go away as we get more element worked into the project... minigames!
Yes we are trying to fit in some minigames. Charlie our producer and I sat with one of our Executive Producers and 'brainstormed' some ideas on what we can do to make this app less of a toy and more of a game. Hopefully this will excite the team a bit more.
As for the programmer obstacle, Felix and I are both looking at Unity and implementing things that we know we will be using in the project. That is menus, UI, and tap and move. I've also been making a list of what needs to be done by the Engineers (programmers) and how to divide that work up between us most efficiently. That will be fleshed out by our next meeting.
Our Artist (Michelle) in the meantime is starting to create assets for us.
Well keep your fingers crossed for us.
Friday, October 21, 2011
Post-Mortem
Well, the XNA prototype for Mechanical Engineering has finally been "completed" and presented. I am very pleased with the outcome of our game. I'm especially pleased that we were able to get all our main features in (minus the money collection). I think that the success of this build was rooted in our team work and willingness to work over Fall Break.
When we first got together we effectively planned what the roles of each team member would be along with what each member expected from the others in the group. I believe that this openness and frankness allowed the group to function as a cohesive unit, thus allowing us to get the project together. I feel that Troy did an excellent job on getting us to do this early on. I was very pleased that we were able to get art assets from Ashley early on in the production. This helped the engineer's immensely. From my past experience with XNA I can't help but cringe at the stress and and effort it took to get art assets from our team that we could use in game. Having it early on allowed us to work out those bugs early on and boosted the moral by making the game feel as if it was actually progressing. I mean no matter how much code we had, if we can't show it off with a graphic it just doesn't come across as being done. As far as Engineering the game, it was great that both Kameron and I were familiar with XNA. We were able to quickly hash out what we needed to program and divide the work so that we wouldn't need to depend on the other person's code early in the development. For example, Kameron worked on the level setup and game objects the first week, so I worked on mouse control and the menu, credit, and other screens because they didn't rely on each other. As we got further into the process where single files were in need of editing, we were able to sit together and team program our last minute essentials when
Cheers to our team Repel. I am pleased with the results and I can only hope that the rest the projects in this class go as well.
When we first got together we effectively planned what the roles of each team member would be along with what each member expected from the others in the group. I believe that this openness and frankness allowed the group to function as a cohesive unit, thus allowing us to get the project together. I feel that Troy did an excellent job on getting us to do this early on. I was very pleased that we were able to get art assets from Ashley early on in the production. This helped the engineer's immensely. From my past experience with XNA I can't help but cringe at the stress and and effort it took to get art assets from our team that we could use in game. Having it early on allowed us to work out those bugs early on and boosted the moral by making the game feel as if it was actually progressing. I mean no matter how much code we had, if we can't show it off with a graphic it just doesn't come across as being done. As far as Engineering the game, it was great that both Kameron and I were familiar with XNA. We were able to quickly hash out what we needed to program and divide the work so that we wouldn't need to depend on the other person's code early in the development. For example, Kameron worked on the level setup and game objects the first week, so I worked on mouse control and the menu, credit, and other screens because they didn't rely on each other. As we got further into the process where single files were in need of editing, we were able to sit together and team program our last minute essentials when
Cheers to our team Repel. I am pleased with the results and I can only hope that the rest the projects in this class go as well.
The Final Crunch and Presentation
When we met again on the Monday after fall break we received more fantastic art from our Artist Ashley. We now had the assets needed to create our Market Place. In the game after the Prince is launched you are taken to the Market place in order to purchase upgrades for your catapult and other items. We only have the catapult upgrades in our market at the moment. There are three. You can purchase an upgrade that allows you to customize the Force at which the Prince is released, on to adjust the Angle at which the catapult releases the Prince, and an object to adjust the Length of the catapult arm. Kameron and I did a team programming session and got this added into the game just in time for us to show our Executive Producers our game so far.
Three of our Four EP were able to give us feed back as to what we should do before our final presentation of this prototype. On the Art side we were told to make the lines of our objects bolder. The details of the objects just weren't shining through. It was also recommended that we make the objects bigger. It was also recommended that we reposition the objects in our game so that they didn't distract from what our main focal point was supposed to be.
For Engineering we were told to have the catapult arm move with the Prince and to make the Obstacles in the air actually move instead of remaining static. We also told that adding in an achievement system would be cool and we could use a help button to show the physics equation so that the player would know how to adjust the separate components of the catapult.
We took these suggestions to heart and tried to implement as many of them before Wednesday. While Ashley went to work on fixing the art I talked with Kameron on what files would need to be edited in order to make the objects move and then I made the adjustment so that all of the objects moved either up and down, or left and right. I then took the new art from Ashley and placed them into the game. By this time we needed to finish for the day.
Before Wednesday came I was able to add the catapult arm to the game. Initially we were thinking of having the catapult movement be based on a sprite sheet, but as we thought about making it adjust both angle and length we realized that we would need to take one image and manipulate it with code so that it would act correctly. I took the image that we had for the catapult arm and implemented the movement and growth into the game. It was very satisfying to see the arm move, lengthen, and shorten in correlation with the Prince as the different values were adjusted on the scrollbars. It definitely gave the game a nicer polish. I even made it so that after you chose the angle at which the arm would release the Prince and pressed the launch button, the arm would then go back and then launch the Prince. Before the Prince would just take off from the release angle. The speed of the catapult launch even reflects the Force at which the Prince is released. If it's a low Force the arm move slowly, the higher the Force the faster the arm movement.
After this I added an achievement system. At this point I didn't have much time, so I was only able to make three achievements. They correspond to hitting the obstacles in front of the Princess' tower. If you hit the Pegasus you get "Pegasus Rider" the Bear gives you "Bear Trainer" and the Dragon "Dragon Flayer".
Title Screen:
Main Menu:
Game Screen when launched:
Market Place:
Preparing to Launch again (Notice achievement in top right corner):
Win Screen:
Credits Screen:
The presentation went well on the game and we all came away feeling pretty good about it.
Three of our Four EP were able to give us feed back as to what we should do before our final presentation of this prototype. On the Art side we were told to make the lines of our objects bolder. The details of the objects just weren't shining through. It was also recommended that we make the objects bigger. It was also recommended that we reposition the objects in our game so that they didn't distract from what our main focal point was supposed to be.
For Engineering we were told to have the catapult arm move with the Prince and to make the Obstacles in the air actually move instead of remaining static. We also told that adding in an achievement system would be cool and we could use a help button to show the physics equation so that the player would know how to adjust the separate components of the catapult.
We took these suggestions to heart and tried to implement as many of them before Wednesday. While Ashley went to work on fixing the art I talked with Kameron on what files would need to be edited in order to make the objects move and then I made the adjustment so that all of the objects moved either up and down, or left and right. I then took the new art from Ashley and placed them into the game. By this time we needed to finish for the day.
Before Wednesday came I was able to add the catapult arm to the game. Initially we were thinking of having the catapult movement be based on a sprite sheet, but as we thought about making it adjust both angle and length we realized that we would need to take one image and manipulate it with code so that it would act correctly. I took the image that we had for the catapult arm and implemented the movement and growth into the game. It was very satisfying to see the arm move, lengthen, and shorten in correlation with the Prince as the different values were adjusted on the scrollbars. It definitely gave the game a nicer polish. I even made it so that after you chose the angle at which the arm would release the Prince and pressed the launch button, the arm would then go back and then launch the Prince. Before the Prince would just take off from the release angle. The speed of the catapult launch even reflects the Force at which the Prince is released. If it's a low Force the arm move slowly, the higher the Force the faster the arm movement.
After this I added an achievement system. At this point I didn't have much time, so I was only able to make three achievements. They correspond to hitting the obstacles in front of the Princess' tower. If you hit the Pegasus you get "Pegasus Rider" the Bear gives you "Bear Trainer" and the Dragon "Dragon Flayer".
Title Screen:
Main Menu:
Game Screen when launched:
Market Place:
Preparing to Launch again (Notice achievement in top right corner):
Win Screen:
Credits Screen:
The presentation went well on the game and we all came away feeling pretty good about it.
Friday, October 14, 2011
Fall Break Fun
Before Fall Break started Troy (the Producer), Kameron (An Engineer), and I (Another Engineer) got together and started to work on putting the actual Physics into the game. Troy had been studying the exact Physics we would need to work the catapult and how the different variable affect the projectile formally known as Prince. We ended that session with the Prince launching and gong the desired distance with a nice looking parabola of travel. We decided that we should meet again during Fall break to get more done and fine tune the Physics.
We met again during Fall break. Kameron had made it so that the Prince would change position when the angle was adjusted. I added a scroll bar for the length of the catapult arm and made the adjustments so that the prince changed position with the arm. At the point the Catapult arm remained static and only the Prince's position was changed. The Physics were also smoothed out so that the Prince traveled in an aesthetically pleasing manner.
We met again during Fall break. Kameron had made it so that the Prince would change position when the angle was adjusted. I added a scroll bar for the length of the catapult arm and made the adjustments so that the prince changed position with the arm. At the point the Catapult arm remained static and only the Prince's position was changed. The Physics were also smoothed out so that the Prince traveled in an aesthetically pleasing manner.
Tuesday, October 4, 2011
Scroll to your heart's delite
The game is moving along now. We decided that the game needed scroll bars to adjust the value of needed variables. That is, the prince in our game is going to be launched from a catapult in order to get to the princess. We have it so you can adjust certain attributes of the catapult in in order to land in the right spot. These adjustments are going to be controlled by scroll bars. You adjust the scroll bar until it ready the value that you want to assign to that specific attribute and then you press launch and hope you reach your goal.
I have just completed the code for the scroll bars and added some into the level of our game and it looks pretty good. Once we have all the place holder images completed it will look even nicer.
I have just completed the code for the scroll bars and added some into the level of our game and it looks pretty good. Once we have all the place holder images completed it will look even nicer.
Monday, October 3, 2011
Mouse Control this is Major Tom
We decided that since this new project is going to be for windows that we would like to use a mouse as a controller. I figured that that would be simple, but it ended up being a big pain. First, you need to make the mouse visible, easy. Now you need to make it so it can detect objects and influence what they do and that they can tell if they have been clicked. Not as simple. You do have a MouseState provided for you, but it just tels you if there is click on one of the buttons. I decided that since I had to write a bunch of code for detecting if the mouse button is being held, and if the click counts as a double click that I would just write a new mouse class or object. so that is what I did. The cool thing about ti is that we can now have a custom cursor for our game, and I understand how it works, because I coded it.
To go with the Mouse object I ended up writing a new object class for clickable objects. That is, this class is for any items on the screen that we want to click and have interact with the mouse. things such as buttons and scroll bars.
I made up our menus and went a ahead and applied the clickable object code to them and it's working pretty good. Now to make scroll bars. Yay!
To go with the Mouse object I ended up writing a new object class for clickable objects. That is, this class is for any items on the screen that we want to click and have interact with the mouse. things such as buttons and scroll bars.
I made up our menus and went a ahead and applied the clickable object code to them and it's working pretty good. Now to make scroll bars. Yay!
Subscribe to:
Posts (Atom)