In today’s last part of the tutorial, we examine the remaining Machinations. Let’s look at the teeth of registers, retarders and graphs, finally, we’ll talk about color coding and look at data export and auto-testing.
Returning to the Warcraft model, one of the things that was not captured is the gold mining slot rule. Each mine you own will allow you to employ a maximum of 5 peons per mine (you can send more, but at one point there will never be more than five workers in the mine). Registers are used to express this rule.
The register is an element whose value is equal to its expression, its variables being determined by the input state modifiers, and the right side of the expression is determined by the value of the output modifier. You can then add a warehouse expressing the number of owned mines, a warehouse with the number of miners in the mines, and an output modifier with a value of> 0. Then you just define the expression as (5 * “Down Down” – “Number of Workers in the Mines”) and attach the Output Modifier to the Gateway, which will allow you to send the peons down.
If the expression is greater than 0, additional peons can be sent and the control gateway becomes active. Mathematical expressions can then be defined by a number of conditions. For example, if you want to allow a player to send 10 workers down, even if no mine has (God knows why), just adjust the term to 5a-b + 10. Alternatively, if you want the first pit not to release any slots, you can modify the expression to 5a-b-5. As a bonus, there are currently 3 math functions that you can use as value values.
- add – the value of the register is equal to the sum of the values of all the elements connected by the input streams
- min – The minimum value of all input elements is equal to the value of the register
- max – the maximum value of all input elements is equal to the value of the register
Unfortunately, the term add does not work at this time. However, you can simply replace it by marking the input modifiers of the registry +1 instead of the letters.
Registers can also be interactive. In this case, you can change the registry value while running. Conceptually, an interactive registry is the same as a warehouse attached to the consumer and the producer.
However, the output of the registry may not be just a condition. It can also be a classic modifier. For example, here:
And you can also connect multiple registers at once:
For more examples of use, please visit the official Wiki Machinations .
With registers, you can create very dynamic constraints within the gaming engine model, so you might want to try them out and remember them when you create your own models.
In some cases, the raw material is removed much before it is actually aware of the effect of its removal. Typically, this is the production of units in strategic games. Although raw materials are read immediately, the unit is produced with a certain delay. A retarder is used to express such an element.
The retarder always receives the raw material and holds it for a certain number of intervals. This is given by the output current value. The retarder may be in one of two modes:
- Classic – Each raw material it receives will hold exactly the length of a given number of intervals
- Queue – Allows a maximum of one feed to pass. The others are in the queue.
Try it on the following model:
The retarder is also value and can act as an activator. Its value is equal to the number of raw materials it currently holds. Likewise, it can be a trigger. It starts whenever the retarder releases the raw material.
Colors play a crucial role in Machinations and add information about the flow of raw materials, but primarily serve to express the type of raw material. In many games the player operates with many kinds of raw materials and many of them also mix in the same store. Color coding lets you create rules that decide how to handle the raw material of the type.
The basic feature of color coding is the following rule:
If the color of the source differs from the color of the input or output stream of the warehouse, the raw material can not pass through.
However, this rule only applies if you have selected “Color Coding” in the general diagram settings. Then you can create a situation like this:
Producer creates both red and yellow sources at the same time. Consumers, however, accept in varying amounts. If the color coding is turned on, in accordance with the above condition, the red current will always be red only. However, the color of the stock differs from the color of the current. If we have this situation:
Then the yellow stream would pass through the red current (but for the yellow current the condition is still valid – the color differs, so nothing changes here). Besides, there are several special cases in Machinations where colors are also in a different sense. Let’s look at the following model:
Part A can be tested purely to illustrate the basic color coding rule. Try different variants with encoding turned on and off to see how the diagram behaves. However, it contains the first exception. And this is the “all” label.
If you label the label as all, the color coding condition is applied regardless of whether you have it turned on. Paradoxically, the drawx label format ignores default color coding. Thus, it does not take into account the color of the current or the store, nor does it set the diagram and the raw material always.
Let’s look at Part B now with the merchant. Here the colors also determine the path of raw materials among the transaction subjects. The raw material, irrespective of its own color, is sent to the output stream of the same color as the input stream it came through. However, this feature does not block the color coding function itself.
Finally, in section C, you can see additional color use using the converter. Here, the color of the output stream determines the type (color) of the raw material that the converter produces. The same is with the producers (see examples above). However, the color coding rule still applies to the colors of the input stream of the converter (if it is turned on).
A list of all applicable colors can be found here.
Artificial Player (Artificial Intelligence)
When balancing the finished model it is certainly very annoying and challenging to test it all the time. Especially if the model is complex and it takes a long time to test it. In this case, you can use Artificial Intelligence.
Artificial Intelligence is basically just a script to be performed at any given time. It can be just like a warehouse in one of four modes, which does not differ in its function. Mostly, however, automatic mode is used.
Each script line may contain a command and a condition for executing it. Within a given timeframe, then the line per line of the script is evaluated and executed. However, the database of commands in the official dossier is practically non-existent, so I only managed to find out the following two:
|threads (element)||fire (Buy army)||Invokes the action of the target element (pull, push). The command parameter specifies the name of the target element regardless of its mode (passive, active, etc.). Name is case sensitive.|
|fireRandom (element1, element2, …)||fireRandom (buy army, Buy army, buy peon)||It works just like a fire, randomly choosing one of the listed elements. The number of parameters is arbitrary (at least 1), and you can list it more times to increase the weight of a certain element (2: 1 in the example).|
If you know how a condition is defined in programming, you can jump to the next chapter boldly. The condition is defined by the keyword if and followed by a parenthesis with a definition of the condition. For example:
- if (Money> Woods) fire (Sell woods)
“Or” is expressed using two vertices: “||” , “and at the same time” is expressed using the ampersands: “&&” . They can also nest and group together different conditions. Like:
- if (Peons> 5 || (Woods / 50> Peons && Gold / 50> Peons)) fire (Buy army)
So if you have more than 5 peons or you have enough raw materials to double their number (one peon cost 50 woods and gold), buy the army. Currently in programming also uses the keyword else , which defines a situation where the condition does not apply. However, this does not work in Machinations. You must define a new script line where you specify the reverse set of conditions. For example:
- if (Peons> = 5) fire (Buy army)
- if (Peons <5) fire (Buy peons)
The charts are very useful for collecting data generated by the model. Using state modifier (beware, streams do not work) you can attach elements to them, and the graph will automatically record information about their values and plot them with a curve.
For better clarity, only part of the status modifier is visible after the link. By adjusting its color, you can specify the color of the chart curve it represents. You can also export data for use by other tools for deeper analysis. Try the chart features on the following model:
But much stronger is a chart combined with automatic tests. We have already shown how to create artificial intelligence that simulates player actions during the model. We also know how to record data. But without automatic accelerated tests it would not be very useful. And to do this, use the Run tab. It contains two buttons:
- Quick Run – Starts a very short time interval diagram
- Multiple Runs – Starts (without animation) a large number of accelerated tests and records their results in the chart. Item runs can specify a plurality of tests and item visible runs can change the number of lines in the graph transparují from previous tests.
Be careful about closing the diagram. A large number of endless loops will cause the application to fall. Unfortunately, graphs can not generate average values, so you need to use their data export functions and find out for example using Excel.
Structure and model information are stored in XML format. You can do this by clicking Save on the File tab or using Export Selection for selected items only. Do not forget to write the .xml end to the file name .Machinations Tool will not do it for you.
The same is done with SVG export by pressing Save as SVG . Open the diagram with the Open button and import button to insert the diagram into the current model.
Group and TextLabel
|These elements are for completeness only. It will allow you to visually distinguish and name part of the chart.|
Congratulations, you have come to the end. There is nothing we can not find out from the current version of Machinations. Yet our series does not stop! In the next work, we will look at recurrent patterns based on Machinations models, and we will continue. Machinations has many interesting things to offer and this was just the beginning.
See you next time