Author: Maxime

A lot of good news in this post. First, Open Bar has been selected for the PAX East Indie Showcase! We’re going to be in Boston from April 22 to 24 to show our game to thousands of players. That’s pretty awesome if you ask me.

Now, you asked for it and we delivered: Open Bar is coming on the Google Play Store on April 21, just in time for PAX! You’ll be pleased to know that the Android version will be free of charge. YES FINALLY OPEN BAR WILL BE FREE, YOU HEARD THAT, TOUCH ARCADE? Obviously, we have to make a living so it will be ad-supported. However, you’ll be able to remove ads and get the same premium experience than the iOS version.

We’re also preparing an update on iOS that will, among other things, add achievements, bring a new and sexier icon and overall contains a lot of misc. improvements.

BUT THAT’S NOT ALL! To celebrate PAX, the iOS version will be 100% free during the whole event!

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.

After 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.

Production

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.

Reception

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!

It’s been a long ride, full of obstacles and challenges, but it was fully worth it! The past weeks have been especially exhausting for both of us. This week-end, we’re gonna take a well-deserved break and enjoy an IRL open bar. 😉

Stay tuned because in the next few weeks, we’re gonna post Open Bar: The Making of an Indie Game. This story is gonna be 100% transparent, full of early prototype screenshots, what went well and what went wrong. Whether you’re a game developer, an indie games enthusiast or just curious about the whole process behind making games, I’m sure you’re going to like it!

Yesterday, Julie and I presented Open Bar to about 600 people at IGDA DemoNight 2016 in Montreal, Canada. That was a very exciting experience (although a bit stressful)! The public response was very positive: the crowd cheered at our motion-design animations… we didn’t saw that coming! A girl came to see us at the intermission to tell us she really liked the game and thought the visual design was pretty slick. Unfortunately we had to leave in the middle of the show, because we had to go back to Quebec City.

I found the public really nice and supportive. It’s harder than you think to show off the game you’ve worked on for the past months / years. We had the chance to show a game that’s finished, but since it’s DemoNight, most presentations were about games in the middle of their development cycle. Things aren’t perfect. Graphics glitch. There’s missing sounds, etc. You want to impress the public, but it feels hard to do that with a product that’s nowhere near completed.

After months of working on a game, you don’t see it in the same way someone will for the first time. You’re not amazed anymore. It’s just your game. You know every little detail by heart. You’ve seen its animations thousands of times. You’ve heard its music so often that you usually turn it off. You become very critical about your game, more than you should. And then you look at other people’s games, and you’re amazed by what they did.

So it’s a really, really good feeling when people cheer when they see your game for the first time in an event like that. It gave us the pat on the back we needed to keep on going.

Speaking in public is always a nerve-racking experience, even more when it’s not in your native language. I publicly spoke maybe 4 or 5 times in English, and every time it was a big challenge. In French, if I mess up I can quickly improvise something and it’ll come out naturally. In English, it doesn’t come out as easily.

For me, with over 10 years of experience creating video games, I built enough self-confidence to fight stress and maybe even look a bit relaxed on stage (although I’m not). For Julie however, she’s new to the video games industry, so it must have been quite the experience. I remember when I spoke at GDC 2008: it was, without a doubt, the most stressful experience of my life. I felt like an impostor. I was quite junior with my 3 years of experience in games development, and there I was on stage giving a talk with notorious industry veterans.

All in all, DemoNight was really cool and I certainly plan on showing our next game there in a year or two!

The Reality of AAA Games Development or: How I Learned to Stop Worrying and Go Indie

Back in 2005, I remember my boss asking me where I’d see myself in 10 years. I answered without hesitation: I want to be a software architect on a big-ass AAA project! The dream came to life a few years later, when I started working on Assassin’s Creed Syndicate as – wait for it – software architect. I was fulfilling my dream of becoming a well-respected game developer, working on a prestigious AAA franchise.

Then I suddenly quit and started a small indie games business with my girlfriend. Some of my friends and family found that move… let’s just say… bold. They wondered why I left a safe, well paid job, with tons of advantages, including the excitement and fame of working on the next game everyone will talk about.

