Connected 3D Game Development for Mobile Devices using X-Forge

Game Developers Conference 2005

March 11, 2005 - 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 viewwith 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 WheelPosition

Gas PedalPosition

physical layerlogical layer game layer

filter 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 andsimplified physical geometry

y+y+

terrain approximatedusing 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

750ms750ms

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