Open Bar: The Making Of An Indie Game


A few weeks ago, we launched our first game, Open Bar. It’s an indie puzzle game for iPhone and iPad. The reception was great, and it got featured by Apple as one of the best games of January. It took about a year to complete, and the road was full of obstacles. This is a story about fun and excitement, but also learning and challenges.

Gingear Begins

Back in the summer of 2014, my girlfriend Julie and I considered starting an indie games business together. Julie had an entrepreneurial mindset, and for me it was a dream come true.


Financially speaking, we were in relatively good shape. We both had a good amount of personal savings, and we figured that we could survive for a few years if we drastically cut in our expenses. I got rid of my car and we moved into a less glamorous, but cheaper apartment. I stopped going at Starbucks… that was hard.

The elephant in the room was my job at Ubisoft. Back then, I worked on Assassin’s Creed Syndicate at the Quebec studio. We knew we couldn’t seriously start Gingear with me keeping my job. But it was not an easy decision to quit a safe, well payed job. I talked about that in details in my previous post, Why I Quit my Dream Job at Ubisoft.


Early October, after months of weighing the risks and consequences, I finally made my decision and informed my employer that I’d quit. Although the timing was perfect for Gingear, it wasn’t great for Syndicate. Ubisoft offered me a part-time job until the end of the project, which I gladly accepted.

The idea

For our first project, we knew that we had a lot to learn. I could code almost anything, but we didn’t have any experience in game design, marketing, PR, etc. We knew we’d make mistakes, so it was a priority to reduce risks as much as possible. Our objective wasn’t to get rich; it was rather to start the business, ship a game and learn as much as possible along the way.


That’s why we decided to make a mobile puzzler. There are really good games with a relatively low production budget available on iOS and Android. We were inspired by Threes and games by Zach Gage. We were perfectly aware that the market is very saturated. It seemed foolish for an unknown developer to create another mobile puzzle game. Yet, we didn’t mind because the risk was minimal and we would learn a great deal.

In 1999, I was already passionate about creating video games. I had many home-made projects here and there… most of them were never finished. One of the few projects that I completed was a PC version of the board game Take It Easy.


In this game, you place hexagonal pieces on a board. There are three numbered lines on each piece. You make points every time you complete a line with identical numbers. When the board is full, the game is over. It’s quite fun, I recommend it if you never played.

Here’s a screenshot of my version.


Pretty, isn’t it? I remember sending an email to the editor, asking them if they’d be interested in publishing my PC version. They never answered, for some reason.

That said, I made it all by myself, and I was proud. It supported multiplayer, so I could play with my friends over the Internet. It was really cool! Too cool, actually: my brother was totally addicted. He played all the time, and consequently monopolized the computer.

Back to 2014. When brainstorming for a good puzzle game concept, I thought about making a game inspired by Take It Easy. What if you could play forever, like in Tetris? What if the lines would clear themselves once completed? This was the key idea behind Open Bar.

Early Prototypes

Here’s a screenshot of the earliest build I found in our archives. Feast your eyes on this gorgeous piece of art!


We soon discovered a fundamental game design flaw. You can’t play indefinitely, because as soon as you align two pieces of different colors, that line is never going to clear itself. After a few moves, it goes downhill and it’s game over.

Our first solution was to add abilities to each color. Back at the time, the game was about magic. The pieces were some kind of runes that would cast a spell when you aligned them. For example, the red pieces were fire runes and they would clear across intersections (like a fire that spreads). Making a line of thunder runes would clear all similar runes on the board. We also had a wildcard that matched every other runes.

If you think it sounds overly complex, you’re damn right about that.

Nonetheless, those mechanics helped players to get rid of unwanted pieces by using their abilities strategically. It wasn’t suited for an endless, highscore game like Tetris. It was more appropriate for puzzles, so we decided to go that way.

The Japanese Version


At that time, Julie and I were in the middle of watching Jojo’s Bizarre Adventure. For those of you who have never heard of it, it’s a crazy, ridiculously awesome anime. The artistic direction is very cool, particularly for its unusual color choices.

We drew inspiration from Jojo to find a new theme for the game. We weren’t all that sold on that magical runes thing. We went for a zen look & feel, something calm and relaxing, with a desaturated color palette. One of our visual references was Okami.


As the player would make bigger and bigger combos, the game would reward him with very colorful animations and feedbacks, Jojo-style. To actually understand what we were aiming for, you need to see it in motion. This opening of Jojo was our visual reference.

While brainstorming about Japanese culture, we stumbled across the Japanese zodiac and its twelve animals. We thought it’d be cool if pieces were an abstract representation of an animal. So our fire pieces became rat pieces. Thunder became rabbit. We added the tiger, which destroyed tiles when you cleared a line. The snake did the opposite and created new tiles. Since there are twelve animals in the zodiac, we had to find twelve interesting abilities.


Our level selector was a sky with constellations, one for each animal. You could rotate it and zoom on any animal. Each one was made of a few stars corresponding to levels.