On my last day at Ubisoft, while I was saying goodbye to my colleagues, nobody asked why I was leaving to work on my own games. Even people who barely knew me had a pretty good idea. A lot of them were actually envious, although they worked on Syndicate too, realizing one of their own dreams. I’m sure that many professional game developers might have a clue about why I made this move.

So, I decided to write about the reality of AAA games development or: how I learned to stop worrying and go indie.

Modest Beginnings

In 2005, Ubisoft announced they would open a new studio in Quebec City. This is about 250 km away from the famous Ubisoft Montreal studio, that created all kinds of obscure games like Prince of Persia: The Sands of Time, Splinter Cell & Assassin’s Creed. I was recruited from day 1, together with about 30 other employees. You can imagine that I was really excited. I celebrated by spending my future paycheck on a brand new $2000 guitar. (5 years later I totally stopped playing guitar. Yeah, not my best move.)

Most people who start a career in game development, whether in design, art or programming, are very passionate. They love playing video games, and they love creating them. During my first weeks at Ubisoft, I couldn’t believe that I was actually getting paid to do this! This was better than holidays.

For the first two years, I worked on small PSP titles: Open Season & Surf’s Up on the Playstation Portable. Those are very average games, not especially good nor bad. However I had a lot of fun working on them. I’ve learned a lot, and I made very good friends. The teams were pretty small (between 15 and 25 people, if I remember correctly), so everyone knew everyone else. It felt like a small family and the team spirit was good. In retrospective, we were a bunch of noobs who had a lot homeworks to do.

The thing is, we wished we’d work on bigger projects, AAA projects. It’s not super glamorous when you tell your friends you’re working on some kids movie’s game. Nobody starts a video games career to work on that kind of title.

The PoP Years

After Surf’s Up, our studio’s director met us in a conference room (yeah, the entire team fit in a single room… ahhh the good ol’ days). He announced that our next project would be the Wii version of the upcoming Prince of Persia game. I distinctly remember some kind of awkward silence after. Nobody knew if it was good or bad news.

Then someone shouted: “YES!”

Of course, YES. This was WAY better than our previous projects. It wasn’t Assassin’s Creed, but who cares. I remember being a bit disappointed by the console (back at the time, I was super excited by the PS3, not so much about the Wii), but all-in-all, it was very good news.

The project lasted about 3 years, and became known as Prince of Persia: The Forgotten Sands. It wasn’t a port from the 360/PS3 version: we made a specific version just for the Wii. All in all, it’s a really good game. If you didn’t play it back then, go dust off your Wii and give it a try!

Over my whole time at Ubisoft, this is the project I’m the most proud of. I had a lot of fun, and I had ownership. By that, I mean that I strongly believed that my work had a major impact on the game. My contribution was significant, and when I was playing the game, I could see it everywhere. So, obviously, I was super motivated. I wanted that game to be the most awesome game ever. Most developers know that feeling very well.

At its peak, the team size was about 75 developers. It’s a big family, but still a family. Over the course of the project, I had to interact with most of these people. I’m pretty sure I talked at least once to everyone on the project. You might wonder why I focus so much on team sizes, but more on that later…

AC3 WiiU

After PoP, I contributed on several games here and there, and eventually landed on a technically very challenging project: porting Assassin’s Creed 3 on the WiiU. This was very different from my previous work. The team was super small: we were 2 programmers at the beginning, and at the peak I think we were like 15 or something.

I was pretty excited by the challenge. Most people at Ubisoft didn’t think we’d be able to pull that off. All Assassin’s Creed games are very, very intense games in terms of CPU & GPU performance. Believe me, your console is pretty much at its maximum capacity when running around in a big city like Boston (or London). The WiiU was less powerful than the PS3 and XBox 360, at least on paper, so the odds weren’t on our side. Even worse: we had to make a straight port, that is no data changes, just code optimisations. It’s much cheaper to do a straight port than to downgrade all game assets.

After about a year, we reached a point where it became obvious that we’d successfully port the game with similar performances than the 360/PS3. It was a huge success: even Nintendo engineers were surprised we made it. Life was great.

