Changelog
• Updated on Nape 2.0.8
• Updated on DragonBones 2.1.1
• Mouse/Touch are disable on objects to save performances, use touchable new property to be able to interact with touch/mouse on the object.
• Box2D contact provided by handleBeginContact, handleEndContact… uses the worldManifold instead of the local (made collision management easier, like it was with Box2D Alchemy).
• An entity uses a Vector to store components instead of a Dictionary.
• ObjectMakerStarling FromMovieClip’s function allow to use an AssetManager object!

On each object that you want to be able to interact using mouse/touch event, you will have to turn its touch property to true: var box:Crate = new Crate(“box”, {touchable:true})
Explanations.

We hope there wasn’t this 3.1.5 but directly a 3.2 with all the features, but the time is going very fast this last weeks. So we decided to publish this udpate right now. Maybe it is better, people will have time to check the changelog and update their game accordingly.

In brief we have added comments in the SWC, added EazeTween as the default tweening engine, updated on DragonBones V2.0 and added lots of flags (boolean) to improve performances!

Changelog
• SWCs include comments!
• Added EazeTween as the default tweening engine.
• Update on DragonBones V2.0
• No more duplicated code between States class, all use the same basis: MediatorState. Now States class are just wrapper.
• When Starling is set up it picks up fullScreen dimension if it’s running on mobile. The Context3DProfile parameter is also added.
• Added updateCallEnabled property to CitrusObject: This property prevent the update method to be called by the enter frame, it will save performances. Set it to true if you want to execute code in the update method.
• Added updateArtEnabled property to Art object. Set it to false if you want to prevent the art to be updated. Be careful its properties (x, y, …) won’t be able to change!
• Add physics flags to prevent running contact if not necessary (beginContactCallEnabled, endContactCallEnabled, etc.).
• Now physics is added to objects only when they are added to a state class. It’s called addPhysics function.
• ACitrusView.update has the delta time in argument (and so its children).
• Instead of a simple parallax property, now there are two: parallaxX and parallaxY
• SoundManager can handles more than 32 sounds.
• StarlingArt handles Texture view. It creates an Image.
• AnimationSequence can add new animations and remove them.
• Added a FluidBox into complex objects using ThresholdFilter, metaballs effect.
• Removed set velocity on Box2D and Nape dynamic objects since we already use a reference.
• Nape MovingPlatform’s default speed is 30.
• Improved Box2D Hills.
• Fixed a bug on Nape Missile’s angle.
• Prevent to add several time the same object to the state.
• Added a PolarPoint math class.
• Added an Accelerometer Input Controller.
• Added a ScreenTouch Input Controller for Starling.

EazeTween
We didn’t want to reinvent the wheel, so we took a look over the existant tweening engine and grab the best one!
Why using EazeTween instead of the very famous TweenMax? EazeTween has a MIT licence whereas TweenMax hasn’t. TweenMax isn’t free if you’re publishing your game on the App Store and sell it.

Flags?
We have added several flags (boolean) into the engine to prevent lots of unuseful function call: for example a Coin object doesn’t need its update function to be called. On mobile it will save lots of performances! No worries, all the examples have been updated with the last engine code!

Alef
It was about time to prove that the Citrus Engine could also be used for several type of games, and even apps! Let’s take a look on Alef.

Happy coding!

With this new update, we have included Feathers into all SWCs builds including Starling. Feathers isn’t used by the engine itself (at this time so this addition won’t change final file size if you don’t use it), but it was requested by many guys to make advanced user interface for their game. With this new update, you’ve all the Adobe Gaming SDK in one framework especially designed for building awesome games! Using SWC file, you will compile your game in no time, and also we make sure those libraries are up to date, and compatible between them!

This update involves many improvements concerning camera, State management, Flash Pro as a level editor, UI and physics objects. Also we have started the draft for the V3.2.0 and as usual we will enjoy your feedback!

