Wow long time since the previous update guys, right? Probably too long… Anyway here is a new one with mostly libraries update and small bug fixes. We also changed our way to make the SWCs (ie: removing dependencies for the build process) so it will be easier for us to provide you with the latest engine updates in the future, and you can also use the ant-task to make your own custom build!
I think it’s time to make a statement for the Citrus Engine V3:
– we keep using it monthly so everything is really stable, but no major updates so far. For a long time we haven’t had new projects asking for new features or most of the time they are too specific to include it in the core or to open-source them (but we do share whatever we feel is appropriate and what we legally can!).
– the Citrus Engine popularity comes from its platformer kit. However it has a downside: many people still think that we can only make platformer games with the Citrus Engine, and recent feedback has confirmed that unfortunately. It was just an example on how implementing objects!
– we’re mostly proud of the whole engine architecture, but we’re not keen on the way SpriteArt/StarlingArt classes work. Their extandability is null, without having to actually patch them completely… So its not official so not “supported”.
– There are plenty of things that can be improved, and we know how, its just a bigger endeavor than just a bug fix, on top of that this means structural change that will translate into API change, and we didn’t want to keep you waiting more for that, hence this minor update soon, and a major update later.
This last year we’ve worked on many HTML5 games and are still working on a big Unity game (and of course Air/Flash games). Here is our experience with HTML5 games:
– Pixi.js is definitely the rendering library to use, but it’s not a game engine (comparable to starling in that regard).
– Flambe is really a cool game engine, but it’s non display list approach on graphics make it hard to use with complex UI stuff when you come from a display list workflow background.
– Phaser is the result of a very long hard work and we’re impressed by the amount of work done. But unfortunately, for several reason it didn’t fit our needs and probably won’t until v3.
Since HTML5 is a pretty work so HTML5 games are a trend, we all have job opportunities in HTML5 obviously…. but for this we need a game engine. This is the perfect opportunity to try out a new structure for the Citrus Engine (for a HTML5 target) and transfer back to the Flash version what worked later in terms of structure (probably for a V4) if we’re happy with it!
We won’t start from scratch for the Citrus JS… and at this time I can already tell you that it won’t use JS directly but Haxe! You get it, we will use Pixi.js for the rendering and a bunch of awesome libs for other parts. That’s the spirit of the Citrus Engine: an engine linking awesome libraries and making them work together right out of the box!
We’ve no release date at the moment, since we’re still experimenting different stuff. But we’ll keep you updated on the progress and you’ll be the first to know when we will have something pretty solid 😉
A word from Thomas:
Hi guys. So you’ve heard. Don’t start thinking that Citrus Engine is dead though. It’s not and we actively still push for Air when we have the decision on commercial projects and that project is 2D / ui heavy. We’ve talked about the structural changes we’d like to try for that js version, but for the flash version, at least for a 3.2 version or maybe earlier, there are clear things we CAN do to make the engine better. I put my attention on state transitions recently and that made me work out what we could start with. that involved state management (something I liked about Phaser that we didn’t have) and changes that these things imply will solve the issues many of us have faced when managing a paused game, a pause screen and so on. The solution is already quite stable, it just involved too much of a change for 3.1.11 though.