OpenFL and FB instant games

Since FB open their instant game platform for all developers, and in the recommendation JS engines no haxe/OpenFL, does it means we still can use it without fear from FB feedback: “you must use recommendation engine”

Where do you see that? I don’t think they know or care how the game was made.

I don’t think there is any engine prohibited, only suggested/recommended - they repeatedly write that it’s a list that “devs might want to consider”:

However There is a “lightweight” section recommending 1Mb for initial download (without mentioning if it counts the gzipped payload) - this is indicated as being a “manual curation” but this goal may be hard to achieve (without JS splitting) with OpenFl because the JS output can easily be greater than that:

PiratePig, which is a very simple game so most of the size comes from OpenFl, is about 600Kb minified, and less than 200Kb gzipped.

In comparison, for reference, I estimate that Pixi.js v4 is close to the size of OpenFl JS engine - I’m comparing with a very optimised single platform engine, so it’s not too bad :slight_smile: A 3D engine like Babylon.js (also recommended) is close to 2Mb minified.

I’m told by an early IG creator that there aren’t any technical restrictions: the bounce rate from the users is the biggest thing you should be afraid of.

Literally each second counts during startup so it is very important to optimise it:

  • customise HTML template to have inline visuals/progress before the game’s JS is loaded,
  • carefully organise assets management: only minimal load at startup, the rest on demand,
  • make sure it runs on low-end devices, with and without webgl,
  • and maybe look into JS splitting when code complexity grows.

Now that said, I’d say there would be a real opportunity for OpenFl/HaxeFlixel/etc. community to come up with a nice sample FB IG project with basic FB social integration. It could well become a recommended engine!


@elsassph so can haxe-modular help with JS splitting? (I didn’t tried your library, yet).
Also this part

  • Game should not use particles on any features that require hardware acceleration
  • Game should not require WebGL

Is this mean we should force canvas rendering over WebGL and where’s possible run WebGL. But, in other hand, in first row they said to “not use any features…” I’m little bit confused.

openfl.min.js (which includes ALL of OpenFL) is currently 224 KB

Dead-code elimination should help reduce the size further for most projects. The rest of the file size is really up to any additional code added by your project :wink:

Our default behavior is to use WebGL when available, but to fall back to canvas if it is not, so we’re covered there

So you suggest that we use npm version instead standard Haxelib openFL?

No, I’m just using that as a real-world illustration of size. The NPM version has the “kitchen sink” with everything included, standard Haxelib builds will omit what you do not need. The initial generated JavaScript size is deceptive, as gzipping shrinks the size down greatly :slight_smile:

1 Like

Oh I stand corrected - the release-final build of OpenFl is much smaller than the debug build.

Would that be even smaller without webgl support?

Re: Modular:

  • There seem to still be a few problems with Modular splitting with OpenFl 7.1.2 here. @singmajesty did you change all my suggested static init code? CanvasGraphics seem still incorrect as far as I can tell.
  • Also -final doesn’t compress all the bundles (only the main JS); Modular is now friendly to using -lib closure if that can help.

I have some thoughts about openfl.min.js.

if all required functionalities are included with openfl.min.js, can we also market this openfl.min.js as a html5/js game engine to help marketing openfl further in html5/js market? web developers can write their html5 games using this html5/js game engine with pure javascript, babelJS or whatever third party Javascript framework of their choice. furthermore , a github repository especially made to generate openfl.min.js can be created; these web developers can then contribute this repository for any html/js specific change.

We can certainly orient it as an HTML5 game/app library. You can use pure JavaScript, or a compile-to-JavaScript language, we currently support type externs for Haxe, TypeScript and now ActionScript 3.0.

We have made the same repository oriented for building the OpenFL JS modules and the optional single file “openfl.min.js” file. It’s also available on CDN.

However, I’m not sure that contributing JavaScript changes directly the output would be ideal, though if someone does this locally, we certainly can try to work with them to effect their changes in the real sources :slight_smile:

Is there any Openfl Extension to use the Facebook Instant Games SDK?