Grantoo is now Fuel

 

fuel_logo-01

We started Grantoo with the vision of leveraging peoples’ love for games by connecting them with charities that helped address the growing tuition problem. Along the way we experienced ups and downs and learned many hard lessons. While our charitable tournaments provided some success, our vision to make a huge impact was limited – the learning was tremendous. We realized that there is a big opportunity in mobile games and if we succeed, we will be able to make a larger contribution in solving the tuition problem.

As we delved deeper into mobile, and the power of connecting people with an ever-connected smart phone, we realized that by marrying the fun and engagement of mobile games, we could unleash the innate competitive nature of us humans. Thanks to our partnered success with huge publishers like Miniclip and Spry Fox, we built a unique multiplayer service that grabbed the attentions of millions around the world.

In 9 months, we have seen users grow from 5 million in January 2014 to 24 million in August 2014. We attracted investors – Middle East Venture Partners and Rising Tide Fund to fund our Series A. Our success attracted the best people in the industry to join us in solving the broken experience of making games more fun when played with others.

We are pleased to welcome Shrikant Latkar (former CMO of InMobi) as our CRO, Mike Upton (who has built multiplayer experiences for Sega and EA) as our Executive Producer, Jeremy Nusser (former VP of BD at Playspan, acquired by Visa) as our SVP of BD, and Clive Jeffries (former Relationship Manager at Playspan, acquired by Visa) as our VP of Strategic Accounts.

 

All this success, led us to think about who we are, what are our aspirations as a company are, who we truly represent, and how we want to be perceived by consumers.  decided to launch ourselves as a new company.

group-shot

We homed in on the name Fuel – a name that represents what we bring to the mobile game industry, and our vision for delivering delightful experiences by connecting consumers with each other through a powerful common bond – the games they love.

Everything leading up to the launch of Fuel has been humbling, yet an incredible accomplishment. The dedicated team behind Fuel has settled for nothing less than creating a world-class platform that will take mobile multiplayer to uncharted territories and delight players around the world.

We’re proud to have built outstanding technology that continues to challenge and push the boundaries of social experiences on mobile. It’s been a massive undertaking, but the results speak for themselves.

Fuel’s vision is to enable developers to continuously delight their gamers through personalized experiences and features based on our deep insights into player behavior.Fuel is also an attitude that drives all the crucial decisions we make in order to do work we’re proud of. Fuel has become the verb of choice when discussing how to enhance our partner’s games and how we approach the creation of memorable experiences for their players.

We are excited to partner with the best publishers in games while continuing to deepen the relationships we have with the outstanding studios we work with.

-

Alan & Mik

Free-to-Play Monetization: Should the game industry regulate itself?

The ethics of free-to-play monetization in casual and mobile games is a hotly contested topic. Numerous articles have been written on Gamasutra and other sites, naming F2P gaming as “chasing addicts” or “entertainment socialism”. EA’s recently released remake of Dungeon Keeper revitalized the discussion and brought into focus how F2P monetization can even anger players depending on how its implemented. Google recently announced that it would stop labelling apps with in-app purchases as Free in it’s European app stores. Simmering under this debate is the question: Are video games addictive?

It is a pivotal moment for the game industry as we transition to a new business model that not everyone understands and that can be employed with good or malicious intentions. To me, the crux of this debate is an interesting question: should free-to-play gaming be regulated, and if so, should the free-to-play game industry regulate itself? Certainly it is a preferable alternative to being regulated by the government, whose heavy and blunt hand would undoubtedly cause more harm than good.

I will discuss this point and others at the panel Ethics of F2P and Balance Between Quality Content and Staying in Business at Casual Connect San Francisco. The panel takes place on Tuesday, July 22nd, at 3:30pm in the Continental 7-9 Room. I’ll be joined by an awesome crew: Lauren Feldman, Co-Founder of MassInstinct, Lisa Marino, CEO of RockYou, Ken Murphy, VP of Social & Mobile Games at Gamehouse, and Mike Lu, VP of Product at GREE. It’s set to be a fun one, stop by!

The Future Is Multiplayer, But Where Is Mobile?

I had the pleasure of attending my first E3 with some of my coworkers. We were there to spread the love we have for multiplayer games and its move to mobile. The first thing I noticed when we arrived at the Los Angeles Convention Center was that the Multiplayer frenzy had already begun! Evolve, Assassin’s Creed Unity, Destiny, No Man’s Sky, Little Big Planet 3, Project Spark, Sunset Overdrive, Battlefield, The Crew, Super Smash, Rainbow Six Siege, The Sims 4, The Division, and many, many more were all present with their shiny new multiplayer.

Evolve was one of the games at E3 that excited us the most

Evolve was one of the games at E3 that excited us the most

