Critical Analysis: Tower Defense

Tower Defense

For this proof of concept we chose to create a futuristic tower defense that incorporated event systems. The event systems would control the use of turrets and when you could unlock them. Rather than using a 2D setting we decided to use a 2.5D setting to show off our towers and enemies. We wanted to go with a more futuristic theme for this game because it felt like that medieval had been used up. The enemies followed a set path to come and kill your base. There are 3 waves all with different enemies and turrets that can be used to kill these enemies in order to protect your base. 

Our original idea for this game was making the tower defense game into a multiplayer. So how would this work? Well at first we wanted to make it so that one player was the defending team and the other was the attacking. Using fog of war to mask the players intentions and strategies, we would have rounds where the player place the attck and defenses. The attcking player would declare which lane and how many troops and the defensive player would place the turrets where he/she saw most fit. after about thirty seconds the round would commence like a normal tower defense. 

This seemed like a great idea but we decided that we were biting off more than we could chew. Reason being is that we would have to create strategies for each and balance out each side so that there was a reason to play both sides and so that they were both fun. We also didn't know how we would implement event systems for each of the player simultaneously. 

We then discussed creating a tower defense game like plants vs. zombies. We weren't too satisfied with this idea because it didn't seem fun and not all that challenging at the time. So we decided to scrap that idea all together.

With some further thought and brainstorming we came up with just doing a regular tower defense game with a futuristic twist. The reason why we went with this idea was due to the fact that we believed that we could make more out of simpler game than we could out of a complex one. So we stuck with a more traditional based TD game.

Some of the thing s that we changed during implementation were drag and drop from a spawn point; Unlocking system based off currency, and having a boss level. 

The reason why we change the drag and drop was because or main coder, Vivek, knew of a better and more efficient way of doing this type of code. I stead of dragging from a spawn we decided to make it so that when we pressed a UI button the prefab would be instantiated onto the mouse coordinates and would follow the mouse until it was placed. This proved to be more effective as well as impressive/slick.

The other thing we changed during building/implementation was the unlocking system. Spenser was tasked with creating an unlock system which was based off the currency the player earned. So initially we wanted it so that when the player had collected 30 coins from killing the enemies they would be able to unlock the next tier of towers for them to use. However, with lack of time we were not able to implement this mechanic even though it was really cool and used event systems. So instead we made it so that when the player completes the wave the player unlocks the next tier. 

The other notable change that we made during building/implementing our game was having a boss level at wave three to show the capabilities of the turrets. Do to lack of time we just scratched that idea due to it not being that important in the grand scheme of things. 

With all this said there were some real strong points within our proof of concept. One of the major strong points was the implementation of waves and giving the player the ability to start the next wave at their own leisure. This was done by Vivek. It was great addition to our game to really give it the feel of a tower defense game.

I also believe that the turret tracking was another one of the strong points. Reason being is that its not all that easy to code and if it doesn't work then the game will suck and no one would want to play. It alos makes the game feel more complete even though its just a proof of concept. It shows that we have most of the main mechanics down that can be elaborated on.

Lastly I think the main strong point was the point and click to drop the turrets. This was some really hard coding that Vivek and I attempted together. We were able to complete it to give the player that sense of control and strategy you get from playing TD games. Because its based solely upon where a player places their towers. This mechanic really made the proof of concept feel accomplished and makes me want to come back to it and work on it again. 

I am really happy with how our proof of concept turned out. It was hard work but we got it done due to the work ethic of our group and the drive to want to make it better and fun. We had a lot of success in terms of implementing the main mechanics of what makes  a TD game such as the waves, drag and drop of the towers, the unlocking of the towers, etc. I feel like this is the most complete proof of concept due to all the major mechanics we completed for our game. This is definitely a game i would like top come back work on because it seems very promising.  

   

Proof of Concept: Tower Defense

Tower Defense

For our fourth and final proof of concept we were given the options of creating a proof of concept that incorporated the following archetypes:

- Tower Defense

- Sports Game 

- Management/Simulation

We decided to go ahead and attempt to create a fun and functional tower defense game. The reason that we chose the tower defense archetype was because we had to implement event systems into our code. We thought that the tower defense game would present more opportunity to use them more and use them effectively. We also really wanted to do this archetype because it seemed more fun and achievable in the time frame that we were given.

