THE ASSET PIPELINE EDITOR - PART 6

After a short break to do some marketing about the APE (sigh!), it's time to resume posting so the turn goes to a couple of recent additions I implemented into the core functionality:

• "Direct" build (what?), and
• Asset Packagers (oh yeah, baby!)

These features have been requested by some of you, so here they are ...

Direct Builds

In part 4 of the series I mentioned that there were two actions when compiling assets, the first one was "build" and the second one "copy/move", and the way to indicate whether to copy or move assets was by (un)checking the following checkbox:

Well, as a corollary of the command-line tool "APEBuild", a new third option may take place: direct build. Now you can indicate the APE to compile assets directly on the output folder instead of doing it on the "local" folder. In short, it's a way to reduce steps. No need for move or copy.

So, you will have three options from now on: "Copy Assets", "Move Assets" and "Direct Build". Needless to say that the "Default Copy Action" field ("Copy Always", "Copy If Newer" and "None") will be only enabled when "Direct Build" is disabled and that this feature can also be used with APEBuild.

In the picture above, if you look at it carefully, you will have a preview of what I'll talk next ...

Asset Packagers

Throughout the years, as a moderator in the creators' forums, I read many questions regarding the possibility of zipping your whole content folders. Recently, it has been brought to my attention (thanks again Javier) that some authorware offers the possibility of compressing all output into a single zip file.

Guess what? Now you can also do it with the APE!

How come? Simple ... you create your own packager (where you can use any of the compression techniques available in .NET 4.5, use third-party libraries or add your-own compressor) and when you plug it into the APE, the latter will show it as an option on the General Settings tab:

By default, as usual, there is a "pass-through" packager built-in, named "No Packaging", which we can use for the cases where no zipping is required. 

So, when you create/load a solution, its panel will look like this:

We can then select the packer along with the writer to set as the default one for the solution (which of course, can be overriden per project). But that is not it ...

The picture above shows a new field to set in the Project Settings tab: "Pack To". By default, that field will initially equal the path assigned to the "Copy To" field, that is, the output path.  But you can change it, in case you need to have a different target directory for the zipped file.

This opens a new set of possibilities since selecting a packager won't disabled copy/move operations, and vice versa. So, if you decide to copy assets and also create one huge compressed files for the whole structure, you can set a different path for the packed files and presto! Do you want just the packed files? No problem, set either the direct build or activate copy/move actions with "None", and you will only get the zipped file.

As I say, you can build, build+copy/move, build+package, build+copy/move+package, direct build, direct build + package. Pick the right combination for your project's need.

Please notice that the packaging action is meant to apply to a whole structure of assets and not to each asset individually; in other words, alike assets writers -which affect each raw file individually as part of the import/export process even though they are applied per project, asset packagers affect a structure of folders and asset files per project. Say you have a folder named "Content" with all the asset files built in the last execution of the command, then this folder is the one the packager will take as a reference to create and output the compressed file (or the compressed files you decide to output).

Last but not least, the "Writers" tab has been renamed to "Output Providers" given the fact that it now includes a configuration panel for packagers, where you can select the packager to use per compilation profile and configure its properties, if any is available.

In the example above, no packaging is set for the Windows target platform and the "Debug" compilation profile. Plus, since this default packager is a pass-thorugh one, there are no public properties you can tweak.

And again, this feature is automatically included in APEBuild!

To sum up ...

With these two additions, the APE now covers several use cases: from usual ones to the weirdest! Thus, I am eager to see what you guys come up with when the first released version of the APE gets launched ...

Btw, I continue working on this handy solution as we speak, so new and exciting features are added on a daily basis.

We are close to start the campaign at IndieGoGo so I hope you stick around!!!

'till next post,
~Pete