Many games were expected to tout the traditional multiplayer features (Call of Duty, Battlefield, etc…), but some surprised by giving us new ways to be individuals among players that seek to bring their uniqueness to the game.

  • Evolve gave us a 4 vs. 1 multiplayer game that pits players in an unorthodox style of multiplayer that allows for an infinite amount of problem solving. This is because the game’s main boss is no longer computer controlled.
  • No Man’s Sky aims to have us reach friends lightyears away in what could be the most ambitious multiplayer game I’ve ever seen. The concept is simple: put players in a randomly generated world and scatter them as far apart as possible to see what happens.
  • Super Smash has us going back to our roots while Rainbow Six gives players the ability to destroy the environment around them to solve arising challenges.
  • The Division gives us individualized team work with drop-in and drop-out gameplay.
  • Project Spark is putting the power of game development in the gamer’s hands.

Where’s The Mobile Love?

With all of this multiplayer innovation, my question is why hasn’t it carried over into mobile at the scale and importance that PC and Console games have? We at Grantoo, work tirelessly around the clock to push multiplayer for mobile forward, but we also like to think we’re not the only ones. It only seems natural that with the endless amount of content and experiences players can create in games like Little Big Planet, Destiny, and Project Spark, high innovative multiplayer features would carry over to mobile by a flurry of companies. Yet, here we are with multiplayer features on mobile that lag behind than that of console and PC’s.

We need this excitement for multiplayer innovation in mobile games.

Retention + Engagement = Multiplayer

Monetization experts in the mobile space preach about making a game with high “engagement” and “retention”, yet the very thing that drives both these metrics through the roof is either missing or implemented as an afterthought. We here at Grantoo know how difficult it is to make an engaging multiplayer experience. It’s not easy, but that is not a good reason to leave key functionality out. When all the content that has been designed over months of blood, sweat and tears is played through in a matter of hours, it is other players and their interactions with each other that will keep a game alive well past the end of its developer created experience.

If you can sense my excitement for multiplayer, you can be certain I can go on and on, but the point is this: by giving players freedom and the ability to interact with each other, we create the most memorable experiences a gamer can have. Players are faced with solving problems that AI and computer controlled players will never be able to create.

Your peers are always going to pose tougher and ever-changing challenges that a computer simply cannot emmulate .Player’s are faced with solving problems their peers have created. As we all know: solving problems while having fun are what video games are all about.

The Future is Multiplayer

I’ll go on a limb and predict that the future of games is and always has been multiplayer. That is not to say that single player games cannot generate lasting impacts. They will and they should. Single player experiences are still very important in games. Journey is the first game that comes to mind, but even That Game Company’s master piece has an ingenious multiplayer mode well integrated into the experience, giving it a memorable offline and online experience.

Developers can design for replayability, but it still doesn’t hold a candle to the user created content and play styles that players provide each other through competitive and cooperative play. If we want players to play often and play longer, we need to introduce them to each other.

We want to help you do exactly that.

 

 

Adventures in User Testing: A survival guide for UI designers

image00

Recently I was involved in user testing some new UI designs here at Grantoo. As an artist and designer, I have done quite a bit of informal testing over the years, showing my work to family and friends. This was my first chance however, to participate in more rigid testing as we are a very small team and we need as many helping hands as we can get. I was pretty excited to see how complete strangers reacted and validate my work through a more ‘scientific’ method.

Here’s what you need to know:

Perfect The Prototype

When working on a new design, I can put together up to three mockups a day for review by the team. These are done fast (Illustrator is my wireframing tool of choice) and I often leave out the polished details in favor of quick iteration time. Everyone on the team knows this and can overlook these missing pieces. For the most part they see the big picture.

This is NOT the same for a group of strangers who are unfamiliar with your product. With one particular design we were showing participants, I had not tweaked the animation of a sliding menu on our interactive prototype (we use proto.io) as much as I should have and it came across as buggy. I overlooked this because I knew how it was supposed to move in a finished product and assumed others would also. But this bugginess was ALL the users could see. Because they didn’t share my insight, the choppy animation on the menu was a huge problem to them and might have skewed their preferences in the test due to my mistake.

Make sure you tighten up your prototypes as much as you possibly can and remember that from the users point of view, this is the finished product.

Put on a lab coat.

Testing requires thinking like a scientist and putting together a fair, documented experiment. When I am in the process of creating mockups, I like to create as many different variations/combinations of a design as I can and provide quite a few different options to choose from.

What I found was that this kind of approach can be disastrous with formal testing.

Our first round of tests used three very different menus and we set out to discover which the users prefer. The problem was, while each prototype had a different menu, each prototype also contained slightly different features and visual styles. After running through our results we quickly realised that we couldn’t decipher what it was we were actually testing. Did users choose an option because of a menu or because of some other feature that would skew their opinion?

In the second round of tests I made sure all three different prototypes were EXACTLY the same except for the menus, this way we could be sure it was the menu that was the differentiating factor.

Always have a detailed plan outlining the exact features that need to be tested and create uniformed prototypes around these specifications to avoid inconsistency.

Make sure you bring a pen.

This sounds like an obvious one but being prepared to take notes is important. When you are caught up in interviews and observing a participant’s behaviour it can be difficult to write the amount needed for proper review later. As I have the handwriting of a four year old child who has found their way into their parent’s Red Bull stash, I really should have taken better care to write down my results clearly. It took me about two days of trying to decipher my horrible scribbles so I could present them in a manner that the rest of the team could understand.

 

