Mixins in game development

Programmers tend to think in the Object Oriented Programming paradigm all the time. We create complex class hiercharies that describe every single entity on the game. Thats what we learn at school, we are programmed (deeply into our firmware) to do that, but there is a whole world of different pradigms and approaches we can use, and the scripting languages are bringing the dynamic style into the game.

Functional programming can be great for game scripting, Lua has beeen a very popular game scripting language for a very long time, and a bunch of game engines uses it (including CryEngine 2.0 and Gamebryo LightSpeed). The ability to attach properties and functions into an object at runtime, for example, is incredibly useful to create high level game logic and even artificial intelligence.

We can talk about dynamic languajes and their benefts here, but I want t focus on Mixins as the modern approach to game entity description:

Mixins are chunks of functionability that can be applied to game objects. You can think of them as little pieces (building blocks) that you use to create a complex game entity. The most basic mixin every game entity is the entity’s transform which defines its position, rotation and scale. Each game engine implements entity’s transform in a different way, but the concept is the same.

Mixin complexity can vary from a simple mixin that lets you name an object (holds a string identifier), to very complex mixins like the one that provides characters the ability to use pathfinding to navigate the scene.

Each engine handles mixin agreggation in it’s own way, some engines even let you use multiple inheritance with mixins. Please note the difference between mixin inheritance and mixin agreggation:

Inheritance:

Mixins can be inherited

You can have mixin class hierarchies just the same way you can with normal classes

Aggregation:

Game objects agreggate a number of mixins to aquire their functionability

Mixins are agreggated (added to game objects) to create entity model descriptions

For example: A mixin called BoomerangTarget provides the ability to be the target of the player’s boomerang. BoomerangTarget is a child of another mixin called Target which provides the generic ability of being a target of a player’s weapon. At the same time, an Enemy agreggates the following mixins: Actor, BoomerangTarget, SwordTarget. Actor lets the enemy play animations, BoomerangTarget is the mixin desvribed above and SwordTarget provides the ability to be hit by a sword. SwordTarget mixin is also a child of Target, thus, both BoomerangTarget and SwordTarget share the basic functionability defined in the Target mixin.

A lot of game engines are using Mixins these days. Mixins have become the standard way to represent game object functionability.

Hi,Your article is interesting. Mixins sounds a good architecture for rapid prototyping. However, I do not understand how mixins' properties link to the C++ code. For example, a light mixin has ambient, diffuse and specular attributes, there is necessary some way for C++ programmer to use a light mixin to manipulate real graphical light data structure.