Anatomy of Exporter

If Supernova would be a human, the exporter package would be its brain. The package tells it how to behave when code generation runs down to the latest detail. And as its brain, it has access to all tools available. This means that exporter package can do any operation and can access any data Supernova provides. If you see it in the user interface, you can use it inside the exporter. And you can also use more information that is not normally exposed at all.

But the brain analogy is not exactly true. That is because, usually, you can't change the brain inside one body (but it would be cool!). In Supernova, however, the brain simply connects to its body. Do you want to generate code for a different platform? Simply switch the brain - change to different exporter package - and the resulting code will be dramatically different. Do you want to generate just assets? There is a brain for that.

The following paragraphs contain a lot of in-depth information about how exporters internally work. It is useful to know when you build them or are interested in how we achieved such a level of customization, but if you are only interested in using Supernova blueprint editor to make minor changes, you can skip it freely.

Exporter execution flow

The exporter package is loaded just before it is used and then discarded immediately afterward. That means that you can freely change its configuration and it will always run the latest version. The full execution flow of exporter package is as follows:

  1. Exporter package is loaded and validated

    • Validation checks that exporter contains valid exporter.json configuration

    • Validation checks that all blueprints have proper configuration files

    • Validation checks that all blueprints are valid

  2. Blueprints are compiled and validated to see that they don't have a syntax error

  3. Mapping information is loaded. Mapping contains "commands" to be executed in parallel, such as "invoke a blueprint X", "generate .png asset" and so on. Mapping also contains an information about where to write the output once it was generated

  4. Any static assets provided with package are loaded into memory

  5. Exporter runs all loaded commands. This means generating blueprints, generating assets, and so on. The entire output of the export is kept in memory at this point

  6. If all commands were successful, the export output is copied to the destination. It is only possible to write into the local file system now

As a general note, the exporter paralellizes everything and uses it can to achieve better performance, so running export on a multi-core CPU is much faster than without it.

Exporter Package

Exporter package is a folder that is of specific structure so MacOS can recognize it as a bundle. If you open the exporter on windows, it will be just a directory and nothing else, but you can still edit it because the format is fully open, readable, and accessible. Exporter package always comes with an extension snexporter. The proper bundle structure is as follows:

info.plist // Bundle info file, needed for OSX to recognize the bundle
exporter.json // Main exporter configuration file
icon.png // Optional package icon
Blueprints/ // Folder containing blueprint definitions
Config/ // Folder containing blueprint configurations
Assets/ // Folder containing all static assets to be copied

You can find details about each of the part of the exporter and their purpose in the following sections:

  • Configuration section teaches you about basic metadata and base configuration file

  • Blueprints section teaches you about how blueprints are stored and their configuration files

  • Mapping section teaches you about how mappings are stored and their configuration

  • User interface teaches you about how to adjust the user interface to obtain additional information before the export runs (Coming soon)

  • Bundled assets section teaches you about how to bundle assets with exporter package, so you can then copy them on export (Coming soon)