Should I use lime or OpenFL for my game engine translation?

Lime
#1

Hi,

Warning, Haxe/OpenFL newb here.

So… given that my hobby-engine is data driven and not really object oriented, what part of Lime/OpenFL should I use to get best performance/control when drawing things to the canvas/whatever, so that I can more or less implement the engine with the same data driven approach and not ending up with too much Objectiveness overhead?

I guess I need to have some kind of low level draw/blit abstraction or WebGL/OpenGL abstraction, as well as Keyboard, Touch, Mouse, Audio, Asset Loading etc.

Is there any point in using only Lime and not OpenFL, or can I mix and match between them?
Can I go low level width OpenFL or does it require a high level API and the whole game engine being adapted?

Background
I have written a small and fast 2d game engine (hobby project) in Javascript that I later translated to Typescript. After optimizing it for modern compiling JS engines and being happy with a smooth 60FPS but being increasingly irritated that I wasnt writing much javascript, more like writing “V8-script”, in order to make Crankshaft (the optimizing compiler) happy, I decided that maybe it was time to move on. I rememberd Haxe from somewhere in the back of my head and revisited it and it really lookes just like I wanted. :slight_smile: But if I want to get the multiplatform part I have to use something like lime or OpenFL, to abstract some hairyness away.

I know, theres a million game engines out there, but it all started with me loving JS optimization and the rest just happend. Its never gonna be the fastest and for everyone but I reach fullscreen 1280/720 60FPS smooth on a windows tablet as well as a 3yo Ipad.

Thanks,
J

#2

OpenFL is more higher-level, so I would suggest looking more into Lime. With more specifics though, probably others with more knowledge of the OpenFL rendering workflow could answer. How does your engine look in terms of API it connects to?

#3

Thanks cactusantuary,

My engine is built on very thin GameObjects (and other objects such as Vec2 etc) being mere pooled data structs and then a bunch of static managers (Renderer, Collision, VectorMath, Animation, Audio etc) acting on these structs. Wise or stupid, my thought was to keep the overhead to a minimum and making it easy for the browser to optimize (and for me to predict it. So the managers sometimes depend directly on HTML5 APIs but the game logic en enteties do not. But because its not an object oriented approach (more procedural), it doesn’t allow for easy translation to that either on an API level. So the “smallest” real Class (with functions and inheritance) is a Scene, which is actually just a subset of the game logic and lists of its resources, since all other features such as rendering, staging, physics, movement etc. is handled by respective managers.

Its not using any third party libraries since my idea was to try and build it from scratch.