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 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
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?
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?
- 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?
CanvasGraphicsseem still incorrect as far as I can tell.
-finaldoesn’t compress all the bundles (only the main JS); Modular is now friendly to using
-lib closureif that can help.