Why snowkit

Original author: Sven Bergström
  • Transfer
Now I want to briefly explain why and how the snowkit team and the corresponding libraries appeared.
If you have not read snowkit announcement - I would advise you to read first, it ( translation ).

Ambitious plans

Yes, this is the real reason for creating snowkit and libraries. I believe that Haxe has great potential, which is already evident in the amazing growth in popularity, excellent quality, libraries, tools, frameworks, games and the community. The Haxe Foundation continues to move in the right direction, makes great efforts to make the compiler and platform support better and better, is engaged in improving the site and documentation. Great people are doing this and you can join and help them.

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

Short story

On the way to luxe

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

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

Haxe / nme

I used my engine to create many games, but was not completely satisfied with it in order to submit it to a wider society. 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 that I have been looking for for so long. NME gave me a simple API, very similar to the Flash API, which allowed me to experiment and try what I want. I was inspired by the simplicity of the assembly system and the ability to work very quickly.

Meet lime

But after several weeks of use, I wanted to return to my own API (I hate flash APIs, sorry) and I wanted to port my old games, but unfortunately, the 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 tools and supported platforms. Thanks to the tremendous effort on the part of Joshua, this eventually became possible to do in OpenFL.

I set to work with redoubled forces in order to make the instruments more flexible and independent, which would allow me to take up the reincarnation of 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 in addition, I noticed that I devoted a lot of time to the development of the Haxe infrastructure, 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 accepted into the repository and meanwhile I gathered a community of programmers around me. Then thoughts began to come to me, to offer 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 came up with the idea to completely separate support for native and web platforms from the set of tools that I used. It took me a weekend to do this, and I was surprised 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 took shape and was originally based on aether (OpenFL build system). But over time, it became clear that the XML format is too cumbersome 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, just like with snow, I decided to try to create a build system from scratch.

Work flow

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

So - luxe

Since luxe acquired its current form, there is still a lot to show - tools, editors, modules and libraries. And my comrades who used snowkit insisted on putting it to the court of a wider society. I look excitedly at what the future holds 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’m going to use my strength to move in the right direction.

Also popular now: