Game Over!

Another semester has now come and gone, and, with that being said, our game is now finished! Okay, so I sort of lied there :P The game is finished in the sense that we have submitted the game already so no matter what changes we make to it will not be graded now; with that in mind, that doesn't mean that we aren't free to go and keep working on it over the summer. Here is a trailer for our game:

Most of us probably aren't going to continue working on the game though (wildmagic is a terrible terrible terrible engine to work with in my opinion), and I think most of us are now stressing over final exams, and once that is done, most of us will probably enjoy the summer and take some time off to do something relaxing.

As for me, I will not be working on this game anymore. Instead, I will most likely be working on a new game over the summer/next year so that we can participate in the game con next year. And of course, now that blog posts are no longer mandatory this blog will probably be less updated until the next school year starts again.

Last Week!

With the GameCon coming up this week (Thursday), everybody is working hard to finish their parts so that they can be put into the game. For the most part everything is good and it is all coming together now. There are still bits and pieces missing and my biggest concern is still the networking portion of the game.

A lot of the networking stuff is there and works for the most part, but it seems everything is coming together so slowly that I can't predict whether or not we will be able to actually finish it on time. Of course since this is for marks not finishing this is not an option so I will be working really hard these next few days trying to finish the networking portion and make sure it integrates smoothly into the final game. It is rather unfortunate that I ended up being the only one to work on this for the most part so the end result will be rather far from what I originally had in mind when we planned the game earlier in January.

Other than that I will spend my time working on the postmortem for the group. This way, we can avoid writing this last minute where everybody is confused and scrambling to put the game together before the presentations. Doing the postmortem as well as planning for the presentation ahead of time is always a good idea.

Later this week (or early next week) I will post the end result of the game as well as some links to trailers and/or pictures and also possibly a release version of the game. Hopefully everyone will enjoy the game!

Balancing The Endless Game Economy

In this blog post I will talk about the game economy in Endless (which was the topic of the last game design lecture).

The currency in 'Endless' is gold and player's earn these through killing enemies. The only purpose of gold in the game will be to upgrade the weapons that the players have. Normally, when you think of any game out there what usually happens is a player earns money from killing monsters, and whoever kills the monster can pick up the gold (unless they decide to pass on that and let someone else pick it up). In our game, however, things are going to work a bit differently. To keep in the spirit of teamwork, we are going to try a system where the money is shared between the team. Instead of having gold individually for each player, the money will be the team's money. We are working on getting a few things sorted out first before we will go with this idea. Basically, in a multiplayer game, the person who started the game (aka team leader) will get control of the money, and will have to spend them on appropriate upgrades for each member. Again this may or may not work out, but I am curious to see how this will turn out in the end if we go through with it.

Here I discuss some of the points relating to a balanced game economy:

Fairness: With this system it may be possible for a player to get an unfair advantage. One scenario would be the team leader decides to keep all the gold and only spend it on himself, therefore giving him the best weapons against the enemies while leaving his teammates with only the default weapon and no upgrades. In this case the player may get a bit of an advantage in the early to mid game but I believe this will eventually fail as enemies will not drop enough gold for the player to keep upgrading his own weapon leaving him with no choice but to upgrade his teammates weapon in order to stand a better chance. Teamwork is key here in this game.

Challenge: Since the game will have the player losing eventually, that means that as the game progresses, getting the money needed for upgrades will be come harder and harder. There won't be a weapon upgrade that will be overpowered and provide for a clear advantage over everything else.

Choices: I believe the game is a bit limited here for choices since the only way to earn money is to kill enemies and the only place where they can spend the money is on weapon upgrades. Maybe if we have time we will throw in more choices and make the game more fun.

Chance: Earning money in this game will be more chance based. Killing an enemy (especially in the early game) won't be too hard provided that everyone in the team is focusing on that enemy. The money however, will most likely be randomized. Each time the difficulty or "level" of the enemy goes up, the gold drop cap will increase so that they can earn more money later on and it will also limit the amount of gold the team may receive from killing a weak enemy.

Cooperation: I think how the game works speaks for itself here. Only one person controls the money so it will be important for cooperation and the team leader needs to ensure that everyone has the appropriate upgrades so that they are able to support their teammates.

Time: I would say the way it is right now it sits between earning money too fast and being just right. Again players earn money through killing so earning money will not be a difficult task in this game where there are hoards of enemies. However, I believe that the game compensates for this by only allowing players to upgrade in between levels. This will prevent the team from earning money in between levels and makes the upgrade opportunities more valuable.

Rewards: It can be rewarding earning/spending money, as this would essentially lead to rewards in the game in general. The more powerful the characters are, the longer play time they get.

Punishments: If the team does not cooperate and one player ends up losing early on, then the team has essentially lost one person to help them gain income, and the team also has less choices now as they will not be able to spend money on upgrades for the dead person.

Freedom: There isn't really much freedom in the economy in terms of choices as players are limited to spending the money on only the 4 characters and they are only upgrades. However, if we look at freedom as 'being able to buy the upgrade that you want', then the team leader has a lot of freedom as he can choose to upgrade anyone's weapons as he see's appropriate.

Weekly Update

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.

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.

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.

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.