Development of cross-platform mobile game technology

1,113 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,113
On SlideShare
0
From Embeds
0
Number of Embeds
254
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Development of cross-platform mobile game technology

  1. 1. Development ofcross-platform mobilegame technologyBenjamin J. BlockCute Attack, OyShared Gems 2013
  2. 2. PhD in Computational PhysicsUniversity of MainzMobile Games Technology
  3. 3. 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?
  4. 4. Why no middleware?● No control over development● Performance penalties● I wanted to learn something● Its more fun
  5. 5. Target platforms=(c) Rareware
  6. 6. Target platforms=
  7. 7. Target platforms
  8. 8. Platform independence● Write as much as possible in a standard/portablelanguageObj-CC++Platform independent codePlatform specific codeiOS AndroidJavaJNI
  9. 9. Platform independence?● Easy transition to any platform that supports C+++
  10. 10. Entity System(the glue andcommunicationchannel)SystemPhysicsRenderer (Graphics)ToolsInputGame CodeSoundResourceManagementThreadsFile I/OSceneArchitecture Overview
  11. 11. Engine SubsystemsWalkthrough
  12. 12. 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)
  13. 13. Entity SystemSceneEntities (Game Objects)Collection of components
  14. 14. Entity SystemSceneComponentPropertiesEntities (Game Objects)
  15. 15. 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
  16. 16. Resource HandlingTexturesSound FilesGeometry
  17. 17. ● 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
  18. 18. RendererTimeDraw, Draw
  19. 19. RendererDraw, Draw?
  20. 20. RendererResource StreamingRequestTextureDraw, Draw
  21. 21. RendererResource StreamingRequestTextureContinue, ignoring texture until it is loadedDraw, DrawTime
  22. 22. RendererResource StreamingSystemRequestTextureRead from storage *.zip, unpackRequestdataDraw, DrawTime
  23. 23. RendererResource StreamingSystemRequestTextureDecode, upload to GPURead from storage *.zip, unpackRequestdataDraw, DrawTime
  24. 24. RendererResource StreamingSystemRequestTextureDecode, upload to GPURead from storage *.zip, unpackRequestdataReturn Texture HandleDraw, DrawTime
  25. 25. RendererResource StreamingSystemRequestTextureDecode, upload to GPURead from storage *.zip, unpackRequestdataReturn Texture HandleDraw with actual textureDraw, DrawTime
  26. 26. SoundSmall files, fit in memoryLarge files, need to be streamedAnd compressed~40 MB for a file< 0.5 MB for a fileOne Shot Background Music
  27. 27. Audio Compression?
  28. 28. Audio Compression
  29. 29. ● 4:1 compression ratio● decoded in about 100 lines of code● runs on any platformAudio CompressionAIFC/IMA4Lightweight solution?
  30. 30. Sound on Android● Historically THE weakness of the Androidplatform● iOS: OpenAL, established industry standard
  31. 31. 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
  32. 32. 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
  33. 33. GraphicsSpeaking of GPU fragmentation...
  34. 34. GraphicsSpeaking of GPU fragmentation...
  35. 35. 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...
  36. 36. 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!)
  37. 37. 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!!)
  38. 38. 5Physicsp
  39. 39. 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
  40. 40. 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
  41. 41. Get in touch● Email me at: me@bblock.net● Twitter: lhyanor● Cute Attack Website: cuteattack.comThank you for your attention :)

×