Entity Components in the Vortex-Engine

Last week, we got to a point were we can drag and drop an MD2 file into the 3D view and it automatically instantiate an Entity representing the 3D model. Now, because MD2 models support keyframe animation, suppose we wanted to somehow provide a way for this model to be correctly animated…

The Problem

One way to go about adding animations would be to implement the MD2 keyframe logic inside the Entity class, so that I need only send an update message to the Entity and it will update the vertex data it holds.

Because I can also instantiate Entities from static OBJ files, it doesn’t make much sense for this logic to be part of the Entity. So what could we do then?

Well, again, we could create a sub-class of Entity with the logic that we need for the animation. The problem with this approach is that sooner rather than later, we will have a huge hierarchy of classes where we will need to constantly refactor and add intermediate super-classes in order to have Entities that share some behaviors (but not others) in a way that enables code reuse.

The Entity-Component-System Model

Wouldn’t it be nice if, instead of extending and inheriting code, I could somehow cherry-pick the properties and functionality that I want for my Entities from a set of prebuilt components? Not only could we build a set of off-the-shelf tested and reusable components that we could mix and match, but also, we would be favoring composition over inheritance, effectively eliminating the need for sub-classing altogether!

This is the main idea behind the Entity-Component-System architecture of modern Game Engines, and it has been the main focus of the work in the Engine this week.

The brand new Component architecture allows adding properties (and even behavior!) dynamically to Entities in a flexible way that prevents coupling and encourages code reuse. The idea behind is simple enough: components that are added to entities will get regular update() calls (once per frame) that can then be used to affect the Entity they are attached to or the world around them.

In the image above, the “Knight” Entity has a Md2 Animation Component. This component has its update() function set so that it takes care of updating the Entity’s vertex data according to the animation it’s playing. It can also expose, by means of the Inspector, an UI that the user can access to set the currently playing animation and its properties.

Native vs Scriptable Components

At this time, as the new Component concept is introduced, the only component that the Engine provides out of the box is the Md2 Animation Component. The idea from this point on, however, is for all extra functionality that affects Entities to be implemented as components.

I envision that we will end up supporting two types of components in the future: native components (developed in C, C++ and Objective-C against the Vortex API) and scripted components.

If you have been paying attention to the Editor screenshots I’ve been uploading, you will have noticed that since day one we have had a “scripting” tab sitting alongside the 3D View tab. This is because the idea of exposing the Engine through a scripting interface is something that I’ve been interested in for a very long time. With the Component API taking shape, I think that allowing components to be developed through a scripting language is going to be a feasible option that will open the door for implementing tonnes of new features.

There is still a lot of work ahead for both the Editor and the Engine, but I’m sure that the next version of Vortex, “V3”, is going to be the most significant major update within the 6+ years of the history of the Engine. Stay tuned for more!