This post is a short reasoning and history post about creating the snowkit collective and especially, the initial set of libraries.
If you haven't yet, please read the announcement post first.
Aim higher
This is the real reason for the creation of snowkit and it's libraries. I believe Haxe has great potential - and is already astounding growth and amazing output and libraries, tools, frameworks, games and much more from the community. The Haxe Foundation continues to press forward in a positive direction, working hard at making the compiler and targets better and better, and improving the face of the Haxe eco system with renewed web presence and a huge manual, which is a continued work in progress by great people (you should help there if you can).
snowkit is a continuation of this upward trend, hoping to set a precedent for high quality, community powered development to enrich and empower the Haxe eco system for the future, for all of us, and for those that have yet to find Haxe and stumble upon it - we want them to know that Haxe is a beautiful thing.
A short history
on the road to luxe
I have always used my own engine/tech to build my games, do game jams, and create tools for them. In 2009/2010, I had finally made one that felt like other people could use it, so I started documenting it, and preparing it for a first release. The homepage, looked a bit like this :
This older technology I was looking for something, I wanted to write games quickly, efficiently, and once - and have it run on the platforms that I care about. I wrote the initial engine in C++, and after about a year of use, I added full deep integration with the V8 javascript engine, and moved all the game specific classes into the javascript code which gave me exactly that. It was also quite portable, except for the V8 part. V8 also wouldn't run on iOS, so I ended up binding the engine to SpiderMonkey, JSCore as well as V8, for easiest portability.
Haxe/nme
Over time, I used the engine for many games but could never get around to finishing the "user facing" experience I had in mind, until around 2011, when I stumbled on Haxe - and in it, NME.
What Haxe gave me (the programming language/toolkit) was a write once, deploy everywhere approach I was looking for, but the code ended up as native to the target I was deploying too. NME gave me a simple flash like API to experiment with, and I was really happy with the simplicity of the build tools and being able to work quickly.
enter lime
After a few weeks I really wanted to get back to my own API (I hate the flash API, sorry) and I wanted to get porting my existing games, but the nature of the API's I had in front of me weren't fitting. I explored the option of undercutting the NME stack, and going directly to the native code so that I can use the tools + the platforms without the API, and upon the announcement of OpenFL and the great efforts by Joshua, it was finally possible to do that, to some extent.
I pushed hard and constantly to make the tools more agnostic, more flexible, and allow me to build a reincarnation of my engine on top of it. Aside from some hitches here and there, I was still able to make great progress and within a few weeks I had something usable.
and then luxe
My end goal all along was a reliable, portable, simple to use engine for my own games and the people that work like me. I managed to achieve that about 90% of the way in terms of workflow, and flexibility with the tools, and at the same time invested a lot of time into improving the haxe eco system, the OpenFL framework and native backends, and helping out wherever possible while I get up and running.
From May 2013, through to about March 2014 I was pretty happy with the direction things were headed. Around that time some merging had to happen, and I had already cultivated a user base alongside me and I was starting to feel the need to promise them stability and reliability and I needed control over the decisions to do that.
along came snow
Originally called lumen, I explored the idea of a completely divorced native+web backend from the entire toolchain I had been using. This took about a weekend to get rolling and I was really excited about the clean minimal approach I had originally intended it to be. It would also seem that my efforts weren't unnoticed and inspired other frameworks to follow suit, and we shared code where possible.
snow was taking shape, and originally still relying on aether, it started to feel the strain of the chunky xml project files and the build times, I was fighting for agnostic flexibility in the project format and only partially getting results so I decided, much like with snow, that I should explore the possibility of more focused tools as well.
working flow
After a long time using the nme, then lime stack, and using the aether tool stack it had come to the point where I had moved away from the eco system entirely and was really happy with the results. I continued to bring alongside testers and friends and the original audience of lime alongside for testing, and we duked it out and started using the trio in full.
Finally, luxe
As luxe has evolved, a now third generation of my preferred approach to development, there are many tools, editors, features and things I would love to show you, more modules/libraries I would love to write for luxe but as time moves forward I am continually pressed by friends who know about luxe to get it into peoples hands already - so I am looking forward to seeing what the future holds for haxe, luxe, snow and flow and the rest of the snowkit family.
I will continue to press toward positive growth and I am really excited about where Haxe has, and will be taking us.