If your handwriting is anything like mine, it is probably best to bring your laptop.

Be Quiet. I mean really, don’t say anything.

 

As an artist I appreciate honest feedback. Often though, I feel I need to explain the reasoning behind my work if someone doesn’t quite ‘get it’ and I can get discouraged if I get negative feedback before someone has seen a finished piece (and I feel that they are judging too soon).

 

But, user testing is not about explaining your work as a designer. It is about observing a user’s true reactions to your product when you aren’t there to guide them. You don’t want to influence their perception with your own biases and that means being as unattached to the test product as possible. It took a lot of effort on my part not to explain to people something they might not understand, point out that something wasn’t finished yet or even express happiness when someone said they liked a certain feature.

 

You can learn the most when you sit back, be quiet and just observe.

Take What you Learned, and Throw it out the window! (Sort of)

 

So you’ve run your tests, tabulated the results and have findings that you perhaps did, or did not expect. What now?

 

It was pretty clear after looking at the numbers that some things worked and some things didn’t.

But, we also found that there were some areas of our tests where there was no clear consensus.

 

People have their personal preferences and there will never be one design that makes 100% of people happy. While we felt that our tests had certainly made the overall path clearer on where we should take our new design, a lot of the little details were still up for debate. Though I will certainly keep in mind our users personal preferences while tweaking our new designs, I’m not going to take them as gospel.

 

Just because the users preferred one way of doing things does not mean there isn’t a better way out there. From a creative point of view, it is important to keep your mind open in order to explore new design possibilities.

My adventures in user testing have made a couple of things clear. One being that gathering structured feedback and results is an invaluable part of the design process. Another being that it is important to approach user testing from an organised and scientific viewpoint. And lastly, and probably the most important, I made the right life choice becoming an artist and not a scientist. Not a lot of scientific advancement would have been made had I been in charge of taking notes.

At Grantoo we concentrate on bringing happiness to the world through games. We provide multiplayer and social solutions for mobile games. We focus on great user experiences and high levels of customer service.

Mobile Games & The Return of the Viral Hit

 

Image Credit: Space Inch via VentureBeat

A very interesting thread in the Gaming Insiders Growth group today turned my attention to a phenomenon I noticed, but not paid much attention to: in an age of six-figure monthly UA budgets and terrible built-in store discovery, there seem to be more simple indie viral hits at the top of the App Store then ever before.

It began with Flappy Bird, the viral sensation that honestly left a lot of people in the game industry puzzled. How, we asked, did such a simple and frustrating game capture the attention of over 50 million players? How did it climb the charts with no marketing while hundreds of companies pour thousands into user acquisition every day? Now apps like Piano Tiles, Don’t Touch The White Tile, 100 Balls, 2048, and Make it Rain have all reached the Top 10 US Free rank on the iTunes Store in the last two months. What has changed that allows these apps to flourish?

To start, let’s look at what changed about the marketplace we all live in: the App Store. Believe it or not, these apps’ success might actually show that Apple’s efforts to eliminate ways to rig the App Store have paid off. Developers used to use incentivized installs, where a user was rewarded with currency in one game for downloading and opening another, to great effect in burst campaigns, as well as leveraging sponsored promotion in app curation services like AppGratis. Both incentivized installs and AppGratis have been banned, taking away two of the key tools that developers used to consistently reach the Top 25. Now that the Top 25 is no longer as pay-to-play as it used to be, it creates a larger window for outsiders and viral hits to enter.

Additionally, we all know that discovery via search is a disaster right now. Oddly, I feel like this could be contributing to the propensity of a “viral” hit. No one is going to find out about a game like Make It Rain through search. They almost certainly discovered it from their friends.

The nature of “virality” has changed. Coming from the era of social gaming, where “virality” was first introduced as a primary driver of game growth, I wonder if we have been boxed into thinking that virality only exists on the internet and through social channels like Facebook and Twitter. And this is still possible and viable: many credit frustrated tweets about the game with Flappy Bird’s rapid rise. But if you do a Twitter search for Make It Rain or 100 Balls from before the app became popular, there’s hardly any tweets about it.

Let’s use Make It Rain: For The Love of Money as an example. You see above that the game blew up between April 1st and April 30th, but in that time frame none of the Top Tweets for the phrase “make it rain” were about the game, and no tweets at all from April 1-15th for the phrase “make it rain” mention the game that I could find.

image01

This viral growth is not predicated on Twitter or Facebook alone. It is being driven through different channels now, ones that are either offline or not public. There has been a shift away from public social networks by teenagers and young adults due to the desire to keep their social lives private. It naturally follows that the networks these age demographics use most will be the best viral channels for these games. The bad news is that it’s impossible to track this kind of virality, but the good news is that you can adjust your game and its marketing to account for these changes. To make your game more “viral” in these private channels and on the schoolyard, a catchy name and app icon is a must. Every game that has been a top viral hit has had this, and it is crucial for being easy to find in a crowded store. A share button that offers a link that can be easily pasted into chat services is helpful as well.

