Posted February 26, 2023 by jaymartin
#postmortem #tetra #long #thoughts #design
Making a game with composable Tetris shapes was in my mind for quite a long time. For example, THIS was on my desk for at least two months. I was interested in that, but found it difficult to match with anything worth doing.
Back then, I had been thinking really big - my brain had been occupied with combining RTS gameplay with composable Tetris. I was making several concepts and was trying to find promising system dependencies. A few of them caught my interest to the point of dropping the composable Tetris all-together and focusing purely on them. That’s how Emergent Shapes experiments were born.
Emergent Shapes took some time, but eventually I got back to the drawing board and started with a simpler idea - combining composable Tetris with Match-3 mechanics. I made a quick prototype from the remains of Emergent Shapes and brought it to the Something Random office.
The result exceeded my expectations. The first prototype spread like a virus. People could not stop playing it! With the confidence gained from the first version I decided to develop the idea further. Without me noticing, I was making a quite big project (in terms of solo pet projects, of course) and found myself adding a progression, movable power-ups, random-balancing systems, a game flow & ending, a save system, shops, a cheat console, feedbacks, sound effects. The list grew exponentially. A tiny prototype became a five months commitment.
In the end, I had too much of it (at this point, I think we should all refer to it as some kind of game development syndrome of “Prerelease Aversion”) but it was totally worth it. Primarily, it gave me a solid understanding of the process of restricting and balancing emergent endless gameplay. Going through the whole development cycle of the product, even a small pet project can really open one's eyes and I find it a priceless experience for the creation of bigger games.
Making those small games revealed to me some kind of game-making paradox. As game developers, we focus on iterations. As Jesse Schell’s The Rule of the Loop claims:
“The more times you test and improve your design, the better your game will be.”
We all know it by heart - an iterative design is a standard approach for most of us. But game development is also a very complex and time-consuming process that most of the time takes years to complete. So on the one hand we do a lot of iterations within a single game, but not so many iterations of different games. We’re becoming experts of the details, but stay newbies of making believable, coherent, fluent and engaging games as a whole.
I think important lessons are hidden in those small projects. Lessons that can be hard to notice while being in a multi-year development of a bigger title.
For this project (and basically all projects from that time) I decided to focus purely on mechanics and leave story, fantasy and themes behind. As I mentioned before, it’s a blessing and a curse at the same time. Early on, it can really open up the design of the game - having no logical restrictions, where nothing is against the rules can lead to truly innovative solutions. But, as the process continues, I think that we need to seek a good moment to blend it together with a fantasy and work simultaneously on both aspects from there. At the right time, you need to storify the gameplay.
For many people that could not be the case. I personally like to think of gameplay first, without fantasy, pure abstraction. But many people start with the fantasy or story and try to capture it somehow using game mechanics. Then, a process of gamification of the story happens. Don’t get me wrong - both approaches are valid and can lead to great games.
To my mind, Tetra missed that moment of storifying. With every iteration on any abstract mechanical game, you calcify the gameplay a bit. Systems start to work in a specific way, there is less and less space for change, the number of moving parts decreases. If you try to storify your game too late, too many systems are set in stone and, unless you make radical design changes, it becomes really hard to match with a right fantasy. And even if you do, it will probably feel far from the core of the game.
* I coined this term for the sake of this text, but it feels good. To me, at least.
I see myself as a rather systemic person and coming up with stories is not that natural to me as finding interesting mechanics. But, having a solid theme comes with a lot of benefits:
Glance Value - people think in stories. It’s easier to catch the player’s attention by telling what the game has to offer fantasy-wise than telling directly what the mechanics are. Game could be extremely fun to play, but when all you can say about the game is as abstract as placing cells adjacent to each and collecting colour groups, you don’t have that many weapons at your disposal to attract players. Abstract talk requires effort. But, on the other hand, if somebody is not into your theme, it could work worse than having no theme at all.
Understanding - when the game’s fantasy corresponds to something familiar to the player, he can understand it quicker by drawing analogies from his real-world experience. He can use his common knowledge and apply it to the challenges faced in the game. It’s easier to understand that: you place a magnet on the map and all the metal pieces of a given type are pulled by it than: you place a Collector Cell and when it is directed towards a group of adjacent Cells of the same color, the group is pulled. I’m exaggerating a little bit, but you get the idea.
Having a clear and well-defined goal is essential for any game. It provides players with a sense of purpose and direction, enabling them to stay motivated. Goals also give players a sense of accomplishment when they reach them.
I like to think of goals as extensions of the main thing you do in the game. In other words, if players keep doing the “main thing” they will eventually reach an extreme, a boundary. To my mind, the main goal should be that extreme. Let’s see it by example:
I think you get the idea. You do something, until you can’t do any further.
Meanwhile in Tetra, you group and collect adjacent color cells until… what exactly? Basically, until you remove 8 tiles from the map and survive a couple of turns more and eventually remove all tiles using final Tetra cell. In hindsight, a really lazy solution on my part… Don’t get me wrong - the goal is valid and offers an interesting challenge for the player, but it is not really connected with the main thing, the core of the game. The reason for this, I think, it’s the case of adding a fixed ending to an endless game at too late stage of development. Too many things were calcified at that point in design to make it coherent.
To be honest the same goes with all movable special cells that you unlock throughout the gameplay. They come in handy from time to time, but to my taste, they are too far from the core experience of the game. I made them as an experiment and couldn’t let them go, even when I realized that they are not that good. That’s why I made a separate game out of them. I saw a potential in them that was not fully utilized in Tetra.
But then, even worse happened. The progression of the game relies on those special cells as well as gaining enough gold to afford them. It’s practically impossible (practically, because random is well… random) to finish the game without unlocking any powerups. So to finish the game, you need to use special cells more and more, to the point where in the late game they can become your main point of attention. So basically, every step towards the finish line, drives your gameplay away from its core.. yikes!
I think it’s not entirely a bad thing, but the proportions are out of place here.
Early ideas for progression and building complexity.
Some time ago, I gave a little talk about randomness (in polish sorry!) where among other things, I described different approaches for making random systems along with consequences of using them. Tetra relies heavily on randomness and was a good testing field for my claims stated in the talk.
Initially, the whole game was made using a dice system (or uniform random, however you like to call it). It managed the distribution of colours, special cells (collectors, glass) and also obstacles (shields, snow). It’s the easiest system to write but it can spin out of control pretty quickly. Balancing a game becomes a nightmare - some runs are super easy and play themselves, some are impossible to overcome after a couple of turns. I needed more control.
Eventually, I took a different approach depending on a context:
The name comes from the idea of covering a slice of bread evenly with butter. The idea of spreading the material all over the surface.
Randomness can spin out of control pretty quickly and we have to deal with deadly consequences of having negative or positive output too many times in a row. Butter Random splits the given space into containers, each having its own total capacity and positive capacity. Then, you give the system positive and negative elements. Positive elements are one by one put in random containers until the positive capacity is reached. The remaining space (towards total capacity) is filled with negative elements.
The system gives you the benefit of unpredictability, a control over the extremes and allows you to see the randomness of the given part of the game from a broader perspective. It’s about seeing the whole landscape.
And also, as in a deck system, after the cycle is complete, you know that every element was drawn making the game exactly the same for every player in those key moments. So, the order of elements may vary within the cycle, but at the moment of ending the cycle, you know exactly the state of the game.
The initial design of Butter Random
When I’m making those small games, I always start with a template that makes the whole development much, much faster. After finishing every game, I took time to review what I have done and what can be useful in the future.
This philosophy speeds up my process with every game I make and also gives me motivation to write features that I don’t really want to write at the given moment. I thought to myself then “I’m gonna write a basic version now, and I could use it in the next projects”. We all know that it doesn’t always work that way, but having the time to review, restructure and take further with you is crucial to my way of making games and it’s one of the reasons, why I make so many pet projects in my spare time, while a full-time job a designer of bigger titles.
It’s all about recycling.
The initial design of Tetra.
Ufff… that’s a lot of talking. But, I think having a half-year project requires a proper ending. Thank you for staying with me, and I hope you had at least some moments of fun while playing Tetra. I personally had a lot while making it.
To wrap it up, here are some takeaways that will hopefully guide my next projects:
If you don't want to play, but still want to see the game in motion, check out this gameplay videos:
The original postmortem can be found on my website along with other design deep dives and portfolio of my projects. Take a look!