For the Greater Good Final Report

Final Report





Game Description

The story follows a group of cursed knights whose town in under siege. You play one of these  knights and it is your teams goal to protect your fleeing king from the invaders. The invaders main objective is to enter in waves and assassinate the king and anyone who stands in their way. Although the odds may seem to be against you there is a catch. You are given an assortment of abilities that you can use to turn the tables. You can also pick up power-ups that will give you overwhelming power in order to overcome groups of invading soldiers. Some of your abilities require resources… also known as civilian sacrifices.  Fortunately, there are a handful of “resources” that flee the castle with you that you can use. It is not your duty to protect the civilians but it is important to keep them alive as a resource for your abilities.  These abilities, while powerful, can also have terrible negative effects so it’s important to use them wisely.


What we achieved

Our final game is most of what we planned to achieve with our optimal plan inside of our design doc.  We implemented 3 different playable classes: medic, brute, and necromancer.  We implemented 6 different power ups,  added audio, visual cues, animations, a fun environment, civilian rescue spawns.  Overall, we feel that the game is balanced to a point where it’s fun to play and achieved what we set out to create.

What Worked

Co-op gameplay with different classes for balancing abilities

From the start of our development, we knew that there needed to be co-op gameplay with a focus on balancing different classes and abilities to work together.  By creating classes that complemented each others weaknesses and strengths, we were able to form a style of gameplay that made each class important and fun to play.  The medic was responsible healing the team and the king for survival.  The Brute was the powerhouse that could do the most damage and could afford to get farther away from the center of the level.  The necromancer didn’t do as much damage as the brute but was able to create an army to fight for him.


Power ups, especially individual rampages.

The power ups helped by adding variety to the gameplay.  These power ups had good actions upon being picked up such as: heal everybody, put a shield on the king, freeze all enemies, and rampage. However, they also have bad actions:  warp to a random place in the map, and slow.  This combination of good and bad power ups made the gameplay more exciting.


The rampage power up, in particular, was a really positive part of the gameplay.  We were even able to cater the rampage to each individual class to give it an even better feel.   The medic’s rampage heals and puts a shield on every person on your team, including civilians and the king.  The Brute’s rampage complements his strength by making him super strong and able to 1-hit any enemy.  The necromancer’s rampage turns his ability of bringing a close dead enemy back to life into an ability that brings back all dead enemies on the screen back to life instantly.


Enemies attack in waves of increasing numbers.

The enemies attack in waves that get harder and harder as the game progresses.  By having the gameplay be wave-based,  we are able to give the players a little time to adjust to the gameplay before they are swarmed with enemies.  This also means that the gameplay could be the same while allowing for different difficulties.


What Didn’t Work

Unity and version control

Unity isn’t the best software to work with in a central code repository.  When several people tried to make modifications to the same scene file, it was extremely hard to do any manual merging.

Playing on a laggy network

As you might expect, playing on a laggy network causes problems with the gameplay. When playing an online co-op game where you rely heavily on your team mates, it’s especially important to have a good internet connection. Playing on a laggy network would cause issues with everyone except for the host. The game would still go at it’s normal pace and not slow down for the players who are lagging, which would often lead to them dying or at least taking damage while they are lagging.

Not enough balance on good vs bad events

The necromancers ability initially was too risky to use. Initially, when the player would raise an enemy from the dead there was a high chance that the zombie created would be an enemy and fight against you. We felt that this was too much of a drawback and made it feel like using the necromancers ability was not worth it. Especially since there are, in many stages of the game, more allies on the map then there are enemies which makes the zombies more likely your enemy than your ally.

Controls for some actions weren’t intuitive.

Many people mentioned while testing the game that the medics healing ability did not feel intuitive. The medic can distribute health by hitting his ally with his basic attack ability. People felt that this was counterintuitive as it is the same attack you use to deal damage to your opponents and heals your allies.

What We Learned


Balancing gameplay is very important and equally difficult.

The idea for our game always evolved around the idea of co-op play; so an important part of that was balancing the gameplay.  The only class that even has a chance of surviving on it’s own for a long time is the medic since he can heal himself and the king.  This was designed this way so that each player would work together to complete the game.  Finding the right balance between the different types of classes can be difficult though and takes some time, especially in a game that gives the players abilities that are both good and bad at the same time.  An example of where we ran into issues of balancing the classes can be found in the section “Necromancer’s ability adjusted” section below.  It was also important to make sure that the player gets attacked enough for them to feel threatened.  In this case, we made the enemies attack faster and also improved their targeting system.


