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!
- 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 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?