Additionally, much can be said about designing games for the younger audience that seems to be the driving force behind these apps’ successes. Play the games that have hit that viral status and see what ties them together. Anecdotally, they seem to prefer games that are super quick to pick up, simple to understand, have short gameplay sessions, are actively difficult, and don’t push in-app purchases heavily. There’s much more to it than that, but as a general guide it seems the viral hits we’ve seen recently have all followed those rules.

As always, success in the App Store takes a great game and a little luck. Making a viral hit isn’t easy, but take the tips above into consideration and hopefully they will improve your chances.

At Grantoo we concentrate on bringing happiness to the world through games. We provide multiplayer and social solutions for mobile games. We focus on great user experiences and high levels of customer service.

Making Mobile Analytics Matter – Part II

This is the second blog in a two part series on mobile analytics. The first blog can be found here.

In my last blog, I typed about the challenges involved in the mobile space in creating a valuable analytics loop. It isn’t enough to talk about analytics and analytics systems; you need to effect positive change through. Without action they are just a bunch of numbers. In my first blog I boiled down the problem of creating value to three core issues.

1.How quickly we can change or enhance the analytics we are gathering

2.How quickly we can deliver a new solution(s) based on the analytics

3.How quickly we can accurately verify which solution is best solving the problem.

The third point needs a further explanation. For many people coming from traditional gaming worlds, accurately verifying multiple solutions is something not often done. A solution is decided based on the information available and designer knowledge. Delivering multiple variants of an application or feature to a user’s device can be complex and often slowed by the platforms submission and verification process. Traditionally, features have been delivered as a whole, and then deemed as working or not working by very coarse grain analysis. This is very different in the web world where multivariate testing and funnels are commonly used.

I will use a particular feature to help illustrate how we approached the three core issues and how we broke down the problem to improve our outcomes. As mentioned in the previous blog we were able to achieve some amazing gains in our multiplayer game usage in a relatively short time period. The goal we were concentrating on was having a user complete a single online match*.

In many cases a feature goal is made up of smaller goals or tasks. For us, we wanted people to complete an online match. To complete an online match the user must complete the following smaller tasks:

  •  Enter the online section of the game
  •  Select an opponent to play against
  •  Play a round of the game
  •  Report the score of the round
  •  Return to the online section to view the result

When the user has completed the final smaller tasks then we can consider our goal completed. The sub-goals are a series of conversions.  For example, converting a user who has started the online section to a user who has selected an opponent is a conversion. The issue is that the percent of users completing each subsequent conversion diminishes. The ultimate goal would be to have all the conversions carry across 100% of the users from the previous conversion and have a 100% completion of the desired results (which fortunately never happens and keeps us all gainfully employed).

When doing analytics driven development, an interesting thing happens: the assumptions you make about what needs to occur (i.e. the smaller tasks) are sometimes wrong, or sometimes in the wrong order. You often find that the small tasks need to be further broken down to provide better understanding or granularity on why that portion of conversion is under performing. You may find that the measurement you originally created is not really reflecting an accurate picture of what is happening.

This leads us to tackle the first challenge:

Change or enhance the analytics gathered

Unfortunately we won’t get everything right the first time. This is why we iterate on the data we receive from our mobile game. There are two main approaches:

1.Boil the ocean and plan for everything

2.Keep things lean and iterate as needed

The first method doesn’t really work in a rapid iteration environment. It’s the same as the waterfall development model versus the agile development model. It can work when nothing surprising occurs but it otherwise limiting. In my experience (particularly in the gaming world when emergent discoveries can make all the difference) method one will fail to provide the data needed. So even in the first model you still need to iterate, and when it comes time to iterate you want to do it as fast as possible.

Additionally, I’ve found that collecting huge amounts of data without purpose can have a negative effect. Besides the obvious data storage cost, maintaining the mechanism to ingest data, and code complexities; the problem of huge data is that it very quickly becomes background noise. Finding the right piece of data can be obscured and confuses what needs to be looked at. The numbers become overwhelming.

A dashboard with 27 flashing red lights is a problem if only one of them really needs to be looked at.

In our example we noticed we had drop off between the start of the online game and the selection of an opponent to play against. While some of the predefined metrics indicated that we had some general asset loading issues there was an additional loss after the loading of assets and before the player was given the option to start a match. It turned out our tutorial was acting as a deterrent to starting the first match. This was only understood through multiple rounds of iteration and changes to the data sent to our analytics server. Fortunately, this was all done within a day.

We need to look at systems that can iterate quickly. This boils down to dynamic code or writing code which can act dynamically based on data. An example of the former is a scripting language engine that can run different scripts at execution time. An example of the latter is a configuration file that can turn on and off a series of command (a variable set to 0 might indicate that only level 0 analytic data should be sent and level 1 might indicate that level 0 and level 1 analytic data should be sent). Clearly the former provides more flexibility so we chose to dig deeper down that road.

