Skip to content
Carlos Javier Gutiérrez Sánchez edited this page Apr 16, 2019 · 79 revisions

Welcome to the Svelto.ECS wiki!

Please feel free to modify this wiki if you can add more value!

Svelto.ECS is the result of years of research and application of the SOLID principles in game developing. It's one of the many implementations of the ECS paradigm available for c# with some novel unique features, introduced to solve the intrinsic issues derived by the use of pattern itself.

This wiki is by no means a substitute of the many articles written on the http://www.sebaslab.com/ blog, but it complements them. Anyone who has a good understanding of svelto is free to contribute to it. This Wiki really needs your help to stay up to date

At Glance

the simplest way to check the fundamental features of Svelto.ECS is to download the Vanilla Example and the Mini-Examples

Unluckily there is no short way to understand the theory behind this code that could look simple, but confusing at the same time. So the only way to proceed is to spend some time reading my articles and trying out the examples provided.

Note: at any time the examples could be outdated compared to the latest code and the latest best practices.

Introduction

Lately I have been discussing Svelto.ECS extensively with several, more or less experienced, programmers. I gathered a lot of feedback and took a lot of notes that I will be using as starting point for my next articles where I will talk more about the theory and good practices. Just to give a little spoiler, I realized that the biggest obstacle that new coders face when starting using Svelto.ECS is the shift of programming paradigm. It's astonishing how much I have to write to explain the novel concepts introduced by Svelto.ECS compared to the small amount of code written to develop the framework. In fact, while the framework itself is very simple (and lightweight), learning how to move from the class inheritance heavy object oriented design or even the naive Unity components based design, to the "new" modular and decoupled design that Svelto.ECS forces to use, is what usually discourages people from adopting the framework.

Being the framework extensively used at Freejam, I also noticed that it's thanks to my continuous availability to explain the fundamental concepts that my colleagues have less of a hard time to get in to the flow. Although Svelto.ECS tries to be as rigid as possible, bad habits are hard to die, so users tend to abuse the little flexibility left to adapt the framework to the "old" paradigms they are comfortable with. This can result in a catastrophe due to misunderstandings or reinterpretation of the concepts that are behind the logic of the framework. That's why I am committed to write as many articles as possible, especially because I know that the ECS paradigm is the best solution I found so far to write efficient and maintainable code for large projects that are refactored and reshaped multiple times over the span of years and Robocraft as well as Cardlife are the existing proof of what I try to demonstrate.

I am not going to talk much about the theories behind the framework in this article, but I want to remind what took me to the path of ditching the use of an IoC Container and starting using exclusively the ECS framework: an IoC container is a very dangerous tool if used without Inversion of Control in mind. As you should have read from my previous articles, I differentiate between Inversion of Creation Control and Inversion of Flow Control. Inversion of Flow Control is basically the Hollywood principle "Don't call us, we will call you". This means that dependencies injected should never been used directly through public methods, in doing so you would just use an IoC container as a substitute of any other form of global injection like singletons. However, once an IoC container is used following the IoC principle, it mainly ends up in using repeatedly the Strategy Pattern to inject managers used only to register the entities to manage. In a real Inversion of Flow Control context, managers are always in charge of handle entities. Does it sounds like what the ECS pattern is about? It indeed does. From this reasoning I took the ECS pattern and evolved it into a rigid framework to the point it can be considered using it like adopting a new coding paradigm.

Compiler Directives

Composition Root

Svelto.ECS concepts

EntityStructs and EntityViewStructs

Why Implementors?

Svelto.ECS memory layout

How to design an Engine

Communication in Svelto.ECS

Write Svelto.ECS code at the speed of something fast with refactoring tools

Svelto.ECS and Unity

Svelto.ECS and GUI

Svelto.ECS and SOLID principles

Svelto.ECS and Unit tests

Svelto.ECS and FSM

Svelto.ECS real life best (and bad) practices

Unique Svelto ECS features

Update Svelto.ECS from a previous version

ExclusiveGroups to group Entities and manage states

Handle events in Svelto.ECS - Reactive Engines

ExclusiveGroups to handle the one entity case

Beyond StaticEntityDescriptor: polymorphic and dynamic EntityDescriptor

Sequencer

Example: Create a quest system with Svelto.ECS

FAQ (Tips & Tricks)

You can’t perform that action at this time.