MOBILE GUIDE: Middleware

Happy Birthday games middleware – you’re ten years old. It’s a decade since the launch of Renderware Graphics 3, the first middleware product that really struck a chord with game developers.

The reasons for its success? Conditions were right; sufficient HW/SW diversity in the viable platforms and sufficient complexity of content demanded by consumers.

Games middleware has never looked back; we’ve moved from a world where middleware was a curiosity to one where almost all games contain some third party component; and for triple-A titles, middleware budgets of over $1 million are now commonplace.

These days, mobile is the new massive growth space for games. So what about mobile middleware? Are the conditions right for it to thrive, and if so what are the requirements for success? In this article, we’ll analyse the drivers for mobile middleware and compare the conditions and success criteria with the console world.

TARGET HARDWARE

In console, there are huge differences between system architectures such as graphics, storage and processor parallelism. Game engines that abstract these – with tolerable performance loss – create value. In mobile, system architectures are more similar. Most devices are based on half a dozen chipsets, and any proprietary chipsets still use the same core CPU (ARM) and GPU designs. Game engines don’t have much to abstract here.

As is increasingly the case for consoles, mobile device form factors also vary only slightly; touchscreen smartphone, tablet, and possibly slide-out keyboard.

Performance-wise, the typical mobile target is significantly more powerful than the PSP, but increasing screen resolutions leave most devices heavily GPU-bound, so engines focusing on high-end rendering features will not currently create much value.

TARGET OPERATING SYSTEM

In console, the OS is a relatively simple and predictable target. OS’s are single-tasking (in the sense of running a single userspace app), interrupts of the app (by the OS or associated services) and are mainly focused around interactions with networked game services.

In mobile, the OS is more complex and unpredictable as the device is not a dedicated games machine. Your app can be interrupted by physical screen rotation/sliding, incoming calls/SMS, volume key presses and battery level warnings – potentially all at the same time. An engine that can truly abstract and tame this complexity creates value.

TARGET FIRMWARE

In console, there is really only one firmware per OS as there is only one device per OS. In mobile, things couldn’t be more different. There are multiple manufacturers per OS, and multiple devices per manufacturer. Each manufacturer is trying to differentiate by tweaking stuff – either modifying the OS itself (as in encouraged by the Open Source nature of many) or by stuffing new peripherals onto the device, inevitably impacting the software stack. Moreover, the OS providers are in a continual battle over features and user interfaces, so OS versions are regularly ramped.

The result is a huge degree of cross-device fragmentation; another challenge for smart middleware to solve.

DEVELOPMENT ENVIRONMENT

In console, development environments are largely standardised, with the majority of programming done in C++ using IDEs such as Visual Studio. To a large extent, game and higher-level engine code can be migrated between target platforms quite easily.

In mobile, there are huge differences between development environments; the iPhone SDK mandates Objective C, Xcode and a Mac; Android mandates Java and recommends Eclipse; the list goes on.

There is simply no easy route from iPhone to Android if the original game is written wholly in Objective C using the iPhone SDK. If mobile middleware could provide game developers with a single integrated environment based around C++ and Visual Studio, it would deliver real value.

SERVICES

In console, connected services are limited and mandated by the platform/channel owners. In mobile, there is a rich and exploding diversity of these services, and exploiting these can be key to monetisation; for example advertising, currency, analytics, recommendations and push notifications.

Successful mobile middleware must support not just a fixed set of services, but the ability for developers to choose and integrate any service.

In conclusion, the problem set for mobile middleware looks very different from console, as follows:

* Tame the interoperability between app
and OS
* Smooth the huge fragmentation at the device firmware level
* Provide a single C++ development environment (HW and SW) that can cover all targets
* Enable integration with any 3rd party service
* Little need to address system
architecture variances
* Less need for high-end rendering features
* Less need for features focused around console-style genres

In summary, the winning mobile middleware formula will be more about smarter platforms than sophisticated engines. Here’s to the next ten years.

www.ideaworks3d.com