For our tutorials, we had designed a cat named Steven. Interestingly enough, the cat isn’t in the Japanese zodiac. According to the legend, the rat tricked the cat and denied him access to the zodiac. In our game, the cat manipulated the player to get his revenge and earn his place in the animal pantheon. By the end of the game, he’d reveal himself as the “final boss”.

Here he is. Poor cat, he didn’t even make it in the final version of our game.


Then, we started playtesting. Every week, we asked a few of our friends to play the game. Participants had to fill a SurveyMonkey after their session. The most important question was: how would you rate the fun of the game? Players had to choose between 1 and 10, 1 being not fun at all and 10 being extremely fun. We aimed for an average of 9/10, nothing less…!

The first week, we got 7.5/10. Most players had a hard time understanding the rules, so we added feedbacks to improve comprehension. The week after, we still got 7.5/10. We tweaked them a bit more, and improved level design to make the puzzles as interesting and balanced as possible.

lsAfter about of month of this, we still got 7.5/10. Initially, we thought people gave poor ratings because they didn’t understand the game. But that wasn’t the problem. We got the same ratings even when players fully understood the rules.

I remember one particular playtest session with my former colleague, Guillaume. He wasn’t the bullshit type: if he didn’t like the game, we’d know it for sure. And he gave us the worst rating we’ve ever had: 6/10. After a month of working hard to improve feedbacks and level design, that hurts.

For the rest of the week, I didn’t sleep much. I was anxious and kind of depressed. One night, I wondered WTF was wrong with the game. The first impressions were kind of boring, it took about 15 minutes for the players to start having fun. But we couldn’t do anything about it, because the interesting mechanics were too complicated to introduce straightaway. You had to go through the boring basics before accessing the fun part.


We were far from our initial concept. We wanted to do a fun, Tetris-like game with simple mechanics. We ended up with a not-so-fun puzzle game with intricate mechanics, the Japanese zodiac and a plotline featuring an evil cat.

So, we took the first big decision of the project and went back to the drawing board. No more animals and special abilities. Let’s fix the core gameplay mechanics and return to our initial idea of making a highscore-based game.

The Highscore Version

Once we removed abilities, the color misalignment problem was back. As soon as the player aligned two pieces of different colors, he’d be game over within a few moves. We made a paper prototype, and that’s when we came up with the slide mechanic. If misplaced pieces were a problem, why not let players move them? The token would just take the initial position of the pieces you moved, and voilà!

I quickly prototyped that version, and I had one of those Eureka! moments. It was a lot more fun than the color abilities of the Japanese version. Actually, while writing this, I got caught into playing a game.


A few months later we added the token rotation, which completed our triad of gameplay mechanics: drop, turn and slide. During playtests, those mechanics were really appreciated. It felt just right.

Wasted Time

I have a strong background in graphics programming—I love special effects, and I wanted the game to have a unique look. I don’t remember exactly why, but I came up with an idea about paint. As if the pieces were made out of paint that would splash on the board when you cleared a line.


Not only it would’ve required a lot of work to make it pretty, but it hindered clarity. It’s a game about matching colored pieces. If the background is the same color as the pieces, it’s misleading and annoying. Lesson learned: work with a graphic designer or an artist before spending too much time on visuals. It sounds obvious, but it’s easy to fool yourself into thinking otherwise.

Then I spent a lot of time figuring out the details of the score system. It was based on multipliers. Your score was multiplied by 2 if you cleared several lines at the same time. It was again multiplied by 2 if the lines were the same color (so a total of x4), and again if they had the same length (total x8). So in order to get a lot of points, you had to gather as many multipliers as possible.


Ultimately, it was just confusing. In Tetris, you don’t actually care how many points a combo gives you. You just need a visual or audio feedback telling you if you made a good move or not. Feedbacks come first; the score system itself is irrelevant in the player’s mind.

The Difficulty Curve

In a highscore game, you need a rule that will make the game harder and harder as you progress, and it has to be skill-based. In Tetris, the pieces fall faster and faster. In Threes, the board gets more cluttered as you merge bigger numbers.

We didn’t have that, and it was a major problem. The mechanics were enjoyable, but you could play indefinitely. We prototyped a lot of ideas to make the difficulty increase smoothly. One of them was to add colors as you progress. The problem with that is the difficulty spikes. With three colors it’s very easy. With four it’s more challenging but still feasible. But with five colors, it’s hopeless. The difficulty curve wasn’t smooth at all. Worst, it wasn’t skill-based: it was just impossible to keep up, and it had nothing to do with your skill level.


We also tried changing the shape of the board from level to level. It was interesting, but again, it wasn’t skill-based enough. When you were game over, it felt like you couldn’t do anything to prevent it.

One interesting idea we explored was to randomly spawn little clocks on the tiles. You had ten seconds to clear all pieces from that tile, otherwise it locked itself and you couldn’t interact with it anymore. I liked it because it added a timing element to the game. The downside was that it was counter-intuitive and very hardcore.


One of the best idea we tried was to add numbers on pieces. You had to clear them that many times before they disappeared. It solved the difficulty scaling and it was fun. We were really close to ship that.


