Super Nut Jump taught us a lot about handling our assets for cross-platform projects. Our pipeline worked, but it was time-costly in a tight spot because things just needed to be done, not done efficiently. Now we have time to prepare for future projects by using a slightly modified version of the Super Nut Jump pipeline, made possible with Flash. Flash makes setting up a cascading inheritance system extremely easy. Applied properly this can lead to massive time savings, even in the face of ‘need-it-now’ changes.

The Problem With The Cross-Platform Pipeline

One way of developing for multiple platforms requires several sets of assets tailored to different screen resolutions. This means the same assets and animations at many different sizes, which in turn means a lot of resizing and exporting. The issue is compounded because all assets will eventually change, and going back and resizing and re-exporting everything is a time sink even with vector based graphics. Waiting until we think we’re asset complete before exporting for other platforms isn’t a good solution either because we’d like to be testing on as many platforms as possible as soon as possible.

So how do we quickly change, update, and export the assets for every platform? We use Flash to create a cascading inheritance pipeline.

The Cascading Inheritance Solution

It’s not exactly an award winning infographic, but this figure illustrates the basic pipeline for getting all of our assets:

Figure 1

The Mother FLA allows us to do all of our editing in one file throughout the duration of project. (We could also have it inherit from other files itself if we needed multiple artists to be working on the project at a time.)

Once we have all of our known assets in some initial placeholder state, we can start saving out copies of the Mother FLA and resizing them to fit different resolutions. Each movieclip in the libraries of these Sized FLAs has to be set to inherit from the Mother FLA. This way when we make changes everything can be updated without having to resize it again.

Once everything is sized properly, we use the Sized FLAs to save special PNG Export FLAs that will contain only the graphics we need to export to PNG format. This is done because Flash exports everything that is visible on the stage when it exports PNGs, so we have to tailor the size of the stage to each individual PNG graphic so we aren’t dealing with massive images full of wasted pixels. We can still have multiple graphics in one PNG Export FLA, though (all standard sized buttons, for instance). The PNG Export FLA libraries should also inherit directly from the Mother FLA.

The inherited libraries allow us to easily make changes once and have a full set of ready-to-export, pre-sized assets for every targeted platform.

Smoothing Out The Process

There is always a high probability that the graphic needs for the game will change course during production. That could throw a wrench in our system if we wanted to add something new. Any fresh artwork might have to be dropped into all of our Sized FLAs and painfully calculated to be resized in each one. To remedy this, we can keep things grouped together logically in big movieclips (all buttons, all menu items, all characters). That way when we add something new we can stick it in a movieclip that is cascading down the pipeline already.

Keep your library organized from day one, asset one. As soon as your library gets out of hand you will be spending half an hour a day digging through it. This is true for each library, but it’s most important in the Mother FLA.

Keep a folder in the Mother FLA to contain all of your old, out of date assets and animations. This will be helpful later if design needs are reverted.

Use Flash Project folders to build all of your .FLAs at once, updating every asset for all platforms with a single click. Set all of your inherited movie clips to update every time the FLAs are published, and publish the whole project at once.

Movieclip inheritance links will break once you edit a movieclip. If you want to keep the link you will have to reset it after editing. Because we are embedding multiple graphics in single movieclip containers (all standard size buttons), we would want to turn certain layers on or off before publishing. This counts as an edit and will break the link. We could export and re-establish the link afterward, but this adds a complicated step to the pipeline. To remedy this problem, we can nest asset movieclips in a container movieclip that will update everything, and keep the single movieclips on their own top-level layers we can turn on and off without breaking any links. This bloats our top-level timeline a little bit, but is worth it.

Save out some templates for different screen resolutions. These can be used as a reference only, or you can copy and paste your content from the Mother FLA into these pre-sized templates instead of saving a copy and changing your stage size every time. When copying content into a template, select all (ctrl+a) and use locked width/height to quickly scale everything using a precisely calculated number. Have a stage outline rectangle specifically for matching everything up by snapping the corners to a grid.

Limitations

In this pipeline, absolutely everything has to be inside a movieclip. Top-level free artwork will not inherit down, so it has to be contained in something that can be grabbed from another FLA automatically.

This system does not export final assets automatically (still working on that one), so any changes to graphics will still have to be re-exported for every device after they are updated.