Changelog:
• Renamed AVirtualButtons and VirtualButtons classes into AVirtualButton and VirtualButton. Yes, they just add one button now. Easier to add many.
• Added Starling’s simple trick to avoid the state changes (alpha 0.999).
• StarlingCitrusEngine and Away3DCitrusEngine accepts State, useful to display quickly a state with graphics from a swf, ect.
• States classes have a new method killAllObjects(…except). The _objects variable has also a getter.
• States classes have a protected variable _ce which refers to the Citrus Engine.
• Nape’s Hero has a static friction removed when the player move, and set when it stops moving (to prevent sliding).
• ObjectMakerStarling has a FromMovieClip function. The second argument is the TextureAtlas. Objects made in Flash Pro can use a texture name for their view.
• Added Panning to SoundManager.
• Added a camera lens parameter to view.camera.setUp function.
• Added zoomFit() to StarlingCamera and SpriteCamera.
• Added a get function command for the console.
• Added a trace to inform if we create a group with a high value.
• view.camera.setUp returns the instance of the ACitrusCamera.
• StarlingArt doesn’t generate mipmaps if view is a Bitmap.
• Added Crate object to Nape.
• Added a UI package for inventory and lifebar.
• Added a Path class which is a set of points (MathVector) that can be used with the MovingPlatform.
• Added Nape version of the Moving Platform managing also a Path if it’s specified.
• Added line equation to MathUtils.
• Added linear interpolation function to MathUtils.
• Added Tools class with a print_r function to display objects and arrays content.
• Improved the Timer’s cannon: it is paused if the CE is not playing.
• Added a Bridge, Rope and Pool objects, into the new objects.complex.box2dstarling package.
• Added a Multiply2 function into Box2DUtils.

UI
UI and HUD are really important in your games. Adding Feathers to the Citrus Engine will help you to make cool menu and interfaces for your game. Also you’ve certainly noticed the new ui package. At this time, there is only a life bar made for Starling and an inventory package managing objects (you defined) state.
In the Citrus Engine, we used to make a compatibility with new features: they were available on the display list and Starling. Since we believe that Starling is the future of Flash gaming, we won’t port all the future features on the display list. Based on the inventory example, we will make the UI using Feathers. This will save us lots of time, but it won’t help to make a port easily of this inventory on the display list. So we prefer to drop the display list compatibility for those kind of features (saving time), and make sure they will be very powerful.

V3.2.0: Physics improvement
As a developer, it’s very important to try different tools. This last month, I played a lot with Unity3D and really enjoyed it! It gives me ton of ideas on level editing and coding.
Do you remember our issue using the Frame Rate Independant Motion? Using the same code logic than Unity, it will help us to make sure that our game is running exactly at the same speed on different devices. Explanations:
In Unity there is an Update function (called on each object) which is like a function called by the enter frame event in Flash. In this function you’re never sure that the call is made exactly at the same time than the previous one. There is also a FixedUpdate function which is performed at the same time than the physics engine doing a step. In the FixedUpdate function, we’re sure the time elapsed between each function is exactly the same.

So what I’m suggesting is to replicate this behavior:
- keep our update function with the time delta as a parameter coming from the CitrusEngine class using an enter frame and the Date.time, and create a protected variable in APhysicsObject to register the timedelta (so it can be used in FixedUpdate).
- then create a fixedUpdate function in APhysicsObject which will be called each time the physics engine make a step. The step of the engine comes from a Timer which have exactly the same delay than the physics engine step.
This way we keep our view syncronized with the FP/AIR, and are sure the physics engine is performing at the same speed on each devices.
The downside are we will have to rewrite some physics objects code, and there can’t be a backward compatibility. What do you think?

Happy coding!

We’re happy to provide you a new build one day before the Gobal Game Jam!

We’d time to improve the new camera system which is now very flexbile and have more cool features. Thanks you all for your feedback!

Some users ask us to create a wiki to get start more quickly with the engine. We’ll took advantage of this opportunity to create also a part explaining how the Citrus Engine works internally. For example what happen when you add an object to the state, how StarlingView and StarlingArt works ect. The wiki is already available there. Yup we stick with the Starling (excellent) community. Again feel free to tell us what you want to see there, if you have some better ideas for the structure ect. This wiki is made for you!

