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