For this proof of concept my responsibilities were team manager and coding. The responsibilities were a little bit slimmer for this proof of concept because a lot of the code tied in with each other which made for large pieces of work per team mate. As the team manger I made sure that another trello board was created to ensure that everyone knew what they had to accomplish for the proof of concept. I also stressed to my group that it needed to be used more because during our previous proof of concept it was used very little. Consequently, it made things difficult in terms of figuring out what was done and what needed to be done. I also created another google drive folder for our group so that we had place to put our new work for our new proof of concept. Over the course of these proof of concepts, the google drive and the trello boards have made such an positive impact on our organisation and time management. It has kept us on track as well as organized which is key for success in any group environment. 

I also held two group meeting during the course of the proof of concept. The first one was the day after we were assigned the proof of concept. During that meeting we started with our usual brainstorming exercises to come up with a lot of ideas so we left no stones unturned. During this meeting we were able to come up with what kind of archetype we wanted to do as well as where we wanted to head with it. For our second meeting we made a lot of changes to the initial idea that we had. This was crucial because looking back on what we had previously I do not think that we would of had something to present with the time frame that we had. After finalizing what we wanted to go forth with we then divided up the tasks equally. 

Some challenges I faced this week was the lack of communication between myself and another one my group members. It has been a very busy week in terms of assignments and I have no doubt that this person was very busy. I did try to reach out to make sure that things were being done and that this person was in track. However, I got very minimal responses. For future projects with this individual or with any individual that is lacking communication I think will approach the matter differently. Perhaps having a separate meeting with the individual so that I can express my concern and hopefully get across that communication is key in group.

My other responsibility for this proof of concept  was coding. The coding that I did for this concept was the enemy movement and the spawning of the enemy. So in a typical tower defense game you have the enemies that follow a path towards "YOUR" base. So what i had to do was create the path on which the enemies would follow as well as where they would spawn. 

For the movement of the enemies I wanted to make them move more organically in terms of turning corners  and making them seem like they were on a path. So to do this I used some code from the boxy assets package as well as my own to create movement of the enemies. Using waypoints and speed I was able to create the organic movement that I wanted. I used multiple waypoints in a consecutive fashion to create the smooth organic path.

I did not have any troubles with this code due to act that i have done this type of code numerous time so I recycled and reiterated most of it.

The next part of the coding was the spawning of the enemies. So we had two paths that merged into one, so I had to create two spawns that would spawn the enemies. Using arrays and for loops i created a spawn script that allowed you to create a set amount of enemies that you wanted to spawn and then then delayed the time between them so that they didn't spawn all at the same time. I used an Ienumerator to do that. When the enemies spawned they would then follow their set path. 

The trouble that I had with this part was the delaying of the spawn. They just all spawned at one time which was a pain. So I looked up on the unity forums to figure out to best solve this problem and i wound up learning how to use ienumerators. This turned out to be very helpful because before this I did not know how to use this type of code or know what it was used for. So now that i have a pretty decent idea of what it is and does i would like to implement it more into my code seeing how useful it turned out to be.

I am very happy on how this proof of concept turned out. It was a lot of fun to work and I think we have made the most progress on this proof of concept than we have on the past ones. If I were to visit this project again there would be quite of changes that I would make to this game to make it a fun and playable tower defense game. 

the first change/implementation of this game would be adding in upgrades for our turrets. Yes we have the upgrade of turrets from light, medium, heavy. But what I would like to implement is an upgrade hierarchy to each individual turret. So I would like to emulate the type of system that Bloons 5 implements. In terms of having different upgrades/abilities/versions of each weapon they have. It makes the game more fun a makes the player strive for the better upgrade to get a better score. 

The other thing I would like to implement into our game would be different levels for our game. I find it to be boring just having one set path that never changes. A possible idea for a map would be having a moving map so in some instances the path would change and the enemies would travel to a different location based on how the map moved. 

Another thing that I would like to implement would be a more complex currency/economy into our game. Having this would allow us to dictate the unlocks a player gets to the amount of coinage an enemy drops. This would give us a more balanced game would make it a more complete tower defense game. 

All-in-all I am very happy with how our last proof of concept turned out. My team has done a great job and has done a lot of great work over the past 4 weeks and i can honestly say I would pick this group over any group due to the work ethic and the drive of wanting to do and help more. Its a blessing to have such diligent workers.