We are here, the end of the road. This moment is bittersweet but it was worth every moment to get here. We as a team were able to band together through all the global issues, setbacks and changes and come through to a completed product that we are all proud to put our names on. The bitter part comes when I realized that this was the last time to work with a team like this. I was honestly spoiled as a design lead, having a team that was able to exceed my expectations but I digress, I could go on about the team, which I'm sure I will later, but here is the result of the completion of the game and the lessons we learned. 

What went right

Communication
With any team communication is an important aspect, ours was no different and we were on top of it as far as talking to everyone as soon as something came up that required clarification. Our team did an outstanding job at staying up to date on their tasks and not hesitating to reach out if the need required it. From our position as leads we did our very best to give appropriate and effective feedback or references to help move our team along in the event we were stuck. Things like tutorials for particle effects or concept art was a huge part of this to help move our team along. Our other task as leads was jumping on every question as quickly as possible, which I believe we really did a good job of.

Cohesion
Because we have been working together on projects in the class and as well as in our major we were all pretty comfortable with each other. This comfort allowed for many of the team members feeling confident to propose ideas or concepts that they believed would benefit the game and the player later down the road. This eventually moved some of the finished concepts such as versions of the models that made it into the game, animation behaviors and some mechanics as well as particle effects. 

Game Play Features
Because of this impressive communication and Cohesion that we had within the team there were several amazing fully fleshed mechanics that made their way into the game. Fully animated and automated enemy AI as well as animated allied units to combat them. The Allied units were fully controllable from a single troop to the max you have at one time. This line of symmetry was continued to the Castle having its two types of attacks to combat buildings and other smaller troops as well as, you guessed it, siege engines. The Siege engines allowed for more complicated combat maneuvers to be performed in order to deal with these. Next we were able to add player feedback in the form of visual effects: particle effects, visual changes (rotating wheels) health bars and sound effects such as cannon fire sounds, arrows flying and wheels rotating. All of this was then compiled into 4 different themed levels that were able to be put into the game, going from the primary Allied City to the Farmland to the Forest and lastly the Forest Ruins.

What Went Wrong

Too Large of a Scope
From the beginning I had high hopes for a game with a team of this size. I realized when we started to work on the project that there was going to be way too many concepts and pieces to get through that we were not going to have time for. This meant that we needed to scale it backwards a little bit. In our first and second sprint we were tackling this as if we thought we were going to get everything we had concepted out into the game when this was just not the case. 
If we were doing this as a full time job and were getting 40 hours a week to get to work on this game then probably we could have implemented all the mechanics and then some however we did not have this so we scaled away about half of the game. Reducing our original design from six siege engines, six enemy units, six allied units, ten levels with personalized assets and two alternate game modes to the game now. The current game has three siege engines, three allied units, three enemy units, four levels and our primary game mode.

Fluctuation in Workload
Part of this was due to the global pandemic and part of this was prioritization. At the beginning of each sprint we had an idea of what we wanted to have in by the end but we didn’t always make this known and there were times when some members of the team ended up with more work than they thought they could do or less work due to the priority at the time. 
The communication at this level did hurt here because we did have individuals who wanted to try and do the work but realized they couldn’t when they got going. The pace of these individuals was overestimated and presented challenges later which we did our best to handle.

Complex AI
Before I begin here, this is not to say our AI was a problem in any way. The way we initially approached this was the problem I want to address here. I was extremely set on having a product at the end of our semester that we could deliver and not necessarily one that I thought may have been fun. This resulted in our game getting essentially a reality check. I failed this part having attempted to restrict the player to a few sets of abilities and complete automation from the game at this point. 
It wasn’t till we received some feedback from our executive producers that I realized we needed to throw caution to the wind and push myself and the team to make a game that was inherently more fun but more difficult at the same time. This then evolved into the RTS strategy that we have now which is my favorite genre to play which made me extremely happy to go this way.

What did we learn

Communication is the Key to Success
As I said above this is obvious for any team to be successful but in this case the lesson here was that we all and observe the same things differently. For some a task that they needed to do was a simple one word and they knew what to do. For others who were working on more complex items a more complete description was necessary to get them on their way. Noticing these differences early would have helped us elaborate in the appropriate ways to get the desired tasks completed but also another factor would have helped but I'll explain that later

Communicate Changes to the Whole Team
I made a rookie mistake a few times when it came to development and this was not the biggest issue until it was which is why I learned real quick that this was a problem. There were a number of times that someone had reached out to me and I had made a decision or told them to take a direction that I felt was best for the game. They would then work on this mechanic and implement it and our other programmers were unaware of this change. In group testing sessions a programmer would remove this feature not realizing that it was a mechanic that I had changed. This is nobody's fault but my own in this case since the change of direction needs to be discussed with the programming or modeling team. Especially when I would not consider myself a good programmer or modeler and a better approach could be provided by someone a little more skilled or if an known error that would prevent that new mechanic from working was present in an alternate script.

Prioritization
We did a decent job of prioritizing ourselves once we passed a certain level of comfort but we struggled in the beginning when we had the huge chunk of game to remove as well as when we moved past that and realized some of the more major mechanics of the game were missing and nobody was working on these. This was then adjusted and framed for the new direction of our game with the corrected scope.

Mechanic Scoped for Specific Instances
An issue we ran into toward the end was that we didn’t take the time to adjust our mechanics for the other levels and focused on keeping our mechanics working perfectly in the first level. This eventually hurt the work that was required for the following 3 levels since the level designers were quickly running out of things to do surrounding the construction of their levels with regards to terrain manipulation and environmental asset placement.

Explain the Purpose of the Task
Every single task had a premise to the game as they should however some were not aware of the intentions of the task they were working on. This was difficult to do without a working model for the game but this is not any time for excuses the explanation of the task should have been given to elaborate the context of the asset, character, sprite or mechanic that the individual was working on. With a working model of the game now it would be much more possible to help point individuals in the right direction if given a second opportunity to work on this title.

Conclusion
In conclusion the game was a success and that is to say in the least. All the hard work, frustration, late nights and nail biting last minute fixes before a build paid off and we have a very impressive game that we are proud to put our names on. Having placed in the ECGA’s in the non mobile category for our game was also a huge bonus and win for not only our team but for myself. I could not have done this project alone so my thanks goes to my incredible team, my executive producers and my producer for helping me create a truly incredible title that completes my first experience leading a team of this size.