development of cross-platform mobile game technology

Development of cross-platform mobile

game technologyBenjamin J. BlockCute Attack, Oy

Shared Gems 2013

PhD in Computational PhysicsUniversity of Mainz

Mobile Games Technology

Background

Software Engineering in Games is HARDArchitecture is most important challenge

Why?● High performance constraint

● High complexity and interconnectivity

→ Can reusable and modular software design be achieved while maintaining high performance?

Why no middleware?

● No control over development

● Performance penalties

● I wanted to learn something

● It's more fun

Target platforms

=

(c) Rareware

Target platforms

=

Target platforms

Platform independence

● Write as much as possible in a standard/portable language

Obj-C

C++Platform independent code

Platform specific code

iOS Android

JavaJNI

Platform independence?

● Easy transition to any platform that supports C++

+

Entity System (the glue and

communication channel)

System

Physics

Renderer (Graphics)

Tools

Input

Game Code

Sound

Resource Management

ThreadsFile I/O

Scene

Architecture Overview

Engine SubsystemsWalkthrough

Input

ThreadsFile I/OSystem

● Initialize Subsystems

● Provide a callback that is called each frame

● Provides threads for asynchronous tasks

● Invoke certain device specific actions (e.g.: Post to facebook, show onscreen keyboard, In-App purchases)

● Input: Touch handling, Keystrokes (Android: Back button), Other platforms (Keybaord, Mouse)

● Read and write files (resources, save games)

Main platform dependent part

Entity System

Scene

Entities (Game Objects)

Collection of components

Entity System

SceneComponent

Properties

Entities (Game Objects)

Entity System

● Component properties can be saved to and loaded from storage

● Properties can be read and modified by runtime systems (physics, game code, renderer, etc)

● Fast queries of the type: Return all objects that have a certain component

e.g. render all meshes, rotate all cannons, etc

Resource Handling

TexturesSound Files

Geometry

● Decompression is fast compared to reading data from storage

● Extract resources on-demand from ZIP

● Retrieving a resource still takes time, and we need a robust system to handle this latency

Resource Streaming

Renderer

Time

Draw, Draw

RendererDraw, Draw

?

Renderer

Resource Streaming

RequestTexture

Draw, Draw

Renderer

Resource Streaming

RequestTexture

Continue, ignoring texture until it is loadedDraw, Draw

Time

Renderer

Resource Streaming

System

RequestTexture

Read from storage *.zip, unpack

Requestdata

Draw, Draw

Time

Renderer

Resource Streaming

System

RequestTexture

Decode, upload to GPU

Read from storage *.zip, unpack

Requestdata

Draw, Draw

Time

Renderer

Resource Streaming

System

RequestTexture

Decode, upload to GPU

Read from storage *.zip, unpack

Requestdata

Return Texture Handle

Draw, Draw

Time

Renderer

Resource Streaming

System

RequestTexture

Decode, upload to GPU

Read from storage *.zip, unpack

Requestdata

Return Texture Handle

Draw with actual texture

Draw, Draw

Time

Sound

Small files, fit in memoryLarge files, need to be streamedAnd compressed

~40 MB for a file< 0.5 MB for a file

One Shot Background Music

Audio Compression

?

Audio Compression

● 4:1 compression ratio

● decoded in about 100 lines of code

● runs on any platform

Audio Compression

AIFC/IMA4Lightweight solution?

Sound on Android

● Historically THE weakness of the Android platform

● iOS: OpenAL, established industry standard

Sound on Android

● Historically THE weakness of the Android platform

● iOS: OpenAL, established industry standard

● Android < 2.3: Java-only API

- Not easy to access from C++

- High latency on some devices

- More problematic than GPU fragmentation

Sound on Android

● Historically THE weakness of the Android platform

● iOS: OpenAL, established industry standard

● Android < 2.3: Java-only API

- Not easy to access from C++

- High latency on some devices

- More problematic than GPU fragmentation

● Android >= 2.3: OpenSL ES

GraphicsSpeaking of GPU fragmentation...

GraphicsSpeaking of GPU fragmentation...

Graphics

● OpenGL ES 1.1 with fixed function pipeline

(support for early iPhones and some low cost android phones)

● OpenGL ES 2.0 with shader generator & shader cache

(for current and future devices)

Speaking of GPU fragmentation...

Textures

● Store textures in a native format, to avoid long loading times (NO PNG!)

● Consider using 16 bit formats instead of 32 bit

● Do not use alpha channel if not needed

● Consider using Texture Compression if you can control the artefacts (alpha!)

Texture Compression

● Many different compression standards

● On iOS there is only one brand of GPU (PowerVR) and all support PVRTC.

● Android: Trouble, at least 3 major different formats, some devices do not support any compression

● If you can avoid it, perfect (we avoided it on Android, but we use PVRTC on iOS)

● Retina/Hi-Res Screens might force you to use some form of compression (2048x2048 Texture = 16 MB!!)

5 Physics

p

Physics

● 2D physics

● Sequential Impulse approach for collision response

● For everyone interested – check out the GDC 2009 slides by Erin Catto (Box2D) they should get you started.

● Custom solution – very simple, but I wanted to get to the bottom of it

Lessons learned

● It works! (→ Captain Clumsy)

● Platform abstraction is worth the effort

● Custom technology is feasible, even fora small team

● Technology can be reused for next games

● Spend more time on tools

Get in touch

● Email me at: me@bblock.net

● Twitter: lhyanor

● Cute Attack Website: cuteattack.com

Thank you for your attention :)