Initial plan vs final product

When we first thought about the game and what we wanted to add we created the following list:

• Tower Defense Game
• Tile based
• Limited amount of towers
• Multiple tower types
• Multiple enemies
• Money is earned by killing enemies and beating waves
• Upgrades to boost the towers already placed
  • This should also be the main way you get stronger and beat later waves
• Global resource to upgrade towers permanently

As we can see we ended up adding everything we wanted to add except for the global resource for permanent upgrades. This got dropped as time constraints did not allow for development on it to happen.

What is left to do?

While the game mechanics are there and technically the game is fully playable there are still things we wanted to add if we had the time to do so.

1. Adding Music! This is something that would be necessary to consider the game "done."
2. Adding the dropped global resource and permanent upgrades
3. Adding more towers, enemies and maps
   3.1. The foundation of the game makes it easy to add content like this but we had to focus on other things so we couldn't add more than we have right now.
4. Further reviewing balance
5. Potentially adding a way for players to add their own Maps -> introducing an Editor outside of Unity
6. Linking the wiki accessible in the game to the online wiki ensuring the validity of the information
7. Adding more and/or adjusting current assets
8. Difficulty settings
9. Other kinds of rewards
   9.1. Achievements
   9.2. Cosmetics

Lessons learned

On Lucas

One heavy lesson we had to learn is that we should communicate more with our lecturer and our team members. As referenced earlier in the team introduction we had a team member leave us.
Lucas was our third team member. Early on he struggled with getting used to Unity and the whole environment associated with it. As the project went on towards the playtest in December all the code, he could add he wrote with a lot of help from the others. Towards the end we learned that he mainly worked from Monday to Wednesday which explained why it often looked like he just started working on his tickets when we met every Tuesday. We then had an internal meeting where Lucas thought about leaving the group. We told him not to and he should instead try and focus on writing the documentation. This way he could add to the project without having to add to the codebase. From that point on his sole task was to write the documentation. Unfortunately, we felt that even for that he did not do what he could have done compared to what we achieved at the same time. Therefore we asked for an additional meeting to discuss this issue. Before the meeting he messaged us and told us that he would leave our group and not attend the meeting.

This escalation could have potentially been avoided if we had mentioned this issue a lot earlier and could have properly discussed this as a group with Mr. Schubert.
We also should have more clearly discussed our time plans to not assign tickets that require other tickets to be finished.

Other things we learned

Max

I learned that working on a large project like this requires a lot of coordination and communication with the team which was not always my strong point.
I also learned that I still struggle with fully grasping maths which has caused issues on multiple occasions throughout the project.
But as a positive I learned that working on a game can be a lot of fun even during times where it feels like the work doesn't end you can receive a lot of joy seeing you code work the way you envisioned it.

Valentino

I learned that if you plan out your software properly and think about how things are going to work development and coordination in a team can be much more efficent. It also helped us build a solid core without us having to do rewrites of core components of our game. Once we had that solid foundation it was very fast to develop new towers and expand upon it.
I also learned that while i am pretty good at coordinating our team i am not as capable in "human resources" type of tasks and that our attempts of solving problems internally should have ended earlier. Also we should have set much more clear expectations for our team members and communicated them to them.
Another thing i learned that sometimes you have to shift your focus from the game itself to the documentation and other things that are not directly related to the game if the "customer" expects it.
And of course i enjoyed working on this project and i am happy with the result we achieved even though we did not finish everything we wanted to do.