Llama Drama, Spit Pit!
About
Llama Drama, Spit Pit! is a tower defense taking place in the Machu Picchu mountains where the local llamas has become filled up with the over tourism and decided to take matters into their own hands
​
This was our first Game Project at Playground Squad. Everyone got divided up to 5 different groups to make a game using the in-house engine, Tengine.
​
With only two designers for an entire game we got to try our hands at a lot of different areas. I can not possibly talk about all of the things I did but below you can read more about some of the designs and decisions I was solely or partly responsible for. Additionally this was my pitch that got chosen so naturally I also had to fill a kind of Project Manager role.
Link to our game on the schoool homepage:
https://portal.playgroundsquad.com/spelprojekt/llama-tower-defense/
Main Role: Gameplay Design
Team Size: 2 Designers, 2 Programmers 4 Artist
Time: 5 Weeks
Engine: Tengine
Platform: PC
Genre: Single Player, Tower Defense
Towers
A necessity when it comes to a Tower Defense is obviously the defense. However, for our game the towers are represented by Llamas rather than the classic towers. In total there are ten Llama towers.
​
The part that makes our Tower Defense stand out from the rest however is that the Llamas the player can pick from are always random. Out of the entire pool of Llamas, between each wave, the game will pick four at random which is the selection the player can pick from.
There are however some rules behind the scenes to avoid having the player unable to build anything the first few levels. All of the llamas are divided into three different tiers, where the first tier is generally weaker but also less expensive, while the third tier represent the opposite.
Using this tier system we can force the game to pick at least one tower the player should be able to afford with each wave.
​
While this does not make the llamas completely random we avoid having the game feel unfair, but we still achieve the main idea of why they were random in the first place. One of my biggest issues with the Tower Defense genre is that once someone figure out the perfect recipe anyone can beat the game building the same kind of Defense.
By having the selection of towers be random between each wave there is no longer a recipe to success that works every time. Instead the player have to consider what they build, where they build and also if they rather save the money and hope for another set of towers after the next wave.
​
Another additional benefit is that every new playthrough is somewhat different to the previous.
To move on to the actual Llamas themselves. I will briefly talk about some of the towers in each tier.
The Vampire Lama. It is one of the fastest tower in the game, but also the cheapest. It does however have a rather short range and weak damage.
The King Llama. This tower is noticeably weaker than the other towers in its tier, but what makes it different is the passive effect. For each of these towers the player own they will get additional gold at the end of each wave.
The Christmas Llama. Once an enemy is hit by this tower they are frozen for a short period. The trade off is that it deals very low amounts damage, and the frozen effect does not apply to boss waves.
The Angel Llama. Most expensive tower in the game.
To begin with the tower was intended to work much like the Gold PP7 (Golden Gun) from Golden Eye 64, with a slow rate of fire but instantly kills any enemy hit. However it proved to be rather difficult balancing it so that it felt worth the cost, but did not instantly win the game we removed the instantly kills function and instead gave it incredible range.
UI
For the UI it was decided early on that we would try to keep everything needed consecrated in one area in order to obstruct the view as little as possible, but also to make sure the player do not have to go all over the screen when she wish to take an action.
​
Different positions for the UI block were tested in a prototype I made.
Eventually we agreed that placing it on one of the sides felt more convenient and less obstructive than top or bottom.
The reason as to why it is on the right side it because enemies spawn from the most left side of the world and moves towards the right.
So having the UI block on the right meant it would obscure vision of the enemies less often.
​
At the very top the player can see the amount of gold she currently have, as well as the remaining number of lives. Each enemy that slip through the players defenses results in one health lost. Boss waves deal more damage.
​
Below follows a row of towers that were randomly selected for this wave.
Hovering the mouse cursor over a Llama portrait will display more information about that specific Llama. Damage, range och any special ability like slowing down movement speed of the enemy can be found on this pop-up panel. This feels less cluttered than if we were to present all this information, at all times on the screen.
​
At the very bottom is a picture of one of the tourists which would also display a number equal to the current wave, and next to that is a button to start the next.
Prototype
The last part I want to bring up about Llama Drama, Spit Pit! is the prototype we used and how incredibly helpful it was.
Since all groups had to make our first game project in Tengine we were also limited to what Tengine has to offer. And it is not use friendly.
​
Compared to probably the two most well known engines, Unity and Unreal, Tengine lacks in a lot of areas. Especially when it comes to time and efficiency to throw something in there and just test it.
Which is why early on I made a very simple, ugly but functional prototype in Unity. Pretty much every part of this game was first made, and tested, in said Unity Prototype. Every Llama, enemy, track layout and UI location/function first got tested in the prototype before we decided if it was worth the investment of putting it into the actual game.
​
The algorithm that pick 4 random towers from the bunch is something I first wrote in the prototype that we moved over to real game with very little change to the actual code, only the necessary changes that are required when you take code from C# and move it to C++.
​
I believe without the prototype the game would never have reached the same level of polish as it did. Considering the ability to place towers, have those tower attack enemies, and enemies that followed the intended path was something we did not have until mid week 4, we essentially gained weeks of testing tower balance before that we would otherwise have been able to.
