Long term support?

[orther]

I really enjoyed your Pixi.js tutorials and like the idea of using Hexi for my new web based interactive animation project. My only concern is that you may not have intentions to develop this for an extended amount of time. Do you have an idea how long you intended to support and work on this library?

Thanks for all your awesome writing and coding!

[kittykatattack]

Hi Orther! This is a version 0.001 experimental library. I cannot in any way recommend it for production, nor offer any guarantees of support! :) But, if it breaks, I'll fix it, and if I notice something that obviously needs to be improved, I'll improve it. At the moment, Hexi is 100% bug free as far as it's been tested - which is quite extensively, but not exhaustively.

Should you use it for your commercial production project? No! You should use Elm, which is the only web technology I could ever recommend for production work of any kind (apps, website, games):

http://elm-lang.org https://youtu.be/XJ9ckqCMiKk https://youtu.be/FV0DXNB94NE

It's what I use in my day job making educational computer games for children at TV Ontario, and I would use nothing else. Really, invest some time into learning it - it will change your life. All the time you spend learning Elm will be paid back by Elm itself in the countless hours it will save you in testing and debugging your code.

But what about Hexi?

I'm looking for volunteers who can help! If anyone out there is reading this who appreciates the ideals of this project (dead-simple API, flat architecture, and first-class performance) - please let us know. Foremostly, I am looking for ideas about how to re-architect the source code (meaning simplifying and removing code - not adding 3rd-party junk) so that it's easy for others to contribute to.

What about features? I'm being extremely conservative about adding features simply to avoid feature-creep - a plague which ruins all software projects. I would actually rather remove features from Hexi instead of add them. Rather than shovelling on more and more features, Hexi should be a limited set of very flexible, low-level tools that users can use to build more complex components themselves - like Lego (or Flash, in the good old Macromedia days). My goal is that Hexi should have a simple, stable, unchanging API so it's a rock-solid foundation for myself and others to build on.

Hexi is really just a thin, opinionated API layer on top of Pixi - there's really isn't much original code there at all! :) It's just a little under 1000 lines of glue code that bridges Hexi's higher level API with Pixi's API, fixes some of Pixi's quirks, and loads in some helpful modules. It just makes the most common tasks in Pixi really, really easy, especially for the needs of game developers. And, I built some extra (optional!) external libraries to help me with things like simple collisions, tweening and interactivity - but those can easily be swapped out for more full featured (or less featured!) libraries.

I built this library entirely for myself for because I had no long-term faith in the developers and maintainers of the other game engines out there. Phaser has a staff of 1, but all the other libraries, including Pixi, are pretty much hobby projects run by volunteers. And, I was not willing to commit to using a proprietary commercial engine because these have a long history of being plagued with bloated code and quickly abandoned when the business fails or changes. Phaser and Pixi at least have enough critical mass - they've shown some staying power, and my conservative recommendation to most people has always been to use one of those libraries (I even wrote the book - the only book - about Pixi: http://www.apress.com/9781484210956).

But! I personally feel that both Phaser and Pixi have a lot of problems with their user-facing APIs and I have never been willing to write code that forces me to write in that style. Also, I've been burned in the past by investing a lot of time into technologies (Director and Flash) only to have the technology die overnight, leaving me as an expert in a totally useless skill-set.

So, this time around, I decided to build my own set of tools. How hard could it be to build a game engine, really? I had never done it before, but decided to find out! I started with Ga, which was designed for the JS13k game competition as in experiment to find out what the least amount of code was needed to write a full-featured game engine.

https://github.com/kittykatattack/ga

I was surprised by the result! A full-featured 2D game engine, only a few thousand lines long, that does most of what Phaser and Pixi (and Hexi!) does and compresses down to 6.5k? Could it really be that easy? I guess so! (Yes, Ga is still in development - it's my baby! - and I have continuing long term plans for it. It's even purer and simpler than Hexi.)

