Creating Engaging and Optimized 2D Flash Games for Connected TVs

1. Tomasz Wisniowski Playjam Ltd. Creating and Optimizing 2D Flash Technology–Based Games for Mass Market TVs October 2011, Adobe MAX @playjamdev

2. Table of contents • Why create games for ConnectedTV? • Evolution of CTV • Market Dynamics • Target audience • Challenges for developers • Technical aspects of creating CTV games • AS2 vs. AS3 vs. AIR • Input • Display • Sound • General code guidelines • Case study • Sum up • Closing remarks

3. Continual Evolution • Major Consumer Electronics (CE) vendors driven by the hunt for recurring revenues & the necessity to shift from pure manufacturing to service operators. • Addressing global markets with richer, faster interactivity than ever seen on TV before. Made possible by lower prices and better tools: Better hardware Optimized software Smarter input

4. Market Dynamics • Combined installed base – 1billion devices by 2015

5. Market Dynamics So, we have: • A viable casual games platform today • In huge volume • Globally HOWEVER:

6. Are Games Important? • 21% connecting primarily to access games • 47% of connected homes would play games

7. iTunes – A Great Precedent

8. Smart TV - Early Indicators 24% = Games 23% = Educational apps Samsung @Internet TV Store

9. Who’s Playing? Male Female Age Frequency Gender

10. Playing Behavior Genre Motivation

11. So what are the challenges? • Delivering and app store experience conducive to the TV / Living Room • Solving discoverability for content owners • Coping with technology pace and fragmentation • Creating sustainable revenues

12. Technology choice • First questions – what technology to use, and which programming language to choose • Javascript? Flash? • If Flash – AS2 (Flash Lite) vs. AS3 (Flash 10.1+) • Flash or AIR? ? ? ? ? ? ? ?

13. Platforms/Technologies

14. Javascript • In most cases – older TVs • Still a big market • From our experience, less compatibility problems than with Flash

15. Flash • AS2 vs. AS3 (or rather Flash Lite vs. Flash 10.1) • Things to consider: • Performance • Do you already have a backlog of games that you want to re-deploy on CTV? • External libraries access • (subjective) AS3 code easier to create, more modern

16. Technologies comparison Yahoo! Widgets Panasonic JavaScript

17. Input • Different types of input • Each remote has a different key layout • OEMs typically want you to support all types of their input • Your application MUST be fully navigable by d-pad + enter

18. Input – continued • Things to keep in mind: • Different key codes for each manufacturer • Input lag • KeyUP/KeyDOWN handling • Technically impossible to press two keys at once

19. Display • Most of the devices support HD, but the recommended resolutions for applications are QHD or 720p • Since the graphics are upscaled, they tend to be blurry and/or pixelated

20. Display - continued • Problems when deploying your application to 720p devices if your initial version was QHD – this happens quite often. • Flash software scaling causes performance drops – avoid if possible! • Safe zones:

21. Sound • Some devices support sound, some don’t • Some support BGM only • Most allow for various file types: mp3, ogg being most popular • Sound support varies by device – some can play music/sfx straight from Flash, others need to play sounds via fscommand2 or javascript

22. Programmer’s guidelines • Typically the amount of memory available for applications is more than enough (for casual games) • Graphics are usually stored with 32 bits per pixel. Full hd screen = 1920x1080 pixels * 32 bits = 66 355 200 bits = ~8MB – way too much memory! You usually have about 6 MB of texture memory in total, everything over that causes a significant performance loss. • TRACK YOUR MEMORY USAGE! • Avoid the use of alpha • Avoid rotating objects (especially in javascript) • The application should run at 20+FPS

23. Case studies Case 1 Pick & Nick AS2/AS3 Case 2 Space Shooter MAX Demo, AIR 3.0 with Molehill

24. Summing up • There is a wide range of devices to choose from • Make sure that the application is designed for a 10ft experience: • Don’t use fonts smaller than 18px • Don’t make the user read a lot of text • Keep the forms (input fields) to the bare minimum • Double check that every functionality you designed is accessible by d-pad + enter. System keys such as EXIT and BACK/RETURN are programmable too, as well as the colored keys. • Making your game support mouse input will make it work with most „wand” input methods too!

25. Summing up - continued • Use hardware acceleration where possible (cache as bitmap) • Remove everything that does not to be on the screen from the memory, if possible. Remember this is a memory-tight environment. • Don’t use Flash native tabbing, create your own input mechanisms. • If you want to use objects with alpha, make sure they don’t get on top of each other! • Don’t bloat your application, some platforms have a limitation on how big the installation can be. Store the assets, or even separate .swf’s remotely in such cases.

26. Summing up - continued • Make sureyourgraphicsarescaleable – youprobablywon’t be sticking to eitheronly QHD oronly 720p. • Usevectorgraphicswherepossible – less strain on thememory. • Gameplay-wise: • Avoid situations where input lag might affect the fun. • Avoid asking the player to press two buttons at the same time.

27. Closing remarks • Flash Lite was never meant to create games or applications • The market is slowly moving away from Flash Lite towards Flash 10.1/AIR2.5 • It means better support for game developers – access to more game engines, better libraries • Better cross-platform opportunities – immediate porting to iOS, Android, and many more

28. Thankyou for coming! Thankyou for coming! Tomasz Wisniowski PlayJam Ltd. @twisniowski @playjamdev