Haxe game engine code sharing

Skip to first unread message

Ben Morris

Oct 5, 2016, 12:20:36 AM10/5/16
to Haxe
Hi everyone,

Posted this idea in the Flixel slack group but wanted to open up to a wider audience.

There are many standard formats used in game development - tmx, ogmo, pex to name a few. Many Haxe game engines end up duplicating work to support each of these formats. While the integration of the format (such as rendering a level) will be engine-specific, the parsing logic is the same, and sometimes the formats can evolve quickly making it difficult to keep up with the changes. I think the community could benefit from a shared "HaxeGameLibs" Github organization which hosted engine-agnostic libraries for parsing these formats, which we could pool our efforts to keep up to date.

Some candidates:

- tmx and ogmo map parsing
- pex particle parsing
- spine and spriter animations
- bitmap fonts
- controller type -> button mappings

I'm sure there are many more.

I'd love to hear what people from the various OpenFL projects, NME, Snow, Kha, Flambe, and others think.

Daniel Uranga

Oct 5, 2016, 12:36:05 AM10/5/16
to haxe...@googlegroups.com
Some tmx map parsing I did a time ago in case you're interested:
> --
> To post to this group haxe...@googlegroups.com
> http://groups.google.com/group/haxelang?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Haxe" group.
> For more options, visit https://groups.google.com/d/optout.

Daniel Uranga

Oct 5, 2016, 12:37:20 AM10/5/16
to haxe...@googlegroups.com
Also Gaf animation ( http://gafmedia.com/ ) format support:

Alexander Kuzmenko

Oct 5, 2016, 2:33:39 AM10/5/16
to Haxe
I believe the most complete tmx implementation atm is this: https://github.com/Yanrishatum/haxe-format-tiled

среда, 5 октября 2016 г., 7:20:36 UTC+3 пользователь Ben Morris написал:

Tarwin Stroh-Spijer

Oct 5, 2016, 4:28:05 AM10/5/16
to haxe...@googlegroups.com

Tarwin Stroh-Spijer

phone: +1 650 842 0920

Developer at Fanplayr Inc. (Palo Alto)
Original at Touch My Pixel (touchmypixel.com)


Ben Morris

Oct 5, 2016, 10:51:36 AM10/5/16
to Haxe, tar...@touchmypixel.com
All of these libraries do exist already. The point of this post was more to see whether there was agreement on shared ownership of these libraries, keeping them engine-agnostic, and collecting them in a common location.

Jérémy Faivre

Oct 7, 2016, 7:22:29 AM10/7/16
to Haxe, tar...@touchmypixel.com
I quite like the idea of having a shared organization to host these various github repositories together and make it easier to have multiple collaborators work on them.

That said, a "common location" doesn't have to be a shared github org. It could simply be a curated list of these libs, available somewhere, a web page.

Both options could be helpful. Then comes the question of who and how this list is curated/managed.


Oct 10, 2016, 1:46:57 AM10/10/16
to Haxe
Framework developers are a strange bunch.  Things outside the ecosystem are generally ignored, and there is a big "not written here" mentality.
So firstly, I would suggest targeting your ideas at the end developer (user of the framework) rather than the maintainers of the projects.
And I think these developers are fairly rational and will look for an existing library before anything else.  So the "build it and then they will come" is a pretty sound idea.
If you are looking to organize an agnostic HaxeGameLibs site/repo/group, I think you will get out of it what you are prepared to put into it.
A site with good examples and tests would be a great resource for all haxe developers.

One problem I see with parsers is keeping them platform agnostic as well as efficient.  The haxe.format code is certainly platform agnostic, but the typedef/enum structure is generally not that efficient on cpp, and imposes a certain style.
And, say, for a tiled map - do you encode the tileId + rotations/flips into a single "Int" using bit flags, or do you use a class?  Maybe a good library would have both options. 
Sometimes, it is tempting to blend the implementation with data - for example Svg on a flash-based target using the flash enums for line-caps and blend-modes makes some sense, but no sense in the general case.  Some kind of conditional typedef might be a solution here.
Adding a specific renderer(backend) to generic parser also makes the libraries more valuable, although I'm not sure you want to go there.  For example, "new spine.nme.Renderer(data)" would be very nice.  And perhaps this is just "new spine.Renderer" because "nme" is defined at compile time (and therefore the flash enums are selected too).

I guess this does not help you much.  So let me just wish you luck.

Nicolas Cannasse

Oct 11, 2016, 3:52:20 PM10/11/16
to haxe...@googlegroups.com
Le 05/10/2016 à 06:20, Ben Morris a écrit :
> Hi everyone,
> Posted this idea in the Flixel slack group but wanted to open up to a
> wider audience.

That's the idea of the "format" library which gives independant modules
for reading/writing various file formats. I'm getting regular
contributions for adding new ones, which I'm usually accepting.




Oct 11, 2016, 9:22:31 PM10/11/16
to Haxe
I like this idea! I think this could also be a chance to show the general gamedev community (not just the haxe family) some love by having a single codebase for logic that can work in any of haxes target, not just haxe projects

Ben Morris

Oct 13, 2016, 3:02:55 AM10/13/16
to Haxe
Thanks Nicolas, I hadn't considered format but it seems like a great idea, particularly for simple data types. Some of these could be quite large and complex (Spine being the main example I can think of) so not sure how everyone would feel adding something that size to format.

Ludovic Bas

Oct 18, 2016, 6:48:50 AM10/18/16
to Haxe
Hello Ben,

For Spriter, I'm trying to have as much libraries as I can (Openfl, flixel, Luxe, etc.) inside my project but it is not an easy task since I don't really know how to optimize performance on each of these libraries. So most of renderer libraries are for Openfl (there are different method of rendering and I let the user choose it depending on his target). I'll be glad to get some feedbacks to improve the way renderer libraries are handled in SpriterHaxeEngine and how I can contribute to your project.




Oct 20, 2016, 7:07:03 AM10/20/16
to haxe...@googlegroups.com
Hi all

There is also my library for spriter : https://github.com/wighawag/spriter
It is logic only and thus renderer agnostic. It should run on all target since it use plain Haxe (tested only js and cpp)  
It has been optimised to produce 0 allocation upon updating (tested on cpp target)

I think it is a good idea to completely separate what is framework agnostic to what isn't (the same way the format library operate). This way we can reuse the same code across framework.

There is a renderer for kha : https://github.com/wighawag/spriterkha
and it should not be hard to add more renderer.

Reply all
Reply to author
0 new messages