Tanks With Hands was my first proper commercial product ever released. It was the product of a summer course held at Kajaani University of Applied Sciences which lasted for two months. When the project started and we had our team formed, we sat down to brainstorm. We quickly settled on the idea of an action game in which you control both of your arms independently using two joysticks. We had a bit of a problem, though. Because we were using both the sticks to move the hands, we didn’t exactly know how to move our player character, of if the player would move at all.
Then, I almost jokingly said: “What if the guy had like treads instead of legs, so you could also control each tread with bumpers and triggers just like in some older tanks?” For some reason, the idea stuck and the premise of the game was born. We settled for local multiplayer because we would get a lot of content with relatively low development time. We’re all students at this point, so we needed to scope our project with everyone’s capabilities in mind. Little did we know how many UX problems this game would have at this point. Before we start, though, here’s the basics on the game I wrote back when we started.
High Concept
Wacky physics based brawling! Wield ridiculous weapons, wallop your opponents with ragdoll arms and steer clear of hazards. Control both of your arms and treads with each side of the controller.
Features
- Physics driven animation and gameplay. Players control both of their arms separately, trying to make best use of their current weapon.
- Defeat your opponents by flailing your weapon at them or knocking them into environmental hazards scattered around the map.
- Dodge environmental hazards with tank-like tread movement. Each side of the controller moves the respective tread.
- Many wildly different maps, each with their own way to achieve victory. Maps have their own visual themes with matching props.
- Loads of different weapons to pick up in each map. Each one handles differently and requires different inputs for each arm to swing efficiently.
- Several fast paced rounds are played in succession to determine the overall winner. Maps rotate in cycles.
Some mistakes
The initial concept of the game would also be the downfall of it. The game for us, the developers is still fun to this day, because we actually know how to play it. For others, it’s a different story. The control scheme is so, so alien and takes time to learn. Being a party game, it should be easy and intuitive to play, but in our case it could take upwards to an hour to see meaningful play emerge. Almost all parts of the game would be misaligned because of this fact. But hey, it was the defining feature of our game, we couldn’t change it!
The first thing I started designing were different control schemes. From the get-go it proved to be a challenge. As soon as we had a proto of the controls, it was difficult to get a proper swing going and we knew we had work to do. Especially when we combined the unusual movement with the weird combat mechanics, we knew something had to be done. At a later stage, I arranged some playtest sessions, a station to play the game in, a feedback form, all the good stuff. We got the feedback we expected and we saw it during the test, people were having trouble playing the game.
The first major mistake in the project was being too much in love with the initial idea and being afraid to pivot to something new. Looking back on it, it was a great lesson to learn to be more critical of yourself and the design of your game. I wish one of the testers had slapped me in the face and told me straight it was impossible to play. I think we were too conscious about the schedule and thought we didn’t have time to re-design and implement the controls as well. In reality, we should have re-scoped the project in order to be able to re-design the basis.
Now that we got that cat out of the bag, let’s move onto some of the actual systems and design that went into this game. I promise it’s not all doom and gloom!
Design pillars
- Anyone can pick up and play the game, understand the goals and have fun in a matter of seconds
- Innovative controls keep the players interested and provide a smooth learning curve
- Fast paced and mindless fun everyone can enjoy and appreciate.
- Hilarious physics-driven moments with players getting punched, slashed and punted everywhere
I had the right idea, at the very least. At this point in time I didn’t really know how to establish player stories to support the pillars, so I didn’t.
The design and my role
We wanted to keep the game child friendly, so very early on we decided to cut all plans to include bladed weapons. Instead we enforced the physics-based nature of the game by tying the blunt weapons to a knockback system that would become an integral part of the game.
The game works on a round-based system. Win enough rounds and you win, basic stuff. Everytime a round is player, the level changes. The levels are separated into map sets, each set containing about 5 levels. Each set has their own mechanic/hazard and the first level introduces it in a fairly safe way. Then when all levels of a map set are played, the map set is rotated out for a new one. The same map set can’t be played until all other sets have been visited.
The design ethos was that even though levels have hazards, they should be fairly trivial to avoid. The only reason a player would die to hazards was if another player pushed them into the hazard or prevented them from escaping it. See, the game has a HP system, but really, it is all about getting space, pushing people in and out of places and using level design to your advantage. Most maps have power positions you want to control, but in order to control them you need a good weapon. Weapons and power positions are never in the same position and better weapons are further away. It becomes a decision on if you want to get an ok weapon and defend your space, or get a really good weapon and try to invade someone else’s space. I wanted each level to include at least a few different ways to win.
This was the main loop of iteration and work in the project for me. Tweaking weapon spawns, hazard timers and level geometry until everything was perfect. Whenever observing other players, I made sure to note how they died and what were the strategies of the winning players. I wish we had the technology to map out player flow and hotspots, but it ended up being me with a notepad desperately scribbling notes down as gameplay happened. Once I was relatively happy with how a map set played out, I set out to make a new one until we had enough content. I’m actually really happy with how most of the levels turned out and how different they all are. Only a handful of levels ended up being scrapped completely, but almost all of them went through some sort of a rework after playtesting.
Small victories
Another thing I’m really happy with is the amount of polish and juice we ended up having in the game. We have all the usual camera shake stuff and fancy transitions, but the things I want to highlight are some of the way we cheat for the player. When we saw that people who accidentally drove off the level slammed on their breaks, we implemented a little something. Obviously doing a slight miscalculation on some of your movement and losing because of it feels bad, so when you slam on the brakes and the game detects you not fully being on the ground, it’ll actually give you a nudge back towards the level in hopes of getting you back in the game. This mechanic gets disabled for a brief window of time if you get hit so that you can’t save yourself if someone else pushes you off the stage.
Another thing was to cheat with player HP slightly. Although most of the time HP doesn’t come into play, there are a few stages where we push towards KO’ing your opponent. We don’t have any UI during the fights, so you have to keep a mental idea of your health when getting hit. Once you reach a quarter of your health, your character’s helmet pops off and that’s when you know you’re kinda in trouble. What we do here, though, is that when you reach that quarter of a health, we cap you to it. This means if you have 26% health and are hit with a massive double flail for 60% of your health, you’re still only getting dropped to the last quarter. This was to give losing players a bit more of a chance to do a comeback through environmental kills. We wanted to enforce that back-and-forth gameplay that is integral to good party games.
Conclusion
Whew! That was a lot of stuff… There’s so much more to talk about, but I feel like I covered the biggest failures, successes and the lessons I learned. The biggest takeaway, really though, is to make sure you’re building your game on a rock-solid base. If the base mechanic isn’t absolutely perfect, doing everything else right won’t make it good. And so we end the tale of Tanks With Hands, a game built on a fallacy.
If you want to learn more about the level creation in TwH, I have a blog post about it here.