Using this system is also going to require a lot of forethought and prep work, which may be counter-productive and slow down the beginning of your project. Having a dedicated ‘pipeline negotiator’ would help alleviate this issue, but it will still result in time savings with even a single artist.

Conclusions

We will be using this Cascading Inheritance system for future projects until something better reveals itself. It’s a great way to keep our assets organized, consistent, and easy to update. It’s fast and reliable, but does require some invested preparation. Please share your thoughts, questions, and any tips you might have. If you try this out, let us know how it goes! Next time I’ll tackle how to design the assets themselves for a cross platform production.

Recently I funded a project on Kickstarter because I’m a huge hipster, but mostly because I thought the project was going to make a big splash in the 2D game development sector. As of the time of this post, 1,844 other people agree with me and the project has been successfully funded to almost $50,000 over its intended goal.

The project in question, Spriter, is a 2D modular animation tool developed by BrashMonkey. For some time, modular animation has been an expensive trick used in 2D games with bigger budgets. Now a full suite of modular animation tools is available to any developer with twenty-five bucks to spare.

Any game that is drawn in 2D will probably also have animation, but the distinction here is ‘modularity.’ A lot of 2D games in the independent world have always used sprite sheets because they’re cheap to create.

Sprite sheets are big images (or textures) containing multiple frames of animation that can be rendered in pieces over time to create the magical illusion we call animation. Figure 1 shows a standard sprite sheet.

The problem with the sprite sheet method has always been size and an unfortunate level of inflexibility. Sprite sheet animations can be layered, but generally speaking even small changes need to be recompiled and often require a lot of extra work in the name of mistakes and changes of mind. Sprite sheets also often repeat parts of images over many frames with very little change, so the file sizes of these textures can become quite large as animation complexity increases.

Now, here comes Spriter to save the day.

Spriter allows an artist to create modular animations by translating and swapping pieces of an image. If you are familiar with Flash or Toon Boom Studio, Spriter will make perfect sense because it uses a very similar tweening and symbol system. If not, just know that the animations have gone from a series of baked-in frames to single images stored in different positions.

The modular animation is rendered in-game by displaying each image at its stored translation values over each frame. This generally allows for a smaller asset footprint because there is no redundancy. The animation information is stored as a set of values in an XML file. When using sprite sheets, there need to be separate images for each possible frame of animation, even if there is little change or even no change in some pieces of the object. Modular animation allows an artist to break up objects into pieces and only make changes that need to be made each frame.

Figure 2 shows the necessary images required for the same animation using each technique. In this example the position, rotation, scaling, and tint will all be stored as XML values by Spriter instead of rendering each individual frame.

If you’re familiar with games like Rayman or Castle Crashers, you’ve seen modular animation in action. So why are sprite sheets still used so frequently by independent developers?

Until Spriter came along, if a studio or development group wanted to have a modular animation engine, they would have to write the tools themselves. Usually this involves some extension of Flash exporting, but sometimes it’s something a lot more involved like the UbiArt Framework. Writing tools costs a company a lot of time, and it’s less cost efficient than paying a lot of artists to export PNG sequences of their animations and re-package them into sprite sheets using existing free tools.

However, as previously stated, sprite sheets are costly in file size because there are so many large images required.

So, Spriter is going to open the floodgates for a whole new wave of developers to easily and cheaply get their hands dirty with modular animation, and it’s probably going to result in some very awesome looking games given the time savings. With features like adding variable changes and hit-box regions to frames, which are then exported in the animation’s XML, there’s even pressure taken off the programmers to some extent.

Thinking ahead, I’d like to see a tool (or a feature of Spriter) that combines the image loading benefits of sprite sheets with the low asset footprint benefits of modular animation. For instance, an artist might load a compiled sheet of pieces into Spriter instead of whole frames, then choose which section of the sheet they wanted to animate. This would reduce loading times because pieces of animations could be loaded as whole textures instead of individually, yet the engine would still see the benefit of loading less overall because of the loss of redundancy via modular animation.

In conclusion, if you can’t tell, I’m excited to start using Spriter and see other people using Spriter. I think it’s going to shake things up in 2D the game development world. If you’re an animator or 2D artist with any time saving tips, tricks, or tools, I would like to hear about them. Thanks for reading!