Scriptable solutions or dynamically interpreted languages have several challenges. There are a huge number of languages with mature interpreters to choose from (lua, actionscript, javascript, insert your own favourite solution here). Until recently Apple had frowned on a number of these being included in games because of the potential for circumvention of the submission process (although in reality this is no different from a piece of code that chooses a new code path based on any dynamic information like the time of day). Using a scriptable solution allows us to change the analytic data being sent from the user in both its format, and its frequency. The script needs to have access to the data that wants to be sent but providing access to data universally is a much more tractable problem than trying to determine what data is actually valuable in an analytics system.

The additional considerations for a dynamic scriptable solution are how the scripts are delivered and how they are stored.

A simple system for transfer could be using a standard communication protocol (such as TCP or UDP) to access a network stored asset at a known location. The script could then be stored in local storage and new versions can be checked for periodically.

Writing a system that did all of this, however, didn’t seem to make much sense to us. A perfectly acceptable solution is built into almost all platforms. Cutting to the chase we choose to use the standard mechanism for web page communication, an HTTP request for transfer and a standard web cache for storage. This handles all the delivery, versioning, caching and rechecking of new versions for us. By using a WebView (which also exists on nearly all platforms) we also gain a complete scripting engine (javascript) The nice thing about a web view based script is that it is well sandboxed and alleviates the fears platforms may have with running amuck of existing code and accessing restricted calls.

The advantage of using standard protocols is that they allow you to take advantage of all the existing systems out there that have been built to optimize and accelerate web traffic. You can do so without having to write custom code and their advantages are well known. A good example of this is leveraging a context delivery network, or CDN, which can place your script code as geographically close to the user as possible.

To us the problem of changing the analytics is best remedied by being able to dynamically change the data being sent. We believed we could not properly predict what data was needed, so a scriptable solution was required. In using a scripting system it was clear that the issue was not just a system which could interpret new code, but the mechanism of the delivery to and storage of that code in the client application. Our solution was to use a WebView. A WebView can be used to run these scripts in a safe environment and the mechanism to communicate with WebViews from native code is well known (calling directly through to Javascript and even allowing for asynchronous callbacks via URL requests). But for us, the choice of a WebView was also wrapped in trying to solve the second core issue.

Delivering a new solution quickly

The Grantoo product is a vibrant UI and backend solution, which supplies online and multiplayer services to games. Fortunately the solution is NOT the game itself but a UI that can be used to set up a multiplayer game and allows users to build a community with their friends around the games they play. Being UI-centric versus a twitch portion of the game was a significant criterion in how we solved the second problem of delivering a new solution into the game.

We knew that we wanted to iterate quickly and respond to our analytics information as fast as possible. We knew there were platform limitations (i.e. submission processes) in place that would hamper that delivery and slow the iteration cycle. It also is generally a bad practice (from an SDK standpoint) to rely on your game partners integration of a newer version of your SDK to improve your offering. Finally we also wanted a solution that would be available to all users at the same time, not having to rely on the user accepting a new version of the game, for us to be able to rapidly improve the performance of our subsection of the game.

In some ways this is the same problem as the scriptable code issue, just more complex. It essentially is the scriptable scene and UI problem. There are several solutions around this but each has their complexity and limitations. Most modern game development platforms are engines, which accept a number of assets in order to compose a visual scene. For the sake of performance, however, these scenes are “baked” so they can perform optimally on the target devices. This involves reducing script to machine instruction, asset compression, and optimization indices and layouts (amongst a whole other bunch of voodoo magic). In doing this kind of compression, the dynamic nature of the content creation process is removed, and it becomes difficult to change small subsections of the scene and its layout (of course, human ingenuity shone out with the early mod community which was able to decode bit streams, “patch” portions of the executable, and create incredible change in what were believed to be monolithic systems).

Given our need to build a UI and not a game, our options were increased. We choose to go with an HTML5/Canvas based solution (particularly cocos2d-html5) on the delivery of our UI. We were willing to give up some of the performance and extreme features to gain the flexibility of being able to add code and assets quickly, universally, and modularly. We also recognized that we would be able to leverage the growth advantages of an emergent technology. Mobile browsers (and WebViews) are becoming faster, more robust, and more full featured over time. Middleware providers of the HTML5/Canvas authoring systems are striving for speed, efficiency and platform compatibility. Essentially the platform providers are invested in the same goals that we are looking to get to.

This is not to say that we wouldn’t look at other ways to deliver our solution (particularly inside a WebView … any solution that could be hosted inside that environment is a fairly trivial switch for us as it continues to preserve the aspect of not requiring a new submission to work and can be delivered quickly and universally). Newer solutions such as famo.us (more CSS, DOM, JSS based) would work just as well for us and can be delivered without a hitch to our end users. Other solutions exist but for us the WebView with its built in script handling, solving the first core issue, made it easier for us to cement it as our choice to solve the second core issue.

In our example, the changes and eventual removal of the tutorial system was all done dynamically (i.e. no new integration was required by the game team and changes were immediately and universally available to all game users). Several iterations were required where different parts of the tutorial system were removed and tested to see impact on the sub-goal of “getting the player to select an opponent”. The selection screen itself was tested to see where placement and highlighting of buttons would bring the most people through the funnel.

