Catapult
Who doesn't like catapults?
Dev team size: Four people
Time spent on Project: Three Weeks
My role: Lead Designer & Programming assistant
The simple but enjoyable design
The creation process of Catapult was quite the unique experience when compared to other teams I have worked on. The main reason for this was the time we had to not only come up with an idea, but prototype it, test it, and update/finalize it. For this whole process we had only three weeks. Knowing this time limit it we all decided to create something simple, but still enjoyable in its simplicity.
Thus one day we held a meeting where we brainstormed for hours on end writing down all of these possible ideas that we could create during the allotted time frame. We used random game name generators during this process to help us further brainstorm potential game ideas. Having created a list of around 50 game ideas, we began going through each one and either keeping it or removing it based on the name alone since we didn't have time to waste thinking of all the systems and mechanics that could go into each one of the 50.
After about 30 minutes we got the list down to about ten games. This time however we spent a little more time on each game skimming the surface each title via what would the game be and would it be enjoyable to the selected player base? After 45 minutes we cut the list down to three different game ideas. We took a little bit more of a dive into what these games could become until we all voted on one game, Catapult. Although it was quite different in its first concepting phase than what it became in the end.
The Process of elimination
We now had a game that we all agreed on making and so the design process began. From the start we knew that we wanted there to be two different sides each with their own base and catapult. For simplicity sake we just made it the blue team vs the red team. Now with some basic game structure we started going more and more in depth as if forgetting that we only had three weeks in total to make this a playable and testable game. We wanted to have a wide variety of different ammo types, customizable bases, and even an AI the player could test their new builds and learn the ammo types on.
Yet, overtime given many unforeseen complications with coding we had to cut many of the gameplay aspects we some desperately wanted to add. Thus we all held a meeting to discuss what we wanted to keep and what we wanted to remove at this point. Given the nature of coding customizable bases and how long that would take based off what our programmer told us, we wouldn't have anywhere near enough time to add such a feature.
Therefore, we all agreed that at this given point in time we would place the customizable bases on the backburner and would work on more pressing matters such as finishing the game loop. Thus with the removal of this feature we all marched on in hopes that would could at least get the other two desired mechanics and systems into the game in time.
We soon realized that the AI would take to long to program and thus one more system was eliminated. Despite, these loss of mechanics we still believed that we could implement the different ammo types that we had planned from the beginning such as an explosive shot, triple shot, and a sniper shot.
Although much like the other features we had remove previously we simply didn't have the time not only to add them, but the large chunk of resources it would take to balance each of these shots in game. The design team was willing to take the task on already we had discussed a variety of different ways to balance out the ammo types such as a limited amount of each, a point system, and how they reacted to the wall types within the game. Sadly though it wasn't meant to be and with only a week left we didn't have the time to test all of these changes.
System Design:
Yet what remained?
With all of these cuts to gameplay and the overall content of the game what really remained of the once great concept of Catapult? Well, there were a couple of key mechanics and systems that despite our many challenges we were able to implement to a degree that for those who tested the game quite enjoyed the experience. These elements were the aiming and firing systems, the domino destructibility of the bases, and the strategy of how best to pick off the enemy's dragons.
The aiming and firing systems were simple enough for any player to understand. Once it was the players turn they would use the arrow above their catapult to angle their shot. Unlike other games similar to catapult we decided on not implementing a guide line for we thought it would ruin any difficulty the game made the player to endure.
Thus unless rather skilled an knowledgeable about each angle and were the shot would land, the players didn't quite know where their shot would end up. Which makes sense given that back in the medieval ages they didn't know exactly where their shot would land, but would aim in accordance to where they wanted the shot to go.
While aiming their shot the player could also decide on the power of the shot which was represented by the expanding or shrinking arrow. The larger the arrow the more power the player was given to their shot and vice versa for the smaller arrow. Although we made sure that the player couldn't shrink the arrow to where they could no longer see it.
Once the player was satisfied with where they were aimed they would click to launch their shot across the map and towards the enemy base. Given that we only implemented one ammo type we had plenty of time balancing how the shot would function in correlation to base damage. I sadly don't have precise numbers on their coded interactions, but the shot would react with the pillars and roof sections slightly differently.
The reason for this was that each was given a different weight number and thus the higher the weight number the more force was required to move said pillar or roof piece. This was done to create a more dynamic play field where different pieces that made up the bases reacted differently than others and thus it wasn't just same reaction each time a shot hit an enemy base.
Therefore, the more experienced players would still have a challenge taking down enemy bases and not just crush everyone they played against.
Furthermore, these differences in base pieces was created not only for more dynamic play but was also a part left over from our desire to add in customizable bases. Yet, with all of this a large issue remained and that being the first turn advantage that the blue team has over the red team. We tried multiple solutions to this problem such as the first player didn't have as much of a angle and power range that the second player did thus shrinking their possible choices of attack, but that felt unfair and restrictive. We also talked about implementing a timer to add pressure the first player to spend less time aiming and thus would increase their inaccuracy, yet that just gave the second player the advantage. We soon fell into a design pit where almost everything we talked about implemented switched first turn advantage to second turn advantage. Sadly we never could fix this issue for we ran out of time to implement any possible balancing changes.
Despite it all
Despite all of these losses of mechanics and systems the core gameplay and being unable to implement a fix to the first turn advantage we still created an experience that players very much enjoyed. This proved to us that we had a least created an enjoyable experience despite it being rather simple and having known flaws, which was the goal all along. For during those weeks of constant gameplay cuts and balancing issues we still worked hard on creating and designing an entertaining game that anyone could pick up and enjoy.