-
-
Notifications
You must be signed in to change notification settings - Fork 96
Old Wiki, Svelto 1.x and 2.x
Warning: Since Svelto ECS 3.0 will be soon out of beta, this wiki is mostly outdated. I will not find the time to personally update it any time soon, so your main references must be the Svelto Miniexamples, the Svelto.ECS tests, my blog HTTPs://sebaslab.com and obviously the Discord channel for direct support https://discord.gg/3qAdjDb. 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
the simplest way to check the fundamental features of Svelto.ECS is to download 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.
During the last years 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.
Before to start: Remember this wiki alone won't be sufficient to understand Svelto ECS, please research using all the resources available from https://github.com/sebas77/Svelto.ECS/blob/master/README.md
FAQ (Tips & Tricks)
Side notes: