Legend of Grimrock II: Refactoring the Object System

In the first of what we hope will be many developer blog updates for Legend of Grimrock II, the team at Almost Human discusses the object model they used in the original title and the transition they’re making to a component based object system in the dungeon crawler sequel. Modders, listen in:

Another classic problem is fitting new features to the class hierarchy. Consider, for example, the Decoration class that was used in Grimrock to implement decorative objects that have no gameplay functionality. The class was used for anything ranging from wall chains to statues. But what if we need an animated statue? Should we add a new class AnimatedDecoration (adding redundant code), or add support for animations to the Decoration class (bloating all decoration instances that do not need animation support)? The problem gets even worse, if we happened to need a statue with animations and a continuous humming sound.

The final nail to the coffin of class hierarchies is rigidity. The features of entities are hardcoded into the classes. But there are dynamic conditions such as being frozen, burning or poisoned that are hard to implement using this model. Basically adding and removing these features need to be solved in a custom way for each class that need them.

Regardless of these problems, the class based system worked relatively well for the first Grimrock, mainly because there was a relatively small set of object types and we knew pretty early what we needed. However, with Grimrock 2 we are planning to have a larger variety of objects and therefore we need to be able to quickly prototype new kinds of objects. With these requirements the class system begins to fall apart.

Luckily there is another kind of object model which has gotten pretty popular in game developer circles because it happens to solve all these problems neatly. It is the component based object system. With this system all objects are made of a number of components. Ideally each component implements a single thing and these things would not overlap. The components themselves are quite simple but the complexity arises when these components are combined. For example, the animated statue with sound would be made by combining Model, Animation and Sound components together.

For the past week I have been going through the existing classes in Grimrock and rewriting them with components (btw. this is one of the changes that would not have been possible if we were making a DLC). There is still work left but the codebase is already looking a lot cleaner. And we have already implemented some new objects, bridges over chasms to give you an example, that would have been messy to do with the old system.