The downside was that the second half of the project was a bit boring. The challenge was gone. Port code, fix bugs and optimize. Rinse & repeat until the game is shipped. Overall I keep a good memory of this project, but by the end I was ready to do something completely different…

Tasting the Forbidden Fruit

After AC3, I worked on 2 internal pitches. For legal reasons, I can’t say much about those projects, but they were so important to me that I need to take some time to talk about them.

On the first project, we were a team of about 6 developers, all very senior. It was a multiplayer game, and our goal was to create a functional prototype in about a month. Our days were somewhat like this:

Play the game together

List the features and changes we wanted to see in the next version

Implement them

Repeat until we have a cool prototype

The team spirit was sooo good! Our motto was “on est crinqués!”, which more or less translates to “we’re so hyped!”. During our play sessions, we were so excited we were screaming and shouting all over the place. I think it bothered colleagues working next to us, but hell, we had so much fun. I didn’t feel too guilty.

Since we were such a small team, we had to break down the traditional jobs barriers. Everyone had their saying in the game design. A UI artist made the level design, because we didn’t have a level designer with us. I did gameplay programming, which isn’t my speciality at all (I’m more of a low-level, engine & graphics guy). But we all really enjoyed it.

Unfortunately, for various reasons, the project got cancelled.

Then I started to work on another internal pitch, with an even smaller team: 2 developers + 1 producer. This project definitely had that “indie” feeling. It was again a multiplayer game, and again we made a pretty awesome prototype in a few weeks. Every day during lunch time, we invited everyone in the studio to play. We even organized an internal tournament which attracted around 60 participants.

But again, the project got cancelled.

I was never as happy at Ubisoft as during those 2 projects. I worked with very talented & motivated individuals. Because of the smaller team sizes, I had my say on the creative side of things. This was a nice change – being more of a technical guy, I could never do that before. And I absolutely loved it. When you work on a small project, your contribution is, obviously, HUGE. So is your ownership. And so is your motivation.

One of my former colleagues nailed it when he said that I tasted the forbidden fruit. Once you’ve had that feeling, you can never go back.

AC Syndicate

Then, the studio received the mandate of leading the next Assassin’s Creed title: Syndicate. We knew the AC franchise very well: we collaborated on every title since Brotherhood. However, this was not a collaboration like before. For the first time ever, an Assassin’s Creed game would be led by the Quebec studio instead of Montreal. This was a big achievement, but I wasn’t happy at all. The memory of my 2 beloved projects was still fresh. I knew I’d have to work on AC, there wasn’t any way around it.

As predicted, I started working on Syndicate very soon in the development cycle. I wanted to give it a try, even though I feared I wouldn’t like it at all. At first, since there wasn’t a lot to do on the technical side, I collaborated a lot on AC Unity with the Montreal studio. I worked on cool new techs developed for ACU, it was fun and challenging. I had a good relationship with most of my Montreal co-workers (even though it’s harder to develop a good relationship when you mostly communicate by email). I continued collaborating on ACU every now and then until they shipped.

After a few months, Syndicate started for real. The team was getting bigger and bigger as we entered production. For me, this is the root of all issues on AAA games: big teams. Too many people. Syndicate was created with the collaboration of about 10 studios in the world. This is 24 hour non-stop development. When people go to sleep in one studio, it’s morning in another one.

With so many people, what naturally occurs is specialization. There’s a lot of work to do, and no one can master all the game’s systems. So, people specialize, there’s no way around it. It can be compared to an assembly line in a car factory. When people realize they’re just one very replaceable person on a massive production chain, you can imagine it impacts their motivation.

With specialization often comes tunnel-vision. When your expertise is limited to, let’s say, art, level design, performances or whatever, you’ll eventually convince yourself that it’s the most important thing in the game. People become biased towards their own expertise. It makes decision-making a lot more complicated. More often than not, it’s the loudest voice who wins… even if it doesn’t make much sense.

