As indicated in my last post, I attended the Austin Game Conference last week, mostly following the mobile track. Overall, I’d say the mobile track is not as mature as some of the others, and the content seemed more fitting to people new to the mobile market rather then people currently working in the field. Still, it’s always nice to pop out of the rabbit hole from time to time to hear what other industry people are talking about, and there were plenty of opportunities to have casual conversations with people from operators and development shops about the projects they’re working on and the challenges they’re facing.

For my conference summary, I’ll start with some overall themes, then move to highlights from a few individual sessions.

Major themes

[1] Mobile 3D:

There was a lot a talk about 3D graphics, and just as many mixed opinions. However, there seemed to be some confusion on why mobile 3D is such a hot topic for developers. While there were a few people who pitched this as 3D games (ala first-person shooters and N-Gage titles), and just as many people who proclaimed that mobile devices would never have the processing power or form factor for this, the real drive for mobile 3D engines is to reduce the development costs of games by moving away from bitmapped sprites that must be customized for every screen size. 3D engines (and even SVG or Flash, for that matter), should be able to scale the game canvas and objects to match the hardware, even for games that don’t appear to be 3D. For example, imagine a mobile Checkers game… Using bitmap sprites, you would have to hand-draw every possible chip and board piece for all the mobile phone screen sizes you are supporting. But with a scalable engine, you simple tell the code how many rows and columns should be in the grid, and that you need red and black circles to fit the grid’s cell size. With the scalable engine, your post-production porting costs should go way down (which means margin’s go up.)

[2] Supporting hundreds of mobile devices:

The number of devices developers have to support is getting to be a problem logistically, not just technically. For major game titles, developers claim to be supporting 300 to 500 devices globally. Multiply that by 10 language localizations, and you now have 3000 to 5000 unique builds (SKU’s) of your game! That’s one heck of a build process, and you still have to tackle device, language, and network specific bug tracking, and possibly tweak the game play on some phone models if they can’t handle the animations or other aspects of the game.

Before you can start testing though, you need actual phones… and they’re not free. Nor is it free to activate phones (on all the networks you’re supporting) so you can test game installation and multiplayer features. To test real-world performance, you might also need a physical man-on-the-ground in other countries to test on live networks.

[3] Mobile games market is becoming harder to enter.

The mobile game market is starting to close a bit. There used to be open opportunities for small development shops to get their titles “on-deck” (meaning, shipping pre-installed, or at least available via an operator’s portal), but the operators are starting to raise quality requirements and reject mediocre games. This trend on it’s own isn’t necessarily bad since it implies that only quality games will make it to customer devices; However, increasing operator standards isn’t the only issue. With the increasing number of devices to support combined with the need to produce quality, innovative titles, the cost to produce mobile games is increasing. We’re not at the several-year production cycles that the consoles see, but top quality mobile games are now three to four month projects for a small team rather then the one man-month cycles we were seeing a couple years ago.

Wide-audience game distribution is also tied almost exclusively to operator partnerships (direct to consumer distributions models haven’t been as fruitful), meaning that small shops also need business connections in addition to top-notch technical chops.

[4] Mobile multiplayer networking is seen as too complex and unreliable.

Mobile data networks got a lot of flak from developers, with complaints about variable latency, roaming costs, spotty coverage, operator-specific networking API’s, and the testing costs involved. Curiously (and sadly) enough, I didn’t see many of the complainers at Markus Huttunen’s presentation on “Reaching the Mass Market with Connected Mobile Games.”

Session highlights

From Jason Ford’s (GM Games and Entertainment, Sprint/Nextel) keynote:

  • Sprint Nextel has 43 million customers and the the highest customer ARPU in the States.
  • 51% male customers.
  • Average age of 30 (which is younger then average wireless subscriber, 44.)
  • The average age of people who claim they will buy a mobile game next year is 35.
  • Casual game titles are the most successful.
  • Customer feedback (on the Sprint portal) is more important (for revenue) then professional game reviews.
  • The top three players of Bejeweled Multiplayer have each played the game over 40,000 times, logging around 2,000 hours of game play per person.

From the Post Production panel:

  • Data suggests an 18-24 month replacement cycle for mobile phones.
  • Companies launching global game titles can expect to support at least 300 different phone models.
  • Some developers are seeing a 100%+ increase in the number of SKU’s per game. (A unique SKU is created for each build and localization.) The highest number heard for a global title is 5000 SKU’s. Managing these variants is becoming a challenge for small development shops.
  • It’s fairly common practice to do game development targeting four devices (a high-end/low-end Java device, and a high-end/low-end BREW device.) Supporting (or porting) to other platforms generally happens after the game is working correctly on these key devices.
  • For small shops, outsourcing your porting work may make sense, but larger shops would rather keep the competency in-house instead of teaching other companies how to be competitive.
  • Some, but not all, shops are looking to middleware to solve the porting issue.
  • Expect to change some aspects of the game when porting to other devices (ex., devices vary greatly in their ability to handle complex animations and sound.)
  • Mobile multiplayer (over the network) greatly increases development and testing costs, and should be limited to simple things like posting high scores and chat messages. One developer mentioned writing a custom Win32 client to test the networking back-end services.
  • It’s more difficult to do distribution of native games then J2ME or BREW.

Carrier Panel:

  • The cost to produce a mobile game is rising. It used to be $25-30k. Now the average cost is around $100k for a top title.
  • Operators are starting to reject games, and are in general being more selective on offering games to their customers.
  • Publishers are becoming responsible for game marketing, rather then the operators.
  • Amp’d mobile is targeting a younger crowd, and plans to offer “adult” content and games.

From the “Starting, Building, or just not shutting down your mobile dev business” panel:

  • Expect a 3 – 4 month development cycle, even when reusing a game engine.
  • Overall market is shifting from being open, to being one where relationships with operators are key for wide distribution.
  • As operator quality expectations go up, amateur developers will be replaced be pro’s.
  • Off-deck distribution (direct to customer) is not expected to take off anytime soon given the costs to acquire customers.
  • To save development costs, try to get a publisher to purchase your test phones for you, and rotate active accounts between phones as needed instead of activating them all. (Even doing this, one developer claimed a $30k/month cost to keep test phones active.)

From the Casual Games panel:

  • A good publisher can often run the porting effort for a developer (ie., they typically have connections with porting houses already.)
  • The hype around mobile 3D is not to get 3D graphics per say, but to develop scalable game engines instead of producing custom bitmap sprites for every screen resolution possible.

From the J2ME vs. BREW panel:

  • Using a device abstraction layer is recommended to avoid porting headaches.
  • Good build tools should enable targeting multiple platforms with a single build.
  • EclipseME is a nice choice for general J2ME development.
  • The cost of supporting lots of devices is very related to different hardware capabilities like screen sizes and the memory available, not just API differences.

For more on the conference, Carlo Longino and Paul Whitaker attended many of the mobile sessions as well, and have both posted about it:

You can also find a number of additional bloggers talking about the conference via Technorati’s search results.