The Future of Cross-Platform Development: Post-Mortem on Transitioning from Flash to Haxe | Doug Pearson

Douglas Pearson
Co-Founder and CTO
FlowPlay, Inc

VegasWorld.com apps.facebook.com/vegas_world zone.msn.com/en/casino/default.htm
m
iPad Android & Kindle

 ~$1 million/month
 Company size 35 people

 1,400,000 lines of ActionScript
 Code developed over 8 years
 Slow on mobile devices
 Flash way going away…some day

 Art assets used vector art, not bitmap art
 No GPU help
 Slow on mobile
 Aging code base (8 years of work)
 Technical debt
 But only a small development team
 Browsers could drop Flash support at any time
 Would completely kill our business
 Needed to replace the entire car while driving down the freeway
 Players expect new features, new games
 Monetization improvements, bug fixes
 New partnerships, new devices

 One codebase for all devices
 Web
 iPad, iPhone
 Android tablet, phones, kindle
 Needed to support a large, complex code base
 > 1 million line code base
 Type safety a major plus
 Caveat: Solution for our business – not 1 size fits all.

 HTML5 (JavaScript)
 Wrapped on mobile (phone gap, appcelerator, cordova etc.)
 Pros
 No need to cross compile for different devices
 Write once, run everywhere
 Cons
 Slowest performance on the lowest end devices
Structural competitive disadvantage
 JavaScript’s lack of strong type safety
 Facebook very publicly dropped this approach
 Perhaps correct in another 5 years?

 Pros
 Native Android
 Native iOS
 Native Windows App
 Cons
 Define “cross-platform” differently
 No web support
Total show stopper for us
 Quite like that others choose these platforms: “mobile first”
Less open web competition, mobile is brutal

 Pros:
 Cross compile to native (Android/iOS), HTML5 and lots more
 Strong 3D engine and content creation tool
 C# programming language
 Huge community
 Cons:
 Weak on the web (plugin => cross compile through C++)
 Version model assumed game written for one version
Not great for long lived games
 Closed platform
Show stopper bug that nobody else cared to fix?
What if platform died off? Looks most similar to Flash ecosystem today
 “Heavy” platform
Content creation, runtime, cross compilation etc.
Does lots but more tightly coupled

 Pros:
 Cross compile to native (Android/iOS), HTML5 and lots more
 Strongly typed language designed for cross compilation
 OpenFL library to help with porting Flash code
 Open source (MAJOR plus)
 Cons:
 Small community at the time (Tivo,…)
 Could it handle a game of our size and complexity?
 Tool chain, documentation etc. less polished
 In practice did it work as well as the marketing blurb said?

 Project 1:
 Rewrite entire codebase to use bitmap art
 Still Flash (ActionScript)
 Rewriting a million lines of code – no small task
 Project 2:
 Write a Haxe slots game from scratch
 Use our existing backend – shared accounts with web
 Prove we could use this platform and deliver on
 Flash (SWF)
 iOS + Android
 HTML5
 Get familiar with the tech

 New UI design / all new art
 Model-View-Controller architecture
 900,000 lines of new code
 Timeline ~ 18 months:
 9 months small team; 6 months full (20+) team, 3 months QA, Aug 2016 live.

 First handset targeted game for us
 All new design
 First experience with Haxe tools
 Timeline ~ 12 months with a small team (~4)
 Jan 2016 live on Android + iOS
 April 2016 HTML5 (Windows 10 store app)

 Project 1: “Rewrite”
 Complete and live (but polish needed)
 Project 2: “Haxe slots game”
 Complete and live
 Demonstrated Haxe was viable
Flash, Android, iOS, HTML5 all from one code base
Native extensions a major challenge
Haxe plugin for IDEs had some problems
 May 2016 major announcement
 Chrome announced “Flash disabled by default” in 6 months
 We needed to get porting!!

 Direct port of rewritten code base
 No UI/art/game changes
 Initial goal – launch as a Flash game still
 Then HTML5

 Supporting 3 live, large codebases at once:
 Old ActionScript game
 New ActionScript game
 New ported Haxe game
 Still adding features to the live games
 “Rebuilding car as driving down the freeway”
 Anything added to old game needed to be added to new and Haxe too

 Big, complex game
 900,000 lines of code to port to Haxe
 50+ slot machines, 12+ table games
 50,000+ in game items
 Avatars, social features, a whole world
 Picky players
 Social games are hard. Players can revolt.

 Abstract platform design
 Loading images
 Drawing images
 Playing animations
 Playing sounds
 Talking to server
 Modular game design (each game like blackjack largely independent of others)
 Invested directly in the Haxe platform
 Hired Joshua Granick (lead dev Haxe-OpenFL)
 Contracted with Eric Bishton (lead dev on IntelliJ Haxe plugin)

 Limited use of automated tools to port
 Started using “AS2HX” tool
 Switched to our own simple string-replace tool
 Guaranteed correct only
 Rewrite first, port second
 Rewrote in language and tools we knew
 Learned new platform first
 Then ported without changing
 No new art
 No server changes

 Open source platform
 Bugs/problems in rendering engines
 IPv6 support
 Able to extend areas important to us (e.g. modular HTML5 loads)

Sept 2016 - Haxe port started small team (1-2)
Feb 2017 - Expanded to full team (~20) Haxe porting
Apr 201 7 - Haxe (Flash) into QA
June 2017 - Haxe (HTML5) working (very little effort)
July 2017 - Haxe (Flash) ready for release
- Haxe (HTML5) in QA
- Haxe (Android/iOS) soon

 For us Haxe was definitely the correct choice
 It worked !!
 Flash, Android, iOS for today
 HTML5 for tomorrow
 WebAssembly, Desktop app for next year?
 Cross-compiling feels very strong
 Performance looks excellent
 Not tied to one target if market shifts
 Open source so we can shape the future direction

 Haxe tool set lighter than a full platform like Unity
 Less in the platform
 More in the libraries (Starling, Away3D etc.) – easier to extend
 Historically this sort of platform has aged better (e.g. Java vs Flash)
 Company still in business
 Revenues up 50% from when we started
 Time to go build exciting new stuff

The Future of Cross-Platform Development: Post-Mortem on Transitioning from Flash to Haxe | Doug Pearson

The Future of Cross-Platform Development: Post-Mortem on Transitioning from Flash to Haxe | Doug Pearson

Recommended

More Related Content

What's hot (6)

Similar to The Future of Cross-Platform Development: Post-Mortem on Transitioning from Flash to Haxe | Doug Pearson (20)

More from Jessica Tams (20)

Recently uploaded (20)

The Future of Cross-Platform Development: Post-Mortem on Transitioning from Flash to Haxe | Doug Pearson