Melba Philosophy and Architecture — or why we are building a new engine
July 18, 2022 technology
Everything we do at PP, ultimately serves one goal; The Artemis platform. It starts at research, goes through several stages of tech maturity and when viable, is integrated in production.
PP has ambitious goals for Artemis:
1. A true earth-sized, richly detailed environment2. A breathing, living world that feels real & has genuine interactivity3. Share this world with many thousands of users
These three pose our main research challenges. Nothing new, rather familiar wishes. New is the opportunity to genuinely take them on with a fresh perspective and a minimum of legacy considerations.
One of our Applied Research projects is dedicated to engine-tech innovations to support research projects and ultimately Artemis. The Tech was named “Melba”, to celebrate someone who worked on pioneering projects. The Melba-team strongly believes it starts with a simulation minded approach.
To paraphrase Walt Disney:
"not to duplicate reality, rather to use as a foundation for convincing fantasy"
The attribute all 3 goals have in common is “scaling up”. It requires a data-driven approach. Data-driven pipelines have a profound impact on workflow. Besides technical challenges, there are also “way of working” challenges. For example, populating an earth-size environment without hiring a thousand artists.
We have already discovered the answer for the first research question; “how to create a huge, high fidelity environment on-demand?”
Our solution is combining “streaming hierarchical (space) partitioning” with “Machine Learning Agents” running on the user’s system (see patent application). It introduced the first major workflow change. How to design an environment with no map or level to work on?
To prove the solution, the “Prologue” tech demo was created. During its development, we solved many integration challenges and learned many things. Amongst them, that available engine-tech does not match our requirements very well.
All engines make assumptions about their use, the kind of games a developer wants to create and how. That is the added value of an engine. Functionality shared between different developments so your project can benefit. However, if your requirements differ too much from the assumptions made by the engine, your development will not be helped but rather be handicapped.
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 different approach is the whole point of why Melba is developed.
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.
For this people who are motivated by "solving" rather than "creating" are required.
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:
data-A → processing → data-B
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.
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.
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.
The challenge is to maintain a relevant AOI that describes the environment for the changing circumstances of a user
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.
The challenge, with any scalable design, is to identify the single local construct, in both data and processing, that can be used to describe the whole.
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.
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.
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.
Emergent behaviour of many simulation systems working in concord to provide the whole.
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.