ContributionsPostmortem

GreenCod’s Bad Traffic (iOS & Android)

September 25, 2013 — by Mariia Lototska

main

ContributionsPostmortem

GreenCod’s Bad Traffic (iOS & Android)

September 25, 2013 — by Mariia Lototska

GreenCod opened shop in Bermuda in 2009, but has since relocated to Vancouver, BC. Mobigloo has released mobile games since 2003 and is based in North Carolina. Bad Traffic is their latest concoction: a fast paced traffic control game for mobile. Alain-Daniel Bourdages, Founder of GreenCod, talks about their game.

Greencod

22

The Team

Bad Traffic is a collaboration between two studios: GreenCod and Mobigloo. Their founders met at a conference where Alain-Daniel was collecting feedback on what can generously be called an early demo of a game. Mobigloo’s founder comment was: “This looks like crap, but we could turn it into something good.” And this is how the relationship between GreenCod and Mobigloo started.

Before Bad Traffic, there was Traffic Mania, our first foray in the traffic control genre. The player had to avoid crashing cars on nine different layouts in classic endless mode, where the difficulty ratchets up all the time. It was far from a commercial success (maybe being an exclusive for the BlackBerry Bold was not the best idea), but it was well-loved by the players, so we decided to rebuild it for other platforms. We had the graphics, we had the code, so how long could it take? <insert sarcastic comment>

Make Losing Fun

At first, the game had simple traffic control rules: play until you crash a car, the game stops and you lose. The game was working well, but there was one thing that felt wrong: the ending was too static and sudden. The game literally stopped when two cars touched. So under the guidance of “make losing fun,” we introduced a little bit of a physics engine to simulate what happens after the crashes. It turned out to be such good idea that for the next couple of hours, we started new games, crashed cars, and kept doing it all over again. To make it even more interesting, we would send extra cars to make the crashes more epic. Clearly, we had to have a dedicated crash mode.

Turn It Into a Game

Now we had this new play mode with crashes that was pretty entertaining, but how to turn it in into a game? We had been doing reasonably well so far with the development, but this is where we blundered and spent way too much time figuring things out. What should have been a quick exercise of prototyping turned into three solid months of poking around many, many different directions. The crash mode was new, fairly unique and could turn out to be the focus of the game. So naturally, we checked out how far we could take it.

The first take on crash harkened back to the successful Burnout series: the player would get points for causing as much damage as possible. Sounds good in practice, and we even shipped a version of the game on BlackBerry tablets with that mode. However, we did a poor job of explaining it. Players were left with a convoluted way of scoring points they barely understood. Console rules do not necessarily work in mobile games.

Console rules do not necessarily work in mobile games.

Then we tried a version of the endless mode where the player had to survive as long as possible given 30 seconds of playtime. There were bonuses on the roads you had to collect to extend the time and get extra cars. The flaw of this version was that the bonuses didn’t add much to the game play. Next!

For a while, we tried different control schemes and played with the importance of the types of collisions: head-to-head, T-bones, etc. We came pretty close to an interesting game mechanic allowing the player to draw the path of a car on the screen, à la typical traffic control. However, it still didn’t add anything to the game. Maybe we were on the verge of finding a really great thing there, but the project was already way behind schedule, so… close, but no cigar.




We still had not figured out the proper gameplay for crashing cars, but by that time, we realized that the game wouldn’t be only about crashing. Whichever mechanic we tried, it was not deep enough to support an entire game. That meant the game would have two modes of play: save (which we knew worked, due to having a precedent) and crash.

Around the same time, we started to question the endless nature of the game. Endless modes are good for developers, as they require comparatively few assets and content can stretch pretty far. However, they are also fairly repetitive, and there is practically no sense of progression for the player. Infinite runners combat this by changing environments and rewards, but in our case, the player was stuck on a static level. Furthermore, the player motivation to play is to beat their best score, which stops being fun pretty fast.

Save Mode
We broke the endless play into different challenges through which the player has to progress.

In order to give more incentives to players (and because we are masochists), we turned the idea on its head: we broke the endless play into different challenges through which the player has to progress. Beat level 1 to access level 2, and so on. Creating a level progression is ridiculously more work than having multiple endless levels. However, it worked out pretty well in the end: instead of trying to beat their score, the player now has the motivation of discovering what the next challenge is, as well as a clear sense of progression.

There is also another subtle difference: now the player could win. In an endless mode, it doesn’t matter how good you are, you will always lose. Turn it into a progression of challenges and the psychological effect of winning plus the sentiment of progression and discovery made the game much more engaging.




Crashing and Reversing

