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 series 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.
So at this point, we can create objects and we move these created objects. This final section covers ways to manipulate variables in specific objects. As an example, suppose you placed two “Enemies” into your level editor and wanted these objects to have different amounts of HP, 3 and 10. How would you let the level designer set the HP of one “Enemies” object to 3 and the HP of the other “Enemies” object to 10?
This section covers a few general methods one could achieve this. These methods are by no means an exhaustive list of all the ways one could manipulate variables in a level object, but rather a set of fairly general ideas one could flesh out and extend to accomplish this mechanic. Once you are able to change variables in level objects, you have completed all aspects with designing a level and can proceed to saving the actual level; discussed in the next section.
Method 1 - Create Object Variations with Predetermined Values
This method involves allowing the user to select one of many predetermined variations of an object. These variations all hold specific values for the variables. When a specific object variation is created, the proper variables are assigned and the user can no longer edit the variables. If user wants to change these variables, the user would need to delete the original object and choose another variation.
For example, suppose you have three variations of a “Triangle” object with a colorID that varies as follows; white, gray, and black. When the user goes to create an instance of this object, the user can choose one of the available three variations. The user would need to overwrite the original “Triangle” object to “change” the variables.
This method is easier compared to the other methods as the level editor developer simply needs to allow user selection of these extra variations and to create these variations, either statically during edittime or dynamically during runtime. That being said, using this method to change multiple variables adds extra work and tends to be cumbersome to the level editor developer.
If for a given object, for example, you wanted three variations of VariableA and four variations of VariableB, you would need twelve variations for the object. If you also wanted five variations of VariableC, you would need sixty variations! More variations across more variables leads to large amounts of objects for the level editor.
Easy to setup & implement
More variations results in large amounts of objects that need to be created
User is locked into these predetermined variations of objects. If no variation exists with values the user wants, the user is simply out of luck
Method 2 - Using the MMFusion Debugger to Manipulate Variables
This method uses the built-in MMFusion debugger instead of creating a custom debugging system. The MMFusion debugger can import objects, display variables of this object, and change these variables. The idea here is to use the debugger during runtime to slowly change objects’ variables. Since the debugger is only accessible from within Multimedia Fusion 2 or Clickteam Fusion, this method is only viable if the level editor is being created and executed from within Multimedia Fusion or Clickteam Fusion.
Nonetheless, this method involves three main steps. First you create the level from within MMFusion. Second, you use the debugger to modify the Alterable Variables of each object. Finally, you save the level (discussed in the “Saving the Level” section) so that these variables are stored. If you wish to be able to load saved levels, you will also need to be able to pick and load these saved levels (discussed in the “Loading the Level” section).
No need to design or implement an extra mechanic or system to debug variables during runtime
The MMFusion debugger can be clunky and using it to change individual variables across multiple objects can be slow, inefficient, and time wasting
Only those with access to the MMFusion debugger (aka users of Multimedia Fusion 2 and Clickteam Fusion with access to the document) can edit the values
This method involves using additional non-level objects (hereby referred to as helper objects) to change variables of level objects. The purpose of helper objects is purely to help the level developer change variables of a level object, and have no explicit function or use during the execution of the actual level as such.
How helper objects are used is entirely up to the level editor developer. One of the easier usages is to have helper objects modify variables of level objects they overlap. When the level starts, any helper object overlapping a level object changes some variable(s) of the level object. The helper object is then destroyed or otherwise rendered useless.
The helper object could definitively set a variable (such as “Set MAX_HP to 10”) or increment a variable (such as “Add 1 to MAX_HP”) depending on the developer’s wishes. As an example, HelperObjectHPSmall may set the MAX_HP of any level object to 20 while HelperObjectHPLarge may set the MAX_UP of certain level objects to 100.
This usage was one of the simpler examples of using helper objects that can be implemented during edittime or runtime. There are many other usages how helper objects can be used; it is simply up to the level editor developer to decide where and how they are are used.
Mechanic implementable during edittime, runtime, or both
Helper objects are extremely customizable
The level editor user needs to be able to select these helper objects, know how to use them, and know what they do
Code must be implemented to achieve the various helper object effects
This method involves changing a variable based on some user action, similar to method 2 in the “Creating the Level Objects” section. The definition of user action is the same; some action that the user explicitly initiates such as a keypress or mouse click. The idea is that the user increments or decrements a variable after a given user action. How much to increment or decrement is up to you, the developer.
Works for any level editor
Extremely flexible when changing the variable; you can increment the variable by any value
Need to ensure the proper objects are scoped
Need to implement code for each user action (and potentially for each object/qualifier)