Some challenges of having so many people working on a team seem to be that there are so many moving parts, that it’s sometimes hard to see the goal as all of these pieces are moving, and not always cohesively. As a student of design, I have come to terms with the fact that the original concepts are almost always better in your head than in actuality. That said I have discovered some fun and interesting concepts within the past two playtests and through these sprints to be able to add into our game.

To reiterate, our game is a real time strategy (RTS) based game in a Tower Defense world. The concept has recently shifted to incorporate more features and concepts of the RTS genre including such features as unit control and micro/macro controls and steering away from rigidity and confinement of player control. This decision was due to the most recent playtest as well as the prior playtests that had told us the same information but in two different ways, which I will get to later.

First to discuss the progress of the game in its entirety I would like to start with the developments of our team 2D artists. They worked hard this last sprint to get us as much concept as they could on level design assets mostly for our fourth level which is a forest ruin map that begins to tell a little bit of narrative as the player progresses through the game but also with UI as I will show below. 

From the images above we are hoping to give the player a feeling of being in a lost civilization, perhaps too advanced for their time, however, they no longer exist and nobody knows why. The scope as to why is left to the players imagination as it is never mentioned or covered in the span of the game. Following the themes above the alternate task for our other concept artists included pieces of our UI, as shown below. 

In this current state I was happy with the way our UI was beginning to shape up and the original concepts of the UI were still able to be shifted to adhere to our new concept with the RTS style. The image above is our in game resource bar, meaning that these are the resources you will be paying attention to the most, when in game. The section above is actually going to be placed in the top left corner of the screen to allow the player to always have an eye on these stats since they are valuable in more ways than one. The top red bar is the castle's health bar, that will decrease as the player’s castle takes damage. The second is the food amount that is given to the player which will auto increment and decrement with the spawning of troops. The rest of the UI is in the process as a large panel across the bottom of the screen to house all other useful information.

The Modeling department this sprint was chugging away at models that were necessary to not only the gameplay but also the environment. This was especially important as we moved forward since we needed to ensure that the levels were getting the necessary models completed and the tasks were moving in the right direct

  ion. 

Above is a bridge necessary to cross the large gaps seen in the first level, this same concept will be applied later into level 4. This bridge, environmental in premise, is important to show the art style and also the theme of the first level. Also above is the model of the enemy goblin Stronghold that will be the enemy base of operations at the end of the level. This large structure relays the concept of the enemy power in showing the player what the pinnacle of the level will be. Below is our finished low poly version of our enemy ranged unit, “The Slinger”. This unit will be vital to showing the player how to combat alternate enemy types as well as function as the enemy ranged tower operators, holding few of them on top to combat allied units.

nits.

To move toward Level Design, I saved this for later since it incorporated a lot of programming elements so it’s only fitting that I talk about these together. With each of the level designers I had them placing the enemy buildings and baking NavMeshes on to the levels. The NavMesh is essentially laying out where the AI knows they can move. In places where there is no NavMesh or the mesh is broken between it there is no way for the AI to cross that path. The Level Designers tasks were to take these broken paths and connect them together to eliminate the possibility of errors.

The Programming within this duration of the development phase was aggravating to say the least. There were a number of setbacks that caused us to be a little farther behind than normal and this was to no fault of our programmers which is the root of the problem. Having an intelligent RTS AI was definitely a tall order for those of us who have never messed with AI before, with errors that were causing a number of setbacks I have nothing but the highest respect for them all sticking through it and developing at least a halfway working AI that tracks and connects with enemies but does not kill them at this time. In regards to animation we had a difficult task of getting our rig together but its now in one piece and we can now place our animations on the models and move forward with our animation pipeline. 

Coming to the playtest, we had a few features that were not able to make it into the game such as the completed AI or many of the models that we had completed. There were a lot of things such as the camera movement, UI feedback, castle health and other playability issues that caused problems with players enjoying the game to the full extent of the mechanics we had initially set up. Alternatively we had two builds that show several of the mechanics we wanted to show but they were not combined therefore there was an issue with the builds sharing the mechanics to show them all off at once. 

In conclusion we have a lot of work ahead of us with balancing the mechanics in the game and playtesting with new users and feedback to derive the game that best suits the players but we are prepared to take on the tasks necessary and learn new things that will make our game amazing.