Towards version 0.0.1

[kittykatattack]

Hi Everyone!

To my surprise, other people besides myself have started to use Hexi! I'm extremely happy about that, but, until now, Hexi has been really nothing more than an elaborate "experiment" that I could not in good faith actually advise anyone to use in production. Yes, people have been using it production - especially me. But Hexi was always just a labour-of-love by one inconsistent maintainer (me!) who likes to take long holidays in remote parts of the world without internet access. 😟 😄 ✨ (As an aside: I can highly recommend doing that!!) And, as much fun as Hexi is to work on (it's my baby!) I pretty much have to turn all my attention to paying gigs when they come up to keep the lights on. And, unfortuanly, I'm drowning in paying work at the moment. 😒 😭 🤑

So, my goal is now to put all my efforts into stabilizing Hexi's source (core.js) and dependent modules so that we all have a solid foundation to build on. The first step is to lock down the current version of Hexi on the master branch at version 0.0.1. And, do the same thing for its dependent modules:

• Bump: A complete suite of 2D collision functions for games.
• Tink: Drag-and-drop, buttons, a universal pointer and other helpful interactivity tools.
• Charm: Easy-to-use tweening animation effects for Pixi sprites.
• Dust: Particle effects for creating things like explosions, fire and magic.
• Sprite Utilities: Easier and more intuitive ways to create and use Pixi sprites, as well adding a state machine and animation player
• Game Utilities: A collection of useful methods for games.
• Tile Utilities: A collection of useful methods for making tile-based game worlds with Tiled Editor. Includes a full suite of isometric map utilities.
• Sound.js: A micro-library for loading, controlling and generating sound and music effects. Everything you need to add sound to games.
• Smoothie: Ultra-smooth sprite animation using true delta-time interpolation. It also lets you specify the fps (frames-per-second) at which your game or application runs, and completely separates your sprite rendering loop from your application logic loop.

Once that's done.... Hexi will have it's first official "release!" We can then delve into squashing the last of its bugs and thinking about it's future. (I've currently suspended work on using Pixi v4.x as the renderer but will resume that work when 0.0.1 is done.)

Also, it's become obvious that Hexi needs more maintainers. Volunteers welcome!!! The only thing I ask is that we agree to agree on following guidelines:

• We're regular users of Hexi and depend on it for the kind of work we're doing (hobby or paying).
• We're wiling to come a consensus regarding user-facing API changes (anything that affects usability, backwards compatibility or risks breaking production code in any way.)
• We resist the temptation to refactor just for sake of refactoring. This is the death-curse of most open source projects - we can do better! There has to be qualatitative benefit to end user: either in reliability or maintainability.
• You're willing accept Hexi's core development values: increasing simplicity, reliability, usability (for the end users of Hexi), and, very importantly removing unnecessary features. It's Hexi's goal to become a Zen Garden for game developers. The simpler, more streamlined, and easier we can make the work of creating games for our users, the better we're succeeding.

If you're good with that, just request to be added as a collaborator in this thread.

Cheers, kk.

[kittykatattack]

Here are the goals for 0.0.1:

• Establish that all Hexi's core.js and supporting libraries have 100% compatibility with Pixi v3.0.11 (the most stable version of Pixi).
• Add MIT licenses to all libraries.
• Grunt/gulp build process established.
• Publish to NPM.

Once we've done we'll tag all the libraries as 0.0.1 and work through squashing the last few remaining bugs.

Please let us know if there's anything more we should add to this list.

[Nicholaiii]

I can help you with the last three goals of 0.0.1; and am able to do so autonomously; but I would like to suggest Webpack over Gulp or Grunt, for simplicity and maintainability. Having worked a lot with both Gulp and Webpack, I think Gulp is more suited for larger multi-part frontend applications, whereas webpack is perfect for libraries. A full config that will cover building Hexi.js is a /mere/ 7 lines of code. (10 with uglifying) The strength of Webpack lies in its integration with the NPM eco system. You can require() everything you need; All dependencies are declared in package.json and installed and bundled upon build.

[Nicholaiii]

Another issue to discuss is package naming - A lot of the packages like dust, smoothie, bump et al are already taken. I think pixi-* is a good approach tho? It seems to be the convention for libraries targeting other libraries pixi-dust pixi-smoothie eg

[Qriva]

Question: Can we expect modules like utils, charm etc in version compatabile with pixi 4.* ? and if yes - then when?

[kittykatattack]

@Qriva That will happen eventually once v4 stabilizes - which could take a while. At the moment v4 is in too much flux with arbitrary API changes and is too buggy to risk in production (at least for me.) And, v4 doesn't offer any significant features or performance improvements over late v3, which is incredibly stable and bug free. I'll see how things play out - there's a distinct possibility that I might skip v4 completely wait till v5. Let's see! 😄

But, if any volunteers would like to work on v4 branches of those utilities, please do!