Development of cross-platform mobile game technology
Development ofcross-platform mobilegame technologyBenjamin J. BlockCute Attack, OyShared Gems 2013
PhD in Computational PhysicsUniversity of MainzMobile Games Technology
BackgroundSoftware Engineering in Games is HARDArchitecture is most important challengeWhy?● High performance constraint● High complexity and interconnectivity→ Can reusable and modular software design beachieved while maintaining high performance?
Why no middleware?● No control over development● Performance penalties● I wanted to learn something● Its more fun
InputThreadsFile 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)
Entity SystemSceneEntities (Game Objects)Collection of components
Entity System● Component properties can be saved to and loaded fromstorage● 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 componente.g. render all meshes, rotate all cannons, etc
● Decompression is fast compared to reading datafrom storage● Extract resources on-demand from ZIP● Retrieving a resource still takes time, and weneed a robust system to handle this latencyResource Streaming
● 4:1 compression ratio● decoded in about 100 lines of code● runs on any platformAudio CompressionAIFC/IMA4Lightweight solution?
Sound on Android● Historically THE weakness of the Androidplatform● iOS: OpenAL, established industry standard
Sound on Android● Historically THE weakness of the Androidplatform● 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 Androidplatform● 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
Graphics● OpenGL ES 1.1with fixed function pipeline(support for early iPhonesand some low cost androidphones)● OpenGL ES 2.0with shader generator &shader cache(for current and futuredevices)Speaking of GPU fragmentation...
Textures● Store textures in a native format, to avoid longloading 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 cancontrol the artefacts (alpha!)
Texture Compression● Many different compression standards● On iOS there is only one brand of GPU (PowerVR) and allsupport PVRTC.● Android: Trouble, at least 3 major different formats, somedevices do not support any compression● If you can avoid it, perfect (we avoided it on Android, but weuse PVRTC on iOS)● Retina/Hi-Res Screens might force you to use some form ofcompression (2048x2048 Texture = 16 MB!!)
Physics● 2D physics● Sequential Impulse approach forcollision response● For everyone interested – checkout the GDC 2009 slides by ErinCatto (Box2D) they should get youstarted.● Custom solution – very simple, butI 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: firstname.lastname@example.org● Twitter: lhyanor● Cute Attack Website: cuteattack.comThank you for your attention :)