Screenplay by Tom Vian


Published on

Tom Vian of Super Flash Bros. explains how to properly optimize your Flash games for many different screens of mobile devices.

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Some of my games Most with Adam for Armor Games Some with BBC Most recent popular game was Haunt the House, Halloween 2010
  • Port of sfxr by Tomas Petersson Runs in the browser, also open source library for runtime Got started talking at FOTB 2010 with elevator pitch
  • Current game with Adam, for iPhone, iPad, Android phones, Android tablets, BlackBerry PlayBook, desktop, etc One other artist, Catherine Unger 7 voice actors, including Tomamoto and Egoraptor Music by Raphael Benjamin Meyer, finished in under a month Started in Obj-C/Cocos2D, moved to AIR once 2.7 hit
  • Flash Player in the browser, used in games like Machinarium AIR for desktops, new Captive Runtime bundles in AIR runtime to native formats (.exe, .app) AIR for Android devices, again new Captive Runtime bundles AIR into the .apk AIR for iOS, works differently due to licence, compiles the swf into native machine code, along with Flash library AIR for PlayBook, AIR built into device AIR on home devices, Samsung SmartTV pictured, also BluRay players and settop boxes out there Mostly talking about mobile devices, a little about desktop
  • This is the list of officially supported mobile phones, as compiled by Adobe Mostly Android, 5 iOS devices in the bottom right Including iPod Touch here because almost identical to iPhone, despite being mini-tablet You’ll see lots of different sizes of screen, a few physical keyboards, one game pad
  • Officially supported tablets from the same list Again, mostly Android, PlayBook, then iPad 1 & 2 Again, different screen sizes
  • ‘ Screen size’ broken down into 2 measurements, aspect ratio and pixel density
  • Aspect ratio is the ratio of width to height, usually in pixels Important for deciding layout
  • Based on the Adobe supported devices list, weighted by the popularity value from gsmarena Evenly distributed across the 3 main ratios
  • Also based on gsmarena popularity Tablets tend more towards widescreen All this means that if you’re developing for all screens, you should design around a wide screen, then adapt for more square devices
  • Based on data collected by Steam client, which is a good target market for gamers Like tablets, PCs tend towards widescreen
  • Pixel density is the diagonal pixel size of the screen divided by the diagonal physical size, usually in inches Important for sizing elements on the screen, especially user interface Smallest density on mobile is iPhone 3GS/ iPod touch 3G: 165 Smallest density on tablet is iPad: 132
  • For very simple games, you might be able to get away with Flash auto scaling Set the scaleMode to Show All, and Flash will handle the resizing for you However, you get no info on how your game has been scaled Have to stick to your original stage area Perhaps extra background outside the stage to make it look better
  • For most games, you’ll want manual control of resizing Set your scaleMode to No Scale, and flash will resize your stage rather than scale it You can listen to the resize event and apply your own layout and scaling based on the new screen size This way, a pixel on the stage is a pixel on the device
  • For games that stick to the original stage area, you should design extra sections of background to allow for the most extreme aspect ratios The areas shown in bue are the extra areas you need to cover, note the sections missing from the corners
  • When dealing with user interface elements, its far better to scale to a physical size as opposed to a pixel size Use Capabilities.screenDPI to calculate That way, a button will always fit nicely under a finger
  • Lay out your elements based on the size of the screen and the position/size of other elements Can use virtual containers to decide layout For text, Flash Text Engine is great for layout, but poor on performance
  • Vectors can still be useful in certain cases Large, long animation Frames within frames Get the best of both by drawing correctly sized vectors into BitmapData
  • Cpu composites bitmaps, takes up computational cycles Allows you to use filters, blendmodes Good for simple games, low motion
  • Gpu composites bitmaps, leaves cpu for everything else No filters, limited blendmodes Much faster
  • When scaling up on the cpu, smoothing can be used, but it’s slow
  • On GPU, there’s no choice, always smoothed, faster
  • When scaling down, if snapping is turned off, resampling can cause rippling when moving slowly Smoothing can help, but still there
  • Turning on snapping prevents this, but minimum speed is 1 pixel, so looks jerky Auto mode snaps only when bitmap is not rotated or skewed, scaled to ~100%, but doesn’t account for the slow movement
  • Combat scaling issues with a mipmap Have several different versions of your bitmaps compiled in, use the one that’s closest to the scale you need Faster rendering Less scaling issues
  • Any IDE using mxmlc has conditional compilation support Set flags in your code to be compiled in only if true Switch the values for each build Means recompiling for each target, not super neat
  • Better to check at runtime for the capabilities you actually want Enable/disable features based on what’s available NEVER use Capabilities.os to check for platform Can leave features turned on, just unused if unavailable
  • For AIR on desktops, Android and PlayBook, its actually a SWF running in a hardware specific AVM2 with extra features ABC is JITed at runtime into native machine code Standard best practices are a pretty safe bet
  • On iOS, the ABC is put through the LLVM LLVM optimization, compilation step is not well documented on Flash Docs Means you can’t be sure what code is actually running Benchmark things, don’t assume AS3 best practices apply
  • Biggest problem is probably going to be memory, low compared to desktops Techniques like object pooling can save memory and stop object creation, especially for graphical objects Always benchmark if you aren’t sure
  • Talk a little about control schemes These devices have a wealth of new ways to interact Some old ways don’t work to well
  • Button based games Using finger like mouse click Very intuitive Just listen to mouse click
  • Dragging, direct simulation of physical interaction Like moving a piece of paper about a desk Intuitive, even for users new to touch games Does cover the screen though Mouse down, mouse up, enter frame (NOT mouse move)
  • Gestures work great for users who are used to touch screen conventions Fairly intuitive for new users too Built in support for touch gestures in flash
  • For certain types of game, like racing, pretty intuitive Trouble is screen moves with device Need really high contrast, obvious objects on screen Can tilt viewport to keep up, difficult to implement on fast paced games Built in support in AIR
  • Use finger to drag a cursor about Only good if porting a game that really needs mouse over
  • Difficult to implement well Keep buttons to a minimum Maybe start analogue stick wherever you first touch, allow for comfort
  • Camera can be used, but most only on the back of the device Some phones have physical keyboards, good for fallback, but shouldn’t base game around it
  • Fixed ratio game, where the layout of the game doesn’t need to adjust its ratio Can be treated like an app Screen ratio doesn’t affect gameplay The empty space can be filled with background graphics
  • Variable ratio game, where the play area of the game changes shape with the screen Have to take gameplay into account, eg distance you can see ahead of you in a shmup or platformer, distribution of objects as they spawn at the edge In a scrolling game, you should scale in the main direction of motion
  • Screenplay by Tom Vian

    1. 1. ScreenplayBy Tom Vian
    2. 2. Tom Vian Screenplay By Tom Vian @SFBTom
    3. 3. @SFBTomMy Games
    4. 4. @SFBTom
    5. 5. @SFBTomDetective Grimoire
    6. 6. Screenplay Screenplay By Tom Vian Screens Graphics Code Controls Gameplay
    7. 7. ScreensScreenplayBy Tom Vian
    8. 8. Screenplay - Screens @SFBTom Flash Platform
    9. 9. Screenplay - Screens @SFBTom Mobile Phones
    10. 10. Screenplay - Screens @SFBTom Tablets
    11. 11. Screenplay - Screens @SFBTom Screen Measurements
    12. 12. Screenplay - Screens @SFBTom Aspect Ratio
    13. 13. Screenplay - Screens @SFBTom Aspect Ratio: Mobiles
    14. 14. Screenplay - Screens @SFBTom Aspect Ratio: Tablets
    15. 15. Screenplay - Screens @SFBTom Aspect Ratio: PCs
    16. 16. Screenplay - Screens @SFBTom Pixel Density
    17. 17. GraphicsScreenplayBy Tom Vian
    18. 18. Screenplay - Graphics @SFBTom Flash Auto Scaling
    19. 19. Screenplay - Graphics @SFBTom Manual Resizing
    20. 20. Screenplay - Graphics @SFBTom Background Overflow
    21. 21. Screenplay - Graphics @SFBTom Scaling UI Elements
    22. 22. Screenplay - Graphics @SFBTom Dynamic Layout
    23. 23. Screenplay - Graphics @SFBTom Using Vectors
    24. 24. Screenplay - Graphics @SFBTom CPU Rendering
    25. 25. Screenplay - Graphics @SFBTom GPU Rendering
    26. 26. Screenplay - Graphics @SFBTom Bitmap Scaling: Up (CPU) No Smoothing Smoothing
    27. 27. Screenplay - Graphics @SFBTom Bitmap Scaling: Up (GPU) No Smoothing Smoothing
    28. 28. Screenplay - Graphics @SFBTom Bitmap Scaling: Down (No Snapping) No Smoothing Smoothing
    29. 29. Screenplay - Graphics @SFBTom Bitmap Scaling: Down (Snapping) No Smoothing Smoothing
    30. 30. Screenplay - Graphics @SFBTom Mipmapping
    31. 31. CodeScreenplayBy Tom Vian
    32. 32. Screenplay - Code @SFBTom Conditional Compilation
    33. 33. Screenplay - Code @SFBTom Checking Capabilities
    34. 34. Screenplay - Code @SFBTom AIR Runtime
    35. 35. Screenplay - Code @SFBTom Compiling to iOS
    36. 36. Screenplay - Code @SFBTom Speed Tips
    37. 37. ControlsScreenplayBy Tom Vian
    38. 38. Screenplay - Controls @SFBTom Tapping
    39. 39. Screenplay - Controls @SFBTom Dragging
    40. 40. Screenplay - Controls @SFBTom Gestures
    41. 41. Screenplay - Controls @SFBTom Accelerometer
    42. 42. Screenplay - Controls @SFBTom Fake Mouse
    43. 43. Screenplay - Controls @SFBTom Game Pad
    44. 44. Screenplay - Controls @SFBTom Others
    45. 45. Gameplay Screenplay By Tom Vian
    46. 46. Screenplay - Gameplay @SFBTom Fixed Ratio
    47. 47. Screenplay - Gameplay @SFBTom Variable Ratio
    48. 48. Tom Vian Screenplay By Tom Vian @SFBTom