- Grey scale shader
- I wrote a shader that would take the texture and apply a certain level of grey scale to it (based on a variable that could be changed dynamically).
- Color shifter/animator
- This script would transition from the original color to the target color over a certain amount of time. An altered version was used to change the grey scale factor on the shader.
- Globule behavior
- Made the globules more dynamic and interested by having them "pulsate" (grow and shrink).
- Globule collection
- Set the system up so that globules could only be collected once per game (3 drops = 1 game). The player had a type of tractor beam/attraction to globules (Chris Bright actually created it for his collectable rain drops, but I modified it a little to make it better for globules).
- Globule
- Globules could be different types (randomly configured at the start) and had a certain score modifier.
- Scoring system
- The score was actually a sum of many different factors:
- Distance (how far the player had fallen)
- Proximity (the player got more points the longer they fell next to something like a building)
- Splatting on different objects could add points to the score (different objects had different point values. Objects included cars, trees, mail boxes, etc.)
- Globule collection
- Collecting rain drops didn't directly alter the score, but would allow the player to create a larger splash, thus hitting more objects at the end and allowing for a higher score.
- Scoring system UI
- Had to format the display of the score on the screen.
- During the level, the round score was displayed (the sum of everything)
- After the level, the score was broken down into parts so the player could see where they did best (for the object scores, it was broken into the top objects hit with how many times each kind was hit).
- Targets/Object identifier
- Wrote a script that identified the different types of objects possible and set up behaviors for each one once hit by the player or splats.
- Trees would have spotlights on them that altered in intensity (no intensity made the trees look brown and dead and full intensity would make them look green and alive)
- Cars would go from grey to random colors
- Planter boxes would animate from wilted and brownish to strong and vibrant
- Particle system manipulator(s)
- Wrote a script that would allow a collection of particle systems to move to a location and play (it would cycle through 4 or 5 systems instead of creating new ones and then deleting them after a while).
- Scale and lifetime could also be changed.
- Dynamic model manipulator
- This would alter the vertices in the model. It was created to give the character a more fluid feel/appearance. In order to achieve that effect I used a Perlin noise generator and applied it to the vertices.
- The problems with using the Perlin generator was that initially I had it running every update (huge costs since there were a lot of vertices in the model). To alleviate that, I changed it to update every 10 frames or so.
- I did some more research and I would like to change from using a Perlin noise generator to using a Simplex noise generator since it has less overhead and requires less computational power.
- Nonlethal interaction
- We wanted some things the player could collide with to not kill them, but have it change their status in some way. Such items included fire escapes, clotheslines, and such.
- When a player collided with one, they would lose some mass.
- A future feature is to make the lost mass recollectable.
A blog about the Game Engineering track at the University of Utah's Master Games Studio.
Monday, December 17, 2012
Summary of what I did this semester
This semester comes to a close and as such, our project is wrapping up (for a little while...we'll be back at it next semester). It's been a tough semester with multiple direction changes, SDK changes, and just general problems that popped up. It's also been a very educational and useful semester. I'm going to compile a bullet list of what I worked on for our project:
Thursday, March 1, 2012
Thesis Project
The prototype I was working on (Nanograte) was not selected to move on to the next stage. Instead, I have been re-assigned to the Flyboy project, a Kinect game that explores falling.
The Flyboy prototype had a falling stage before the player could start flying through the city to collect coins. The majority of the people we presented to liked the falling part of the Flyboy prototype, but they didn't like the actual game (the flying part). Therefore, we have to find a new idea to continue on. The requirements:
1) Must be Kinect based
2) Must be about falling
Once we actually have an idea, we still have to prototype the new idea before we can get started on the actual game. We are supposed to have our project to an alpha release (functional and fully featured, but not necessarily finely tuned or complete) by the end of the semester. It will be tough to get a new prototype done and get it to alpha level in less than 3 months, but we have a good team, so we should do well.
During our first team meeting, we've thrown around a lot of ideas, but we haven't decided on one yet. The idea I like the most is a "A falling Stuntman with the Kinect". The player would be a stuntman where all the levels they play are falling scenes in movies and points are awarded based on how well they do and after each level, a trailer (using the player's actions) is shown.
The Flyboy prototype had a falling stage before the player could start flying through the city to collect coins. The majority of the people we presented to liked the falling part of the Flyboy prototype, but they didn't like the actual game (the flying part). Therefore, we have to find a new idea to continue on. The requirements:
1) Must be Kinect based
2) Must be about falling
Once we actually have an idea, we still have to prototype the new idea before we can get started on the actual game. We are supposed to have our project to an alpha release (functional and fully featured, but not necessarily finely tuned or complete) by the end of the semester. It will be tough to get a new prototype done and get it to alpha level in less than 3 months, but we have a good team, so we should do well.
During our first team meeting, we've thrown around a lot of ideas, but we haven't decided on one yet. The idea I like the most is a "A falling Stuntman with the Kinect". The player would be a stuntman where all the levels they play are falling scenes in movies and points are awarded based on how well they do and after each level, a trailer (using the player's actions) is shown.
Tuesday, January 24, 2012
Semester 2: The Pre-Thesis Introduction
Right now in our Projects 2 class we're working on prototyping some games that were pitched (7 were chosen). After this month long prototyping is done, 2 games will be selected for full development for our thesis project!
I'm working on the prototype for a game called "Nanograte." The idea of the game is to use your Command Nanobot to collect nanobots together into a swarm; once a swarm is aggregated, the player attacks the enemy swarm in an attempt to destroy the opponent's Command Nanobot.
The original designer wanted to simulate murmuration within the swarm:
Some other suggestions the group came up with are to make it a 2.5D view (similar to most real time strategy games where the camera has a tilted view down onto a plane), swarm formations, and allowing customizable formation shapes (rather than have a list of available formations).
Now for the good stuff (the technical details):
We're using the Unity3D engine for developing the prototype. Our target system is the iOS and/or Android. The nice thing about Unity is that it has a lot of functionality that we don't have to create (best thing for a prototype!) so we can focus on the two most important aspects/features of the game: murmuration and formations.
I'm really excited about this game! It should be really fun and have really great effects, if we can pull of the programming. Unfortunately I don't have much experience with Unity, so some time and energy will be spent on learning the engine well enough to manipulate it. More details such as problems, achievements, and updates will be posted as they come up! Any comments, questions, and/or suggestions are welcome, just leave a comment.
Go to the official blog for Nanograte for more details: Nanograte Game Development
I'm working on the prototype for a game called "Nanograte." The idea of the game is to use your Command Nanobot to collect nanobots together into a swarm; once a swarm is aggregated, the player attacks the enemy swarm in an attempt to destroy the opponent's Command Nanobot.
The original designer wanted to simulate murmuration within the swarm:
Some other suggestions the group came up with are to make it a 2.5D view (similar to most real time strategy games where the camera has a tilted view down onto a plane), swarm formations, and allowing customizable formation shapes (rather than have a list of available formations).
Now for the good stuff (the technical details):
We're using the Unity3D engine for developing the prototype. Our target system is the iOS and/or Android. The nice thing about Unity is that it has a lot of functionality that we don't have to create (best thing for a prototype!) so we can focus on the two most important aspects/features of the game: murmuration and formations.
I'm really excited about this game! It should be really fun and have really great effects, if we can pull of the programming. Unfortunately I don't have much experience with Unity, so some time and energy will be spent on learning the engine well enough to manipulate it. More details such as problems, achievements, and updates will be posted as they come up! Any comments, questions, and/or suggestions are welcome, just leave a comment.
Go to the official blog for Nanograte for more details: Nanograte Game Development
Subscribe to:
Posts (Atom)