What Went Wrong
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.
- Text on image textures
- Lack of space in text containers
- Direct string references in code
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
- Never place text in a texture. Disable your artist's Photoshop font tool.
- Design text containers so they can take 20 to 40 percent longer strings. For designers and artists, it's a good habit to draw an approximate text container size on UI sketches (with dashed lines, for example).
- Use indirect string reference (using a macro, for example). Also include font size into localization files if your containers cannot select font size automatically.
- Avoid localized sounds. For example, we used abstract paddle exclamations in most cases, but still have a "Tap Me" audio message that is strange and fearful for at least one Russian-speaking mom.
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:
- Don't insert FTUE code directly into your game logic. Encapsulate it into a separate subsystem and connect it with the game through a few clear interfaces.
- Force your game designer to design the FTUE before you begin game development. If you know all the features that the FTUE requires, it will be easier to implement them. Too often, a team will wait to design the FTUE until after the game is completed, arguing the game must be finished first. It's a trap!
- Make content lockable from the start (buttons, tables, game itself, etc.). At a minimum, UI features should support some kind of disabling/enabling property.
- Some content items should be processed separately. For example, if you block all UI content on the level selection screen and allow only the "Unlock Level" button to be pressed. Design unique access methods for such separately processed items.
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