Project Details

Development Time: February 2017 - March 2017
Team Members: 5
  • Aaron Sutton - Game Developer

  • Jesse Baker - Game Developer

  • JohnLee Cooper - Programmer

  • Justin Capcap - Level Designer & Artist

  • Matthew Murchison - Artist

My Roles

Game Developer

  • Created and updated documentation throughout development

  • Designed and created gameplay mechanics & functionality

  • Created and implement UI

  • Designed and created 3 game maps

  • Created, adhered to, and reached all set deadlines and project milestones

Tools Used

  • Unity

  • Unity C# Monobehaviour

  • Microsoft Visual Studio

  • Visio

  • Adobe Photoshop

Design Challenge 

Create a turn-based game where your actions change the way the player interacts with the battlefield

Project Overview

“Stacktus” is a turn-based artillery game, where 2-8 players take control of their own tank and try to defeat their opponent(s) by damaging them with cacti, or bouncing them into cacti-stacks with watermelons. The cactus projectile will immediately stick to any surface it touches, while the watermelons act in the complete opposite way, and bounce off any surface they touch. The game was developed “game jam” style over the course of 3 days, before we decided to polish our original idea further over a 5 week development cycle before reaching our final version of Stacktus.

 

Features that were added in during our second development cycle include:

 

  1. The ability to cling to the walls and ceiling of a level

  2. The ability to adjust the power of your shot

  3. Cacti growth where the cacti on the level will grow to different stages and deal more damage over time

  4. Breakable platforms that break when there is too much weight placed on them

  5. Exploding crates that bring an explosion of cacti and watermelons when hit with a watermelon

  6. Bouncy and slippery platforms

  7. Instant-kill pits

  8. 4 more unique worlds and 8 more unique levels

My Development Highlights

The Stacking of the Cacti

The original idea for Stacktus was when one of our team members (Jesse Baker) came to our design plan meeting with his sketchbook and showed us a drawing he had done of a person getting a cactus stuck to them. When he said sticky cactuses could work as a fun gameplay mechanic, and as we talked about the possibility of working on a tank game, the weird mashup of ideas was something our team could not get out of our heads. One of my jobs for the game was to design and implement the base of the cactus projectile’s functionality e.g. how it stuck to walls, how the stacking, and dislodging worked.

 

 

 

 

 

 

 

 

 

 

 

 

I completed this by creating rough diagrams and pseudocode to help illustrate their range of capabilities and reactions. The cacti would react using physics and impulse forces once fired from a cannon or dislodged from their stack, freeze their physics upon colliding with a wall, link themselves to other cacti if frozen and touching other cacti in order to create chain reactions, and would damage other tanks if they collided. Once my teammates approved the design from my diagram, I moved on to the technical development and implementation.

Working as a Cohesive Team

My team and I developed “Stacktus” in our second year at Sheridan College. At the point of developing Stacktus and throughout my 1.5 years in the game design program, Stacktus had been the only team that I found to work effectively and cooperatively enough to make me feel as though I was working on a real team. Stacktus was a major leap forward for me in terms of my professional development and understanding of team dynamics and working relationships. The biggest reason that my group was so successful was because we communicated clearly and consistently at every milestone, and built a schedule with evenly divided tasks that played to each team members strengths at the beginning of development. Each member was assigned roles and tasks that were meaningful to them, with set dates for deliverables which everyone stuck to. These project management skills that I learned when working on Stacktus were traits that I carried with me and improved upon for every project after, and set me up perfectly for my role as a project manager on our capstone game “Spirits”.

Process

Gameplay - Mixing Strategy and Party Elements

Stacktus was first and foremost designed to be a strategy game, but once we added the ability to play with up to 8 players it became apparent that the true core of Stacktus was a mix of a strategy & party game. The reason Stacktus could not be 100% strategic is due to the slow nature of building up the cacti around opponents. In order to deal significant damage, the player must allow the cacti to mature before knocking them onto the other players and as a result it the standard player most often found it difficult to strategize 4 turns ahead.  The opponent always has the option to move and block your attacks within those 4 turns, often changing the gameplay strategy after each turn. In order to make the pace of the game a little faster, and to allow for more exciting moments, we decided to add more party elements to the game such as the breakable platforms, bouncy platforms, slippery platforms, explodable crates, and instant-kill pits.

 

Our playtest sessions after adding in more party elements resulting in far more satisfied player experiences. The game progressed from the hardcore chess-like gameplay that the original prototype went for, and our players appreciated being able to take advantage of the new mechanics as opposed to just the cacti and watermelons.

