Backstory

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.

Iteration Paradox

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.

A Right Moment To Storify*

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.

Benefits Of Having A Theme

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.

• Commitment - game mechanics can be extremely engaging and can offer countless hours of entertainment. But at the end of the day, the story is the element that stays with us for the longest time. When the fun of touching the boundaries of the interactive systems is long gone, we still continue playing to find out what’s gonna happen in the grand finale. Maybe it’s not the case for such small games like Tetra, but curiosity is definitely a driving force of commitment. And stories heavily rely on curiosity.

Meaningful Goals Aligned With The Core

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:

• In Super Mario Bros, you primarily go right (main thing) until you reach the end of the map (goal).
• In racing games, you accelerate forward, until you reach the finish line first.
• In Space Invaders, you shoot aliens, until they are all defeated.
• In Pacman, you eat dots, until you eat them all.

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.

Progressing Without Losing The Core

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.

Approaching Randomness

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:

• For collectors and glass, I ditched randomness all-together. One glass spawns every turn, one collector spawns every three turns. Those elements are too essential for the game to play with their frequency. Also, having this cycle of one collector every three turns gives the gameplay a good flow and almost breathing, wavy quality. You try to survive underwater, but you know that you are about to be back on the surface soon. But only for one breath.
• For colors, I decided to go with a deck system (removal random). There is a predesigned, fixed pool of colors from which the elements are randomly drawn. When the pool is empty, it’s refilled with the same elements again. With that approach, you merge two worlds - you have random elements and players don’t know what’s gonna happen next, but also - when the pool is empty, you as designer know that a whole cycle is over, and you are sure that all elements appeared in the game. The big question here is the size of the pool. The bigger the pool the more random the game is within the lifetime of the pool. Also, the proportions and the number of possible duplicates matter.
• For shields and snow, I needed to figure out a different approach. The level of control needed to be higher. Deck system is cool, but in the worst cases, it allows something to happen too many times in a row. For the obstacles in Tetra, it could have disastrous effects. Imagine that snow happens four times in a row and the whole Tetris shape is blocked. In practice, it is equal to game over with the player having no agency. We could fix such problems in many different ways, but I decided to find a more universal solution that I can add to my toolbox. I called it Butter Random (I have a tendency to give fancy names to ordinary things, I know).

Butter Random

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

Expanding Designer’s Toolbox

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.

Takeaways

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:

1. Make small complete games. You will gain experience in seeing games in their entirety.
2. Abstraction gives you freedom, but don’t miss the moment to storify.
3. Align the goal with the core. Seek extensions of the main thing.
4. While adding a feature ask yourself a question: Does it derive from the core?
5. Don’t make a progression that drives you away from the core.
6. Think of the impact of every use of randomness. Do I really need it here? What’s the level of control I need?
7. Butter Random is cool. Use it when you need to spread something evenly across the game and have it under control and limits.
8. Write simple. Don’t over-engineer. Seek parts that you can take with you to the next projects. Recycling takes time, but it’s worth it.

Videos

If you don't want to play, but still want to see the game in motion, check out this gameplay videos:

More

The original postmortem can be found on my website along with other design deep dives and portfolio of my projects. Take a look!