One of the most common problems beginners experience with .scn files is portability. Textures referenced by a .scn use the SpriteEditor’s location as the relative folder. This requires that either the SpriteEditor is in the same directory as the project’s .exe or that the SpriteEditor has the same folder structure. Both of these options are problematic, and even moreso when a .scn is to be transferred from one project to the next.
The .scn filetype is pushed as a standard FRB file so that it can be used from one project to the next. One reason this is important is it allows new FRB users to work with existing .scn files both in code and in the SpriteEditor. Another benefit is that generic .scn files (such as UI screens) can be used in multiple projects. Finally, taking levels from one game and using them in a different game can also be enjoyable.
Therefore, for the November release of FRB, I’ve added the ability to specify the directory to which assets are relative to in code. A new class called the FileManager provides methods and properties both to simplify working with files as well as to specify the relative directory which will be used by the engine when loading files.
The second improvement coming in November is the ability to specify that all files referenced by a .scn file should be relative to the .scn itself. This removes the tie between the .scn and .exe, and allows users to create a zip file with a .scn and its referenced assets and send it to any other user. The .scn can be loaded in the SpriteEditor or code without having to create the same folder structure below the .exe.
I anticipate that as the .scn and Screens become more common in FRB projects, standard .scn files will be available on the site for use as generic .scns. Furthermore, objects like SpriteRigs, AnimationChains, and other FRB-specific files will become more modular, improving reusability.
–Vic–