This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
1. No Hablo Español
It's a long road between a winning contest demo and a shippable game. There are a lot of additional components that comprise a full-featured game besides gameplay. To win the contest we didn't need all of those other features, and in the development rush we didn't optimize our app for a worldwide release. After winning the contest, we had to quickly implement those additional components, and what's worse, these new features tended to require a line of code here, there and everywhere. One example was localization.
In hindsight, we should have planned for localization from the beginning, but in the contest development rush it was a corner we cut. We had a lot of strings, level names, paddle names, and other text baked into our graphics and our code. To ship the final game, we had to remove text from all graphics and hard-coded text strings, and add localizable text support.
Localization Best Practices
Localization required approximately 140 man-hours across the Pong World team, not including the actual translation and Language QA, both of which were done by Atari. Pong World now supports six languages.
2. We forgot the FTUE
One more feature that we didn't plan beforehand is a tutorial for first-time users, commonly referred to as the First Time User Experience, or FTUE. We like to pronounce it as "phtooey!"
This is a must-have feature for every modern game. When someone opens your game for the first time, he needs a guided tour of gameplay and features, and you need quite a lot of steps to show everything you want them to know.
Pong World FTUE.
Our FTUE consisted of approximately 17 steps, and we needed to create a nice and unobtrusive way to show the tutorial texts. We created a stylized popup box and some arrows, but the hardest part was creating the scripting logic for all 17 steps. For example, one step included adding coins to the user's balance, and several steps needed to point at a specific button while all other buttons are disabled.
To properly implement a FTUE, you should keep in mind the following:
Adding and perfecting the Pong World FTUE resulted in over 200 man-hours of additional work.
3. Releasing Builds Too Often Can Lead to Mistakes
One of the requirements by Atari was to release the builds often, especially when we came close to the App Store release. This is a problem, because the build process takes from two to eight man-hours to merge, build, and test the game, especially taking into account the amount of features that need testing.
Though frequent releases are a good practice, they can work against you when done too often. Our QA team was not able to regression test everything in every build, and started to miss some bugs. We had a very disappointing bug with the amount of coins shown on different UI screens, and people were obviously confused by it. Missing this bug resulted in a lot of negative reviews in the App Store.
For the future we plan to implement several practices that would help us speed up the build process. We currently use a build machine and building script, but we could set up a continuous integration server, and cover some of the core functionality with unit tests. While having a build schedule is good, out-of-turn builds should be avoided unless it's absolutely necessary.
4. There Was No Soft Launch, or "I've Got You Under My Thumb"
It can be very useful to soft-launch the game in a secondary market a month prior to the worldwide launch. A soft launch can ensure there are no major issues with the store (in this case Apple), and it verifies you can get through the store QA and approval process. No one likes to get rejected days before launch over a guideline issue, and have the release set back by weeks.
A Pong World build was submitted to Apple more than a month before launch and was approved. However, the decision was made to hold off on the soft launch of the game due to the lack of the FTUE in that build. In hindsight, valuable information could still have been gathered.
Pong World FTUE intro.
A soft launch serves as a wide-area beta test, and can point out important problems with the game that aren't obvious to the core development team. For example, after the worldwide release many users complained they could not see the paddle under their thumb. It's an obvious and natural way to play, but most of the team tended to use their index finger instead, and this issue wasn't raised in our local play tests. A soft launch would have caught this easy to solve problem, along with a few others, and avoided some negative reviews for the worldwide launch.
5. We Were Surprised by the Number of Frameworks
Pong World uses 14 (!) different framework SDKs. That's getting to be normal for any game, but even we were surprised by the number, and every framework adds its own set of problems. It can be hard to research and implement the various frameworks, because they don't tend to be very well documented and often do not work very well. It takes a lot of time, and you have to be ready for that.
Some examples of the trouble we faced with framework implementation:
StackMob: Generally provides really bad support. Our questions related to problems with push notifications weren't answered for weeks at a time.
Flurry Video Ads: We really wanted to add the Flurry vAds framework to show rewarded video for game coins, but we the fact is, it doesn't work without server-side support and we didn't have time to add it, since our game is purely client-side. We went with AdColony instead.
Facebook SDK: This is a complete mess. Try to add sharing/authentication features to your game just once -- you will understand. The SDK has two primary APIs -- deprecated and new, and the documentation is only partially updated to comply with the new API. Have fun sorting that out!
MoPub: Sometimes the ads that come from the Chartboost server would not close themselves and have no Close button. An ad would get served and essentially lock the game up indefinitely. We had to add a hook that closes ads after some period of time.
Unfortunately, these were just a sampling of the problems.
Entering the Pong Indie Developer Challenge and developing Pong World for Atari has been a very positive experience for us. Obviously it doesn't hurt that we won first place, but we also got the chance to show we can design and deliver a major title for a well-known publisher like Atari. We're continuing to update Pong World as well as develop new titles for iOS, Android, and Windows Phone, using Cocos2d, Cocos2d-x, Unity3D, and even PhoneGap.
The zGames Pong World Team.
Our Red Weed game for Android was recently featured by Amazon as the Free App of the Day, giving our brand even more exposure. Ouya has our attention (we're a founding member) and we see a lot of opportunity out there for our own games as well as contract game development. Look for another reimagined classic title from us later this year from yet another icon of the game industry.
Developer: zGames, LLC.
Publisher: Atari, Inc.
Start Date: March 2, 2012
Release Date: Nov 29, 2012
Number of Developers: 3 devs + 1 game designer
Number of Artists: 4
Length of Development: 5500+ man-hours, 7 months
Lines of Code: 67,000
Development Tools: cocos2d, Box2D, xCode
Kicker (Foosball) matches played: 240
Nights spent at the office: 9
JIRA artifacts: 590
Number of intermediate builds: 30
GDD revisions: 11
Number of classes: 250
Number of play tests: 3