What is Honest Dan's Trout?
For my LD41 entry, I ended up combining two genres of the arcade genre, to create an infuriating, challenging and rewarding game. The game brings together the mechanics of the well known games "Tetris" and "Breakout" (Arkanoid). This post will talk through the process of how I came up with the idea and design decisions along the way! You can try it yourself here.
Planning
Plan A
My original idea for the game jam was to make a rhythm-based bullet-hell game, where you could only shoot on the rhythm of the music. After spending most of the day trying to get beat detection working, unfortunately my lack experience and musical knowledge meant that I could only get it working to the repeating beat of the song, which really detracted from the novelty and challenge of the game I imagined. At the end of day 1, a new plan was formulated...
Plan B
I went back to my google doc... slightly dejected... and decided I wouldn't give up at the first (albeit very large) hurdle! I started to focus on the theme, as I know the theme is a very strong part of the gamejam and can leave a big impact on the player. Incompatibility for me was the concept of two things being put together and causing problems and conflict for each other. I started writing down a list of different familiar games, and along side them writing down the "objective of that type of game". My goal now was to find conflicting goals on my list - and when I stumbled across the idea of Tetris and Breakout... it seemed to good a match.
The goal of Tetris is to carefully plan and place puzzle pieces, such that you can remove them all in one fell swoop. You need to remove entire lines, and if you don't remove lines you'll fill up the puzzle board and it'll be game over.
The goal of Breakout (arkanoid) is to destroy all blocks. When your ball hits a block, it's a good thing! You just need to focus on the ball placement and ensure you stop the ball from falling off the bottom of the screen. The blocks are static, which allows you to plan and "aim" your shots.
For me - there was a clear conflict between the game play of these two games.
- Breakout requires you to focus on the ball and paddle, but puzzle pieces falling would directly affect your concentration
- Breakout usually works in a static environment, but the falling puzzle pieces add a dynamic aspect that directly impacts the ability to predict the trajectory of the ball.
- Breakout usually encourages any destruction of blocks, but Tetris' goal of creating complete rows of blocks now means you need to be selective of which blocks you destroy.
- Tetris requires planning over time to stack puzzle pieces carefully to create a no-gap stack of blocks, but the ball of breakout will chip away at your blocks constantly.
- When a puzzle piece is falling, you eye up where it will be the best place to put it. However, the ball can change the shape of the piece as it falls, or change the shape of the area you planned to put it, meaning your plans often need to be changed on the fly / last minute.
At this stage I could see how they two genres co-existing in the same game would create problems, but with a day wasted already - I didn't have time to prototype to see how the game felt. I just had to get started!!
Visuals
Art is not a strength of mine, but recently I've reverted to pixel art with limited sprite sizes and colour palettes - and I find it has really helped me create a style I'm comfortable with! As these two games were of the retro arcade era, it felt only right to choose an retro style look to the game, but I wanted to avoid the gameboy palette. I decided on greyscale as it was future-proof - meaning, I could just apply a tint to sprites in Unity to turn my game from grey scale to a game-boy style green etc if I fancied it. I also had plans to add some "juice" to the game, such as flashing colours when you complete a line... but that never ended up making it into the game. I chose my 5 colours and got to work.
I use PyxelEdit for my sprite work, a nice piece of software (Aseprite is also good, I've heard). I went at it to create the ball, paddle, walls and blocks. Initially they were meant to be placeholder but it turned out that they worked quite well with the "mood" of the game. The puzzle pieces were just combinations of the blocks, so there really wasn't a great deal to do with regards to the sprite work. One thing that turned out better than anticipated were the frames for the UI. I highly recommend people (if they don't already know) to learn how to create sliced textures to use on UI elements in unity. It meant that something as simple as this sprite, could make the UI panels you see in game:
Integrating the Genres
It was important to allow the player to feel the overwhelming conflict that the two games create when combined. Some thought had to go into the design of the game - to ensure players got a true sense of this conflict. It was important that you could still get some reward for playing the game either way (breaking blocks or making lines). However, it was apparent that the breaking blocks part of the game didn't really require much thinking - it was just a bi-product of bouncing the ball off the paddle. Therefore, I wanted to make the Tetris element of the game provide the player with a higher reward.
I went about this in two ways. The points awarded for a line vastly outweigh the point-per-block of removing block using the ball. However, the most valuable thing that lines provide the player with is time. This allows a player to extend the game for long as they can keep making lines - opening up the possibility for a wide range in high scores based on someones skill-set. The reason I felt this was the correct way to do it, was that those who didn't read the instructions (that explain lines reward time) can still get a good 3 minutes of stressful challenge from the game! However, those who spend time with the game and get better at it can get more out of the game for playing well. It also encouraged player to try and achieve the more challenging "lines" rather than stick to the block breaking mechanic only.
I didn't predict how difficult a Trout would be to achieve. Having had the game running now for a few weeks, it is clear that achieving a Trout is something rare and extremely difficult due to the destructive and difficult to control nature of the ball! The result is that player tend to focus just on clearing single lines, as that is possesses less risk and still gives enough of a reward to keep the timer increasing and the point accumulating.
A final addition was to reward an extra life to players upon accumulating X amount of points. I think it was important as the game is very difficult and this gives a way for people to claw their way back into a comfortable position.
Representation
The breakout part of the game was the easiest to implement, as we could just use the built in physics within Unity, using colliders etc to get the desired behaviour. The problems I didn't foresee was the unexpected behaviour of the built in physics, which lead to me trying to design my own physics to control the ball movement. However, this resulted in a large amount of lost time, frustration and a buggy mess! So I ended reverting to the Unity physics but chose to override some things to try alleviate some of the general / gameplay issues that it caused. One thing was to add slight variance to the bounce of the ball, to avoid situations where the ball bounces horizontally back and forth. Another thing was to add 45 degree angled corners to the top left and right corners of breakout "walls".
The tetris representation was the harder part, as we would need to be able to check for lines and valid moves (when turning a puzzle piece), whilst only allowing pieces to exist within a row and column structure. This essentially ruled out allowing physics to handle the placement of blocks. The approach taken was to create a 2D array that would hold "block" objects. This 2d array would map up with the puzzle-board in the game's world space. We would need to manage both separately however, so whenever we moved a block in the real world, we would need to update the array with the changes. With some careful design, I was able to set it up so that I could translate any game objects "world position" in unity into an array co-ordinate.
When you have a 2D array structurethat tells you all of the blocks and "non-blocks", then you are able to start applying some logic to this in order to check for valid moves (such as when a puzzle piece needs to stop falling) along with detecting if a row of blocks has been completed. It proved valuable to make some crude debugging tools (that print out the state of the 2d array) so that it becomes easier to debug and fix unexpected behaviours during implementation.
(to be continued)
This post has already grown pretty long, so I'll write another installment over the next few days <3 I plan on covering a bit more on the implementation, along with some reflection on the game after submission. Thanks sincerely if you read through this!