Changelog:
• new Camera system ready! you don’t call anymore view.setupCamera function, now it is view.camera.setUp
• input uses its own update loop using Event.FRAME_CONSTRUCTED.
• fixed tiled map parser’s problem where the layer index might be wrong.
• fixed a bug in Keyboard’s input where some actions weren’t performed.
• fixed Starling VirtualButtons and VirtualJoystick ‘s destroy method.
• fixed a problem with parallax when zooming.
• fixed a bug where Nape Missile’s angle wasn’t in radian.
• Nape’s Hero no longer has a static friction.
• fixed Nape’s Hero was able if the collisionAngle was really close to 0.
• moved SpriteDebugArt and StarlingSpriteDebugArt into their respective package.
• SpriteArt/StarlingArt/Away3DArt content property becomes private with a getter. It should only be set internally.

Camera demo
We’ve made a new demo using this new camera stuff! Demo. Mouse wheel to zoom, x to rotate the view and r to randomize cloud positions. Source code.

Have a fun game jam!

2013 is already there, and we’re pretty sure this will be a good year for the Citrus Engine!

The Global Game Jam is in one week, and we’re happy to share that Aymeric and Gsynuh will meet for the first time and make a game (with some other great guys!) using our beloved game engine. Before the game jam, it’s important for us to let you know on what we’re working and what we will be improved during the next week. As usual, we always love your feedback!

This update provides performances improvement using physics engine and a good scalability with some cool new features : CitrusGroup and outsourced camera stuff.

Changelog:
• improved physics performance removing the update call to the debug view if it isn’t visible.
• outsourced camera stuff into a ACitrusCamera class and one camera by view : BlittingCamera, SpriteCamera, StarlingCamera and Away3DCamera2D.
• renamed CitrusView into ACitrusView class.
• addSound method has now two arguments : the id (String) and the sound (*, String or Class).
• added CitrusGroup class to group different kind of objects.
• added createAABB method in MathUtils package.
• added CollisionGetObjectByType into Box2DUtils and NapeUtils.
• added getObjectsByName method.
• added a fla with Citrus objects components to create quickly objects using Flash Pro as a level editor.
• you can change physics step thanks to their public var.
• updated on Starling 1.3.
• fixed a bug where the group property wasn’t updated using Away3DView, SpriteView and StarlingView.
• fixed on StarlingArt, the object’s view changed but animation doesn’t update on the new view.

For more details on CitrusGroup, please follow this discussion and feel free to say what you need!
Concerning camera, take a look on the work in progress of StarlingCamera, most of its content will be moved to other camera too. It gives great options for developers : zooming and rotation. Combine this with your favorite tween engine and you will have easily an awesome scripted camera!

Happy coding!

We would like to thank you for the very nice feedbacks on the previous build, it seems that you loved the Braid demo!

It’s already time to provide a new build with some fixes and improvements. We have unify the way that Away3D is added, now it uses a template like Starling with a cool setUpAway3D function which also allows Stage3D Interoperation. It means that you can easily create your Citrus Engine game with Away3D and use Starling for a 2D interface, in-game menu, ect.

Changelog:
• created starling and away3d package in citrus.core for StarlingCitrusEngine, StarlingState, Away3DCitrusEngine and Away3DState classes.
• removed stage argument in setUpStarling function, override the handleAddedToStage method to call setUpStarling function instead.
• added Nape parser for polygon/polyline.
• AVirtualJoystick : action value scaling.
• TimeShifter now listens to and routes input to his defaultChannel which remains channel 16 when instanciated.
• fixed a bug where Starling couldn’t dispose.
• fixed a bug on TimeShifter using params.
• fixed camera offset for BlittingView.

