From Browser to Mobile Game Development Â– An InnoGames Retrospective
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
We followed several approaches to come to this conclusion, and for us, only one really paid off. In the following, I will give some insights into what we tried at InnoGames, and how we have made very promising steps towards a highly engaged mobile player base.
Next Stop: Cross-Platform
Our transition started in the beginning of 2012, during the kick-off of Tribal Wars 2. We just released Forge of Empires and knew that the browser market would reach its climax during the next few years, while the mobile market would stay on the rise. In short, we determined that all new game productions would target the browser and mobile devices (Android, iOS) while having all features available on all platforms at the same time.
Back then mobile development has been completely new to all of us.
While setting up the first new production, we needed to answer questions we never had before in any browser-based project: "Portrait or landscape?", "How do we structure update cycles considering the Android and iOS approval processes?", "Is there any chance to upload a hotfix for our client on mobile?", "How do we create a game with a native user experience for such different platforms?", "How do we get featured by Apple and Google?", "Where do I hire experts?" etc.
At the end, all of those questions came down to one: "What's the target platform to focus on: tablet, phone or browser?" We decided to go for four completely different approaches at the same time, to reduce the risk of total failure. In all of them, we used different frontend technologies and target platforms to go full cross-platform on browser, Android, iOS, phone and tablet.
Cross-Platform production - four different approaches, four different outcomes
The very first projects we could initiate quickly had been the companion apps for our browser games Grepolis and Tribal Wars. Here we decided to start learning mobile development while supporting our core player base to use specific aspects of both games wherever they are with their mobile devices. We didn't implement the full feature set. Instead, we focused on those gameplay elements which players have to execute frequently. We set up two small teams with less than five people each. Grepolis Mobile was developed with Adobe Air, while Tribal Wars used Objective-C for iOS and Adobe Air for Android. Our main goal was to keep the challenge as small as possible while raising retention for our existing player base. We managed. We didn't convert many new mobile players to our browser games though.
For our (now cancelled) title, Rising Generals, we took a different approach while going fully cross-platform. We used Java for our backend and Adobe Air for all frontends. In regards to user experience, we focused on the mobile platform and kept the browser version second. In addition, we decided for phone before tablet. While the design focused on allowing a perfect player experience on the phone, the developers needed to ensure high performance on a lot of different devices at the same time with one single code base. We staffed our team initially with our existing ActionScript web-developers and learned the hard way that new technological challenges need experts to find sustainable solutions. The game was delayed by eight months and died in Open Beta, mainly due to technical issues.
Based on the findings of our companion apps for Grepolis and Tribal Wars, we decided for a different approach to allow our browser-based blockbuster Forge of Empires to grow on mobile. We wanted a full feature mobile version which could be played on all devices with the same account. For the acquisition of new players the mobile version had to be another entry point. We went for using the same backend and porting the ActionScript frontend to Cocos2d supporting both mobile platforms (Android and iOS) with one code base. We used external support to get into the groove because we never did a project with Cocos2d before. It took us around a year to have the first releasable version in place. We internalized the development and released Forge of Empires Mobile to the public. The result was (and is still) a very successful cross platform game.
Top five findings from going cross-platform
- Quality needs focus! There is no chance in creating a "same-feature-set-cross-platform" game from scratch while delivering a perfect user experience on all platforms. One platform will always be in the lead. In the worst case all platforms will suffer because of too many compromises. Start with one platform and make it perfect. Cross-platform means way more complexity for everyone involved. In addition to your programmers, even your game designers, art designers, project managers and product managers will have to deal with more complex tasks every day.
- Hire experts first! Technical challenges are huge in serving various platforms. Whenever you do something new, hire experts first.
- Cross-platform development is slow and expensive! Even if you decide to hire experts, recruiting takes time. Your team sizes grow and the communication overhead with it. You will need more time to adjust a bigger team to be efficient. In addition, technical- and design-refactoring become more likely. If time to market is one of the most crucial factors for your product to succeed, cross-platform might not be the right approach.
- Companion apps can improve your games' KPIs! Smaller companion apps are good for improving retention of existing players, but not enough to attract mobile players. If your target is top grossing on mobile, do a mobile game.
- Successful cross-platform is possible but not for free! With Forge of Empires, we managed to release a successful game on the mobile market. This success comes with the price of currently having more than 40 people working directly in the development team of Forge of Empires. Before the release of the browser, version the team reached around 12 people. The huge ramp-up was mainly necessary for catching up with the browser feature set, while still releasing updates for browser players. It took us a while to find a team setup and processes to manage so many people, while working on the same game with a different pace.
Switching to 'one platform first' strategy - arriving at our destination
Right after the decision to close Rising Generals, we did a post mortem and presented the findings to the whole company. Although we focused on mobile phones as the main target device, we didn't manage to reach our quality targets. We made too many compromises, as the browser version still mattered to us. The team already anticipated a potential failure of the game before open beta release, but they pushed towards making the impossible possible. We hadn't instilled a culture that the closure of projects becomes something normal and valuable.
Based on the post mortem and other findings along the way, we recognized that if we want to really succeed on the mobile market we need ...
... to learn! Instead of using several technologies for different games, use the same technology for different games. Knowledge sharing reduces the potential of total failure;
... to focus! Instead of working on various platforms at the same time, define one target platform and allow your team to focus on it. You won't be successful if you can't focus on a perfect user experience;
... to fail fast! Instead of working on your games in a bubble for years, shift towards a player centered development approach. Intense user- and play-testing must be key. Also, make sure your overall company culture embraces failure;
... to be agile! Instead of navigating 30 to 40 people through a complex production, set up a team of 10 to 20 and center your production on the player.
... to make use of powerful tooling! Instead of forcing your developers to integrate user interfaces or other assets, make sure you have a good tool pipeline in place. All of your content designers will be more than happy to be able to apply changes by themselves.
We took the long road to reduce product risks. The overall goal was converting some of our browser players onto mobile platforms. Instead, we ended up with complex productions which didn't meet our expectations in regards to either technical or design quality. Forge of Empires Mobile was the only product which could keep up with our high expectations. Taking this as a role model, we went for focusing on one platform first, without considering other platforms too much in the beginning.
Since then we've sent three mobile-based game projects into production stage. More to follow soon. For all of them we focused on a true mobile user experience and skipped any thought of a potential browser version. Along the way, we killed more than 100 game ideas in early stages. User testing for us starts with the conception of the game. We thrive towards small development teams with less than 20 people each. The Unreal Engine 4 and Unity provide toolsets which support us in setting up small, efficient, cross-functional teams while developing games with a high production value.