Connected 3D Game Development for Mobile Devices using X-Forge Game Developers Conference 2005 March 11, San Francisco Petrus Lundqvist

Overview Fathammer’s X-Forge game engine is used in 20+ mobile titles High performance, built from the ground up for mobile devices All major mobile platforms supported Windows Mobile (PocketPC, MS Smartphone) Symbian OS (N-Gage, Series 60 & UIQ) Palm OS WIPI & GIGA, BREW Linux Rex, Nucleus, and other common real-time operating systems

Why is mobile game development different? Extremely high level of fragmentation: Form factors Performance Runtime memory size Network type & performance Game delivery method & maximum game size

Where are things headed? Attempts to standardize OpenGL ES J2ME: MIDP 2.0, JSR-184, JSR-239 BREW, WIPI & GIGA Fierce platform battle between Windows Mobile and Symbian Two technology worlds: Java and native (C/C++) applications Networks will evolve, sure, but when will it happen? No major improvements in standardization in the near future

Living with fragmentation Java Pros: provides the abstraction Cons: serious performance limitations Suitable for simple games Native (C/C++) Pros: performance and freedom Cons: middleware is a must Suitable for advanced games

Mobile game middleware - what is it? Platform abstraction Full platform and game services 2D & 3D graphics (vector and raster based) collision detection & physics audio (sound effects, music, 3D audio) controls device event handling file & network IO memory management and other system services haptic effects, math, debugging, profiling, etc.

Case: Stuntcar Extreme Fast paced racing game with realistic physics Detailed, high performance 3D graphics Wide range of supported mobile platforms Optimized for Intel XScale and Intel 2700G

Stuntcar Extreme Application Architecture

Challenge: make it work on all mobile platforms Screen aspect ratios and orientations Portrait vs. landscape Controls Digital vs. analog joystick Performance Software vs. hardware accelerated 3D Wide range of heap memory sizes Network Bluetooth vs. IP-based (ad-hoc WiFi)

Handling differences in screens Make the user interface scale automatically Vector graphics (both 2D & 3D) scale without degradation Layout managers and similar techniques automate layout Define safe areas in cameras to get a guaranteed area of visibility original camera view with safe area shown in red portrait landscape

Getting a grip on controls Clearly separate the different concepts of controls Physical controls Logical controls Game state Filtering between control model layers makes adaptation easy Left Right Faster Slower Steering Wheel Position Gas Pedal Position physical layer logical layergame layer filter

Tackling performance Different devices require different visual geometry Use the same physical geometry across all devices Physical geometry simplified and optimized for the genre Oriented heightfields Cars as sets of primitive shapes (spheres and boxes) visual geometry and simplified physical geometry y+ terrain approximated using oriented heightfields

Making the net work Abstract network model - design for the lowest common spec Finding devices Connection management Sending and receiving data Typical bandwidth and latency GPRS: 40Kbps, 750ms 3G: 256Kbps, 250ms Bluetooth: 512Kbps, 50ms Ad-hoc WiFi: 10Mbps, 10ms 750ms 1500ms aggregate latency with client-server setup over GPRS

Conclusions Use middleware Take into account differences in form factors from the start Separate visual and physical geometry Design the network model for the lowest common spec True real-time is challenging - plan your strategy appropriately