Thanks to this update it is really easy to use Away3D with Starling, it requires only few lines of code. Check the code example!
Also thanks to the new Away3DCitrusEngine we have improved how we set up Away3D. Previously, it was created inside the Away3DView class which means that Away3D was created and removed each time a new state was set up. Now it’s more logical and performance friendly.

Happy coding!

Two weeks without Citrus Engine updates? What happened? No worries, we have worked hard to make this new update available adding tons of improvements, update and new features! A quick cool one : thanks to AIR3.6 and the LevelManager update you’re now able to load SWF levels made with Flash Pro on iOS!

In this update we have made one breaking change : no more “com” and “engine” package, just “citrus” now. This one has been made to remove problems with code hinting in some IDE : you had to resize the code hinting window to actually see if you were in a box2d package, or a nape package, etc. We apologize for compatibility issues with games made with the previous version (it takes some time to rename package in level editors…), that’s why we started to save old SWC releases on the GitHub.

We’re pleased to announce a new input system available! Thanks to this one you can easily change your key configuration, handle VirtualJoystick and VirtualButton for quickly making awesome mobile games. We’ve added a channel system which means that henceforth the Citrus Engine is multiplayer friendly! Also with this new input system comes a TimeShifter for time manipulation, like in Braid game. Yup, we’ve made a Braid demo with the engine (3 Mo to load, shift key for time management), also available on Android devices through an apk (working fine on Nexus 7). That’s one of the features of the TimeShifter, it allows to replay input actions too.

And finally, we’ve updated on Nape 2 (and Starling RC 1.3 without compatibility issue). We’ve worked hard on the Nape platformer pre-built objects, now you have the same feeling with box2d ones concerning : world/space gravity, NapePhysicsObject, Enemy & Hero behaviors. So everything is ready to start this new Ludum Dare!

Changelog:
• Renamed package “com” and “citrusengine” into “citrus”.
• The LevelManager can load levels made with Flash Pro on iOS using a LoaderContext.
• The setUpStarling function may take the flash stage as an argument (useful if not the root class).
• AnimationSequence’s dictionary is now accessible thanks to a getter.
• Changed _input to protected to allow custom Input.
• Added the new input package supporting keyboard, joystick, button, channel, key action…
• Added a TimeShifter à la Braid! Allow also to replay an action.
• Upgraded on Nape 2.0.
• Nape’s gravity is equal to Box2D’s gravity.
• Nape’s object physics behavior are closed to Box2d one (friction, speed, hero & enemy interaction…)
• refreshPoolObjectArt handles the startIndex.
• Now we can easily read the velocity of a body thanks to a getter.
• Thanks to ObjectMaker we can define vertices using Tiled Map Editor software.
• Update on Starling RC 1.3 + added its new AssetManager class.
• StarlingArt is now able to dispose automatically basic DisplayObject.
• Starling’s AnimationSequence has a clone method.
• Starling’s AnimationSequence dispatch onAnimationComplete Signal.

The Input Package

Prior to this update , the Input class was cleverly handling the keyboard with justPressed and isDown giving the basic but very useful methods to define what to do in your update loops as a response to input

Since this new input package is an important step for input handling and it introduces a new way of handling it, It requires some explanation on its origins so you can fully grasp why it was made and what you can use it for.

Introduction :
The basic idea that made this new system came to life is : identifying the player’s intentions and not the key he is pressing. The best way to do that is to have the actual “intention” be easily identifiable – as a string, and that’s how this system works. Intentions are actions like “jump” or “duck” or “fly”, and it makes coding your game objects so much easier…

This means a lot for CE users : you no longer have to remember key codes or import flash.ui.Keyboard to have them of course, you can change the key configuration of your game in real time (a feature a lot of desktop gamers desperately want to have sometimes) and by extrapolating the idea further : it gives room for a wide variety of controllers ( gamepads , socket) … The Hero class would no longer need to know from which controller the “call” came from. Unifying any possible input styles is the best thing a game engine could need.

