Functions and the Function Library - makingthematrix/gailibrary GitHub Wiki

In the context of cellular automata functions working on cells are called „roles”. But I thought it might be a bit misleading – in computer games the term „role” may be used to describe other things, like for example NPCs may have different „roles”. So I decided to stick with Functions, because even though they’re really data structures, most of the time the only important field in the structure is the function itself.

struct Function {
	id: FunctionId,
	dominion: Vector<CellTypeId> // cell types this function works on
	requires: Vector<ValueId> // a list of values which are required for the function to work
	modifies: Vector<ValueId> // a list of values created or modified by the function
	f: (Cell) => Value
}

The Function is applied to the Cell and creates one ore more new entries in the results. Through the cell the function has access to the neighboring cells, and to their neighbors, and so on (although, idiomatically, only one step access should be allowed). The function (f) itself might be either a Rust function, or a binding to code written in another language. I think mainly about providing API for Lua, as it is one of the most popular scripting languages for computer games, but in the future it could be as well for Scala.

The FunctionLibrary is a map of FunctionIds to Functions. The user may register a new function by simply adding it to the map under a unique id. After I wrote the example use case for GAI it became pretty clear to me that a lot of these functions written by GAI users would be very similar to each other, like, for example "find where to move now in order to see the player", or "find where to move in order to hid from the player". If your game is some sort of a shooter, you're probably going to use a function like this. So, apart form the FunctionLibrary holding the functions ready to be used, GAI should also have a catalogue of more generic functions and function builders: functions which will contain common logic and will generate more specialized Functions, based on arguments, such as the map and the visibility graph. If written properly, their usage in the code might be as easy as passing the names of cells as parameters. For example, the code of the "player_visible" function can be already in the catalogue and all the user's got to do is to specify what is the id of the player, the NPC, and the graphs.

A note for the future development: A Function should also be able to delete a field from the cell. An additional list of toDelete ids in the cell, perhaps? It would be possible only to delete fields which were dynamically created before, not the ones defined in the CellType.

Cells and values <- | -> lazy vals