January 20th, 2017


Moved onto the game planner this week and I’ve made some decent progress with designing how the whole thing might work. I’ve coded up a rough prototype in Python (about 1000 lines) to pry apart the model and see if there are any major issues with it. It roughly works as follows:

Choose regions, layouts, and basic features
These create various hard and soft constraints (e.g., a Rock Wall requires SMASH 1 tool)
Trace the network of regions from the start, if you encounter a constraint:
  Search through all mechanisms and implement one [this may require a chain of mechanisms]

A mechanism in this model is a building block of the game and will include a number of elements. For example there might be a basic smashy mechanism that includes: trees, sharpstone, grindstone, and workbench. Implementing the mechanism is a matter of ensuring all elements (e.g., a group of trees) appear in the game, somewhere before the mechanism is required. By designing a whole bunch of mechanisms and chaining them together I hope to have a flexible system for generating different kinds of areas and experiences. There are a lot of little questions which have arisen through the prototyping, and for now I’m mostly choosing the simplest answers. The thing that interests me the most about this method is that it can be improved over time, by decomposing mechanisms into smaller pieces, and adding more rules about how mechanisms interact or are chosen.

Here’s a little snap shot of a network my prototype was operating on. The features like “stone slug” and “iron ore” are selected by the planner, as a result of reacting to the “Clay Seam” constraint that requires DIG 2 to get through. This first pass, over the hard constraints, ensures that the player will always have the available materials they need. Further passes satisfy soft constraints, independently random elements, and so on.

Finally, here’s the system operating on a quest for an imaginary game that isn’t moonman. As the system steps through the nodes, it encounters a constraint called [letter], indicating that the player needs a letter to get through the city walls. A mechanism called mayor has [letter] as it’s output, and implementing it places the mayor feature in a suitable location. This is a very high-level of abstraction, where the planner only sees flavourless concepts like letter, miner, etc. In this imaginary game, the low-level system would need to understand these concepts at the gameplay level, by e.g., actually implementing a guard that stops the player and adding a mayor npc that gives the player a letter of passage. The constraints in Moonman will be simpler and more resource and combat-focussed than this example, but it’s interesting to see the flexibility of the approach.



That’s a super-neat way to test all the possible iterations, is it pretty standard or did you just invent that to satisfy the requirements of MM?


I haven’t seen this much in gamedev, but this kind of constraint solving would be used a lot in academic ai, robotics or scheduling theory. I hope it works out for the game!