To start off this blog post, I will talk about the prototype we are doing in unity.
The idea that we decided to go with was zombie / survival horror combined with bowling. This is an odd mix but I've had a few ides about a similar game in the past. Maybe either zombies replacing pins and they're running around while you try to knock them down or maybe they are coming to eat your brains and you are struggling to bowl as fast as you can to keep them away.
For the assignment we decided to go with something simple. Basically, the player is at one end of the lane and zombies are slowing approaching them from the other end. The player will try to "bowl" and knock out the zombies. At this point you may be wondering, why is "bowl" written with quotes around it? That's because we decided to change it up a bit and make it more luck rather than skill based. I've seen examples of how it would work with actual "bowling" but wanted to try my hand at throwing in luck to see how it will turn out. So instead of "bowling", the player rolls a dice, which determines where the ball gets thrown down the lane. With every throw, if the ball hits a zombie, the first one (aka one closest to player) is knocked down otherwise all zombies will move forward and a new one spawns in a random point at the end of the lane.
For GDW, everybody is working hard and making that big final push to get the game finished (and yes we did slack off a bit knowing that the due date was pushed back by a few weeks). A lot of the work is starting to come together now (the assets are about 90 - 95% finished) and whats left is putting all the pieces together and turning it into a great game.
For the modeling and rigging the medic character's rig is now completely finished and ready to go. I did run into a few problems but those have all been resolved now.
For the sounds we haven't gotten around to finishing recording the rest of the sounds but whats for sure is that we have edited the sounds we recorded previously and a lot of the sound effects are ready to go.
As for the networking, the path convergence code has been added and all that is really left is telling the clients to use that information to render. RakNet has been surprisingly easy to work with. For the remaining portions of the networking I have decided to pass it on to other group members. The networking professor has mentioned he is expecting everybody work with it and it would be wrong of me to "take away" another member's opportunity at learning. I will still help with the networking when and if they run into troubles but just thought it'd be more fair to have other people do networking rather than me finishing all of it by myself.
Hopefully we will have a game that is more playable in the upcoming week.
Sunday, March 25, 2012
Monday, March 19, 2012
Progress Update
To start off I will talk about the design of enemy difficulties in our game. In our game, the waves of enemies will "level up" and get increasingly harder, eventually being too overpowered for the players to handle and cause the game to end. I have started spending more time looking into the numbers to determine if they are more balanced, as this will be important to the flow state of mind.
We want to make sure that our game is intrinsically motivating. We hope that the importance of working in a team is enough to motivate the player to try as hard as they can so that they won't let their teammates down. To create the feedback loop and give the player positive feedback, our game will have rewards (as covered in a previous lecture) such as giving them special abilities, or additional resources, more playing time, sparkle, etc. Again, hopefully the positive experiences they get from working together as a team will be enough to keep them trying their best. These are all related to the flow state of mind and covers some of the principles of learning.
In other updates, most of the sounds have been recorded already (~80% done). The remaining ones are the ones that we can't seem to nail yet as they don't have the desired effect when played back. We are looking on how to fix these problems and then re-record them.
For networking, the base has now been fully set up. The clients will connect to servers and send update packets whenever keys are pressed. I have tested this and have successfully received the position/movement update packets. All that is left now is making sure that our dead reckoning works properly.
For entrepreneurial finance, since the requirement was only a partial business plan, it has now been officially completed. All that is left is just editing or changes that anyone in the group may want to make between now and the due date.
Last, the model I was supposed to rig is nearly complete. I have ran into a few problems but they should be easy fixes and the entire thing should be fully done by the end of next week.
We want to make sure that our game is intrinsically motivating. We hope that the importance of working in a team is enough to motivate the player to try as hard as they can so that they won't let their teammates down. To create the feedback loop and give the player positive feedback, our game will have rewards (as covered in a previous lecture) such as giving them special abilities, or additional resources, more playing time, sparkle, etc. Again, hopefully the positive experiences they get from working together as a team will be enough to keep them trying their best. These are all related to the flow state of mind and covers some of the principles of learning.
In other updates, most of the sounds have been recorded already (~80% done). The remaining ones are the ones that we can't seem to nail yet as they don't have the desired effect when played back. We are looking on how to fix these problems and then re-record them.
For networking, the base has now been fully set up. The clients will connect to servers and send update packets whenever keys are pressed. I have tested this and have successfully received the position/movement update packets. All that is left now is making sure that our dead reckoning works properly.
For entrepreneurial finance, since the requirement was only a partial business plan, it has now been officially completed. All that is left is just editing or changes that anyone in the group may want to make between now and the due date.
Last, the model I was supposed to rig is nearly complete. I have ran into a few problems but they should be easy fixes and the entire thing should be fully done by the end of next week.
Saturday, March 10, 2012
Implementing RakNet and other updates
With the GDW code freeze date slowing creeping closer and closer, everybody is working hard and giving it the final push so we can have it finished and ready.
Since the group hasn't gotten anywhere yet with RakNet and implementing it into the game, I have started working on it so that this isn't left until the last minute. At first I ran into 100+ errors, my worst nightmare has come true! Solving them wasn't easy, but I started looking up other similar problems people had, and started putting the pieces together. What I thought would take me a week to figure out ended up taking only a day! Here's a picture to show that the networking portion is working:
I have 2 instances of the game and the client is able to connect to the server.
Right now I am working on dead reckoning. I have the basics of it going but I still need to test it and do some tweaking if necessary. It is important that we get the position and movement updates using the first order model since this will be worth 25% of our marks. Once this is up and running I will continue to work on implementing path planning and path interpolation.
In the sound area, we haven't started yet, which is another bad thing. However, I am working with some other team members to come up with a list of sounds we will need, and we are going to record all of the sounds and it should take only 1 or 2 days at most. Unfortunately we left sound to last minute last semester and didn't get a chance to incorporate it into the game, so we are going to get it done this week so that the programmers can put it into the game early on.
For modeling, I still need to fix up the gun models from, UV and possibly texture map them. On top of that, I will also be rigging 1 or 2 of the player models. Depending on how well I manage my time this upcoming week, I may be able to get all of this done by the end of the week. Hopefully this will be everything we need to finish the game so that after the code freeze milestone all we have left to do is polishing to make the game look better for the GameCon.
Since the group hasn't gotten anywhere yet with RakNet and implementing it into the game, I have started working on it so that this isn't left until the last minute. At first I ran into 100+ errors, my worst nightmare has come true! Solving them wasn't easy, but I started looking up other similar problems people had, and started putting the pieces together. What I thought would take me a week to figure out ended up taking only a day! Here's a picture to show that the networking portion is working:
I have 2 instances of the game and the client is able to connect to the server.
Right now I am working on dead reckoning. I have the basics of it going but I still need to test it and do some tweaking if necessary. It is important that we get the position and movement updates using the first order model since this will be worth 25% of our marks. Once this is up and running I will continue to work on implementing path planning and path interpolation.
In the sound area, we haven't started yet, which is another bad thing. However, I am working with some other team members to come up with a list of sounds we will need, and we are going to record all of the sounds and it should take only 1 or 2 days at most. Unfortunately we left sound to last minute last semester and didn't get a chance to incorporate it into the game, so we are going to get it done this week so that the programmers can put it into the game early on.
For modeling, I still need to fix up the gun models from, UV and possibly texture map them. On top of that, I will also be rigging 1 or 2 of the player models. Depending on how well I manage my time this upcoming week, I may be able to get all of this done by the end of the week. Hopefully this will be everything we need to finish the game so that after the code freeze milestone all we have left to do is polishing to make the game look better for the GameCon.
Wednesday, February 29, 2012
Modeling with a broken laptop?
So after getting a pile of homework and midterms out of the way I have finally made time to do more modeling for our GDW game. Since other members are focusing on the characters right now I figured I would start working on the weapons models.....when suddenly...........BAM! I was hit with a hard drive failure! There goes months worth of hard work!
After getting a replacement laptop for the time being, I have started doing some modeling and here is a picture of my current work in progress:
 |
