FGS 2011: Making A Game With Molehill: Zombie Tycoon

4,508 views

Published on

Luc Beaulieu and Jean-Philipe Auclair from Frima Studio share their experience working with Adobe's new Molehill API's in making their new game "Zombie Tycoon".

Published in: Technology, Art & Photos
0 Comments
12 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,508
On SlideShare
0
From Embeds
0
Number of Embeds
1,242
Actions
Shares
0
Downloads
2
Comments
0
Likes
12
Embeds 0
No embeds

No notes for slide
  • Here is a quick overview of what we will go through in this session. I will start by looking at the current state of Flash and I will present the Molehill API that Adobe is offering us. JP will then take over and dig deeper in the technical aspects of it all.
  • Is Flash Dead? Look this up in Google and you’ll find many interesting discussions. I have no intention on going into the politics of it, so here are some facts.According to AppData, the top two FB apps attracts close to 150M MAU. Both are Flash games. From known metrics, this amounts to a conservative 30M $ per month, all going to the same company, but still WebGL = Final draft was done a month ago.The Flash player provided advances that « helped » 3D based applications. AS3 was a big one, providing a much faster Virtual Machine, but it’s still non-native software rendering. Molehill provides the jump ahead to real 3D on the browser.35 devices by 2010 – Close to 100 deviceswillshipwithit in 2011Flash Stats based on : http://www.adobe.com/products/player_census/flashplayer/version_penetration.html (December 2010)http://tv.adobe.com/watch/industry-trends/strong-mobile-adoption-of-flash-platform-in-2011/
  • Molehill opens a low-level API to access the GPU. Adobe decided to limit this API to a lowest supported denominator. This decision has been made to keep a consistent experience across all supported platforms.Those are some Pros and Cons, you can probably draw your own list after playing with it No CPU threading API yet on the Flash player. Adobe has been using it more internally and I’m sure they are working on something for us to use soon One thing to note, is the software fallback. Be careful when designing Molehill games, decide if you can afford the software renderer as soon as possible. If you don’t support it, always validate that hardware is used and show a prompt otherwise.I will now let JP discuss the technical aspects of all of this 
  • Starting with the base, the file formatAnd the I Will cover some of the system that we have in ZombieTycoon
  • If you have 1000 quad particles, itmeansyou have to update around 6000 vertex to update, and witharound 10 values soAt the end it’s 60 000 update on yourbytearray.VB: of 64 DWORD
  • If you have 1000 quad particles, itmeansyou have to update around 6000 vertex to update, and witharound 10 values soAt the end it’s 60 000 update on yourbytearray.VB: of 64 DWORD
  • If you have 1000 quad particles, itmeansyou have to update around 6000 vertex to update, and witharound 10 values soAt the end it’s 60 000 update on yourbytearray.VB: of 64 DWORD
  • If you have 1000 quad particles, itmeansyou have to update around 6000 vertex to update, and witharound 10 values soAt the end it’s 60 000 update on yourbytearray.VB: of 64 DWORD
  • FGS 2011: Making A Game With Molehill: Zombie Tycoon

    1. 1. Making a game with Molehill: Zombie Tycoon<br />Luc BeaulieuCTO – Frima Studio<br />Jean-Philippe AuclairLead R&D Software Architect<br />
    2. 2. State of Flash<br />Molehill’s API presentation<br />Digging deeper into Molehill<br />Session Overview<br />
    3. 3. Is Flash Dead?<br /><ul><li>FB Top 10 = 250M MAU
    4. 4. Desktops: Flash 10 installed on 99%+
    5. 5. SmartPhones: Flash/Air 200+M, 100 devices
    6. 6. Streaming: 120 petabytes per month</li></ul>Advances in Flash for 3D games<br /><ul><li>AS3
    7. 7. 10.1, 10.2 …
    8. 8. Molehill</li></ul>State of Flash<br />
    9. 9. Pros:<br />GPU Accelerated API<br />Relies on DirectX 9, OpenGL 1.3 and OpenGL ES 2.0<br />Native Software fallback<br />Cons:<br />No point sprite support, branching, MRT, depth buffer<br />No CPU threading support<br />Native Software fallback<br />Molehill’s API Presentation<br />
    10. 10. This Page Intentionally Left Green<br />
    11. 11. Assuming a basic knowledge of 3D development terminology<br />Zombie File Format<br />Character Animation: Matrix vs Quaternion<br />Optimizing the Particle System<br />Fast Lights & Shadows<br />CPU Post-Processing effects<br />Profiling & Debugging tools<br />Bonus!<br />3D GameDev Lexicon<br />The maths explaining all the numbers I’m going to talk about<br />Cheat sheets<br />Digging deeper into Molehill<br />
    12. 12. Frima 3D File Format<br />Many 3D engine for flash try to support multiple input format<br />…Or try to use generic format such as ColladaXML<br />Using a format optimized for 3D game made in Flash<br />Small File Size<br />Small Memory footprint<br />No processing required<br />
    13. 13. Frima 3D File Format<br />Supporting one Pipe-line for optimized result<br />Using a AIR tool to read Collada files, parse them and fill final game Model/Animation objects<br />Native object serialization (AMF)<br />Native ByteArray Compression<br />
    14. 14. Texturing in Molehill<br />Adobe Texture Format (ATF)<br />Simple PNGs are expended in video memory<br />Native support for multi-device publishing<br />One file containing 3 encoding: DXT1, ETC1 and PVRTC<br />Does not support transparency<br />Contain the MipMapping of the texture<br />1.3x bigger than original PNG<br />Transparency<br />Use PNGs with indexed color<br />Sample a “alpha mask texture” in the pixel shader<br />
    15. 15. Texturing in Molehill<br />Texture type image<br />Graph videospace<br />
    16. 16. Zombie Re-Animation<br />Techniques<br />Matrix linear blending<br />DualQuaternion linear blending<br />Molehill Constraint<br />Vertex Shader constants limits: 128 Float4<br />
    17. 17. Animation techniques<br />When using matrix, each bone take 3 constants<br />Maximum number of bones is 40<br />When using DualQuats, each bone take only 2 constants<br />Maximum number of bones is 60<br />Matrix linear blending can cause loss of volume when joints are twisted or extremely bent<br />Matrix (left) / Dual Quaternion (Right)<br />
    18. 18. Transitions & interpolation<br />Too Much<br /><ul><li>Animation transition require two sets of bones
    19. 19. Idle blending to walk
    20. 20. Same thing for frame interpolation (ex: Bullet time Animation)</li></li></ul><li>You have to choose<br />
    21. 21. Optimizing the Particle System<br />
    22. 22. Particle System<br />Using a divided workload (CPU/GPU) for better performance<br />Each particle property update is computed on the CPU at each frame<br />Alpha, Color, Direction, Rotation, frame(If SpriteSheet), etc.<br />On the GPU<br />Applying theses properties<br />Expending billboard vertex to face the screen<br />
    23. 23. Particle System : Optimization<br />How many particle?<br />Due to the VertexBuffer and IndexBuffer limits,<br />In ZombieTycoon we were limited to around 16383 particles per draw call<br />UsingFastByteArray (alsoknown as Alchemymemory or DomainMemory)<br />Using Azoth, properties updates were 10 times faster<br />Batching draw calls using the same texture<br />Using a 100% GPU particle system<br />It’sexpensive on the GPU <br />Support onlylinear transformation<br />Zero CPU required<br />
    24. 24. Particle System<br />
    25. 25. Lights & shadows<br />Techniques<br />ShadowMap & LightMap<br />Dynamic lighting<br />Fake Volumetric lights<br />Fake projected shadows<br />
    26. 26. Lights & shadows<br />ShadowMap & LightMap<br />We used two textures, a “multiplied” ShadowMap and an “additive” LightMap<br /> Diffuse <br />* ShadowMap<br />+ Lightmap<br />= Composite<br />
    27. 27. Lights & shadows<br />Dynamic lighting<br />Lighting required expensive pixel shader, currently limited to 256 instructions<br />ZombieTycoon support up to 7-9 lights (spot or points) per object. <br />
    28. 28. Lights & shadows<br />Fake Volumetric Lights<br />Using a few billboard particles, it’s easy to fake a nice and lightweight volumetric lighting<br />All object are sampling Shadow and light maps, and since the lights particle are “additive”, if an object is behind the lights, it will look brighter<br />
    29. 29. Lights & shadows<br />
    30. 30. Lights & shadows<br />Fake projected shadows<br />We create a particle of a gradient black spot aligned to the ground<br />Orientation and scale of the particle depends on light position and intensity<br />
    31. 31. CPU Post-Processing<br />Possibility of reading the BackBuffer<br />Althought not suggested for performance reason, it is possible to draw something and readback in the same frame to work on the final BitmapData with as3 code.<br />Effects<br />Bloom<br />Blur<br />Depth of field<br />Much more!<br />Normal<br />With Bloom<br />
    32. 32. Profiling and Debuggingtools (CPU)<br />FlashDevelop<br />Most of the production is using FlashDevelop<br />Now with a profiler and a debugger, it’s very easy to work with it<br />Flash Builder Profiler<br />Profile Function calls<br />Profile Memory allocation<br />FlashPreloadProfiler<br />Profile Function calls<br />Profile Memory allocation<br />Profile Loaders status<br />Can be used in Debug/Release & browser/Projector<br />FlashDevelop<br />FlashPreloadProfiler<br />FlashBuilder Profiler<br />
    33. 33. Profiling and Debuggingtools (GPU)<br />Pix for windows<br />List of API call<br />Shaders assembly code<br />Pixel debugger<br />Texture viewer<br /><ul><li>Intel® Graphics Performance Analyzers (GPA)
    34. 34. Render in wireframe
    35. 35. Profile Vertex and Pixel shader performance
    36. 36. Visuallize overdraw and draw call sequence
    37. 37. Save a frame, and make real time experiment
    38. 38. Identification of bottle necks</li></ul>PIX<br />GPA<br />
    39. 39. Sources & References<br />Geometric Skinning with Approximate Dual Quaternion Blending <br />http://isg.cs.tcd.ie/kavanl/papers/sdq-tog08.pdf<br />Intel® Graphics Performance Analyzers (GPA)<br />http://software.intel.com/en-us/articles/intel-gpa/<br />Pix for windows<br />http://msdn.microsoft.com/en-us/library/ee417072(v=VS.85).aspx<br /><ul><li>TD-Matt blog
    40. 40. http://td-matt.blogspot.com/
    41. 41. FlashPreloadProfiler
    42. 42. http://jpauclair.net/flashpreloadprofiler/
    43. 43. Azoth
    44. 44. http://www.buraks.com/azoth/
    45. 45. Flash in Facebook
    46. 46. AppData.com
    47. 47. Flash Stats
    48. 48. http://adobe.ly/rwXU
    49. 49. http://adobe.ly/gnlUEH</li></ul>Contact<br />Luc Beaulieuluc@frimastudio.com<br />Jean-Philippe Auclairjpauclair@frimastudio.com<br /><ul><li>@jpauclair
    50. 50. jpauclair.net</li></li></ul><li>VertexBuffer<br />IndexBuffer<br />Vertex Constants<br />MipMapping<br />Quaternion<br />Billboard<br />What?<br />
    51. 51. Character animation:<br />Matrixlinearblending:<br />128 Float4 VertexConstant – WorldMatrix – ViewProjmatrix = 120Float4<br />120Float4 / / 3Float4 per bone = 40 bones in the constants<br />Bullet time and transitions requiretwo sets of bones: 40/2 = 20 bones per character max<br />DualQuaternionlinearblending:<br />128 Float4 VertexConstant – WorldMatrix – ViewProjmatrix = 120Float4<br />120Float4 / / 2Float4 per bone = 60 bones in the constants<br />Bullet time and transitions requiretwo sets of bones: 60/2 = 30 bones per character max<br />Max Particle Count<br />The VertexBuffer is limited to 65536 vertex, the IndexBuffer is limited to 983040 index of type SHORT<br />In theory, you could have up to 327680 triangle in one draw call<br />In practice, with no vertex re-use between particles and using quads (4 vertex): 65536/6 = 16383 particle max per draw call<br />Lighting<br />With the PixelShader limit of 256 instructions, we were able to fit around 7 to 9 dynamic lights per object (point or spot light)<br />Bonus Slide: The maths!<br />
    52. 52. CheatSheet<br />Achievement: Geek<br />
    53. 53. Achievement: Super Geek!<br />
    54. 54. Thank You!<br />Questions?<br />Contact<br />Luc Beaulieuluc@frimastudio.com<br />Jean-Philippe Auclairjpauclair@frimastudio.com<br /><ul><li>@jpauclair
    55. 55. jpauclair.net</li>

    ×