Eight months of persistent development is over and now - the second version of the popular (in the future - for sure) vector animation editor and, in combination, the environment for game development has been released. About this release, I am finally not ashamed to tell the habrasoobschestvu. This article will discuss some of the features of NanoFL .

I think that most igrodelov at least once used the Flash Pro environment, so to describe in detail the similar basic features of NanoFL, it hardly makes sense. In short:

1. Editing vector graphics with the peculiarity that the figures drawn on one layer are automatically merged (i.e., a boolean union operation is performed on them).
2. A library of symbols that stores items for reuse (both vector and bitmap images, as well as sounds and fonts).
3. Animation using a timeline (timeline), on which keyframes are placed and the transformations of elements in a frame (tween) are specified.

Without a doubt, NanoFL is still young and cannot compete with Flash Pro in everything. However, he already knows a lot of what his elder brother can. Below we will talk about several features that seem important to me.
')

Target platform - HTML5 / CreateJS

NanoFL, generally speaking, is not tied to the output platform. The plugin system allows you to create an extension that will output data in the format you need. Currently, a single generate plugin is implemented that generates code that is compatible with the well-known library CreateJS .

This plugin is quite flexible: if you want to create a banner, then you don’t have to write code at all (there is an option to specify the URL to which you click when clicking), and if you’re writing a game in pure JS, it’s not convenient for you to generate code in TypeScript or Haxe. Able to plug-in and give texture atlases in the format adopted in CreateJS (this is a very simple JSON-format, so the resulting files are easy to use almost anywhere).

The plans include WebGL support in CreateJS and another popular game engine - Phaser , built on the basis of Pixi.js.

SVG editing support

Yes Yes! You can open the SVG file in NanoFL, edit and save. Just ask to be vigilant: not all features are supported. Among those not supported are code, animation, CSS, patterns, masks, relative text positioning (x / y / dx / dy attributes for <tspan>), as well as filters (except for blurring) and embedded fonts. In addition, the focus on HTML5 / Canvas imposes restrictions on the support of special types of fills. I hope I did not scare you too much? Practice shows that simple, and sometimes rather complex images are processed in NanoFL correctly. Comparison of the render, embedded in the browser, with the output of NanoFL can be viewed here: nanofl.com/docs/svg .

Font support

Custom fonts in HTML have always been a sore point, but in recent years the situation has been corrected: browsers support more and more formats, services with web fonts appear. One of them is Google Fonts . NanoFL is focused on working with it (the ability to manually connect fonts is also, of course, available). By default, only the configuration file is stored in the library, containing font parameters and links to related files. There may be several files, because usually different font styles are stored in different files. In addition, depending on the browser on which the created movie will be launched, different font file formats may be supported. Now the most relevant is the WOFF format (compressed TrueType). Also developed is a descendant of WOFF2 with improved compression. Both formats are supported by NanoFL along with TrueType. Additionally, you can specify links to files with SVG-font (relevant for iOS and older versions of Android) and EOT (makes sense to support older versions of IE).

Import from Flash

Starting with Flash Pro CS5, the * .FLA files are XFL-formatted ZIP documents (i.e., XML). This allowed in a reasonable time to write a plug-in import from Flash to NanoFL. Unfortunately, some resources (bitmaps and sounds) are still stored in binary files with a closed format. Therefore, if those resources are used in a flash drive, NanoFL is forced to launch the Flash environment and export these files to their original format using a JSFL script (of course, it is assumed that you have Flash Pro CS5 +).

A simple game, a screenshot of which is shown in the very first picture, is imported from Flash. Play online here . You can also look at the results of the conversion of other unpretentious flash drives on the site .

Plugin system

Writing a plugin for NanoFL, it seems to me, as simple as it was possible to organize at all. All you need to do is to create, in the simplest case, a JS file with a description of the class containing certain variables and methods (according to the plugin interface) and call a predefined function to register an instance of this class in NanoFL. Plugins come in many forms:

1. Loader (loader) - downloads files from the library (and physically the library is just the “library” folder in the folder of your document) - you can support files of any format (for example, 3D objects from Blender).
2. Importer - loads the document from the external format (your method comes to the input path to the source file and empty structures of the NanoFL document that you need to fill with data).
3. Exporter (exporter) - saves the document in external format.
4. Generator (generator) - allows you to save additional files when you save the document (for example, generate code-binding in any programming language).

If NanoFL sees that it has a plugin for importing and exporting the same format, then it allows you to open files of this format in a transparent mode (for example, due to the fact that NanoFL has SvgImporter and SvgExporter plugins, we have the opportunity to open SVG, edit them and save as if they were native NanoFL documents).

Plug-ins can be written not only on pure JS, but also on TypeScript or Haxe, which greatly simplifies the task (there are header files for these languages, which allows the use of auto-completion in the IDE).

The plans include the support of another type of plug-in publishers to pull out files relevant to the end user from the document folder and save them in a suitable format (this will allow, for example, to integrate NanoFL with Cordova or simply to get only one HTML output -file with the game).

Conclusion

I hope the article turned out not only advertising, but also useful. I ask everyone who is interested in this topic to touch NanoFL and express their opinion. You can write about the problems found in bitbucket .