5. 1,400,000 lines of ActionScript
Code developed over 8 years
Slow on mobile devices
Flash way going away…some day
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Direct port of rewritten code base
No UI/art/game changes
Initial goal – launch as a Flash game still
Then HTML5
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. 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. 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. 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. Open source platform
Bugs/problems in rendering engines
IPv6 support
Able to extend areas important to us (e.g. modular HTML5 loads)
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. 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. 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