We had a solution, which could update quickly and universally across multiple platforms. In this way we could generate new data whenever we wanted and dynamically update what the user was seeing with equal speed. This laid the groundwork for us to attack the third core problem. To really iterate quickly and to really understand the impact of our changes, we needed to do multivariate testing.

Selecting and verifying the “best” solution

Multivariate or A/B testing can be done with any coding system. Given the desire to get results on the largest audience possible (for reduction in sampling error), and being able to turn on and off tests and install “winners” as fast as possible, the multivariate test works best when combined with a system that can deploy features rapidly and universally as described above. Without universal deployment multivariate testing can be detrimental to a product. Imagine a product that (at the very same time) has the following installation profile:

  •  25% of the audience on the old solution
  •  25% of the audience on solution A with multivariate test code
  •  25% of the audience on solution B with multivariate test code
  •  25% of the audience on the final “winning” solution without the multivariate test code

This is a very real scenario when trying to deploy with a non-universal system (such as going through the platform store). Google Play and iOS7 has made it easier to have universal deployment (via automatic app updates) although each of these platforms has caveats on when it will work. The fracturing of the audience will have a long tail impact that worsens over time. Therefore, one of the key criteria on being able to successfully use a multivariate system is being able to quickly move your audience from a solution to test scenario and back to a solution again.

Going back to our example, one of the multivariate tests performed on opponent selection revolved around how many options were presented to the user. Our choices were to restrict user flow to the single option of playing a quick match, or opening up a choice to opponents as they might see after they had played the first match. The questions revolved around whether giving choice at this time was a benefit or more of a distraction, versus the possibility that we might be just delaying the drop off point. It is not a question with a confirmed answer and in reality we had multiple camps within the team. What we did share, however, was the goal.

The test was set up to test both the funnel in question (did the player select an opponent, as opposed to finding a way to exit the app) and the downstream impact (would there be a reduction in retention and creation of a second match) of both solutions. We set up the following A/B test and ran it for several days (over several games in our case to give us more understanding):

1.A cohort that only had the quick match button available on the first match but had all opponents available on the second match

2.A cohort that had all opponents available from the first match on

Through our testing we not only identified a significant lift in the selection of an initial opponent, but also saw no drop (while accounting for the new users who had moved further through the funnel) in the number of users who went on to play a second match. Once the test results proved conclusive we moved our new solution into place and stopped the multivariate test immediately. All players were moved to the new solution without stragglers.

Leaving thoughts

By concentrating on the three core issues identified and finding a system that fit our criteria and constraints (or lack of constraints in some regard) we have been able to build a system, which allows rapid iteration. The system allows us to deploy both data and visuals quickly and universally across all platforms. In addition, building a lightweight A/B testing system on top, we were able to confidently test multiple solutions with regards to our goals.

The end result?

500 online games a day to nearly 150,000 online games a day within one game, within 3 months.

*Grantoo has created an asynchronous cross platform match up system. Each of the two users in the match plays a round (or rounds) by themself and their results are posted and compared to determine the winner.

At Grantoo we concentrate on bringing happiness to the world through games. We provide multiplayer and social solutions for mobile games. We focus on great user experiences and high levels of customer service.

8 Tips for Leading A Game Development Team Into The Unknown

There are challenges facing small teams tasked with creating new technology and experiences.  The amount of unknowns are enough to make your head spin.  But what about the human factor?  How do you deal with a team tasked to solve the unsolved?  How do you deal with the roller coaster ups and downs?  And what do you look for when it’s time to grow, especially since this isn’t your typical 9-5?  I’ve outlined a small set of tips that has helped us along the way.

1) Well rounded skill sets – We hire the best candidate for the job, but give a nudge to people who can contribute on multiple fronts when there’s a “tie”.  You never know when someone’s additional talent will come in handy, whether it be filling in for someone else, or picking up a task that would otherwise go unowned.

2) Drive to excellence – People who demand excellence won’t settle for average.  Having people on the team who live to make things better will help you go from a good product to a great product.  And it’s often that last little bit that’s the most difficult so small teams need all the help they can get.  It’s crucial to have people who are critical of their own work, not defensive about constructive criticism, and take pride in what they do.

3) Diverse Backgrounds  - We’ve found the diversity of our team to be extremely helpful during difficult times.  We have some industry veterans;  people who’ve been there and done that.  Experience is a great ally in making the tough decisions,  but youth has the advantage of exuberance and a fresh take on things.  Combining the two can be a powerful team dynamic when they play off each other, help temper each other, and drive towards the best solution.

4) Common team culture – We don’t often think about team culture in a small environment, but like it or not, a team culture always exists.  This goes professionally and personally, so take inventory of your values, how you interact, and make sure new hires are a match so that they can thrive in your environment. This in turn will help you thrive.

5) Use churn to your advantage – Be sure to have short term achievable goals.  Having smaller tasks means people can still see progress along the way, making change easier if and when it comes.  Lots of change means lots of learning so be sure to take these lessons to heart and adjust your earlier assumptions.

6) Prioritization – Tackling the unknown often means tons of open ended questions.  This can often lead to an overwhelming number of tasks.  While it’s good to track everything, it’s also good to prioritize so people can attack problems systematically, avoiding a scattershot approach.

