Alternatives to animating a sprite the traditional way

[ForgeableSum]

I've been having one of these big 'what if' moments lately. 

 

The sprites in my game use a traditional spritesheet with over a 200-hundred or so frames for each direction and animation (there are 8 directions, hence a lot of frames). This works but it makes the process of creating sprites very tiresome and impossible to edit once the final image, containing all frames, is made. 

 

What if there was a better way? I was thinking of cutting the game character into separate parts: the head, arms + torso, legs, hands, weapons, etc and tweening them independently, sort of like this.  If I used this methodology, I wouldn't need to create a JSON file for each sprite so long as the proportions are the same. .. In my case, all game characters are humanoid and have the same shape/proportion. I could just swap out interchangeable parts. This would also make it easier for people to contribute to the game and increase customization because you can swap out random parts: armor, weapons, even body parts to create new character models. 

 

After I created the first one, I would basically never need to touch code again because I could just follow the template of the first for creating the individual parts. This would make sprite creation 1000x easier and 1000x more customizable. 

 

I want to do this, or at least explore the option. Thing is, I don't know exactly how to go about it. Has anyone ever done this before in phaser or JS? I would appreciate any examples/advice/comments.

[Tom Atom]

Hi, I have been solving this also some time ago. My solution was to cut character into pieces and then build hierarchical tree with them. Tree has Phaser.Groups as non-leaf nodes and Phaser.Sprites as leaf nodes. Final character (root node) is also Phaser.Group. There was one issue I had to solve: how to position parts in groups and sub-groups with minimal effort.

 

 In the end I added extra custom properties into every atlas frame. These properties are "anchor" for easy setting anchor for sprite and "nextItem" for marking position of next node. Next nodes position is set to previous "nextItem" value, anchored according to its own "anchor" and "nextItem" property is read to know where to place next item. I had to tweak Phaser's atlas loading routine to get these extra properties into account, but it works great for me.

 

 I wrote detailed blog post on this (including on tool I used for it): http://sbcgamesdev.blogspot.cz/2015/04/phaser-tutorial-sprites-and-custom.html

[ForgeableSum]

Hi Tom,

 

Thanks for the info, it's very helpful. One big concern of mine is performance. I literally have hundreds of sprites in-game at any point in time. Do you think animating individual parts for so many sprites is do-able? 

 

How much more resource-intensive is your route than a traditional animation with frames?

[Tom Atom]

I am sure, there will be performance penalty, but I do not know how big. Just guessing:

 - if sprite is animated in one piece, then there is running some animation updat with time n. If sprite is cut into x pieces and each is animated there will be x * n animation updates,

 - tweening function has to be evaluated every frame. So, if every part is tweened, there will be more tween functions to evaluate,

 - position, scale and rotation of every node has to be calculated too.

 

 So, there is performance hit for sure, but it depends on how much sprites you have, whether it is relevant to you. Weight it against: smaller texture sizes, possibility of more rich animations (not only frames, but combination of frames and tweens), The above performance hit is mainly from calculation point of view, not rendering. I believe, that today devices are fast from the calculation view and bottleneck is still rendering. Then, the performance hit may be acceptable.

 

 If you have hundreds of sprites I still believe you are limited with screen size. Then, you can for example disable all nodes below root group if you are off screen, so tweens and animations will not be calculated and you can still move root group node. And when the group is on screen, activate child nodes again.

 

 Also check your game size. Too ambitious dimensions can be bigger performace killer than few more calculations. For example: we are just finishig our new game. The base resolution is 1280x800 and it works great on most devices. But there are slow old devices so we check screen dimensions of target device and if its width is smaller (or it is some piece of crap like my old Android device with stock browser) we set game size to 800x500. What is  effect of this? 800 = 62,5% of 1280 and 500 = 62,5% of 800. 62,5% * 62,5% = 39% ... we cut number of pixels to render by 61%!!! Is it difficult to maintain resources for 1280x800 and 800x500? No, its easy if you use that tool (SBC PicOpt / Spritor) described in blog post. It can create atlases with requested scale, so just reexport and you are done. My assets directory structure is:

- assets (where common asstes like music, text, ... is stored)

  -- 1280 (sub folder with 1280x800 atlases),

  -- 800 (sub folder with 800x500 atlases - names of files are the same),

 All loading routines are then prefixed: "assets/" + size + "/assetName"

 All positions, speeds, sizes in game are then recalculated. Base scale is 1;1 for 1280x800. I calculate global scale in very beginning of game and put it into Global variables. If game is 800x500 then Global.scaleY = 500/800 = 0,625. Whenever I then use for example bitmapText I do: this.game.add.bitmapText(0, 0, "Font", "Text", 45 * Global.scaleY, this);

 

Uff. long answer, but there is almost always place where to cut when performace is low...

[lukaszwojciak]

So long story short: spine2d ;] http://esotericsoftware.com/

[ForgeableSum]

So long story short: spine2d ;] http://esotericsoftware.com/

This looks neat. But how would such a thing be implemented to phaser? Does spine2d export as JSON + a single image file or does it need to work differently? 

[drhayes]

So, Phaser doesn't support Spine out-of-the-box. Here's an old thread about it. In it, Rich recommends DragonBones instead. I've seen later threads where Phaser pulled its Spine support because the JS lib was badly done, or Pixi's impl was messed up, or something... but can't find it.

 

Pixi does have Spine support (or it did, a long time ago). Not sure how much of that will work with Phaser at the mo'.