Inside the system :
Now I hope I got you a bit excited about this new feature. This was inspired by the MIDI system : note on , note off, and continuous controller signals (but with a twist). We also thought of an on-screen joystick and buttons for games targeting tablets which was an idea that totally fit in the new input system and even got us to go further and made it what it is now.

How to use it :
We left backwards compatible versions of isDown and justPressed in the Input so the basic games should still run without having to change much code, however If you are using special controls and custom objects requiring other keycodes than the simple arrows and spacebar configuration then you should migrate to the new system or your game will be “broken”. And here’s how to migrate/use the system :

inside your “hero”, you can now use

if(_ce.input.justDid("fly", inputChannel))
{
    //insert "start flying" code here
}

if(_ce.input.isDoing("fly", inputChannel))
{
   //if you are using a controller such as a joystick and want to give more control to your player, you can use the new getActionValue method
   var flying_intensity:Number = _ce.input.getActionValue("fly", inputChannel);
   //and apply it.
   _body.velocity.y = - flying_intensity * 150; //this is just an example application, it might not be as accurate as you'd want it to.

   //insert other "flying" code here
}

inputChannel should be a class property defining the channel the game object will listen to.
Now in your state get the default keyboard from CE’s input instance, and add new actions to your keyboard :

//your hero can listen to channel 1 this way.
hero.inputChannel = 1;

var keyboard:Keyboard = CitrusEngine.getInstance().input.keyboard as Keyboard;
//and here we can add the "fly" action to the keyboard, that will only be sent to channel 1.
keyboard.addKeyAction("fly", Keyboard.F,1);

Now the F key will tell Input that the player wants to fly, and your hero will respond to that.
The keyboard sends values of 1 when an action is on, so getActionValue is not interesting in this case, but if you are going to use the VirtualJoystick it will be.

//create a virtual joystick input controller :
var vj:VirtualJoystick = new VirtualJoystick("joy",{radius:120,defaultChannel:1});

//add the "fly" action to the Y axis of the joystick, when joystick is between -1 and 0
vj.addAxisAction("Y","fly",-1,0);

Now you can fly with the F key, or with the virtual joystick, with the added bonus that VirtualJoystick will control the velocity more precisely.

In this example we have decided to use channel number 1 but it is completely optional, if you do not want to set channels up, everything will go through channel 0.

A purposeful system :

Basically, it is a messaging system but focused on input, as using this for any other type of internal messaging is not recommended (you better use the Signal package). As long as you have access to the CitrusEngine Input instance, whether it be from your game menu or game objects, you can know what the user wants to do.

If it’s a “virtual controller” it’d be the same. It is conceivable to have a “socket” input controller (which you can create by extending the InputController class) from which data from an external server would be parsed and send actions to the input system, so you could control your game through IP very easily if you are into highly experimental stuff such as performance art that need to communicate with electronics (yes because CE can be used for anything !) .
A virtual controller can also be an AI – so your main hero or enemies can be controller by an AI without having to hardcode it inside the class, but simply switching it’s inputChannel.
This of course can have unwanted effects since the physics engine is unpredictable but you can still experiment with this possibility.

Other features :

you can route all input actions to a single channel if you need to : for example if you bring up a pause menu – so all the keyboard (or any other controller) actions get routed to the channel you want for your menu’s UI and in the background, the player’s character will no longer react to input.
This came along with the development of TimeShifter, so we are waiting for your feedback on this feature, or any other features you’d want to be added or modified.

the following will route all input action to channel 5 when a menu comes up for example:

_ce.input.startRouting(5);

when you are done of course, just call

_ce.input.stopRouting();

TimeShifter

TimeShifter is an experimental class that saves the property changes on each frame, which means you can replay actions (kill-cams?) or rewind time, as long as you have registered the properties you want to be saved. It also takes snapshots of actions in the input system so they can get replayed. Replaying actions only is however not the best way to replay a section of gameplay since physics engines are non-deterministic and your player might fall on a platform in one replay and fall off of it on the next replay even though the snapshots are exactly the same.
When constructing a TimeShifter instance, you need to define the maximum size of the buffer (in seconds) since it consumes memory to save “states” of properties and the buffer length shouldn’t be infinite (or it would be similar to a highly ‘dangerous’ memory leak).
As of now, this buffer length you define will be the amount of time that will be replayed or rewounded. For our Braid demo, we keep 20 seconds of buffer, but for a simple “kill-cam” replay style, you’d just need 5 seconds or less.

