A decision needed to be made, either tone down ambitions or take on the challenge of developing more scalable technology that can support our research projects and is in line with Artemis' requirements. Given the unique opportunity, the latter was selected which is not a challenge we take on lightly.

The more ambitious the project, the less success is guaranteed. It will be hard and before all problems have been solved, many failures and retries will happen. In research, we acknowledge and embrace this fact. Many old questions and their answers need to be revisited to ensure they are in line with our goals. If not, we need to get better answers.

Philosophy

Software development, in general, has its roots in the single-core hardware era. Support for multiple cores is often added purposefully and as an afterthought, not with scalability in mind.

The main challenge for writing any non-trivial software lies in how to do “complexity partitioning”. Software design quickly becomes too complicated for a single human mind to fathom in its entirety. So partitioning is required to either solve parts in sequence or apply multiple minds on separate parts in parallel, then hopefully integrate these parts into a working whole. Much of the software industry is focussing on this.

The essence of any software, however, is very clear:

A popular way of “partitioning” in the past 25+ years has been “Object-Oriented Programming” (OOP). It takes how people perceive their environment and projects it onto software design. It assumes there is one, fixed relationship between data and processing set at compile time. Intuitive for the human programmer, but not great for performance and scalability.

Including influences from multiple industries, the Melba team set out to use a different “complexity partitioning” better suited for our goals and the software reality of today’s multi- and many-core processing hardware. Melba is targeting an architecture that could support more complex simulation-driven systems, through emergent behaviour from the interaction of smaller parts.

A different partitioning

Melba’s way of partitioning is to separate data from processing and relate them only when required for the duration of a processing step (data-A → processing → data-B). This way any data can be input for any processing, and different processes do not need to know about each other. Communication between processing steps is always through data exchange, each process accesses a database independently. A processing context is always local, which is great for scalability. This is the essence of Data-Oriented Programming (DOP).

Combining this with an inherently multi-threaded processing approach provides hardware-performance scalability as well. Melba’s threading strategy is completely lock-free. These are important concepts at the core of Melba.

Melba features an “Entity Component System” (ECS) where, during every simulation step, systems run for entities to update data in components. All available cores are applied for this always. It is the system programmer’s task to implement algorithms in a parallel-friendly way.

Architecture

While a fresh start sounds great, in reality, any new effort builds on top of earlier efforts. To make improvements, it is good to be able to revert decisions from the past, that made sense for circumstances at that time, but no longer do for Artemis. It is vital to select the right amount of rolling back to create a balanced combination of both introducing improvements and, at the same time, still benefiting from existing functionality.

As an example, the Melba team is rather small. We aim to stay relatively small to remain flexible. A small team also means being thoughtful in where to invest efforts. The most gain is to be had from a solid core architecture based on sound priorities.

It also means a custom physics implementation, for example, would not have a high priority right now. Good solutions already exist. As existing libraries are often not designed with (scalable) parallel processing in mind, what is required is a way to enable the integration of existing libraries without interfering with Melba's core concepts.

Another example is resource allocation. For ECS, the default is to do one processing step for many data items (DOP, non-interleaved components) versus many operations for one data item (OOP, interleaved object members). ECS-component memory is owned by the ECS kernel that also controls its lifetime. In OOP, however, Object data members are part of the object and lifetime is linked to an object instance.

Melba does support STL, but mixing contradicting design philosophies can be a precarious undertaking.

After properly addressing this intersection where different worlds meet and introducing some guidelines for best ECS practices, system implementations now fully benefit from both existing 3rd party libraries and Melba’s ECS foundations.

Scalability

Larger game environments, in higher detail, with more interactive content, is many gamers’ wish. Still, with increasing hardware capabilities, primarily visual detail has substantially improved. Environment size and interaction detail have remained relatively stagnant in comparison. Combining larger environments, greater detail and more interaction is widely regarded as unfeasible.

Example streaming AOI consisting of parts in hierarchical partitioning

AOI in partitioned space

AOI changes between sim-steps

A short trip to the more abstract...

If we recognise that for an individual’s (user) context (environment), not the entire scope (world) is required or not at full detail, we can focus on the changes of that reduced context over time. It does mean the available environment of that user is changing continuously since it needs to “stream in/out” parts of the world.

Let’s say at any moment, a user’s environment is described by a “collection of parts” called an “Area Of Interest” (AOI). In simple terms, as the user moves through the world, the number of objects the user can both see and interact with changes constantly. The challenge is to then maintain a relevant AOI that describes the environment for the current but changing circumstances of a user.

In Melba’s case, these “parts” are ECS-entities and the changing circumstances could include the user’s avatar position, network conditions, changes in the virtual environment, hardware capabilities or any other property. In every simulation step, systems update the user’s AOI that describes the environment for the user. It is a constantly optimised, tailored “map” specific for that user. This way, Melba aims to conceptually decouple the entirety of the world from the subset relevant to an individual user.

It is tempting to think of the AOI as a collection of “things” related spatially. However, the concept is particularly powerful when applied to any collection assembled based on “metrics” that determine in/out of the AOI. Not just a distance larger/smaller than a radius.

This approach can be applied to elements of a user’s environment separately, using different appropriate metrics to specify what is part of an AOI. All AOIs combined describe the current environment for the user.

Changes in the AOIs should be small enough to be absorbed in time for subsequent simulation step updates, which can be regulated by increasing/decreasing simulation detail.

Summary

Artemis' goals reflect on research and engine-tech requirements, which in turn reflect on the team required to work on Melba.

The Melba team is attempting a balancing act between new ideas and proven solutions. Working on new technology always sounds nice but whether that is truly the case depends very much on your personal definition of “new”. This can be frustrating for many or a delight for others. For us, it means nothing can be taken for granted.

Melba Engine

Data-Oriented architecture (ECS)

• Separate data from processing.

• Processing only knows about its input and output data.

Data-driven pipelines and workflow

• Reduce manual steps.

• Prevent the introduction of editors where possible.

• Maintain data-oriented working.

Software designs excelling in simplicity

• More complex is not better, it's a sign to rethink.

• Prevent case by case, purpose-specific solutions.

Simulation-based systems

• Emergent behaviour of many simulation systems working in concord to provide the whole.

Melba Team

Small

• We pick up unfamiliar tasks, learn new skills, unlearn bad habits, and are always eager to help each other out.

Solution rather than creation driven

• We happily abandon a month’s work for a better solution from a teammate.

Ability for abstract reasoning

• We resist going depth-first by default and take our time identifying the right approach first.

Outside the box thinking

• When stuck, we zoom out, increase our scope and double-check assumptions.

Highly motivated by the project

• Working on a challenging project to allow huge, living worlds that feel real is our long-time ambition.