Clinton Keith: Chris, tell us about iPhone game development:
Chris Ulm: iPhone game development is faster, more competitive and far more unforgiving than any other platform I have developed for. On the plus side, original ideas can become innovative games very quickly. On the minus side, the three month development cycles and low retail prices mean that budgets are tight and we must be ultra efficient. We've found that using agile methods have allowed us to prioritize the scope of our small projects and work effectively with contractors all over the world.
Our iPhone projects are quite complicated with third party advertising APIs, Bluetooth multiplayer, social network and email wireless connectivity. We allow users to use their photo albums and their iPod music as essential aspects of gameplay. We have integrated the OpenFeint social network in all of our games, allowing users to browse leader boards and compare scores with anyone playing the game, anywhere in the world. All of this complexity needs to be built quickly and for a price that starts at free. Without agile, it would be very easy to lose sight of your end goals.
CK: What's different about being agile for iPhone games
CU: Unlike most agile projects, on the iPhone you can LITERALLY work for two weeks and "ship" what you have as a finished product. So knowing when to ship is the most important thing.
A unique challenge for the iPhone is knowing how much to give. People expect a LOT for $0.99. The number one complaint about Zombie Pizza was that the game was only three hours long -- three hours for .$099!
CK: What do agile iPhone projects look like?
CU: Strong vision led by white-boarded interface description and a minimal document to kick off the concept. Big huge whiteboards are everywhere. Everyone contributes, but leadership and vision are important -- we don't have the time or budget to create the vision as we go, so all of Appy's games have a single creative lead with a very specific vision for the game. The vision is always based around a single point of differentiation that fits with the Appy brand values of Personalization, Quality and Fun.
Prototypes: Each game is a series of prototypes until we have one we can ship. We try to get a mechanical prototype as humanly early as possible. Small amounts of pre-visualization - but only enough to serve as a guide for actual code.
Our projects vary depending on complexity; taking anywhere from two to five months or more and our team size averages between four and six people on a given project.
Sprints are either one week or two depending on the project and what "feels" right for the work. We generally have two releases: complete prototype and alpha game.
Sprints, Stories and task cards are used for the "development" phase of the project (2/3 length of the project). How the vision is implemented is left very loose and we are opportunistic about how we modify on the fly based around working gameplay and market conditions.
Time-boxing is critical and we have two values on every decision: Dollar cost and player benefit. It helps if it’s your own damn money at stake!
Lots of testing and watching people play. We are very informal at this stage in the company’s growth, so we’ll bring people in and have them play while we watch, then fill out specific questionnaires. We divide initial comments into three groups:
- Must fix before release: these are usability and navigation issues primarily, though we have also added a last minute feature if it becomes painfully obvious that it would add a lot of player value to the app.
- Add to our active update list: these are features or ideas that we like, but are not considered worthwhile enough to add to the 1.0 version by the game director. These are always the toughest ones, because our impulse is to always keep making the app better. But, you have to have the discipline to ship.
- Add to the update backlog: these are features that we think have value, but we’re going to wait and see what the actual paying audience thinks before assigning them to a an update release.
CK: What is challenging?
CU: Requiring everybody being in the building at the same time -- we have to outsource with contractors.
The iPhone user experience has to be simple. We have to fight complexity all the time. We have to remain focused and avoid “hobby horses” from design, code or art.
Focusing on scope and smart technical, gameplay and marketing trade-offs. This is the most critical aspect of our product development and requires the focus of the whole company. We need to be efficient, yet our business plan calls for us to create original games that are differentiated from the thousands of game apps in the marketplace, so there is always a tension between doing what we know how to do and biting off an experimental feature.
Our Executive Producer, Steve Sargent, assigns an exclamation mark to any feature, no matter how small, that we have not done before. These typically take us 2-3 times longer than the initial estimate as refinement and quality always take more time than initial proof of concept. By looking at the board filled with task cards with exclamation marks, we can get a real sense of the shipping risks of our projects.
CK: Tell us about your agile practices…for example, what is Appy’s “definition of done for sprints and releases”?
CU: "Done" varies, but for the most part, every sprint's work runs on the target platform. Releases are always pushed to everyone's iPhone for testing and evaluation over the weekend. We are informal at this stage. Done means "potentially shippable" and we don't move on to new functionality until the previous functionality is shippable. We strive to avoid at all costs the "parts on the garage floor", and would elect to ship "better with less".
CK: What are the things that surprise you in alpha/beta?
CU: Usually some of the final integration aspects (full audio, stress testing) will turn up some late issues. We are also surprised sometimes by miscommunications between contractors -- not a big or endemic problem, but it happens. We try real hard to identify mistakes as we go and not do them again.
CK: What "feels" the most different between iPhone and console development? What is different about maintaining and communicating a vision?
CU: The platform and audience on the iPhone desire simplicity whereas on the console; technical and gamplay complexity are demanded by a more hard-core player (especially on the PS3 and Xbox). Right now, what constitutes a "genre" is still very much in flux on the iPhone and there are over a hundred thousand apps.
Development teams are much, much smaller and in Appy's case are integrated fully with the financial and marketing needs of the larger company. The vision of the game is communicated through a brutal process where we winnow down many ideas into one that the company is fully behind. That one idea is championed and led by a single person who has authority to be the final arbiter of trade-offs.
The visions are much smaller and more personal to the end user, usually built around a single mechanic.
From my point of view, having led both large console teams and iPhone teams, I spend almost NO time on "career coaching" or re-focusing individuals on the work at hand (which seemed to chew up a majority of my time with the larger teams), but instead spend the majority of my time solving problems, preparing the next game, working on marketing or working on Appy's strategic goals. I love working with my co-founders who are an incredibly creative and talented bunch and we are not big enough at this stage to have a lot of communication problems that can’t be solved by yelling at the guy sitting next to you or across the room.
About Chris Ulm:
Chris Ulm, CEO of Appy Entertainment: A “serial entrepreneur” addicted to building companies from scratch and guiding them to acquisition, Chris leads day-to-day operations, production, and creative development for Appy. An expert in building teams, Chris was essential in developing the creative teams and product development at High Moon Studios and was essential in High Moon Studios’ acquisition by Vivendi and later Activision-Blizzard, as well as the sale of Malibu Comics to industry-leader Marvel Comics.
About Appy Entertainment:
Appy’s first game, FaceFighter, was chosen by Apple as a “What’s Hot” pick and reached the status of “Top Ten Paid Game” in 5 of the 6 major markets worldwide. Their second game, Zombie Pizza was a “Top Ten Puzzle” game in the U.S. and was featured by Apple as a “Hot New Game,” a “New and Noteworthy” app and as a “Best Halloween Game.” In addition, Zombie Pizza was featured in Entertainment Weekly magazine’s “Must List” and on the Huffington Post as a “Best Game for Halloween.” Tune Runner, their newest app, is a music-based action game that provides an interactive platform for players to use their iPods to discover and recommend songs to their friends
Appy's games have both earned "4.5 mice" from Macworld and Appy's apps have been downloaded well over one million times.
It's interesting to read about how others are getting on with agile iPhone development.
If anyone is interested in seeing what an iphone app prototype looks like, I prepared a behind-the-scenes screencast of our upcoming app. http://bit.ly/6uFvbC
The prototype was made in about 10 hours, and effectively made planning and estimation of our app much more realistic.
I've also written about the two key pain points we've hit while using Agile on iPhone projects, and how we avoid them. http://bit.ly/5FkRzp
Great interview, it was really interesting to read Chris’ answers. Although I do not agree with some of the points he makes. First of all, iPhone game development is no faster than Android game development, it all depends on the strategy and on the experience of the developers. But the competition in App Store is really horrible. 94% of the revenue of App Store comes from only 1% of publishers, unbelievable. All of this complexity needs to be built quickly and for a price that starts at free. - well, that is just an exaggeration. No one develops software in UK for free, as these guys say, the price can be really low if you stick to the minimum of features and basic design, but never free.
What I like about Agile is its naturalness - everything is done naturally, with the use of everyday language and friendly interactions.
And it is really interesting that different developers face absolutely different challenges - just check out this Quora thread: people mention issues with discovering apps, development cost, providing new experience for users and so on.
Post a Comment