| The reference image along with the outline of the gun model |
 |
| Here is the model by itself |
Since the game is mainly about surviving hoards of robots one goal for all of the modelers is to keep them as low polys as possible. This gun is only at 26 polys right now so I am on the right track. Here are the other guns that will be modeled:
The assault rifle is for the assault character, and the sniper rifle will be for the sniper character (assuming we have the time to model and rig the character). The above pistol was for the medic.
Tuesday, February 21, 2012
An Overdue Update?!?
It's been a week or 2 now since I've last updated this blog. I will start off the updates with where I last left off: the space invaders remake homework assignment. Below is a picture of the final game:
The original mechanics are all in the game, and all it is really missing are more polished assets/interfaces; but given the 1 week time frame I had to work on it, I figured it's more important to have all the original mechanics so that it can be played properly.
For the GDW game, I will talk about some of the game balancing:
Fairness: 'Endless' is asymmetrical since players control a different character. Although they have different abilities, we are working to balance out the numbers so that everybody has a fair shot at staying alive for a decent amount of time. For example, the medic may have higher health since it has a very weak attack, while an engineer may have lower health since he is able to produce turrets that can be used to attack and distract enemies in game.
Challenge: I think our game has some good challenges for players of all experience levels. Since the gameplay generally remains the same throughout, challenge is incorporated through faster spawning of enemies as well as stronger enemies.
Meaningful Choices: 'Endless' is a good game for implementing some good meaningful choices. In the game, the gold or money is shared between ALL team members. This means that the team has to effectively figure out who's weapons to upgrade and when to upgrade them. The team could try to max out attack upgrades for the sniper, but the other members would suffer as enemies get stronger and they are unable to hold out for themselves.
Skill vs. Chance: When enemies die in the game, they will drop a certain amount of gold (determined at random). To balance out the issue where the team kills a boss and gets 0 gold, each set of enemies will have a pre-defined max drop and min drop so that the team will still be able to get upgrades even if they are unlucky and get the minimum drop every time.
Heads vs. Hands: The game will require both, and the players must be quick in order to win. Initially, the players will have more time to figure out a strategy, but as the game progresses, they will have to think and act fast. For example, if a group member were to die in the middle of a wave what should the team do? Their chances of survival have just gone down so they need to think of a way to continue surviving.
Competition vs. Co-operation: There is a fair mix of both in the game. Since the gold is shared, the team must co-operate and decide who's weapons are important upgrades. Also, the game is designed so that as a single player you are almost destined to lose very quickly, and in order to get a higher score everybody must work together. There is also some competition amongst the team as they will want to be the last man standing.
Short vs. Long: We are currently working on balancing this out, as we feel that it is possible the game may be too long. If the players get too much time they will be able to formulate many meaningful strategies and keep the game going forever. We are trying to come up with different ways for the AI to behave so that once the team formulates a strategy, it will change to a new strategy and keep players thinking.
Rewards: Of course our game has rewards! Monsters will drop gold that is important for upgrading weapons. Points are also given so that they can be posted on a high score board. And of course there are rewards for working as a team (the medic will be able to heal injured players so that everybody can play longer)
Punishment: The game will punish players through the use of shorter playtime and terminated play. Basically if the player makes stupid choices they will die faster, and that results in the team being unable to play for a long period of time, thus ending the game early.
Freedom vs. Controlled Experience: The game is mostly a controlled experience. The only freedom the players have is to run around wherever they please (on the map). Other than that players are only trying to survive for as long as possible and there aren't any side distractions to keep them away from their main goal.
Simple vs. Complex: We are aiming to avoid innate complexity. We want the game to be elegant in that it is easy to pick up the controls and it is fun to play.
Detail vs. Imagination: The game takes place on top of a skyscraper on planet Earth. We aren't trying to create a brand new world. Besides that there aren't that many details and we leave the imagination of the player to do all the heavy lifting.
The original mechanics are all in the game, and all it is really missing are more polished assets/interfaces; but given the 1 week time frame I had to work on it, I figured it's more important to have all the original mechanics so that it can be played properly.
For the GDW game, I will talk about some of the game balancing:
Fairness: 'Endless' is asymmetrical since players control a different character. Although they have different abilities, we are working to balance out the numbers so that everybody has a fair shot at staying alive for a decent amount of time. For example, the medic may have higher health since it has a very weak attack, while an engineer may have lower health since he is able to produce turrets that can be used to attack and distract enemies in game.
Challenge: I think our game has some good challenges for players of all experience levels. Since the gameplay generally remains the same throughout, challenge is incorporated through faster spawning of enemies as well as stronger enemies.
Meaningful Choices: 'Endless' is a good game for implementing some good meaningful choices. In the game, the gold or money is shared between ALL team members. This means that the team has to effectively figure out who's weapons to upgrade and when to upgrade them. The team could try to max out attack upgrades for the sniper, but the other members would suffer as enemies get stronger and they are unable to hold out for themselves.
Skill vs. Chance: When enemies die in the game, they will drop a certain amount of gold (determined at random). To balance out the issue where the team kills a boss and gets 0 gold, each set of enemies will have a pre-defined max drop and min drop so that the team will still be able to get upgrades even if they are unlucky and get the minimum drop every time.
Heads vs. Hands: The game will require both, and the players must be quick in order to win. Initially, the players will have more time to figure out a strategy, but as the game progresses, they will have to think and act fast. For example, if a group member were to die in the middle of a wave what should the team do? Their chances of survival have just gone down so they need to think of a way to continue surviving.
Competition vs. Co-operation: There is a fair mix of both in the game. Since the gold is shared, the team must co-operate and decide who's weapons are important upgrades. Also, the game is designed so that as a single player you are almost destined to lose very quickly, and in order to get a higher score everybody must work together. There is also some competition amongst the team as they will want to be the last man standing.
Short vs. Long: We are currently working on balancing this out, as we feel that it is possible the game may be too long. If the players get too much time they will be able to formulate many meaningful strategies and keep the game going forever. We are trying to come up with different ways for the AI to behave so that once the team formulates a strategy, it will change to a new strategy and keep players thinking.
Rewards: Of course our game has rewards! Monsters will drop gold that is important for upgrading weapons. Points are also given so that they can be posted on a high score board. And of course there are rewards for working as a team (the medic will be able to heal injured players so that everybody can play longer)
Punishment: The game will punish players through the use of shorter playtime and terminated play. Basically if the player makes stupid choices they will die faster, and that results in the team being unable to play for a long period of time, thus ending the game early.
Freedom vs. Controlled Experience: The game is mostly a controlled experience. The only freedom the players have is to run around wherever they please (on the map). Other than that players are only trying to survive for as long as possible and there aren't any side distractions to keep them away from their main goal.
Simple vs. Complex: We are aiming to avoid innate complexity. We want the game to be elegant in that it is easy to pick up the controls and it is fun to play.
Detail vs. Imagination: The game takes place on top of a skyscraper on planet Earth. We aren't trying to create a brand new world. Besides that there aren't that many details and we leave the imagination of the player to do all the heavy lifting.
Monday, February 6, 2012
Magic: The Gathering Cards and Unity Assignment
For the past week I've been working on the two game design assignments, one of which is the make 3 'Magic: The Gathering' cards and make sure they are balanced. Here are the cards I did for that assignment:
The balancing for 'Radiated Slime':
Benefit: 3 attack + 1 defense + 1 color bonus = 5 points
Cost: 1 baseline + 2 colored mana + 2 non-colored mana = 5 points
Here are the numbers for 'The Hooded Figure' card:
Benefit: 6 attack + 5 defense = 11 points
Cost: 1 baseline + 2 colored mana + 7 non-colored mana + 1 5+ mana cost = 11 points
And here are the numbers for 'The Lone Wolf':
Benefit: 2 attack + 4 defense = 6 points
Cost: 1 baseline + 2 colored mana + 3 non-colored mana = 6 points
The cards are above; as you can see, there is nothing special. There aren't any special effects and it is just a simple description of the creature in the cards. Balancing them was fairly easy and I just followed the instructions from the lectures. Benefit points are power + toughness + any color bonuses. Cost points are basically baseline + colored mana + non colored mana + any bonuses.
The second assignment was to remake a game in Unity. I chose to do 'Space Invaders' for this one. Below is a picture of what I have now:
It's a bit different from the original Space Invaders where the enemies are lined up and slowly moving down on you, but this remake works in a similar way. There is only one enemy coming at you at a time (the red sphere) and as the player (purple square), you have to shoot bullets and try to destroy the enemies. The blue shields are there to protect you and occasionally a ufo like object will fly across the screen and if the player can shoot it down it will provide extra points.
Benefit: 3 attack + 1 defense + 1 color bonus = 5 points
Cost: 1 baseline + 2 colored mana + 2 non-colored mana = 5 points
Here are the numbers for 'The Hooded Figure' card:
Benefit: 6 attack + 5 defense = 11 points
Cost: 1 baseline + 2 colored mana + 7 non-colored mana + 1 5+ mana cost = 11 points
Benefit: 2 attack + 4 defense = 6 points
Cost: 1 baseline + 2 colored mana + 3 non-colored mana = 6 points
The cards are above; as you can see, there is nothing special. There aren't any special effects and it is just a simple description of the creature in the cards. Balancing them was fairly easy and I just followed the instructions from the lectures. Benefit points are power + toughness + any color bonuses. Cost points are basically baseline + colored mana + non colored mana + any bonuses.
The second assignment was to remake a game in Unity. I chose to do 'Space Invaders' for this one. Below is a picture of what I have now:
Wednesday, February 1, 2012
GDW Update
Over the past two weeks, I continued to work on the level for the game, a prototype in Unity, as well as some balancing (done as part of homework in Unity). The map is now complete, and below are some images of the level:
I posted pictures previously of what the level looked like but the story was changed and the map had to be completely re-done. The story now takes place on top of a building. Version 2 of the map was my favourite as it seemed more appropriate for a roof top. Unfortunately, most of the team didn't like it too much so I had to add more clutter to the rooftop and remove the billboard.
Since I was the one that designed the map, I was also the one tasked with the task of turning this map into 0's and 1's and throwing them into a text file for the programmer. It was an extremely repetitive task and I messed up a few times at one point, but the text file map is now done and out of the way.
Some of the balancing I did was for the attack damage. I basically threw in a static enemy and played around with the values in the javascript file, tweaking variables such as enemy health, player attack strength, and player attack speed. After tweaking them for a few hours I believe I've found something reasonable, and it allows players to kill enemies easily early one (1 or 2 hits to kill) and the number of hits gradually increases as the level gets higher and higher. Hopefully this will save us some time later on when it is time to balance the game.
For this next week I am hoping to work on either modeling, creating the sound effects, or programming. There is still a lot of work to do, however, with piles of assignments and midterms slowly creeping up hopefully we can have something playable by mid February.
 | |
| This is the level (Version 3) |
 |
| Top view of the version 3 level |
 | ||
| This is version 2 of the level |
Since I was the one that designed the map, I was also the one tasked with the task of turning this map into 0's and 1's and throwing them into a text file for the programmer. It was an extremely repetitive task and I messed up a few times at one point, but the text file map is now done and out of the way.
Some of the balancing I did was for the attack damage. I basically threw in a static enemy and played around with the values in the javascript file, tweaking variables such as enemy health, player attack strength, and player attack speed. After tweaking them for a few hours I believe I've found something reasonable, and it allows players to kill enemies easily early one (1 or 2 hits to kill) and the number of hits gradually increases as the level gets higher and higher. Hopefully this will save us some time later on when it is time to balance the game.
For this next week I am hoping to work on either modeling, creating the sound effects, or programming. There is still a lot of work to do, however, with piles of assignments and midterms slowly creeping up hopefully we can have something playable by mid February.
Subscribe to:
Posts (Atom)