Screenplay by Tom Vian
•Download as PPT, PDF•
0 likes•1,621 views
Tom Vian of Super Flash Bros. explains how to properly optimize your Flash games for many different screens of mobile devices.
Recommended
More Related Content
Viewers also liked
Viewers also liked (18)
More from mochimedia
More from mochimedia (20)
Recently uploaded
Recently uploaded (20)
Screenplay by Tom Vian
- 2. Tom Vian Screenplay By Tom Vian @SFBTom tomvian.com superflashbros.net
- 4. @SFBTom as3sfxr superflashbros.net/as3sfxr
- 6. Screenplay Screenplay By Tom Vian Screens Graphics Code Controls Gameplay
- 8. Screenplay - Screens @SFBTom Flash Platform
- 9. Screenplay - Screens @SFBTom Mobile Phones
- 10. Screenplay - Screens @SFBTom Tablets
- 11. Screenplay - Screens @SFBTom Screen Measurements
- 12. Screenplay - Screens @SFBTom Aspect Ratio
- 13. Screenplay - Screens @SFBTom Aspect Ratio: Mobiles
- 14. Screenplay - Screens @SFBTom Aspect Ratio: Tablets
- 15. Screenplay - Screens @SFBTom Aspect Ratio: PCs
- 16. Screenplay - Screens @SFBTom Pixel Density
- 18. Screenplay - Graphics @SFBTom Flash Auto Scaling
- 19. Screenplay - Graphics @SFBTom Manual Resizing
- 20. Screenplay - Graphics @SFBTom Background Overflow
- 21. Screenplay - Graphics @SFBTom Scaling UI Elements
- 22. Screenplay - Graphics @SFBTom Dynamic Layout
- 23. Screenplay - Graphics @SFBTom Using Vectors
- 24. Screenplay - Graphics @SFBTom CPU Rendering
- 25. Screenplay - Graphics @SFBTom GPU Rendering
- 26. Screenplay - Graphics @SFBTom Bitmap Scaling: Up (CPU) No Smoothing Smoothing
- 27. Screenplay - Graphics @SFBTom Bitmap Scaling: Up (GPU) No Smoothing Smoothing
- 28. Screenplay - Graphics @SFBTom Bitmap Scaling: Down (No Snapping) No Smoothing Smoothing
- 29. Screenplay - Graphics @SFBTom Bitmap Scaling: Down (Snapping) No Smoothing Smoothing
- 30. Screenplay - Graphics @SFBTom Mipmapping
- 32. Screenplay - Code @SFBTom Conditional Compilation
- 33. Screenplay - Code @SFBTom Checking Capabilities
- 34. Screenplay - Code @SFBTom AIR Runtime
- 35. Screenplay - Code @SFBTom Compiling to iOS
- 36. Screenplay - Code @SFBTom Speed Tips
- 38. Screenplay - Controls @SFBTom Tapping
- 39. Screenplay - Controls @SFBTom Dragging
- 40. Screenplay - Controls @SFBTom Gestures
- 41. Screenplay - Controls @SFBTom Accelerometer
- 42. Screenplay - Controls @SFBTom Fake Mouse
- 43. Screenplay - Controls @SFBTom Game Pad
- 44. Screenplay - Controls @SFBTom Others
- 45. Gameplay Screenplay By Tom Vian
- 46. Screenplay - Gameplay @SFBTom Fixed Ratio
- 47. Screenplay - Gameplay @SFBTom Variable Ratio
- 48. Tom Vian Screenplay By Tom Vian @SFBTom tomvian.com superflashbros.net
Editor's Notes
- 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