Here’s how to start a delayed replay :

// we want a maximum buffer size of 5 seconds.
var timeshifter:TimeShifter = new TimeShifter(5);
//and we want to replay the action 0.2 seconds after a coin has been hit
coin.onEndContact.add( function(e:InteractionCallback):void { timeshifter.startReplay(0.2); });

As of now, TimeShifter listens to channel 16 for the “timeshift” action.
It is good to consider a certain channel to be an “internal” channel for such purposes – we arbitrarily chose 16.

TimeShifter only records what you ask it to. So let’s just take a look at how we set up the recording for a hero’s position and animations

timeshifter.addBufferSet(
{ object:hero,
continuous:["x", "y"],
discrete:["dead","inverted", "collideable", "animation", "animationFrame"] } );

the idea here is to give it continuous values (positions for example that will be interpolated linearly when the speed of playback is lower than 1)
and discrete values such as booleans or strings to record.
so what will be recorded here are publicly accessible (and not read-only) properties :
-continuous:
object.x
object.y
-discrete booleans:
object.dead
object.inverted
object.collideable
-discrete strings:
object.animation
-discrete int:
object.animationFrame (which is a number, but cannot be interpolated as AnimationSequences would not know what frame 1.2345 is.
Check out the Braid demo’s source code to learn more about how you can use this system.

Multiplayer friendly
Thanks to this new input system, we are able to make a multiplayer game using the Citrus Engine. First of all, I would like to highlight that making a multiplayer game based on physics engine is something complicated. Here are two links with very good references : Glenn Fiedler’s blog (also very useful for FRIM) and a Valve article.
A quick and dirty demo made with Union Platform and their free services for quick testing (expect lags so some collisions may not happen!). Source code commented there. Obviously this demo needs lots of work to be fully functional like object’s movement interpolation when a new state snapshot is received, occupants management, ect… But it shows that the Citrus Engine thanks to this new input system is now multiplayer friendly!

We hope that you will love this update. Happy coding!

At the same time we have created a new ObjectMaker class exclusively for Starling, to improve performances. Therefore we have updated the parser for the Tiled Map Editor software.

This update has been pushed quickly so every guys going to the Adobe Game Jam in Chicago can test this new features. Also we’re very pleased to announce that Nick, a CE’s contributor, will be present at this game jam!

Changelog:
• DragonBones support for StarlingArt class.
• Moved ObjectMaker2D & 3D classes and tmx package into a new objectmakers package.
• Create a new ObjectMakerStarling class with a parser for Tiled Map Editor’s files optimized for Starling.

DragonBones
Our beloved Patch character meets the Dragon, quick demo.
How can we add a DragonBones object as a view of a CitrusObject? Simply like any other object :

_armature = _factory.buildArmature("Dragon");
var dragon:Hero = new Hero("dragon", {x:150, width:60, height:135, view:_armature});
add(dragon);

You can find all the demo code on the GitHub for examples. Be careful, we’ve modified “stand” Dragon’s animation name into “idle” so it respects Citrus Engine’s Hero animation name.

ObjectMakerStarling
We’ve created a new ObjectMaker class exclusively for Starling, to provide optimized graphics. ObjectMaker2D stays compatible with Starling but you should use ObjectMakerStarling class if it provides method for the Level Editor you use. At the moment, there is a parser for Tiled Map Editor which use TextureAtlas and Quad Batch instead of Bitmap. Check its code example here.
Here we’ve created a TextureAtlas (Genetica-tiles-atlas, you may need to check the Extrude option using TexturePacker) with all the tiles. In the editor, we import the Genetica-tiles png and for each tile we give it the name corresponding to its texture atlas name. That does the trick!
Open the map-atlas.tmx and check how we named a tile. We can automate the process easily writing a simple script and copy/paste the result.
A video tutorial is in the pipeline.

That’s it for today. Have a nice meetup with Nick at Chicago!

We are happy to offer a new build one week after the previous one. The release rhythm is sustained to provide quickly new features and inform on the direction of the engine. We always detail the changelog as much as possible so you can upgrade without pain.

The showcase page has been updated with two new games : Stack of Defence which is a nice mix of tower defence and physics game and Les aventures d’Aïcha a platformer game using Starling where you control several characters having different skills!
Joseph Labrecque, a well known person in the Flash community, has made a game using the Citrus Engine during the Charity Game Jam which was last week-end. He shares his experience with source code!

This time we didn’t need to make bug fixes (good news concerning the stability of the engine!), we have added some cool improvements (PoolObject managed by the State, ATF, Tiled Map Editor ObjectMaker improved) and announcing the future V3.1.0 which will be multiplayer friendly! Also there is a support page now and we invite you to give it a look.

This is the changelog :
• optimized MathVector class.
• a PoolObject can be rendered through the State/StarlingState classes.
• the LevelManager class can load tmx file.
• ATF file format are supported by the StarlingTileSystem class.
• tiled map objectmaker uses dynamic tileset name.
• ObjectMaker FromTiledMap support now multipe tileSets.
• added a RevolvingPlatform in box2d platformer’s package.
• the Starling’s AnimationSequence class has a new parameter : the smoothing. Default is bilinear.

The Ant tasks has been updated to generate the 11 swcs in just one click.

Future input system
We’ve starting to work on a new input system. Firstly, it’ll help to be able to change quickly input keyboard keys. At the moment they are hard coding. We’ll add a Joystick support for playing on mobile and a Button class. The input will be injected, therefore we won’t make anymore conditions on input key but on Actions. It doesn’t matter if it comes from Keyboard, Joystick, … or from a server! At the same time it’ll use a channel system so it will help to have several players on the same game locally, or in a real multi-player mode! And finally we’ll also have a cool replay system, to be able to replay our previous actions. Sound awesome? Stay tuned!

Donation and support for companies
We’ve opened a support section. Companies desiring a strong support may work with a freelancer. You can also make a donation which will be divided fairly between contributors or help to “hire” a specialist to work on an advanced feature requested by the community.
The Citrus Engine is 100% Open-Source, free, and strongly supported. And it will always be!

As always, feedbacks are welcomed! Happy coding!

Theory
We’re creating a game using Starling framework. It means that it runs on Stage3D technology. So the first thing you have to take care of is : don’t mix flash display list elements with Stage3D content, or there will be bad performances. The game HUD must use Starling elements or Feathers.
For the menu, there is an other deal : you may create it inside Flash Pro and use it quickly. If there isn’t any fancy effect, performances will be fine.

StarlingState class extends starling Sprite class, so it means you can easily addChild HUD elements which will be on top of your game. Don’t use StarlingState class as a menu or anything which is not the game.

By default, the game state will be displayed at index 0. It can be easily changed thanks to the _stateDisplayIndex protected property from CitrusEngine class. Don’t forget that the state is added once a new one is created.

Finally, if you use Starling for your menu, be sure that the Context3D has been created before adding any object to Starling. You just need to override the protected _context3DCreated method from StarlingCitrusEngine.

Level Manager
In many games, you can choose a level. Most of the code can be similar between each level : the way they are created, camera target, the logic itself… The Citrus Engine, thanks to the LevelManager class, helps you to create quickly new levels. The LevelManager is based on an abstract class : in this class you will create everything which is common to each level. Keep in mind that everything should be overridable. Then you create one class by level which extends your abstract class and you’ll be able to redefine what you need and add new stuff.
There is a snippet which explains how to set up the LevelManager. It is a bit complex to handle at first since there are many things to set up, but very powerful later. Use it, or create your own.