Level Design Process - From Paper to Engine

After deciding what our new party-style mechanics would be, we moved on to designing our new levels. I often started by writing a list of interesting ideas, interactions, or ways to use the new mechanics, before moving on to mapping possible level layouts on grid paper, and then building and testing the levels in-engine. To me, the process of documentation, to design, then to development, allows for the smoothest integration of unique ideas and I believe is integral to creating a solid level. However, one thing I learned throughout working on Stacktus is how this process may not work for everyone and that the most unique ideas sometimes come from just playing around, testing limits of mechanics, throwing random elements together, and then fine-tuning.

 

The creation of our levels in Stacktus was extremely simple. In order to get our level and mechanics to function for most items, all that needed to be done was to drag the assets into the scene and then to tweak some values. With such ease of use, our programmer JohnLee, would throw together the weirdest levels in order to test out his mechanics. Often they would fail, but sometimes they created the levels that playtesters loved most of all.

 

Through the development of Stacktus, I learned a process that worked for me, and came out with the bravery to let my mind loose thanks to the lesson from JohnLee. Sometimes the best level design comes from unconventional thinking, so long as it is fulfilling its purpose.

Challenges

Rethinking the Game of “Tanks”

 

 

 

 

 

 

 

 

 

The main source of inspiration for our game came from a web-based flash game called “Tanks” that everyone on our team remembered playing on our school computers as kids. Tanks is extremely similar to Stacktus in many ways. One of the main challenges we faced was trying to differentiate ourselves from Tanks while still being able to capture the essence of what made Tanks so fun for us. We found early in development that the main similarities between our game and Tanks were that they are both artillery shooters, turn-based, use fuel as a movement limiter, and have attacks that change the environment. We decided to take those main similarities and kick it up a notch by twisting and reworking their use in order to make a more modern game.

In the end, I’d say we twisted all aspects appropriately. Our game is now an artillery shooter party game, the turn system has people reacting to change as opposed to Tanks more strategic outlook, uses fuel as a movement and attack option, and has attacks that become part of and grow the environment compared to Tanks destruction and removal of terrain within the environment. These change-ups combined with our other special mechanics and twists, I believe allowed us to create a unique game within the artillery shooter genre.

Self Reflection - What Could I Have Done Better?

  • Remove turn-based gameplay: The turn-based gameplay of Stacktus ended up being a major limiting factor as we continued to develop the game. Once we moved onto balancing the game for eight players, we quickly realized that it takes too long for a full rotation of players to occur and made the game move at a snail's pace. The game would have benefitted from experimenting with the removal of the turn based elements and making it a full on multiplayer action game.

  • Refine the physics: The physics involved in both the breaking of the stacks of cacti and the bouncing of the players with the watermelons didn’t work as well as hoped. Half the time, the cacti wouldn’t move as far as players would expect them to when knocked off a stack as they would collide with each other and end up going nowhere. Bouncing yourself off the ground with a watermelon for fast traversal was also not accurate and felt like a bit of a gamble. It would have been best to take the extra time and refine these interactions more.

  • Better mix the party & strategic elements: After going through our second development cycle, Stacktus could have almost been considered a full on party game with few strategic elements. Although this did make our game more fun to play, I think the game would have benefitted from throwing in more mechanics that made the game more strategic, in order to find a perfect blend between the two genres.

Project Critiques - Where Could the Game Improve?

  • The levels need more direction and guides, as they were too open ended and easy to get lost in. This could be done through adding more landmarks, clear pathways, and decreasing the size of certain sections.

  • Controller settings and difficulty - although I added a lot to make this customizable, I wish I added more, such as the ability to change the color and visibility of your HUD, custom cursor speeds and sizes, and changed how fast the snowball would move on different difficulties as it moved too slowly to accommodate new players.

  • Optimization - the game ran around 27-30fps and dipped to 24fps in certain sections of the game, I needed more time to polish. I could fix this by learning how to use the profiler, seeing what’s creating frame drops, and cleaning up some of my shaders.

  • UI and UX - The UI screen had too much information and detracted from the UX. I could fix this by only conveying certain information when it is important to, and by moving different pieces to be diegetic UI.

  • Refactoring pieces of the game after I learned how to use both Unreal and the robot better. The snow trail shader, destruction meshes, and overall blueprint code structure could be remade to be more customizable.

Stacktus : Case Study