Calum Mackervoy

The Commons is property that opens itself up to use by anyone, and which is owned and managed by the people who use it… So what would that mean when talking about game development?

For the past couple of years I’ve been working on the concept of a Games Commons, which is a new way of designing games that centres around flexibility, collaboration and the concept of Do-It-Together. These are games built around a creative community of hackers, like Wikipedia but for game content.

Our flagship project is a game about making and breaking social systems using creative powers. Social systems are made up of networked agents that are running AI scripts built by the player, and shared in common by the community. The design of the tools which enable the player to create and collaborate on such scripts is the subject of today’s article.

An AI agent in games is always essentially running an algorithm; a script directing their interface with the game world. The AI could be a peer of the human player, working with or against them. At the other extreme the agent may be there simply to decorate the world and make it believable. Usually a single game will employ several different kinds of AI, working towards different goals. It may even use different AI methods to achieve those goals. “Good game AI” is therefore not necessarily AI which is complicated; it’s AI which is appropriate to the objectives of the game designer with the agent that is deploying it.

In our case we need to design a data structure which can be used to represent an AI script, and the in-game tools which can be used by the player to create and share such scripts. As such, for now at least, we have chosen a “one size fits all” approach to AI: a single approach that is flexible enough to be used by our game for competitive agents as well as decorative ones.

For this purpose we have proposed using a data-driven version of Behaviour Trees, which are essentially flowcharts that direct the decisions to be made and the actions taken by an agent. A simple behaviour tree might feature the control node “is the agent hungry?”. If the agent is hungry, it would execute the action node: “eat something”. If the agent is not hungry, it would follow the other side of the tree.

The result of the above tree is that hunger is prioritised. If the agent is not hungry, then the flow continues. We can imagine a situation where (relieved of hunger) the agent is free to subsequently pursue a more whimsical chain of behaviours:

In the example above the agent will wander, and then shout. This branch of the tree finishes with a forget node, a special kind of control node for permanently modifying the behaviour tree itself. Execution of this node will destroy the wander-shout sub-branch, since the behaviour should be executed once - it was intended to be whimsical; a moment of madness. It also demonstrates that behaviour trees are modular; we can imagine the wander-shout branch being sufficient to define the entire behaviour tree of a raving lunatic, but for another agent we could plug in the same branch as just one aspect of their behaviour:

If the agent is drunk, they wander, shout and forget, before executing a new node, “learn”. If the player is not drunk, the chart moves on to the hunger condition from the first example. We can see here how the behaviours wander-shout-forget, and hunger-eat, have been packaged into branches. Once packaged, they can be re-used by their creator in the behaviour trees of different agents, and published online with some metadata about what the branch does. Once published online other players can import the behaviour into their own agents, which is already a powerful mechanism for building a games commons. Further from this we have the “learn” node, which with the right metadata, can use search parameters for the agent to discover a new drunken behaviour online from the games commons. The next time this tree executes and the agent is still drunk, he will have forgotten the wander-shout behaviour but may discover a behaviour someone has published on the games commons that causes him to fall over and begin singing.

The fact that the nodes on our behaviour trees are driven by data that can be published and then discovered at run time allows for the emergence of spontaneous and unique behaviour that isn’t conceivable in traditional game design. We can imagine a situation where our player’s agent, hitherto a hunter and a cave man, has a moment of inspiration which allows them to learn the carving of bones into religious statues, and after hunting they begin to perform increasingly elaborate religious ceremonies. We quickly begin to see the flexibility of the behaviour tree system, but this also provides a powerful illustration of what is a Games Commons: another player lovingly created the process of tribalistic religious ceremonies, and in the publishing opened the possibility of everyone in the community to discover and experience them. The game evolves, driven by the creativity of its player base.