A level editor, at its most fundamental level, can be viewed as the integration of three engine mechanics: creating a level, saving a created level, and loading a saved level. This tutorial is broken down into three sections with each section describing one of the engine mechanics listed above. Each section will describe the concept, goal, and several ways of achieving the section’s mechanic in Multimedia Fusion 2 and Clickteam Fusion.
By this point, you should have a rough idea of what variables you are going to save in your level editor. The next important step is determining the storage format for the saved data. For this, you should ask saving related questions such as:
What saving extension(s) will I use?
What is the most efficient way for me to save the data?
Which saving method is easiest for me to implement correctly?
How will I group related data sets?
In the future, how will I load and retrieve data?
These types of questions help flesh out details which will guide you in constructing the saving aspect of your level editor. Additionally, if you do not know what types of questions to ask yourself, this tutorial section mentions some key questions you can ask yourself.
Choosing the Storage Format
Let us formally establish a definition of what storage format means in the context of this tutorial. In software, saving data almost always leads to grouping related sets of data and writing this set into a file or database. For the purposes of this tutorial, the storage format is how you group related data sets within files or databasesand how you actually write or save these sets into files or databases. These questions are important because they directly influence both the saving and loading aspects of applications, two critical level editor features.
If you have checked out the The Basics of Saving Data in Multimedia Fusion 2 and Clickteam Fusion tutorial or completed basic applications using MMFusion, then you should be familiar with the INI extension and Array extension. These extensions allow you to save data using actions, conditions, and expressions relative to the extension’s storage format. The INI extension, for instance, saves multiple variables under one group. This is useful if you collect and save related variables into the same group, such as saving an object’s Alterable Strings. The INI extension writes the actual INI file in plaintext and uses delimiters to distinguish between group names, item names, and items values, as explained in the “The Sections of an INI” tutorial section. The Array extension, on the other hand, groups and saves data in a table-like structure, effectively letting the developer customize how to group the data. The Array extension writes the actual array file in a non-plaintext format and saves either numerical or textual values.
If you prefer to use other storage extensions, or need additional storage capabilities, there are other extensions which you can use, some of which include the Binary object, AssArray object (short for Associative Array), and the INI++ object. Additionally, if you cannot find a storage extension which suits your needs, you can easily your own storage format with the use of a parser (String Parser) or tokenizer (String Tokenizer) extension, the subject of a future tutorial.
As mentioned before, the choice of storage format directly influences the saving and loading aspects of applications. Two examples, described immediately below, shall exemplify this influence.
You have completed the design of a small game. This game contains a title screen, three levels, and a place where the player can configure their controls. You now decide to implement the saving aspect of the game, which requires saving the following information (color coded for your convenience):
High score for each level (100 for level 1, 1000 for level 2, 10 for level 3)
Completion time for each level (60 for level 1, 120 for level 2, 3600 for level 3)
Customized user control configurations (A = Left, W = Jump, S = Down, D = Right)
After some thought, you decide on one of the following formats (click the tabs to view the examples).
Example A - No Format
In this example, you opt out of choosing a storage format and simply decide to save every value by itself in a plaintext file, resulting in the file displayed in “Example A - File Contents”.
The idea for loading values is that each saved value belongs to a certain place (such as the score 100 belonging to level 1), so you need some way of knowing where each values goes. The next time the game loads, how will you determine where each value goes? How will the game know which value in the file is the score for level 3? How will the game know which value is the time for level 2? It would be nearly impossible! Since the data is unstructured and unorganized, you cannot correctly load the saved values into their proper places. As you will see in Example B, you can easily accomplish this task by adding more information/organization to the saved data file.
As a rule thumb, the more you can organize and structure the saved data, the more efficient the saving and loading aspects become.
Example B - INI Format
In this example, you decide to use the INI storage format and INI extension, resulting in a file similar to the file displayed in “Example B - File Contents”.
As mentioned in Example A, the idea for loading values is that each saved value belongs in a certain place. The INI storage format groups related data together so you can determine where each saved value is supposed to go without difficulty.
For example, all of the data related to a given level in that given level’s group in the INI and the scores for a given level can be accessed by searching for the item name “Score” in a given group, both shown in the “Example B - File Contents” image. From these two organizational rules, you know exactly where to find the score for any level, whether you have 3 levels or 300 levels. This concept also extends to the completion time of the level since it is organized in a similar manner. In fact, you can easily save and load any value with the INI object if you can place related values into a group and give consistent item names for each item in the INI.
Since the INI storage format organizes and structures data, the saving aspect becomes trivially easy which will make the loading aspect trivially easy in turn.
Example A - File Contents
This image shows how the saved file in "Example A - No Format" might appear. At a glance, it is hard to see the related sets of data. Click on the "Example A - No Format" tab for more information.
Example B - File Contents
This image shows how the saved file in "Example B - INI Format" might appear. At a glance you can easily see related data. Click on the "Example B - INI Format" tab for more information.