Satie Cells

Satie Cells is a procedurally generated puzzle game with an interactive soundtrack based on Erik Satie’s Gymnopédie n°1

I programmed it in C#, with Unity, and I used Audacity for the sound.

I made it entirely myself as a personal project, in the first half of 2014
(although I first came up with the base concept and mechanics a few years earlier, as a student, while working on a part of a bigger project with friends)

Here’s a short video :

The game can be downloaded for free on [here]


I had a lot of fun making this, it was a brand new kind of game for me to make, with a lot of new challenges especially in terms of code.

Here are the things I wanted to explore with it :

  • I wanted to experiment with a new “delete” puzzle mechanic, in the vein of the classic Bejeweled “match-tree of the same color and they disappear” mechanic, or Lumines’ “make squares and they disappear”, but with rules that I’d never seen before.
    I settled on a mechanic largely based on finding symmetry.
  • Similarly, I wanted to experiment with a different way for the puzzle to re-arrange itself when the blocks disappear. Using again Bejeweled as an example (but also true of SpellTower or Tetris or Lumines), when blocks are “deleted”, the remaining blocks then “fall down” if there’s now nothing under them.
    It’s a way to make the playing field go back to a “compact” state, that is necessary for further moves to exist, and it also plays very well into the goal of those games, that is usually to prevent blocks from reaching a limit near the top of the screen as they pile up.
    I wanted to try something different, where the blocks would always re-arrange themselves towards the center.

Those two main starting concepts then evolved, after a lot of prototyping and iteration, into the game seen above.

Since the levels are procedurally generated and cannot always be completed with a “perfect” score, I also made an AI that tries to solve each level as well as it can, so that the player has something to compare his final score to.

Also, for it not to feel unfair (“well the computer got that score, just trust me on that!”), by clicking a button you can see how the computer got to that score.


This was definitely the most challenging part in terms of code, but I really loved doing it.
The computer is good and has a very high average score, but is not perfect either, so on certain occasions it’s possible to beat him :D
A lot of times I also had the surprise of seeing the computer get the exact same score as the player, but getting there in a completely different way, and with a completely different “shape” at the end.

I think this speaks to the open-ended nature of the game  (something I’m very happy with), but at the same time underlines one of its main flaws : Yes, the game is a lot more “freeform” than if I had carefully handcrafted a finite number of levels with only one possible solution for each, but at the same time, not all levels can be solved “perfectly”, which I understand can be considered a problem for a puzzle game.

I also added a way to make your own puzzle level, by simply “drawing” over cells to change their color. It’s always fun when you make your own level, play it, and then see the computer play it better :D


One last thing I had a lof of fun with was spending time on the way the squares move when transitioning to and from different game states.
Since any level or game state is always going to be composed exclusively of “black and white squares”, I thought it would be a missed opportunity to simply have a bunch of squares all leave the screen, and have a bunch of new squares arrive right after.
So I made sure that whichever squares were left on screen at the end of a level would instead rearrange themselves into the basis for the next grid, or the basis for a custom grid (you can see that in the gif above).
It required a lot more thinking and code than I thought, but I loved doing it :)