Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

251 views

Published on

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

Published in: Software
  • Be the first to comment

  • Be the first to like this

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

  1. 1. Douglas Pearson Co-Founder and CTO FlowPlay, Inc
  2. 2. January 2015
  3. 3. VegasWorld.com apps.facebook.com/vegas_world zone.msn.com/en/casino/default.htm m iPad Android & Kindle
  4. 4.  ~$1 million/month  Company size 35 people
  5. 5.  1,400,000 lines of ActionScript  Code developed over 8 years  Slow on mobile devices  Flash way going away…some day
  6. 6.  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
  7. 7.  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.
  8. 8.  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?
  9. 9.  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
  10. 10.  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
  11. 11.  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?
  12. 12.  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
  13. 13.  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.
  14. 14.  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)
  15. 15.  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!!
  16. 16.  Direct port of rewritten code base  No UI/art/game changes  Initial goal – launch as a Flash game still  Then HTML5
  17. 17.  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
  18. 18.  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.
  19. 19.  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)
  20. 20.  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
  21. 21.  Open source platform  Bugs/problems in rendering engines  IPv6 support  Able to extend areas important to us (e.g. modular HTML5 loads)
  22. 22. 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
  23. 23.  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
  24. 24.  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

×