Terror Squid: An Arcade game jam post-mortem
Our Arcade action game Terror Squid won the Norwegian Gameplay Championships of 2019. In this article, I will try to recap the frantic four days in which it was conceived, with a primary focus on game design and visuals, as those were the disciplines where I was most involved.
Other articles from TRY Creative Tech
Terror Squid
So I’ve decided to do this Tarantino-style and start with the ending, or result if you will. Terror Squid is an arcade action game in which you control a monster squid that is terrorising a planet with carpet bombs. Every game mechanic is tied to bombing. It’s how you move, it’s how you score, and it’s how you fail. The article below will make a lot more sense if you have at least looked at a bit of gameplay from the finished prototype:
The Brief
Tuesday, January 1st, 10 AM: The Norwegian Film Institute (The host of the event) releases the brief for the Norwegian Gameplay Championships of 2019. The theme is simply “Arcade”, along with a list of technical requirements for the controls — an 8 axis joystick and up to four buttons. It is due four days later, on Saturday.
The initial reaction was one of panic and despair — where does one begin? With such a wide open theme we started by trying to identify some key qualities of a great arcade game:
- Easy to learn, hard to master
- Addictive
- Satisfying
I started out by trying to define each of those points, but quickly realised each of them could warrant an article in itself, and whatever I had to say had been said better by others. They are features that every game should try to aim for, but what makes an arcade game special is that the player isn’t financially invested (yet) in your game the first time they play it. If they don’t get it or like it the first round, they’ll spend their coins elsewhere.
Misunderstandings, and the Contours of a Game
We talked about arcade titles we liked. We talked about satisfying actions (blowing stuff up and chain reactions). Developer Michel talked about the game he did for his bachelors assignment during school. Based off that, he described an idea for a two player versus game, where each player could navigate on opposite sides of a sphere while they tried to shoot eachother through shifting geometric shapes. I completely misunderstood the idea and thought he was talking about a game where you fly a spaceship through a sphere built from shifting, geometric shapes (A bit like Superflight). He misunderstood this and thought I meant flying around on a sphere, destroying geometric shapes. I told him that might work and he gave me a puzzled look.
Still, a shoot-em-up on a sphere is not exactly groundbreaking. Geometry Wars did it. Super Stardust did it. Countless others did it. The sphere needed to be more than a visual gimmick. The great thing about a sphere is that if you travel in a straight line you end up where you started. The same goes for bullets. Meaning, if you don’t want to get hit by your own bullets, you need to move after firing, as your own bullets will inevitably hit you if you stay still.
There was a certain elegance to this idea, and I was reminded of the GMTK video The Secret of Mario’s Jump. In it, Mark Brown discusses Nintendo’s philosophy when it comes to game design. He introduces the phrase “versatile verbs” — player actions that can have multiple uses. This is a great fit for arcade games because it means that the player only has to use one action which can still have multiple layers of complexity, making it easy to learn and hard to master.
I wondered if we could push this concept further. So far, we had established that you need to avoid your own bullets. In other words, shooting itself upped the challenge. What else could the act of shooting achieve? An obvious answer would be movement. We decided that the player moves by shooting the opposite way, like they are being propelled by the recoil of the weapon. This way, avoiding your bullets carelessly by shooting wildly will make it harder for yourself later on as they loop around. It gives the player a way to control their own difficulty.
Earlier in the process when discussing satisfying elements, we came to an agreement that chain reactions are pretty much digital crack cocaine. Think Candy Crush when you get that sweet combo and dopamine rushes into your skull. With this in mind, we decided that when bullets explode, they should detonate any other bullets within a certain radius, thus triggering a huge, satisfying orgy of explosions. Of course, whether or not this would actually be fun was anybodies guess until we got to try it for ourselves, so we got to prototyping.
Visuals
While the dev team got busy writing the code for the prototype, I tackled the visual design of the game. Because of the spherical playing field, 3D graphics were a must. I wanted to give the player hints on what was happening on the opposite side of the planet, so a wireframe look seemed appropriate. The winner of the Game Jam would get their game featured in a cabinet at a local arcade and bar, and it was important that the visuals reflected this. Something that went well with music and beers.
After doing a few sketches, I was pleased with how the game was looking more and more like a disco ball. I was less pleased with how generic it was looking. The fresnel-shader wireframe look has been done better by other games, and it just felt very safe. It needed to go bolder. As I struggled to get to sleep after the first day I remembered vector graphics — a staple of early arcade titles such as Armor Attack. Drawing inspiration from this, the design was simplified. No more fresnel or fancy light beams. It was all line work from here. Of course, vector graphics were only the inspiration. There were plenty of modern liberties taken, such as an RGB Shift for the screen shake, and distance fading the wireframe.
The triangles making up the icosahedron-type sphere were used as an anchor for most of the design. Every object in the game (Except for the explosions, which are spheres) is built from triangles and tetrahedrons. At this point you might say “Well duh, they’re polygons anyway aren’t they?” and you would technically be correct, but in most 3D modelling there would probably also be a bunch of quads involved. I used triangles and tetrahedrons as a restriction to tie everything together visually, but also keep the scope of the 3D-modelling to a minimum, as I was the only artist involved in the project.
The Squid
At some point, the ship changed into a squid. I was trying to come up with a player model that would communicate that it throws projectiles in the opposite direction of travel, while still clearly indicating to the player which way it was pointing. After sketching out some suggestions, I arrived at a design that would close and elongate every time the player boosted. If I really squinted my eyes (And my understanding of aquatic fauna) I could sort of make out a squid shape. Thus, the Terror Squid was born.
I quickly animated it in C4D before realising that Unity doesn’t support point animations without some really expensive plugins. Looking back, this was for the best, as it gave me the opportunity to learn some incredibly basic rigging.
The Squid of course also has value in that it differentiates the game from the plethora of other space shooters, as well as giving some narrative context for why you’re being a total menace.
Prototyping and Mechanical Refinement
As the prototype moved along and more features became available for testing, a number of decisions were made regarding the finer details of the design. Here I’ll explain a few of them.
Detonating Projectiles
We knew that we wanted the players projectiles to be the main source of points for the player, as well as the main source of peril. We knew that we wanted them to generate fantastic chain reactions. But we weren’t quite sure how we would start the detonation. Originally, we were considering a few options:
- Spawn pickups that the player can pick up and detonate when they see fit.
- Spawn pickups that detonate the second the player moves over them.
- Have a timer countdown until the player could trigger a new detonation.
The great thing about 1 and 2 was that it would force the player to keep moving to get to the next pickup. Number 2 was however quickly discarded as it made it harder for the player to control exactly when and where they detonated and we figured it would be frustrating combined with a control scheme that is already somewhat challenging. In the end, we settled for a combination of 1 and 3. The player charges a detonation by firing ten projectiles, and simply presses a button to detonate when they see fit. This way, we tie even more mechanics into the action of simply moving around, and ensure that the player needs to generate a certain number of projectiles before getting the opportunity to destroy them.
Death
Sorry to start on such a somber note. I could have called this section Fail Conditions and Player Motivation but it just didn’t carry the same punch. What we had originally planned was also the most obvious choice: The player would have a limited amount of lives, and when they ran out the game was over. To avoid repeated deaths, we also cleared a large area around the player when they got hit.
Through testing we quickly found that even clearing half the sphere wasn’t enough for inexperienced players. They would quickly get swamped with projectiles again, getting destroyed time and time again, never getting the chance to start fresh, running out of lives in mere seconds.
Making the game countdown based seemed more Apt (Pun intended). We decided to clear the entire globe when the player gets hit and provide them with infinite lives. However, the game is over after 60 seconds unless they refill a timer. This has a double effect; for inexperienced players it gives them plenty of breathing room, whereas for pros it would be punishment, as they now have to refill the playing field with projectiles, costing them valuable seconds.
Using a countdown system for failure also makes it easy to tangibly reward players with something other than points — simply add to the timer. We incorporated structures for the Player to destroy and gain precious seconds.
What’s Next?
Although our prototype was good enough to win the game jam, there is a ways to before it’s ready for release in an arcade. Most importantly, there needs to be a mechanic that gradually ups the difficulty and intensity of the game. When you watch a pro playing Tetris at the highest level, it’s a spectacular display even if you’re terrible at Tetris. We want to evoke the same quality in Terror Squid. Impressive performances should also look impressive.
Although it’s not a particularly complicated game to get into, most non-gamer users usually need two or three tries before it really “clicks” for them. This needs to somehow be solved in a manner that doesn’t get in the way for experienced players who are using the same cabinet. A partial solution would be to have a short tutorial displayed while the game is in attract mode (When no one is playing), but there probably needs to be something unintrusive in the game itself as well.
The scoring system needs to be more transparent, and give clearer feedback when the player is doing good. As of now, we only show the multipliers as the player triggers a combo. It might be useful to summarise the entire combo values before adding them to the total score.
We need an original soundtrack with vocoders and wailing electric guitars. We just do.
Thanks for reading!