But, Ga just uses a canvas-based renderer, and I also wanted the option of WebGL for all the fancy filter effects and the option to write my own custom shaders. (For the record, I no longer believe that WebGL support is important except in niche cases - current HTML/CSS renderers, especially using VirtualDom are just performant for most use cases and definitely more flexible.) However, doing low-level WebGL coding is an absolute nightmare and no fun at all. Far better to use a mature, WebGL renderer - hence, Pixi. So I created Hexi, which implements an identical API to Ga, but just uses the API as a simple wrapper around Pixi. That means Hexi is just Pixi under the hood so you can access the full-featured PIXI global object at any time do to any kind of low-level WebGL coding that you want to. ("Hex" + Pi "xi" = "Hexi". The word "Hex" means "witch" - in this case the evil witch that has captured the poor little pixie and is using her to help concoct her devious spells!) And, you can swap out Hexi's built-in version of Pixi with any other Pixi version (or your own custom Pixi build) if you want to. That makes it much more flexible than Ga, and why it's a much better tool for doing production level work. It's also much more flexible than Phaser, which does not give you low-level, full-featured rendering control.

I love Hexi, and it's the only HTML5 game engine I use. But, I love it because I built of from scratch - I know how it works inside-out, and it's freed me from being dependent on anyone else's code or coding style. And so, for that same reason, I would recommend to anyone out there reading this: just try building your own game engine! Don't use Hexi, and don't use Ga - make your own, it's not that hard! (And, do it in Elm!) Then you'll never be dependent on any fly-by-night game engine again. And instead of investing hundreds of hours into learning, using (and debugging) someone else's technology, you'll have invested it into your own skills and eduction - and those you'll have forever.

k.k

[orther]

Thank you for taking the time to craft this thoughtful thorough response! It gives me a more perspective and will definitely help me make a decision.

Thank you!

[gamecubate]

I wish github had a larger star one could star "superstar" projects like yours... Great tutorial, impressive set of features, and an invitation to not use it for production and instead, write one's own (engine). That last part BTW being the most open-minded attitude about one's work that I have witnessed in a long time. Kudos.

That said, I use Clojurescript for my work (at a Montreal newspaper) interactive projects and have also considered Elm for my own. In the end, I gave up on both for game-building -- didn't try for very long, though -- as I find the functional approach rather counter-intuitive when it comes to dealing with and managing stateful (can be messy, I know) objects and their world. Animated sprites come to mind as a first challenge in need of a proof of concept. I couldn't hack it cleanly and gave up there and then.

So will learn your engine and see if it can become (as ImpactJS has in the past) my go-to engine for quick game prototyping and more.

Thanks again.

EDIT: Went through the Elm tutorial and see things have improved a lot since my last visit of a year ago. One can always hope...

[kittykatattack]

Thanks your reply, @gamecubate ! I work at TVO (in Toronto) and use Elm for pretty well all my turn-based interactive games and applications these days. The compiler and debugger are absolutely spectacular, and I can't live without them anymore. But I use Hexi/Pixi for all my real-time video games just because Elm doesn't have the library support for making video games quickly or easily, and wiring it to WebGL is still a tedious low-level effort which is no fun to do.

My long term plan is to write those missing libraries and to port Hexi's API over to Elm - but that's still a long, long while away. (Hexi is really just a high-level API - not a technology - so it could (easily?) be ported to anything.) And I love Hexi - it's so quick, easy and fun to make games with it, and it's "pretty much" 😉 bug free, that I expect I'll be using it for a long, long time to come.

[gamecubate]

Agree with you on all counts. I've been playing (again) with Elm these past few days and awesome though it may be, absence of (non-deprecated) HTML5 canvas support hurts.

One problem I have right now with Hexi however is the apparent change to the API insofar as arrow key listening support (as documented in the tutorial) is concerned (e.g., g.leftArrow, g.rightArrow, etc.). Will scout code to see what happened to it.

[gamecubate]

Okay got it. Should do:

g.leftArrow = g.keyboard(37);
g.rightArrow = g.keyboard(39);
g.leftArrow.press = () => {
  player.vx = -5;
  player.vy = 0;
};
// etc.

[kittykatattack]

Thanks for your patience!

[gamecubate]

No prob. Suggestion: Update tutorial to account for removal of g.arrowControl property. Probably #22.