Finally using SWC for art in the Citrus Engine

Two days ago, I introduced a way to target iOS with the Citrus Engine using the metadata tag Embed. Forget that way, it is really painful.

Instead of using Embed everywhere and probably rewrite method for the CE’s ObjectMaker, we will use a SWC file. Refering to Wikipedia, an Adobe SWC file is a package of precompiled Flash symbols and ActionScript code that allows a Flash or Flex developer to distribute classes and assets, or to avoid recompiling symbols and code that will not change. SWC files can be generated by the Flash authoring tool, and by Flex. They are sometimes referred to as class libraries and cannot be directly executed by the Flash Player.

So in this file, there will be our level with all its graphics, animations, sounds… We will not have anymore external datas. Moreover our level in the flash IDE will not contain only rectangle shape like previously, but our graphics and animations :
Screenshot of the level
It’s more user friendly isn’t it ? My hero is always a rectangle shape because I’ve not the orignal fla right now.

So to do that just import your graphics and animations into your fla’s library. I recommend to create a movie clip named Level and put it on the stage, name it and add a simple trace code into it to inform what is your current level. We will add all our layers and objects in!
Then put the graphics inside your original Background movie clip for example. Next, inside the movie clip’s properties check export for ActionScript3 and set as class Background. Finally add this code into the movie clip :

var className = "com.citrusengine.objects.CitrusSprite";
var params = {
	view: Background
}

Before, we had a background.jpg now we have a class!

For animation it’s the same, but be careful : if you use it in code after it may have a problem of duplicate name, so in my case with the “Roseau” animation, my view is set up as RoseauAnimation. My library :
library screenshot

Now that your level is set up export it as SWC, then import it in your project. And finally to create your level in the Citrus Engine :

package {
 
	import com.citrusengine.core.CitrusEngine;
 
	import LevelA1_fla.Level_1;
 
	public class Main extends CitrusEngine {
 
		public function Main() {
 
			super();
 
			state = new GameState(new Level_1());
		}
	}
}

Et voilà! You can download my zip. There is still the problem with hero deplacement coming from the new version, anyway if you start a new project from scratch with this one, all will work fine!

Now you just have to import sounds/videos in your SWC too…
Be careful if you use a SWC and target the Web, because the swf becomes heavy and if there isn’t an external preloader, people may leave before played your game!

Finally if you want to have great performance on your mobile game, you should take a look on CE blitting method. And you may use Embed metadata tags to add your assets to your game state. I recommend to add them directly in your class, don’t use the level editor. Programming is not always easy 😉

14 thoughts on “Finally using SWC for art in the Citrus Engine

  1. Thanks mate, This is what Im looking for. What do you mean about “hero deplacement”?… I will be building my school game project using this one.

  2. Correct me if I’m wrong, but unless I’m mistaken the way you have the example files set up is such that only *some* of the assets are embedded in the .swc, correct? That’s what the appearance of your library seems to suggest, as well as the appearance of the executable swf when isolated and run.

  3. Hi,

    Starting with game programming and Citrus here, so I’m kinda lost. Some (maybe basic) questions. As I’ve understod SWC is not really a great performer (loading times, not good for mobile). I guess that for a mobile or multiplatform development best technique would be to use Spritesheets.

    But now I’am lost, does blitting as you mention in that URL uses Starling and Stage3D or is it for Display List?

    I guess what i’m looking for is a way to use Spritesheets for objects and characters (Hero, enemies…) and using some level editor (Flash Pro or Tiled) while having GPU acceleration, and probably NAPE (for performance), am I asking to much?

    My intention is to reuse as much as posible for targeting web, desktop and mobile (android at least), well I guess that’s what we all want…

    Thanks for all this great work

  4. Hey Héctor,

    Absolutely, for a multiplatform development you will use SpriteSheets. You will create the same SpriteSheets with different sizes. SWC is equivalent to assets embedded. So you shouldn’t do that with many assets.

    Blitting uses the display list. Now with Stage3D, you should go on the Starling way instead of blitting.

    It’s exactly what the Citrus Engine is offering 😉

  5. Wow, lighting fast awnser!!

    Still doubting about going Citrus way or pure Starling. One of my concerns was documentation and support but your work is really awesome on that matter., I’ll have to give both a try.
    Looking forward for today’s conference, good luck! sure it will rock!

    Thanks

  6. When I tried it with the CE 1.7, the Objectmaker2D can’t process the ‘pure’ movieclip (non-component) in Level1.swc. It only compatible with your ObjectMaker.

  7. Found a little bug with this process, actually. Objects are offset from where they are placed in the flash document. As I understand it, the citrus engine only pulls the xy location and the rotation of each sprite from the level movie clip. Box2d (or nape, I’m sure. Haven’t tested) then uses this point as the center of the physics object it spawns, regardless of where that centerpoint was in relation to the graphic used in flash.

    This wouldn’t be too much of a problem, you’d simply have to place each object’s registration point in the center of the object. However Citrus assumes the registration point is in the top left corner when dealing with graphics as view properties. This means that if you set the object’s view property to it’s flash graphic using the method described here, your graphic will be offset from the object (the top left corner of the graphic will be offset to be in the center of the object). The alternative is to have each flash graphic top-left registered, however as I’ve said, box2d treats these objects as being center-registered when it creates it’s physics objects, which causes each object to be offset by 1/2 height and 1/2 width when loaded into the engine.

    I’ll drop you a formal bug report (including picture documentation or project files) over on the github page tonight, hopefully.

  8. Hey, in fact: box2d & nape assume that you will use a graphic with the registration point in the middle whereas CitrusSprite assumes it is top left. You can change the default registration point via the CitrusObject’s properties 😉

Leave a Reply

Your email address will not be published. Required fields are marked *