7) Let your experts be the experts – Let the best person for the job do the job, rather than micromanaging every step.  For one, it’s too difficult to do on a small busy team, but you also want your team to be confident enough to move forward into the unknown.  This only happens when you give people enough freedom to come up with their own creative solutions.  Provide clear direction and goals, but allow people to figure out how to meet those goals within their discipline.

8) Retrospectives – Look back at your previous work and be open and honest to team feedback.  Dynamic environments mean many of the problems and processes are first passes.  So do what you can to improve things next time around.  Solidify the successes into a process that sticks, while highlighting the problems so solutions can be created to improve things.

At Grantoo we concentrate on bringing happiness to the world through games. We provide multiplayer and social solutions to mobile game developers. We focus on great user experiences and high levels of customer service.

In Defense of the Clones: The benefits of learning through imitation.

clones.png

I have a bit of an embarrassing secret to get off my chest. Something I have been putting off telling the world, that may be considered tacky, lazy or just plain wrong.

I helped create a clone. A Flappy Bird clone to be exact. I mentioned this at dinner the other night to a friend of mine, who also works in games, and the response was a look of unsurprised disgust. “Yeah, you and everyone else” he said. I was pretty proud of my work on this particular game, I’d spent a lot of time on the art and felt that while it wasn’t a masterpiece, I had no reason to feel ashamed of my work. I was doing it to learn a new engine, and what better way than to reproduce something you already know well? And sure, it is not the most original idea in the world, but what exactly is so wrong with making a clone anyway?

There were 60 Flappy Birds clones published to the app store between Feb 28th and March 3rd. That is a pretty crazy number. I’ve played a lot of them, as part of my daily work week involves reviewing content on the store, for both research and inspiration. I can say, a lot of those clones are pretty terrible. Sloppy execution, poor art and uninspired themes which indicate a quick cash grab, trying to ride the tails of the original’s success.

Many of my fellow game creators give the same response as my friend when I bring up Flappy Bird. “Ugh,  I could have made that in like 5 minutes” they say. Or, “I can’t believe there’s ANOTHER one, how unoriginal”. And the ever popular, “Thats not a real game!”, as if the simplicity of the original game somehow voids it of being legitimate.  And sure, when I look at the sheer number of Flappy Miley themed games out there, I can see their point.

My argument though, is that there is essentially nothing wrong with a clone, so long as it adds a little something extra to the original concept. There are very few new ideas in this world, and some of my favourite games and IP’s are derived from something else. Probably my favorite game of all time, American McGee’s Alice (both the original and Madness Returns) is a refreshing and twisted take on Lewis Caroll’s Alice in Wonderland. My new TV obsession, The Cartoon Network’s Rick and Morty, is clearly a clever parody of Back to the Future. And of course Flappy Bird itself paid homage to Super Mario with its art style, an element that I believe had a lot to do with the game’s success. Basically, we wouldn’t have any of these things if it weren’t for what came before it.

True artistic expression comes from honest interpretation. We don’t get all up in arms when a musician covers a song and releases it as a single. Some of the most popular hits are cover songs and in a lot of cases, the cover far surpasses the original in quality. When learning an instrument, we learn to play songs that have already been written. Why should it be any different for games? New designers need to start somewhere and by recreating a favorite, they hone their skills while also hopefully adding their own flare. These designers still deserve to try and profit from their work, and I see no harm in rewarding them for learning. After all, The Beatles couldn’t have produced Abbey Road without first imitating the sounds of Chuck Berry and Elvis Presley.

But how to distinguish between what is homage and what is outright theft? I think most people agree when a large company takes an idea for a large amount of profit with no concern for the original creator, that is theft, especially when that same large company uses its power to stop clones being made of itself. But, if an IP Is smart, they’ll will view a clone as an opportunity. The recent return of Game of Thrones has shown that intelligent parody and homage can create value for an IP. I can’t even count how many GoT related fan works I have come across in the last few days (Game of Goats being a personal favourite). HBO seems to turn a blind eye to the piracy of its show as they know it only increases awareness, making this season’s premiere the most watched show since 2007.

And sure, the majority of the Flappy clones out there were probably created as a way to make a quick buck. But so what? A select few might but it isn’t that easy. The App and Google Play stores both put in measures to protect against outright benefiting from other popular apps and IPs by limiting keywords in descriptions (as I learnt the hard way) but they do not seem to mind about the actual content of the games. In this way, game creators are free to express themselves and build upon successes from those before them, but they can’t easily profit from leveraging another property’s popularity with SEO. This seems like a fair deal to me.

The Flappy Bird phenomenon is pretty amazing when you think about it. That within such a short space of time, such a simple game can a) become so in popular and b) spawn an ever expanding army of similar games, each with their own twist. Ten years ago the general public did not have the tools to easily make their own games, music or even digital art. Now, anyone with a decent computer and a willingness to try can make some pretty cool stuff in no time at all.

