When you tried to search for tools created specifically for Game Designers, you probably came across Machinations – tool and visual language, designed to simulate game systems and mechanics through a set of standardized elements (nodes), which communicate through connections. This was my case a few years ago, when I was starting to work as a game designer for living. I came across the Gamasutra article where Ernest Adams described this new approach to develop and explain game mechanics. The idea sounds fantastic – you will be able to simulate complex game mechanics and features without writing a single line of code or creating Excel spreadsheets. The new tool he was explaining was made by game designer Doris Jorman, who developed this visual diagram language and programmed a simple interface in Adobe Flash. I can remember that the original tool was really limiting, but I tried experimenting with it a little bit. After first simple diagrams I find out that creating more complex mechanics isn’t very comfortable. And was my first experience with Machinations. Now, let’s jump a few years forward.
The team of enthusiasts connected with the original Machinations creator with a clear goal – take Machinations to the next level. They worked hard and you can see the result of their work by simply opening a new, modern version Machination tool directly in a browser. And the next level wasn’t only about improving technology and usability. You can find a lot of documentation and examples directly from authors, which made this project much more accessible than it was in the past.
And once, after I attended an online webinar organized by the Machinations team, I decided to try it again. So I spent a few evenings with diagrams and refreshing knowledge from the past. Honestly, beginnings were hard. It’s like with any new complex software or activity. But slowly I was able to create simple loops and use most of the elements. Yeah, that feeling as when you create your first simple interactive objects in Unity and run them again and again, just to see they are working.
First experiment – a simple game
So I started thinking about some semi-complex assignment, which I will try to create in Machinations to prove, if I will find this technology useful. At the end, I decided to keep the assignment rather simple – simulate player progress through a level based game (let’s imagine standard Match 3). I set the initial requirements for this project:
- For every action in the level player collect some amount of coins
- If the level is successfully finished, collected coins go to player’s bank
- If they fail, one live and all coins collected from current level are lost
- Lives can be purchased for earned coins
- Difficulty of levels is variable
- The session ends when player run out of lives and coins
- Optional: Player can use boosters to decrease difficulty
Did I succeed? Let’s say that after a few hours I was pretty satisfied. I didn’t finish boosters, but all other features worked and I was able to simulate player progress in this fictive game.
At first (and probably on second too) sight can be the diagram a little bit confusing, but I hope that I will be able to provide basic explanation:
- Player starts to play level when the token arrives into the pool “Start New Level” – this action will create a set of moves, required to win level (more moves = harder difficulty). The number in pool “Level” is increased.
- When moves are generated, the “Playing” loop is activated. In every move the player can acquire different amounts of coins (lower amount = higher probability). All coins are collected in the “Temporary bank” pool.
- For every move there is a small chance that this move will lead to player’s loss. If it happens, all coins in the temporary pool are drained (lost), a number of required moves is reseted and one life lost.
- But If the player is successful in all required moves, coins from Temporary Bank are moved into a pool named Coins and a new level is generated.
- In case, that player runs out of lifes and he has enough coins, the extra life is “purchased” (one life costs 500 coins).
- Player’s session ends in case that player doesn’t have lives and doesn’t have enough coins.
Second experiment – Machinations vs Python
For the next experiment I decided to create a very simple random distribution model. First I created it as a diagram in Machinations, after that I used Python (programming language). Here are rules for our model:
- We have simple chest, which contain coins as reward for players
- But the amount is randomized – chance that you will get 60 coins is 10%, 30 coins is 30%, and chance to get 10 coins is 60%
- The output will be distribution of the coins after 300 iterations – chest will be opened for 300 times (limit of free version of Machinations)
import random players = 300 box1sum = 0 box2sum = 0 box3sum = 0 box1count = 0 box2count = 0 box3count = 0 for i in range(players): roll = random.random() if roll <= 0.6: box1count+=1 box1sum+=10 elif roll <= 0.9: box2count+=1 box2sum+=30 else: box3count+=1 box3sum+=60 print("Loot1 ",box1count," - ",box1sum," Coins sum") print("Loot2 ",box2count," - ",box2sum," Coins sum") print("Loot3 ",box3count," - ",box3sum," Coins sum") ----------------------------------------- Loot1 184 - 1840 Coins sum Loot2 82 - 2460 Coins sum Loot3 34 - 2040 Coins sum
As you can see, both approaches worked well. But what is important for me is different ways to think about problems in Machinations vs regular programming languages. In this case, I needed only a simple loop (for) and conditions (if, elif, else) to simulate chest behaviour. For me, this kind of thinking is more natural. When you start modeling in Machinations, you have to think by his own language. It’s not only about visual representations of single elements and connections. Although it may look like that, Machinations isn’t just visual programming. It’s about working with resources, which remind me of more physical electronic devices or conveyor belts in games like Factiorio.
One of the goals of Machinations is to give standardized language and tool into the hands of game designers, to simulate and balance complex player’s behaviour. Honestly, I don’t think that Machinations is the best solution for it. I don’t think that there is one universal tool or process, how to do that. For me is game design about using a wide range of available methods and having knowledge, which to use when. As Excel sheet is on one side universal for storing and working with data, knowing a basics of programming in regular programming language is a universal skill which opens you new opportunities (what about programming your own game on Game Jam?). And Machinations are somewhere there too. It’s worth trying it. Maybe you will be solving problem, where using Machinations will be the best choice.
Recommended videos when you want to give it a try: