connected 3d game development for mobile devices using x-forge game developers conference 2005 march...
TRANSCRIPT
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