On the 6th of January, 2014, I joined IsCool Entertainment as a game developer on the recently released mobile game named Bazoo. It was a long time ago and the project went through a lot of phases. Let me tell you its story…
[All illustrations courtesy of IsCool Entertainment.]
The story of Bazoo begins near 2013, when the mobile market was overwhelmed by match 3 games following the successful Candy Crush Saga released the year before. One producer at IsCool rightfully saw in this trend the perfect conditions to create a game out of his younger memories.
The man had a lot of fun playing puzzle games with his friends in high school and he wanted to bring back this feeling to today’s players. This was quite a good idea since puzzle game is a popular genre today and the gameplay of some past successful puzzles are not exploited today on mobile. Also, multiplayer mobile gaming is a really hot subject, so it is a match!
At its core, the launch of this project can be expressed in few words: let’s do a real-time PvP mobile puzzle game!
At the time, the company’s expertise was into developing and publishing its own games mostly for Facebook with some attempts on the mobile market. Some of these games were played asynchronously in multiplayer. In a way, almost everything in the pitch of Bazoo was new for us. Also, most match 3 games worked on the saga mode, and real time PvP gaming was quite new and still had to prove itself in a business point of view. In order to tackle these problems down, we had to remove some constraints from the initial pitch, starting with the most obscure areas: goodbye real-time, goodbye PvP, our first try on mobile gaming will be a saga-like puzzle game.
A long way to go.
Two thirds of the idea are already out. It was for sure quite far from the initial project’s pitch, hopefully it was a game seemingly reasonable according to our expertise in game development. Actually, I think it is important to emphasize how compromising from the very beginning put us on a path to the game we actually wanted to make.
When I entered the company, the project was already six months in the making. There was a lot of questions about it. Its name has been changed at least once to become Bazoo Block, and its assets were repurposed from another project. The game was quite fun and incredibly beautiful but the team was not exactly thrilled by the product. Actually the subject of online PvP gaming was still present in their minds.
The gameplay at the time was mostly a mix of Baku Baku Animals and Puzzle Fighter, plus some nice features of our own. In short, the player had to survive a fight against a computer-controlled opponent where both characters would receive a sequence of blocks from a launcher to assemble and destroy. Depending on the destructions, a varying quantity of extra blocks would fall in the opponent’s game board, making it harder to clear and eventually filling it completely. The game ended when one player could not receive any new block from the launcher. Chained destructions (a.k.a. combos) were rewarded by an increase in the intensity of the resulting attack.
The first reader to send me a complete list of things in this capture that have been removed from the initial release of Bazoo wins a t-shirt.
As you can see, the core gameplay was very similar to what we have today. From Baku Baku Animals specifically, there was the animals and the foods: four types of animals would destroy their associated food. From Puzzle Fighter there was the super blocks and the patterns of the attacks: grouping similar foods in a rectangular shape would increase their strength in the attacks and the blocks resulting from the attacks would fall in various specific patterns more or less difficult to clean up. On top of this we added some power ups and variations in the gameplay.
The game followed the saga models of this time: the player evolved on a map where he would have to solve puzzles of various difficulties in order to access more puzzles. There were levels where he had to fight against an AI and other levels with a single game board and played in a time attack mode where he had to destroy a specified amount of a given food in the alloted time.
One of the map on which the player evolved.
As the player progressed on the map, its XP gauge was filled. Then every once in a while, when the gauge was full, one of the animals received a level-up, thus making stronger the attacks resulting from the blocks it would destroy.
Then the summer came and half the staff left in vacations. The project slowed down so… Hey, it’s a good time for R&D! What if we connect two devices over the network and make each one to appear as the opponent of the other? Let’s try and see… And there we had our first real-time online PvP mobile game :)
In a few days we went from a classic saga puzzle game to a unique PvP puzzle game. This prototype was a life changer and thus brought a lot of questions. What was the future of the saga mode? Should we throw it, or keep it as an alternate game mode? What if the player has no network? Then went a period of approximately four months during which we maintained the saga in the game until we finally accepted to trash it so we could focus on the game we actually wanted to make.
We are in September 2014 and we have a puzzle game that can be played against other players over the network. Ready for the release? Well, not quite…
Are we there yet?
Let’s get it straight: at least eighty percents of your game is not related to the gameplay. As you may have deduced from the release date of Bazoo and the above paragraphs, we were quite far (like two and a half years) from having a decent game. Here are the subjects we had to work on once the core gameplay was satisfying.
First of all, the game now being online, we need a server and thus more developers. From now on consider that each feature will have a server part and a client part. Twice the work and more human synchronization!
Introducing the game to the players is maybe one of the most difficult parts in the development. When you write a software, everything seems so obvious… Then you run some user tests and all you see is people entering the application with no idea of what to do next, struggling to launch a game during several long minutes. Seriously, do we really have to explain that the rabbit eats the carrots and that the dog eats the bones?
Yes, we must explain it. As a player who skips most tutorials it was quite difficult for me to accept that, but actually several user tests have shown us that we cannot expect a random player to understand the game during its first experience. Every effort put into making it easier for the player to grasp the game is a good move.
So we have added a tutorial in the game, where the player had to perform some fixed moves to see the matching in action. After these actions we would let the player finish the fight against an AI. It was better than no tutorial at all but not enough. The main problem was that the player had to understand the game almost immediately during its first launch. Also he could lose this first fight, so we had to force him to do it again. Finally, for the players who understood the game, this unskippable tutorial was frustrating.
Eventually we replaced this tutorial with a slideshow explaining the basics of the game. This is the first thing you see when you install the game today. We also force the player to try some fights against an AI before entering the arena and contrary to the previous version of the tutorial he can do it at his own pace.
It is well known on the mobile market that your game cannot have good retention metrics without notifications to bring back your app in the player’s interest, for better and for worse. We initially opted for a tool named Parse to handle our notifications. The service was backed up by Facebook so it seemed quite solid aaaaand it has been discontinued one year later. This, kids, is how you see yourself trashing your perfectly good code. We then went with Firebase for the notifications, let’s hope this one will last.
Once the players are in your game you will want to gather metrics so you can adjust the game both to offer them a better experience and to optimize your revenues. For example, we need to track how long the players wait before finding an opponent and arrange the matchmaking to offer them someone at their level in a short time. Typical analytics tools consist into sending an event via their SDK on the specific actions you want to track as they occur in the game. We initially went with Upsight which eventually upgraded its version and money plan in a way that would not fit our needs anymore. Thus we changed for a brand new tool named Omniata, aaaaaand it was discontinued four months after we added it. We then went with Firebase for the client and a home-made tool for the server. And this, kids, is how you write three times your analytics code.
We tried several variations in the gameplay before finding something satisfying. There was a time when the player could use some defense and attack items during the game. It was a cool feature that no one ever used. Players were so focused on the combos that they would go to the end of the game without launching a single power up. We also added a minor change in the way the blocks are controlled such that they can stick to the walls when they are rotated, thus allowing some moves that could not be done before.
Some power ups the player could use during the fight.
There is a huge focus on the customization of the player’s avatar in Bazoo. It is a feature initially implemented with a simple collection of outfits, then it has evolved to become what it is today: an awesome catalog of items that can be individually assigned to various parts of the character.
Look at this! Isn’t it awesome?
Since Bazoo is a pure competitive game it could not exist without the ladders. We have added the world-wide ranking by assigning an Elo-like score to each player and the leagues were added soon after. The first implementation was quite overcomplicated with its groups of various sizes and its skins in the prize pool. We had to simplify the whole thing to make it appealing and it resulted in what you can see in the game today.
What is an online multiplayer game if the players cannot interact before and after they met? Certainly not a game I would like to play. So we added the messages on the versus screens, then we introduced the buddies (i.e. last opponents and Facebook friends) and the chat. On the game modes we had also implemented a matchmaking for players on the same WiFi but unfortunately it was a feature that was almost not used, so we trashed it. Finally the clans where added, allowing the players to team together.
Adding the clans in the game was quite an adventure.
Another nice feature is found in the Battles, allowing the players to fight with their friends or to organize competitions with other players. The first implementation allowed the players to enter multiple battles at once but there was nothing to win but pride. This was a nice feature, maybe a bit overcomplicated again. So we cleaned it up. For the second version, which you can use in the game today, the player can enter only one battle at once and there is a prize for the top ranked players at the end of the battle.
Bazoo being an highly competitive game it was important for us to provide a way for the players to stream their fights and to be able to watch the fights of others.
The first streaming feature was done with the mobile SDK provided by Twitch. Aaaaaand it was removed four months after its integration, when Twitch stopped supporting it (I see some kind of pattern here…). Today’s players can stream with ReplayKit on iOS and with any streaming app on Android.
On top of the screen was a drop down chat with the spectators on Twitch.
We also provide in-game features to watch games so one can study the skills of others and improve his owns, and also because it is fun to watch. The first one is a replay feature allowing the players to watch their last fights and the last fight of other players. The second one is a live streaming feature, enabled for everyone. Every fight can be watched by the other players, in which case the spectators are able to send cheers to the fighters to show their support.
Allowing the player to identify with its Facebook account has several advantages both for the player and the developer. First of all it is certainly the easiest way to link the player’s account on several devices. It is also typically associated with an exclusive bonus in the game and provides a way to offer extra resources to the player’s friends via a gifting mechanism, a thing we have added quite soon in the project. On the developer’s side it is a powerful tool for virality. We already had a plugin named EziSocial to handle Facebook in the saga version. It was a good tool for an initial integration but when we needed up-to-date Facebook services we had to change for something more complete. Thus we went with the Facebook plugin of Cocos2D-X. Again we had issues to keep track of the most recent Facebook API so we finally wrote our own C++ bridge to the official Android and iOS Facebook SDKs.
Apple’s Game Center and Google Play Games were also added to allow the player to use his account on several devices.
Being able to keep a dialog and to answer efficiently to the issues encountered by the players is a key point in keeping your community happy. We use Helpshift for this, which provides an nice interface for the user to access a lot of documentation and a great chat interface with our team. We never had to replace it so I guess it is quite a solid tool. Kudos to them!
By looking at the above captures you may be wondering if they all come from the same game as they are so different from each other. Finding a great UI was a surprising long process. There was the funny one in the saga, then the pirate theme, then another pirate theme, then the flat one, and the modern one.
One game, five homes.
There was also a landscape version of the game for a short time, developed for the tablets and for the Apple TV (yep, we also added support for the Apple TV before dropping it). The landscape mode was very pleasant to use, unfortunately it made the development in no small way harder since every screen had to be composed and tested for both layouts. We thus had to abandon it and go with the portrait version only.
The landscape version made the fights incredibly more intense but was unusable on a smartphone.
The key to success
Creating a game is a lot of work, creating a good game is an order of magnitude harder, and creating a successful game is even harderer. As you may have read before there is no recipe for success in this industry, that is why studios appear and disappear quite frequently. This is a market where a success is a surprise even for the game’s creator and where the ten top grossing titles take literally all the money. So how does one can make a living in developing video games?
Even if there is no recipe for a success there are some keys toward making a great game: do a game you like, keep an eye your metrics, watch the tendencies on the stores and take care of the design to be as good as the bests. Gameplay is important, also are the graphics, also is marketing, and so on. Even if you don’t end with the game of the year, you may still get a nice and working product, commercially speaking.
Then there is trial and error. Some developers try several games at once and trash the ones that do not work, others invest on a single game and polish it until it becomes good. As you may have deduced from this article, we are of the “other” kind, pushing as far as possible the projects in which we believe the most, fixing on the way all the inefficient parts we encounter. Will it work? Maybe there is no market for this game, maybe it will explode. There is no way to tell but we are very proud of the product we have created.
In my opinion the team did a very good job with Bazoo. Going from the initial saga mode to this awesome online PvP puzzle game was done efficiently by compromising among fast and incomplete integrations, trashing the stuff that did not work, hopefully without having spent too much time on it, and refining the stuff that did work, once its usefulness was backed up by good metrics and user tests. I would for sure do it again!
I hope that this view on the developer’s side was worth reading.