There must be a reason for the player to do what you want them to do.

A lot of the feedback that we got in the first alpha demo was that they saw no reason to keep the civilians alive.  During this phase, our enemy targeting system wasn’t complete so they would just pick a random good character (player, civilian, king) to attack.  Because of the low chance of them picking the player, the player was almost never hurt.  This lead to the players of the game to think that there was no purpose to keeping the civilians alive or even use the medic’s ability.  We were able to finish the enemy targeting system and tweaked the enemies to be faster so that they would do more damage to players.  After implementing this, the players saw the medic class as much more important to the overall game.


Even though they were able to steal health from civilians and distribute the health to the king,  because there wasn’t a big reason to do this, they simply didn’t.  Some players even started killing civilians because they weren’t important. Once we gave them a reason to keep the civilians alive, they started to play the medic class as designed.

In a networked game, it’s important to design features to be easily networkable.

When we started developing the networking features, the power up system and gameplay mechanics were already mostly implemented. However, they were implemented in a way that worked in a non-networked game.  Once we started implementing networking, we found out pretty fast that not everything works out well over the network when designed like that.  Because of recognizing this later in the development,  we had to rewrite our code to support networking in a master server and client infrastructure.  If we had known this in the beginning, we could have saved time in development.  It’s also best for everybody on the team to have a good understanding of how the networking works and how to design features to work over networking.


Audio and visual cues

During the in-class alpha demo, we got a lot of feedback about how they couldn’t tell what was happening in the game so they weren’t sure where they should be.  They couldn’t tell the king was getting attacked, see where the other players were,  or see where the enemies were coming in or if they were even coming in.  By using audio cues and visual cues, we were able to help the player have a better understanding of what’s happening in the game and when it’s happening.  For audio cues, we added in sound effects for when the players and enemies are attacking as well as getting hurt.  We also added in sounds specific for when the king is getting attacked that could instantly be recognized.  For visual cues, we added in a mini-map, allowing the player to see where everybody is and when enemies are coming in.  These audio cues were able to give a much better feeling and understanding of the current state of the game.


Changes and Adjustments

Necromancer’s ability adjusted

As described in the “what did not work” section the necromancers ability needed to be adjusted from what we initially planned for it. We felt that the zombies attacking an enemy or ally based on chance made it too unreliable. We wanted less thought to have to go into whether or not to use the ability and for it to feel more natural.  For now,  the zombies only attack enemies.  However, at a later time, we would like to revisit making his ability have negative impacts on use and finding the correct balance.

Camera switched 3D to top-down 2D

Initially the camera did not look straight down at the map but at a slight angle. After comments from game testers we agreed that this was not a crucial feature of the game and only made things slightly more difficult to decipher. We decided that going to a top-down 2D style would make it easier to follow and see what is going on around you.

Narrowed down available classes

In the initial design document we had plans for another class called the guardian. This class was removed from the final build. Aside from time limitations we felt that this class was not necessary to complete the game. We accomplished what we were trying to do using the 3 classes that are implemented. We have 3 classes we feel are fairly balanced in that they are all equally useful in gameplay. We feel that the optimal team consists of all 3 classes that we implemented.

Added and adjusted power ups

We made multiple adjustments to the power ups from the original design document. The biggest chance came to the rampage power up. Initially there was just one rampage power but we eventually added a different rampage for each class. The initial description for the rampage eventually became the rampage for the brute. The necromancers rampage now raises all dead enemies on the map and the medic heals your allies and grant invincibility for a short period of time.

Added civilian rescuing mechanic

In the original design document there were no plans for replenishing the number of civilians you had at your disposal. We considered just adding more civilians as you progressed through certain “check points” in waves in the game.  However, we ended up using a rescue the civilians mechanic from around the city.  The player could civilians away from the fountain that could be rescued.  All the player had to do was go to them, and then protect them as they followed him back to the fountain.  Once at the fountain, they wandered around just like the other civilians.

What we didn’t achieve

The main goal that we all wanted and weren’t able to incorporate in time for the finished project is statistics for gameplay.  It would have been really neat to be able to see who killed the most enemies,  who was the most valuable player, and who took the most damage.

What we would change if we could to do it again

Overall, I think what we were able to achieve in the game is still what we want now that we are finished.  However, there are some things we would do differently.  As of right now, our entire game has only one objective, to the keep the king alive.  We would like to spend some time coming up with alternative objectives to be achieved during the game play. We would also have changed the controls a little. instead of having the characters automatically aim we could most with wasd and aim with the mouse.


Comments are closed.