On large scale projects, good communication is – simply put – just impossible. How do you get the right message to the right people? You can’t communicate everything to everyone, there’s just too much information. There are hundreds of decisions being taken every week. Inevitably, at some point, someone who should have been consulted before making a decision will be forgotten. This creates frustration over time.

On top of that, there’s often too many people involved in making a decision. Usually you don’t want to make a decision in a meeting with 20 people, it’s just inefficient. So the person in charge of the meeting chooses who’s gonna be present, and too bad for the others. What it’s gonna be? A huge, inefficient meeting where no decision is taken, or a small meeting that goes well but creates frustration in the long run?

Being an architect, I had a pretty high level view of all technical developments on the project. While it sounds cool, it has its disadvantages too. The higher you go up the ladder, the less concrete impact you have on the game. You’re either a grunt who works on a tiny, tiny part of the game (“See that lamppost? I put it there!”), or you’re a high-level director who writes emails and goes to meetings (“See that road full of lampposts? I approved that.”). Both positions suck for different reasons. No matter what’s your job, you don’t have a significant contribution on the game. You’re a drop in a glass of water, and as soon as you realize it, your ownership will evaporate in the sun. And without ownership, no motivation.

I could go on and on. There’s tons of other reasons why AAA projects are not satisfying. Don’t get me wrong: it’s nothing specific to Ubisoft or Assassin’s Creed games. This is an inevitable side effect of creating huge games with an enormous team.

I have to add that, obviously, some people are motivated. Those are usually juniors and people who never got the chance to work on a AAA project before. But when you’ve done it a couple of times, the excitement disappears, and you’re only left with the sad, day-to-day reality. That’s a huge problem for studios working on AAA projects one after another. Senior staff gets tired and leave.

Taking the Leap of Faith

Since my very beginnings at Ubisoft, I knew I wouldn’t spend the rest of my days here. I already dreamt of starting my own indie company. Making my own games. Back at the time, I didn’t know much about making games. I still don’t know a lot, just a tiny bit more.

Indie games don’t suffer from big projects issues. I think the ideal team size is around 5-6 people. That’s when the team spirit is at its highest, as well as ownership and drive. You’re not wasting any time with endless email threads and bad communication. There’s a lot less specialization, because a handful of people are doing everything. The job isn’t tedious and rewards you every day.

For me, going indie also means I can work on non-technical stuff. I like tech, but I also love the creative aspect of games… gameplay, visuals, sounds, ambiance… the whole experience. Only indie games will let me cover all aspects of the creation process.

So that’s it. That’s the #1 reason why I quit Ubi to make indie games. I’m sure if you ask other developers, they’ll tell you another story. Some of them really like it, I’m sure. Others might be unhappy for a completely different reason.

For me, this leap of faith was the right and only thing to do. Go take a look at our first game, it’s a nice puzzle game for iOS and Android!

UPDATE #1 – January 23rd, 2016

Hey guys and gals! This post is way more successful than I thought! Thanks to everyone who has taken an interest in my story, I’m really touched. I’d like to answer every question & feedback, but it’s getting harder and harder to keep up with everything. Still, rest assured that I read every single comment.

UPDATE #2 – January 26th, 2016

My ex-coworker Jeff wrote a great follow-up to this article that shows another perspective on the subject. He’s a senior level designer who’s worked on Syndicate as well, and left for similar reasons.

If you wanna hear more from us, follow our indie adventures on Facebook and Twitter!

It’s official: Open Bar is gonna be available on the App Store January 28th! Last week, we put a great deal of effort into creating a compelling website for the game. Go take a look at http://openbargame.com and let us know what you think!

Thanks to everyone who participated in the beta, you helped us create an even better game experience! We’ve added tutorials to improve player comprehension and fixed many bugs.

We’ve been working on Open Bar for about a year now, and it’s been a great experience. Hopefully, you’ll like the game as much as we loved creating it!

So, after about a year of part-time, then full-time development on Gingear, we’re finally online! Lately, we worked super hard on finishing our first game, which is reeeaaaallly close to being done! 😀

We’re currently working on polishing our website & social media presence. A big announcement is coming in January, so stay tuned! In the meantime, you can always follow us on Facebook, Twitter & YouTube.