Why snowkit

Now I want to briefly explain why and how the snowkit team and the corresponding libraries appeared.
If you have not read the announcement of snowkit - I would advise you to read it first ( translation ).

Ambitious designs

Yes, this is the real reason for creating snowkit and libraries. I believe that Haxe has great potential, which is already manifested in a striking increase in popularity, excellent quality, libraries, tools, frameworks, games and community. The Haxe Foundation continues to move in the right direction, makes great efforts to make the compiler and support platforms better and better, is engaged in improving the site and documentation. This is done by wonderful people and you can join them and help.

snowkit is a continuation of work in this direction and, I hope, will become an example of high-quality, community-supported infrastructure for Haxe, which we and new members of the community will use in the future. Creating a snowkit I want to show Haxe in all its glory.
')

Short story

On the way to the luxe

I always used my own engines and tools to create my own games and participate in game dejmas. In 2009/2010 I created an engine that, in my opinion, could already be shown and shared with other users. I started working on the documentation and preparation of its first release. The home page of this engine looked something like this:


Creating this engine, I wanted to create games quickly and efficiently and wanted them to run without additional efforts on all the platforms I needed. I wrote the engine in C ++ and after about a year of use I integrated the V8 into it (javascript engine) and transferred all game classes to javascript. All this helped me to achieve almost all the goals. There were problems with porting V8 to iOS and in the end I replaced it with SpiderMonkey.

Hax / nme

I used my engine to create many games, but I was not completely satisfied with it in order to present it to the general public. This continued until, in 2011, I came across Haxe and NME.
Haxe (as a language and toolkit) gave me the “write once - publish everywhere” approach I've been looking for. NME gave me a simple API, very similar to the Flash API, which allowed me to experiment and try what I wanted. I was inspired by the simplicity of the assembly system and the ability to work very quickly.

Meet the lime

But after several weeks of use, I wanted to return to my own API (I hate the flash API, I'm sorry) and I wanted to port my old games, but unfortunately, a big difference in the API did not allow this. I found out that you can separate the NME API and access the native code and continue to use the tools and supported platforms. Thanks to the tremendous effort on the part of Joshua, this eventually became possible in OpenFL.

I set to work with redoubled forces in order to make the tools more flexible and independent, which would allow me to reincarnate my engine. Despite the presence of crutches and props, after a few weeks I managed to make a version that would be suitable for use.

And luxe

All the time, my ultimate goal was to create a reliable, portable, easy-to-use engine for my games and for people who work just like me. I noticed that using Haxe and OpenFL allows you to get closer to your goal by 90%. But besides, I noticed that I spent a lot of time on developing the infrastructure of Haxe, OpenFL and its support for native platforms.

From about May 2013 to March 2014, I was satisfied with where and how it all moves. My changes were made to the repository, and in the meantime I gathered a community of programmers around me. Then I began to think about offering them a stable and reliable tool and that I want to control the decisions that are made regarding the tool used.

Then it snowed

It was originally called lumen . I had the idea to completely separate the support of native and web platforms from the toolkit that I used. It took me a weekend to do this, and I was surprised at how clean and compact the solution was. The work done did not go unnoticed, and we tried to use the resulting solution wherever possible.

snow acquired the form and was originally based on aether (OpenFL build system). But over time, it became clear that the XML format is too bulky for its needs and, moreover, aether has a rather long build time. I started working on a new, flexible project description format and as a result, as well as with snow, I decided to try to create an assembly system from scratch.

Workflow

After a long use of NME, then lime, and then aether, I decided to completely stop using them. And I must say that I am completely satisfied with the result. My comrades and I began to test the tools I received and soon it became clear to us that the resulting trinity can be used to the fullest.

So - luxe

Since luxe has acquired its current form, there is a lot more that can be shown - tools, editors, modules and libraries. And my comrades, who used snowkit, insisted on putting him on trial for a wide society. I enthusiastically look at what the future has prepared for Haxe, luxe, snow, flow and the rest of the snowkit family.

I look with interest at what Haxe is now and where he will lead us. And I am going to apply my strength so that he moves in the right direction.