We prototyped a lot of other ideas… Making as many points as possible in 60 seconds, unmoveable pieces, a chain reaction system, power-ups, etc. But all those prototypes got cancelled when we transformed the game back into puzzles.

Puzzles (Revisited)

During playtests, one thing came up way too often: players felt like there wasn’t any goal. Of course it was a highscore game, but in itself it wasn’t satisfying. In Tetris, the goal is obvious and it feels good just to clear lines. In Threes, there’s some satisfaction in merging two big numbers together. There was no such thing in our game… It felt purposeless.

Then I made Guillaume (remember my brutally honest ex-colleague?) play the game once again. His review was even worse than the first one: he gave us a 5/10 rating on the fun factor. He explained that he’s not really into highscore games. And as other playtesters, he mentioned the same purposeless feeling about the game.

But he made an interesting suggestion. He said: “If the game was about puzzles, I’m pretty sure I’d like it.” I replied that on the Japanese version, creating interesting puzzles was really time consuming and we didn’t want to go down that road again. He replied: “You could write an algorithm that procedurally generates puzzles. Then, all you have to do is to play them and select the best ones.”


The next day, I did exactly that. In a few hours, I transformed the game from a highscore, Tetris-like game to puzzles where the objective is to clear the board. I then programmed a level generator, and the result flabbergasted me.

One of the first puzzles I generated was so tricky it took me fifteen minutes to solve. And it wasn’t the only one: I generated dozens of unique and very challenging puzzles in just a few minutes. Many ended up in the final game.

It was a revelation. Puzzles didn’t suffer from that purposeless feeling we had with the highscore mode. The goal was crystal clear: eliminate all pieces from the board. The difficulty curve wasn’t a problem either: we just had to order the first few puzzles to make a smooth progression towards harder puzzles.


After months of prototyping and playtesting, we finally had a good game concept! Actually, we had so many good puzzles that I didn’t know which ones to keep and which ones to remove. That’s when I thought: why not keep them all? Why not ship the game with the generator and let players solve as many puzzles as they want to? I rewrote the algorithm, and after a bit of tweaking, we had an unlimited supply of fresh and original levels, generated on-demand.

I recently found old notes from when I programmed the puzzle generator. Behold!


Now we just had to make it slick and pretty. We already had a good idea of what the game should look like. We hired a graphic designer, Simon Giguère, to give us a hand. Given my artistic skills, it was a necessity.

After a few weeks, the game looked like this. Much better, but not there yet.


The game still didn’t have a name. One night, Julie, Simon and I went out for beers to brainstorm names. We suggested over 150 names, most of them weren’t really serious. Here’s my favorites:

  • Bars: Clear’Em: The Game
  • Barzle
  • Plusimple
  • Strip the Rods
  • No Bars Left Behind
  • Just Clear the Board ASAP (but there’s no timer)
  • I Am Bar
  • Bars? You Said Bars?
  • Motherflickin’ Bars
  • Bar: Dead
  • Total Rebars
  • Finger Flicking Good
  • Say Hello to my Little Bar
  • There’s No Diagonals In This Game

That’s when Julie suggested Open Bar! And that was it. We immediately knew that would be the name we’d keep. It both refers the fact that we manipulate bars and that there’s an unlimited amount of puzzles to solve. Simple and clever.

Everything else naturally fell into place. We already wanted players to unlock skins as they progressed. So why not use colors inspired by cocktails? Add a nice gradient in the background, a few animated bubbles and there you go.


The rest of the production went very smoothly. We wanted the game to be as slick as possible, so we invested a lot of time on animations. Then our composer & sound designer Mathieu Robineau added the music and sound effects, and that was it.

Open Bar was done.


A few weeks later, we launched our game on the App Store. The reviews were unanimously positive: both journalists and players loved the game. Apple featured Open Bar in the Best New Games category. The next week, it got featured in Best of January. Yay!

Julie and I showing our game at IGDA DemoNight in Montreal, two days before the release. When we solved the first puzzle, the crowd cheered at the slick animations. That was cool!

Check out what the press said about it.

“This is a puzzle game that I will be playing for a long time to come.” ~ AppAdvice

“You better check out how good it looks in motion.” ~ Pocket Gamer

“Open Bar is a game that, beyond a set of fantastically designed puzzles, looks awesome.” ~ AntyApps

“This is one of the best-looking puzzles that I played in a very long time.” ~ Just Good Bites

Creating Open Bar was a lot harder than I initially thought, but it was fully worth it.

The numbers

  • 2507 changelists
  • 508 cups of coffee
  • 205 walks to breathe some fresh air
  • 112 hours of overtime
  • 94 interruptions by our cat Gigi
  • 39 walks to convince ourselves that everything’s going to be fine
  • 18 playtesters
  • 1 year of development

That was Open Bar: The Making of an Indie Game. If you liked it, go get the game, it’s available on the App Store. It’s a good game, I promise! Don’t forget to follow us on Facebook & Twitter!