Programming: Pyry, Mikko, Henri
Graphics: Helmi
Audio: Mikko (the same one)
About Slingy Slugs
Slingy Slugs is a turn-based 2D local multiplayer game for Android devices where 2-4 teams of stretchy animals battle to death. The core mechanic of the game is a slingshot mechanism with which the explosive animals are hurled at each other and around the playing field. The explosions hurt the animals and destroy the terrain, and the team with the last animal(s) alive wins.
After the starting screen, the number of teams (usually the same number as the number of players) is set. After this, the players choose a level to play on and start the game. Each players’ animals are placed on the map and the battle may begin! Taking turns, the players try to slingshot their animals in ways that cause the opponents to lose health or drown.
The game has four animal types, each with their own special ability. The Slug’s functionality is the most basic one, as it soars through the air and explodes on impact. The Snail does the same with a smaller explosion but also bounces a couple of times, exploding thrice. The Octopus heals team members within its “pollenation” radius, whereas the Siika (whitefish) character burns through the terrain, creating tunnels, slopes and openings. Players have the possibility to customize their team’s animal composition (and names!) from the Team Management menu.
“Angry Worms”
The basic idea for Slingy Slugs emerged, innocently enough, from a brainstorming session where the words “crossover between Angry Birds and Worms” were uttered. Other ideas, even pretty great ones, had been thrown around, but this one immediately caught fire and captured our imaginations. We set out to create a relaxed multiplayer game that was simple enough to just pick up and play but also provided tactical satisfaction.
After a shorter-than-optimal design meeting, the programmers jumped in and started working on the concept the very first day. For the first week or so, things were very experimental (worms were slung around a test chamber), and the team went through all the stages of grief when trying to implement a self-made 2D physics system instead of just using Unity’s integrated Box2D. In the end, it was deemed way to handy to not just employ a system that is already there instead of having to take into account every obstacle we might face with a home-brewn solution.
Another thing that became clear very quickly was that the team simply wouldn’t have the necessary know-how to make a destructible 2D terrain system work within the timeframe of the project, so a bit of plugin research was made. In the end, we decided to go with the excellent Destructible 2D plugin by Carlos Wilkes. As an editor extension, D2D presented the team with the challenge of understanding making good use of the stuff that’s in there, but it was relatively easy to get a handle of the system and modify the well-documented examples to fit our needs.
The right art style was found very quickly thanks to the project’s theme fitting the graphic artist’s skills. There was a conversation about using pixel art, but that conversation was a brief one. The first artistic obstacles were presented by the technical design: how to make the characters out of many parts, some of which stretch and rotate interactively via input, and still make the characters look good? However, even this problem was solved surprisingly quickly by the team. Although the end result perhaps isn’t the finest display of prefab engineering, it’s a functional one.
Very quickly, the game started being fun. The kinesthetically natural feel of the main gameplay mechanic made it almost distractingly fun to play around with the stretchy slugs even before there was an actual game to be played, and this of course lifted the spirits up. For some time, the atmosphere was almost too enjoyable, as progress was made in rather unprofessional, “I’ll just add that too” manner. However, this stage of “just doing” things was pivotal, as without that rush of enthusiasm, we wouldn’t have had all that (fully functional) code to refactor during those desperate Sunday nights before a demo deadline.
Problems, officer?
The biggest and most persistent, but at the same time the most predictable problem throughout this project was schoolwork that was not directly related to it. The weekdays when project work wasn’t possible were enough to make a huge dent, but also, it was difficult to schedule things or have a clear grasp of how much stuff can be achieved when at any given moment, a huge coursework assignment could be dropped on our necks. Although we understand why the problem exists, it doesn’t change the fact that it’s the no. 1 reason why we’re unable to plan our stuff professionally.
Whether or not the volatile nature of schoolwork was the main reason in this or not, we discovered that we are not very good at estimating the time it takes from us to do things. This was to be expected, as many of the project’s tasks were things we had no prior experience of, but we could have helped ourselves greatly by always implementing the “multiply time estimate by pi” rule of thumb. School, work, personal stuff and unexpected problems will always come into the way, so a reasonable delay buffer is better than overly optimistic expectations.
On the technical side, we ran into some rather weird obstacles with the Destructible 2D system. It seemed to cause way too much lag in even our simplest levels, and it seemed hopeless. However, after several days of dedicated research and experimentation, we managed to find the ways to optimize almost all lag away from the game. In a glorious display of ass-backwards logic, it’s actually more efficient to have edge colliders made from a huge image rather than smaller ones, transparent data in said image around the borders is better for performance, and stamping is faster to calculate with a smooth brush than with a clear-lined, hard one. Go figure.
That’s a wrap!
Our infantile efforts in trying to figure out this game development stuff resulted in a pretty sweet, fun game that we feel proud of. Admittedly, some overscoping was done at the start, but all in all, the removal of unnecessary and/or impossible-in-this-timeframe clutter was painless, as the game feels good to play as is. As usual, the biggest breakthroughs in both the technical side and gameplay feel came at the last minute, but that final rush made the experience all the sweeter.
Although school-wise a deadline has been met, the team sees no reason not to expand on the game and add content to it later on, if such an opportunity were to present itself at a later time. The game is actually fun to play, which was the main goal of the project. Therefore, even with the difficulties we had in the process, we dare call this project a success!