Mobile games, and games in general really, are still in their infancy as a medium. As more people get the opportunity to learn and create, more quality content will be produced. If that means we have to sit through a barrage of Flappy games to get to that point, so be it.

So I say, bring on more Flappy clones. Or more number matching games. Or whatever the current fad is at the time. But lets just try and be creative about it. We need to come up with a new twist, feature or maybe just some really cool art if we plan to replicate a game. Let’s do it to learn how to make games, to make a game better or just to pay tribute to our favorite things. Let’s try and add quality to the game space, not just clutter. Who knows, the creator of this year’s Flappy Miley clone could go on to be next year’s game design rock star, lets not hold them back.

At Grantoo we concentrate on bringing happiness to the world through games. We provide multiplayer and social solutions to mobile game developers. We focus on great user experiences and high levels of customer service.

6 Things You Should Know When Using Mongoid and MongoDB

mongoDB-logo

If you are just getting started with using Mongoid and MongoDB, here are 6 things that I found really useful.

  1. ObjectId can be used as timestamp

    Mongoid documents are stored with a BSON ID. These ids store more information than just a unique ID. You can extract the document’s created time from the ID.

    User.first.id.generation_time # 2014-04-10 01:22:13 UTC

    In addition, the IDs are sortable — sorting by id will sort the documents by creation time.

  2. Enable identity map for eager loading

    You already know it’s important to avoid N + 1 queries with eager loading. In Mongoid, include queries actually doesn’t work until you’ve enabled identity map. When identity map is enabled, subsequent requests for a query will not hit the database again. This can be configured globally in the yml file or programatically. We found it better to do this programatically so we don’t deal with cached values everywhere else.

          Mongoid.identity_map_enabled = true
          addresses = Address.all.includes(:user) # 2 queries made here
          addresses.each do |address|
            puts address.user.name # no additional queries made here
          end
          Mongoid.identity_map_enabled = false
        
  3. See debug queries for development environment

    It’s always a good idea to know what your Ruby code is doing behind the scenes. To see this in your debug console, simply add the following lines to your application.rb.

          if Rails.env.development?
            Mongoid.logger.level = Logger::DEBUG
            Mongoid.logger = Logger.new($stdout)
            Moped.logger.level = Logger::DEBUG
            Moped.logger = Logger.new($stdout)
          end
        
  4. Avoid reading from secondaries in a replica sets

    When working with replica sets, one of the common things people want to do is to read from secondaries to increase read performance and throughput. While this is possible, secondaries reads suffers from stale data due to replication lag. Replication lag can range anywhere from a few ms to a few hours. If you want fresh data, don’t read from secondaries.

  5. Monitoring performance

    The easiest way to get started is using MMS. It provides GUI interface to all the critical metrics that indicate how healthy your database is. You can also set up alarms to wake yourself (or your team) up in the middle of the night when something goes wrong.

  6. Use the TTL feature

    The underrated TTL is a MongoDB feature that automatically removes documents after a specified time period. This is an extremely useful feature to keep your database clean and performant for collections where you don’t use old data.

At Grantoo we concentrate on bringing happiness to the world through games. We provide multiplayer and social solutions for mobile games. We focus on great user experiences and high levels of customer service.

Multiplayer Takes Over GDC 2014

photo

This year’s GDC was one of the best in the last decade. The energy level was high, the attitude friendly, and you could tell that everyone was focused on getting work done.

There were a few hot topics at GDC: King’s IPO, Flappy Birds and its clones, and of course the Oculus Rift. But one topic that I am particularly invested in saw a lot more airtime this year: multiplayer.

Whether it be PC, console, or even Facebook, gaming has moved towards multiplayer and online experiences as it’s matured. Mobile is no exception, and that transformation is already under way. With the rise of midcore games and their outstanding success in the last year, casual game developers are looking for ways to compete in a changed landscape.

Developers at GDC were looking for multiplayer and social solutions that would give their game some of the features that midcore games leverage. These solutions took many forms and were not limited to just Grantoo. Unlike the first mobile game services – companies that focused on acquisition and analytics – a new wave of companies have formed, focused on improving engagement and retention.

These companies bring valuable midcore features to casual games in a number of flavors. Social replay sharing startups Kamkord and Everyplay both give mobile developers the same replay sharing functionality that you see on the PS4. During GDC, Everyplay was acquired by Unity and Twitch.tv launched a mobile service, which tells me that this space is just getting started.

There are a number of companies in the emerging “mobile multiplayer” service segment. Naturally, one of them is us, Grantoo, but there are a number of other quality products as well, including Nextpeer, Skillz, and Scopely. Each has their own business model and their own advantages, and it will be exciting to see which of them proves most valuable to developers. Many of the developers we talked to were evaluating multiple services. You’ll find out which ones chose us soon.

Developers need more tools focused on engagement and retention to compete in the mobile game marketplace. The investment required by game developers to build these services can be substantial which makes it a market problem that needs to be solved. It’s an exciting time to be in this new industry segment, and we can’t wait to see how it grows.

At Grantoo we concentrate on bringing happiness to the world through games. We provide multiplayer and social solutions for mobile games. We focus on great user experiences and high levels of customer service.