The introduction of a progression of challenges considerably changed the gameplay problem of the crash mode. In order to keep the challenges simple, we had to provide a single goal for the player to reach. So it boiled the problem down to finding a simple way to express carnage, which is what the crash mode is about.

Counting the number of vehicles crashed would have been perfect, except that it is too easy to crash a car, and therefore not a good measure of the skill of the player. So we introduced the concept of exploding cars: deal enough damage to a car, and it will blow up. Car explosions were good for the pace of the game: they remove clutter from the screen, push the vehicles clumps around and force the player to re-evaluate the on-screen situation.




Explosions
Car explosions were good for the pace of the game.

The next best thing for a simple carnage measure was counting explosions. Almost done! We still needed a limiting mechanism, so we settled on time: cause X explosions in Y seconds. This was in the spirit of keeping things simple: all the players are familiar with a limit on time to complete a level. In future updates, we might introduce an advanced variation where you only have a certain number of cars to crash.

So we finally had the win and lose condition of the crash mode figured out, after months of trying different gameplay scenarios. The other pieces fell in place easily after that, as we couldn’t have different control mechanisms between the crash and the save modes. In the end, there are only a few subtle differences, like the rules for what to do when a speeding car comes up behind a slower one. Having the same rules and mechanics in both modes ensures that the game doesn’t feel like a mishmash of different parts.

Our first implementation of the progression of challenges had one save mode followed by one crash mode, rinse and repeat. I couldn’t tell you how often I was confused with which mode I was playing before realizing it had to change. We ended up with one progression per game mode. What is shameful is that it took so long to realize we had a problem. This is a Game Design 101 lesson learned: do not go against the player’s instincts. Doubly so when the developer cannot even get it straight.

The Angel and Devil

Angel and Devil
The idea of the Angel and Devil as characters trying to influence the player seemed fairly obvious once we found it.

The game was starting to play-test pretty well. Gone were the days when the tablet was politely handed back after 45 seconds with a “It looks nice.” Testers routinely played over 10 minutes, and we didn’t need the comments to understand they were enjoying it.

We were happy, but felt it was missing something. After looking at successful titles, it became apparent that we could use some characters or a story. Cute characters can never hurt, right? We didn’t want a full-blown storyline, but a nod toward some background material on the characters. The game was going after casual, mainstream players, and a story and characters could help us with engagement.

The idea of the Angel and Devil as characters trying to influence the player seemed fairly obvious once we found it, as opposed to Oscar the Squirrel Tram Conductor. There is no way to quantify it (although that would be an interesting A/B test now that I think of it), but I believe the players connect a little bit with our characters, and it helps create an emotional bond with the game.

Our First F2P

Bad Traffic is not the first free game we launched, but it is the first game we designed around the principles of free-to-play. From the start, many smart people told us it is very difficult to make a level-based game like ours fit into the free-to-play model. I think Candy Crush has buried all those naysayers by now, but they sure were right about our implementation. It contained many flaws:

  • Too Generous – It was too easy to earn the in-game currency, so there really wasn’t a reason to buy more of it.
  • Separate Screen for Purchases – The player had to buy items from a separate screen, before he would need them, à la RPG, instead of offering them when the player needed the items.
  • No Reason to Upgrade – The game never made a compelling argument to the player why he should upgrade his cars, which was one of the important monetization points. Monetization item were just there, and we were hoping they would be a big draw. Well, they weren’t.

Those are the things we have figured out since launch. There are probably five other critical flaws any monetization expert could point out that we haven’t yet discovered. Nonetheless, we have reacted to what we learned: our one successful in-app purchase item now is the “Insurance Pack” that we offer at the end of a failed challenge. Basically, it is a continue mechanic where we offer the choice to the player when they are most interested in it: do you want to continue this game or not?




We are also much less generous, but that has not changed the fundamental truth that we are not offering compelling enough items to acquire. We have plans to change what you can do with the in-game money dramatically with an upcoming update.

That is the reality of free-to-play: you have to keep updating the game with more of what works.

Save Streak
That is the reality of free-to-play: you have to keep updating the game with more of what works.

Keeping it Simple

“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.” – Antoine de Saint-Exupery

One of the principles we tried to stick with is simplicity: to remove any feature that didn’t add to the core experience, to narrow down the set of rules, to reduced player confusion where we could. The end result is certainly not a perfect example of simplicity and never was intended as such. However, the importance of keeping that principle in mind certainly is one of the take-aways of this project.

The other take away is “Don’t take 14 months to ship a product”, but I don’t have a fancy quote to go along with it…

Bad Traffic is available on Google Play and iTunes AppStore. Currently GreenCod is working on a new version of their 2011 title, Pinball Deluxe.

Comments




Mariia Lototska

logo
SUPPORTED BY