Hello Fellows,
I am new to this forum, I just registered today, and I found it because I recently had sleepless nights while getting my head around entity systems.
So I was searching the web about more information and hopefully some code to look at, which finally got me to Terasology.
While there are plenty of dev blogs talking about the topic, it seems to be hard to find publicly available implementations which are advanced.
Thus I want to thank all developers involved to share the Terasology architecture on github.
While I just recently started to understand, I see more and more how big the potential benefits of entity systems could be.
And I fail to find any real drawbacks, in theory. (Except human thinking which always wants to explain "things" as "objects")
However I did also not found many success stories where this approach is being used (officially) for really advanced games.
Maybe you know some more I could take a look at?
However Terasology looks great even if it still lacks content, but if I look at the code it seems to be quite elegant and I assume that adding content is even easy at this point.
But to get there it took 5 years of development.
By the way: Happy Birthday and kudos!
So I wonder if entity systems are specific to MMOG or would you suggest to use this approach in a wider scope for any kind of "complex game with many features"?
Because theoretically this seems to make a lot of sense at least to me...
I totally fancy with entity systems right now and I am about to convince my team mates to switch our programming paradigm to ECS/CES for the next game, even if it will be just a simulation game which does not plan to have a multiplayer mode.
My biggest fear is, that I could do something wrong, which finally just costs more time, in case we go fully in this direction.
Thus I would like to ask you what you think about in which scope entity systems are useful?
Is it sane to aim to make (complex/feature rich/simulation) games in general using this approach?
Or could it easily become a terrible development time sink which might be quite risky for a small dev team?
Thanks a lot for input on this matter.
Kind Regards,
Stefan
PS: I hope this is the correct place to create a new thread like this, if not, I am sorry in advance for doing it wrong and please move it where it should be.
Although I'm not an expert on the field of ECS I'd like to throw in my two cents on this topic. First: your impression is right. Working with the system and adding new content is quite simple, at least once you've got used to the ECS-way of thinking. We recently developed a model for dynamically growing cities during Google Summer of Code, which worked out well with the entity system. From this perspective, I'd say that an ECS approach would be feasible for a simulation game - having a multiplayer or not does not matter.
However, as already said, getting used to the "new" way of thinking may take some time. Naturally, with the domain we are settled in, many MC modders approach things differently, and "misuse" the ECS. It may take some dedication and "educational work" to teach your team members how to utilize it best.
I hope that helps for a start, feel free to ask more questions
Doh, I thought I had replied to this earlier! Had it open in a tab a ways back in my browser, I must have written at least a partial post then forgotten to submit it
Thanks for the birthday wishes @v0id ! Yes we've been at this for a while, and there is a lot of untapped potential with entity systems. It is especially useful when it comes to making things extensible, like with Terasology's module system. Applying content developed one place to something completely different elsewhere is super easy.
On drawbacks it can take a little bit of time and brain adjustment to get used to the paradigm, sometimes that can scare off new contributors in an open project like ours. It may be overkill for very simple and shallow games, especially those not meant to be changed much over time, by players or devs. And finally performance may become a problem as you increase the number of entities - there are ways to mitigate that and I have one concept thread up on the topic. Our main architect @Immortius is working on the next iteration of the entity system with more features and performance friendly aspects.
As for whether you should consider it even for a single player game then it would help to know a bit more about it to advise more closely, but probably it would be a good option.
Other advanced implementations of an entity system in a game - I haven't gone looking, but imagine there are a few. Might not be a ton just yet though. I often recommend t-machine's blog for entity system stuff, maybe he has some links.
Hah, now that I got a reply, the notification for this somehow ended up in the spam filter. @Skaldarnar@Cervator
Thanks a lot for your answers.
I was worried, if I should have better posted this into "General & Off-Topic" after seeing this forum is mainly for active development on Terasology and not for discussions like this.
Yea I guess as most guys who stumble upon Entity Systems I wanted to do things better in the next game (engine) and did run into problems regarding deep hierarchies or oddities with too tight coupled components in component based approaches (eg. Unity) in the past.
So I researched a lot on the topic of game dev and finally ended up on Adam Martins blog, which made big promises and I have literally "eaten" all of his blog posts on this topic.
First I even thought "This sounds too good to be true", so I took affords to prove it wrong by starting to make an own Entity System (as others did I guess) and see what it does.
And surprisingly I failed to prove any of his points wrong and was suddenly confronted with a new programming paradigm which seems to have a lot potential to do quite some things better than ever before (which caused the sleepless nights ).
While Adam Martin and others cover quite detailed how Entities work (and this part made a lot of sense to me).
I did miss elegant examples on how to implement the "Systems" part and especially an efficient and loose coupled approach for inter system communication other than by adding, removing or modifying components.
And this brought me after some deeper research to the Terasology engine, which did finally something on this matter which seemed more sane to me in large scales than other approaches I did see before
(And yes I took a quick look at almost all the links on t-machines's blog and on frameworks like Artemis ECS(ODB), Cup Cake, Entitas, (X)Ember, ...)
But still it is embarrassing to see only so few implementations for more complex advanced games (not just smaller mobile games).
Despite the big potential not much scientific work on the topic exist at all.
It seems even likely that certain bigger studios use entity systems since quite some time now.
I even start to think this pattern should rather be taught to computer science and software engineering students on universities; clearly something which should be better researched than it is right now.
Normally when there is any great approach out there I can normally type it in google scholar and find a lot papers on topic, but somehow for Entity Systems they are rare.
Do you have any idea why this is, why entity systems are not much researched (yet), given they are so promising on the other hand?
Meanwhile I was able to fully convince my mates to go this way, simply because of all the facts and since we are a small indie dev team, it is easier to come up with innovative ideas.
I realize there are quite many ways to use the ECS pattern in concrete games, but I think there must be kind of a "Blueprint" that works "good" for almost any more complex game, but there is not much work around this on the web (as far as we could find).
In contrast to Terasology we work with a different focus and in a different programming language (C#) but all this should not change the general approaches behind.
Thus I am very interested in any publicly available (scientific) work on the ECS topic.
Btw. a week ago we found some recent work (the only recent scientific work we could find) which I like a lot and fancy with the shown approach. Maybe also interesting for you?
(Well the direct coupling of one systems output to another might not be the best solution, but this could be easily extended with an event queue like in your engine. However the gain in "outer" parallelism seems great to me.)
If you know additional good in depth papers or articles/blogs please let me know.
Because now that we want to go this route, we would like to do it right
This is going to be theorycrafting with very little evidence, but I suspect there are just so many languages, tools, libraries, and paradigms these days. Every other week some new language comes out that's tailored for something specific. Back when Object Oriented Programming became a thing entire languages were made to follow it (taking years) - that was a big deal. Entity systems? We just cram them into a corner of some existing language that can already be used in a dozen different ways, but probably most favor OOP. I kinda wonder if any new languages have popped up that favor entity systems - maybe some of the ones that make big deals out of traits and other cross-cutting stuff like that.
If you start game dev these days you likely hop on Unity, Unreal, jMonkeyEngine, LibGDX, and so on. Everything is so much easier and you have to think less about the deep architectural topics. The few that do end up doing more creative stuff end up blogging about it like Adam Martin, some building the tools like Artemis or indeed our entity system. I just think overall that's a smaller field since the easy typical stuff is so accessible, and there is just so much.
Maybe Gestalt will become one cool new game dev middleware suite and grow over the next few years, with a few competitors, and the entity system field will finally mature and become popular. Who knows. What it does seem like is that we're part of the process and putting together the kind of early research and implementations that'll help determine how well all that goes. So that's kinda cool.
Thanks for the discussion and links! Will be very interesting to follow this over the coming time
I think part of the reason that entity systems aren't taught is that outside of games or some fairly involved simulation type projects, more traditional programming paradigms are generally suitable. The Entity System approach is suitable for... large, heterogeneous environments where there are common behaviors but mixed in many ways. So for many games this is great - you have lots of things that need to be rendered, or collide, or make sounds, or move around, but individual objects may only need to do some of those things in a variety of different combinations. But it is difficult finding other use cases. Even if you look at, say, Facebook data which has information on people and messages and various relationships between all these things - NoSQL style structure - there isn't necessarily a lot of behavior to drive off of that. And many business systems are much more homogeneous, with a small set of objects handled in a very straight forward way. And even where you have projects that could gain benefit from Entity Systems you would probably have trouble finding people with the skills to use them, especially given the lack of standard implementations. Maybe a bit of a chicken and egg issue though.
Within games... I'm pretty sure entity systems and component systems and similar probably appear in all sorts of games, going back a long time, but probably not labelled as such. My understanding (based on what has been gleaned from the discovered source code) is that the engine for Thief 1 + 2 + System System 2 is entity based in some way for instance. And that is an engine that dates back to 1998. Amnesia uses an entity system (I recall reading a dev blog about this, but cannot find it right now sorry), and that worked well for it. Unity... obviously supports most of the behaviors of an entity system, albeit without the benefits of moving code out of components. Although how many games take full advantage of this, dunno. Certainly even more games have component based subsystems for specific use cases - Unreal Engine 3 for instance.
You do need to reach a reasonable degree of complexity to benefit from entity systems - Minesweeper... not so much. I'm pretty sure any RTS or FPS would be complex enough though. I also feel a lot of the benefit comes from how well entity systems help support non-programmer work as well. As a result of objects being configurations of standard components, level editing, creature design, and more can leverage the ES.
Hello again Immortius and Cervator (+ Who else reads this),
Thanks a lot for all your invaluable input on the topic and sorry for the late reply but I had some busy days[*] and didn't found time earlier.
I had quite some workload for a patch last week, followed by me organizing my own birthday party, celebrating quite intense and dinking too much and getting sober again and concluded by the need to cleanup all the mess and taking another evening to recover
Yea I did quite some research because I got pretty excited about Entity Systems and not only about how they are used already but also about some seemingly yet unrevealed potential.
However I have absolutely no experience with them unlike you guys
Even if this tutorial is a bit broad for one who is looking for some packed facts on Entity Systems, on a first glance it seems clearly worth a look and I am well disposed to find some interesting ideas.
Thanks for this link.
This is going to be theorycrafting with very little evidence, but I suspect there are just so many languages, tools, libraries, and paradigms these days. Every other week some new language comes out that's tailored for something specific. Back when Object Oriented Programming became a thing entire languages were made to follow it (taking years) - that was a big deal. Entity systems? We just cram them into a corner of some existing language that can already be used in a dozen different ways, but probably most favor OOP. I kinda wonder if any new languages have popped up that favor entity systems - maybe some of the ones that make big deals out of traits and other cross-cutting stuff like that.
I like some random "theorycrafting", especially then when evidence seems hard to find
In fact I wanted to answer this thread yesterday but thought I am talking too much with not enough evidence and I am going way too far for one who just recently started to dive into the topic and thus canceled my reply.
But now I thought: why not?
Let's be a bit crazy and talk about unripe fruits and in worst or best case I can learn where I am thinking wrong
So please take everything I say from now as grain of salt as I am still driving my head through it.
I am not aware that there would be any language support for ECS, while I think this would be a very good idea.
But you are right, there are quite many approaches and choices that one could probably simply bypass Entity Systems without ever looking into them.
There are multiple aspect oriented approaches and they can do a couple of things which Entity Systems can but not in the same elegant way.
And there are languages which support mixins eg. traits which serve to some extent what ECS allow and one could see ECS as a very clever implementation of mixins but I think they are by far more than this.
I say this because by putting multiple data fields into component type (which is a name), we give them or imply a (partial) semantic which can be specified elsewhere (in systems) and mixed, matched and replaced in many ways.
And afaik normal mixins are not even available in most modern OOP languages, which are suitable for games[*0] (well D does support mixins, but will it hit the main stream in near future?) and the more elegant solutions for mixins seem to be only present in scripting and functional programming languages, which are all no traditional game developing languages, but we want to use decent existing frameworks which support us rather than implementing all the basics ourself in any esoteric language and don't we want an efficient compiler/runtime?
Another point is for me Entity Systems seem quite near to functional programming but this inside OOP.
Because for my understanding a system can be described as a function (which could have state as its also an object) that has its own arguments and its return values (err out arguments) stored on entities and retrieves them by specifying/querying them as formal parameters (at least some ES implementations make this quite explicit).
In addition such function just needs to specify in a formal way when to run in terms of being called and this is why we need a tick and/or events/messages as well.
In this meaning one could see Entity Systems as a paradigm to introduce a clever description of "state in entities" to functional programming.
There is not only a few people who say that the future will lead us to functional programming (again), because it works better with upcoming computer architectures of the next decades that wont be much faster but will have more cores to use. Unfortunately this combined with comperably slow main memory and small but faster caches to fix the gap [*1] but it's not easy to serve them efficiently in traditional OOP as you surely know.
Functional programming is immutable by nature and embarrassingly parallel and avoids many of todays issues but they are also stateless, harder to understand and miss many nifty stateful tools and data structures like efficient hash maps on the other hand.
And yes there is also the idea of Actors (eg. Erlang/Elixir) and Communicating Sequential Processes (eg. Go).
For me ECS look like they could well provide a quite valid alternative or at least addition to that kind of thinking as they seem to allow to combine stateful implementations which can easily run in parallel on multiple cores, while supporting mixins/traits in a very elegant way and this can be done very cache efficient (well in garbage collected languages it's hard to be assured by the programmer, but maybe not in all future [*2]).
And where ever one does not need this flexibility or parallel performance can still use OOP and has thus best of both worlds.
So I see no reason why Entity Systems couldn't be an (OOP) language feature and I would really love to have that.
There are some CB and ECS purists writing that OOP is evil, but they often ignore that all known ECS (and most CB approaches) are written within OOP languages and that ECS is a very clever and loose coupled form of a strategy pattern (in GoF terms) which does simply favour composition over inheritence (as well in GoF terms) while still remaining in an OOP language.
Inheritance can make sense when there is a clear specialization rather than cross cutting concerns or when one want to make things rigid and enclosed on purpose or simply to save time where nothing will change in future, but we just like to use it way too much and where it makes no sense.
We know it should be used in a much smaller scope than it often is and we quite often face problems where we are better off to use composition over inheritance as much as we can,
and problems where this really becomes important are usually considered as the most complex and dynamic problems and thus those where research should focus on finding better solutions for.
For me ECS seems to give a pretty clever answer to how to get composition over inheritance done right.
Imo ECS could help to extent OOP as a new language feature to make it fit for the future rather than being an argument against OOP per se.
Another point is when we have all components in a data base for component types and we have systems which are interested in instances of these component types, then we can stop thinking about how to retrieve the required data to implement a feature out of a spaghetti, but instead just tell what we need and rather focus on implementing the feature.
(Though one might be not only interested in a set of component types, but also specific values or ranges on their data fields)
Also on this point I see still more unrevealed potential.
I think Entity Systems need to be flashed out even more than they are right now.
And only if it can be proven to work good in practise and more programmers are able to use them, only then they will get more research and a decent language support maybe one day.
However this seems a really hard mind blowing task and you guys did and are doing a marvelous job and I am happy to have the chance to learn from your work.
If you start game dev these days you likely hop on Unity, Unreal, jMonkeyEngine, LibGDX, and so on. Everything is so much easier and you have to think less about the deep architectural topics. The few that do end up doing more creative stuff end up blogging about it like Adam Martin, some building the tools like Artemis or indeed our entity system. I just think overall that's a smaller field since the easy typical stuff is so accessible, and there is just so much.
Well we are even working with Unity, but still want to use an Entity System (on the top).
At least when it comes to the gamestate and the gameplay elements.
Unity is a top rendering engine, but is it "compositon over inheritance" for game play done right?
I have some doubts and the ECS way (code in systems -> component data with implicit semantics) seems for me the better answer.
It might not be the answer to everything [*3], but a pretty good answer to many complex problems in games where you need flexibility, which seem to be harder to handle with other approaches.
I see a plenty of good reasons to be interested in Entity Systems unless someone shows me something better to handle complex dynamic problems efficiently.
All in all Entity Systems look like an "hot iron" which could use still some more smiths forging with it, but it seems it could get somewhere soon.
Maybe Gestalt will become one cool new game dev middleware suite and grow over the next few years, with a few competitors, and the entity system field will finally mature and become popular. Who knows. What it does seem like is that we're part of the process and putting together the kind of early research and implementations that'll help determine how well all that goes. So that's kinda cool.
Thanks for the discussion and links! Will be very interesting to follow this over the coming time
I think part of the reason that entity systems aren't taught is that outside of games or some fairly involved simulation type projects, more traditional programming paradigms are generally suitable. The Entity System approach is suitable for... large, heterogeneous environments where there are common behaviors but mixed in many ways. So for many games this is great - you have lots of things that need to be rendered, or collide, or make sounds, or move around, but individual objects may only need to do some of those things in a variety of different combinations. But it is difficult finding other use cases.
This is the obvious use case where we have some evidence that it applies well (also thanks to your work), but if we forget for a moment that it is an extremly hard task to build an ECS which works and scales well and that there are still performance issues and issues with human understanding (problems which can possibly addressed with further improvements in future), then I do not want to give up fully on the idea that it couldn't be more.
I mean what we get is a very transparent view to the application from an architectural standpoint, small and easy to maintain features, control over the order in which data is changed and who produces and consumes this data when.
Even if you look at, say, Facebook data which has information on people and messages and various relationships between all these things - NoSQL style structure - there isn't necessarily a lot of behavior to drive off of that. And many business systems are much more homogeneous, with a small set of objects handled in a very straight forward way.
So if we ask "Why not use ECS?" then it seems to me it is also hard to find proper counter arguments as well, except: "We not need to use them to implement this." but what if "this" needs to evolve or used in other places at a later point in time?
If I look at how diverse and manifoldy Facebook is, I have an hard time to believe that there aren't good use cases for Entity Systems.
And when we store all our components in a "database in code" while fully determine how these are stored (which does not necessarily need to be a classical RDBMS and not even by any means "relational"), what is then contrasting the idea of "NoSQL"?
I mean we write systems which can query for components in a database without the need to involve any SQL or standard DB approach and we might even use a data grid and organize all this in a distributed system.
Of course this goes now a bit too far, but since we are "theorycrafthing", I could ask: "Why not?"
(I know you mean it pragmatically and thus you are 100% right, but I just like to think loud about the "what if")
And even where you have projects that could gain benefit from Entity Systems you would probably have trouble finding people with the skills to use them, especially given the lack of standard implementations. Maybe a bit of a chicken and egg issue though.
At least for me it looks like that is the real problem, but while researching I found quite some people trying to push Entity Systems further and I was wondering why science is ignoring this so much.
Within games... I'm pretty sure entity systems and component systems and similar probably appear in all sorts of games, going back a long time, but probably not labelled as such. My understanding (based on what has been gleaned from the discovered source code) is that the engine for Thief 1 + 2 + System System 2 is entity based in some way for instance. And that is an engine that dates back to 1998. Amnesia uses an entity system (I recall reading a dev blog about this, but cannot find it right now sorry), and that worked well for it. Unity... obviously supports most of the behaviors of an entity system, albeit without the benefits of moving code out of components. Although how many games take full advantage of this, dunno. Certainly even more games have component based subsystems for specific use cases - Unreal Engine 3 for instance.
Even Amnesia? I had no idea
The Wikipedia article about ECS[*5] is mentioning some games and references some slides to approaches in the links.
But not all of the games listed move behavior out of components and this makes for me actually a big difference and the difference between a Component-based Approach (CB) and an Entity System(ES/ECS). Multiple things said before in this post would not apply or not apply to full extent to CB approaches.
https://en.wikipedia.org/wiki/Entity_component_system
About Thief I was not sure, but it looked like it could be an ES. However for spoiled eyes it looked so cumbersome to use, that I stopped trying to fully understand.
Well then there is Dungeon Siege also a CB approach which inspired Unity and others.
Only when it comes to Adam Martins work it talks about the separation of components and systems.
The finding that Starcraft might have been already a fully fleshed out ECS was new to me.
It would make a lot of sense from Warcraft towards WoW.
When code and components are not separated, the semantics implied by the presence of a component on an entity can not be partial in an elegant way. (without introducing additional systems holding behavior or less elegant inter component dependencies, so why not separating in first place).
So true, unless we would suddenly for no reason assume it would still remain in development and a crazy game designer wants it suddenly in 3D and real time, with a charcter that moves instead of a mouse, so he can retreat from explosions in time with different expanding explosion volumes, showed by differently coloured numbers, or what so ever to make it way more complicated ...
I'm pretty sure any RTS or FPS would be complex enough though. I also feel a lot of the benefit comes from how well entity systems help support non-programmer work as well. As a result of objects being configurations of standard components, level editing, creature design, and more can leverage the ES.
...and from having to do less actual (feature) programmer work once a good working architecture is in place
Thank you very much, this answer fits me well, since we are mainly insterested in RTS & Simulation style games and might play with some FPS elements but not too deeply.
So even if some more crazy ideas do not work out, it still should not go utterly wrong.
Thank you a lot for this sane, reflected and pragmatic answer.
(which is the only correct one if one ever wants to get anywhere in a timely manner, but I am still interested in "theorycrafting around")
Sorry for going a bit crazy with my reply, but I just wanted to share parts of my understanding why I think that the last page of the book about Entity Systems is not written anytime soon.
And I rather should start to get something implemented than throwing words around.
One more question out of curiosity which I couldn't clearly answer myself by reading around, but this time directly about Terasology:
From what I got from reading your wiki you are now focussing on making a flexible engine which supports many MC style mods/games.
But what happened to the original Idea about making one specific game "Terasology" so MC with some Dungeon Keeper & Dwarf Fortress? Is it still a thing?
Cheers and Thanks a lot for this great mind exchange
Posting primarily to let you know I just read that whole glorious thing! But I don't have anywhere near the spare brain cycles to really dig into it and come up with a worthy reply So much to do these days!
I do look forward to seeing the field develop and would love to try out Gestalt (with the next round of improvements ready) for an entirely new game. It is getting some more multi-threading capabilities and yeah that's where we need to move. I'm especially curious about the potential for more advanced AI via pondering things in parallel, but maybe that's less directly ES related.
As for Adam then yeah he has a lot to say about Unity, and not much of it positive, hehe. I did notice a tweet just earlier today seemingly alluding to finishing the post he talked about a year ago. So maybe that's it. Goal is posting it on his Patreon (first at least).
On reaching the complexity to justify an ES like this then yes, I like the added factor of making something extensible, which is one of the big things about Terasology We can do sooo much stuff now, it is quite wonderful to have such abilities.
As far as Dungeon Keeper and Dwarf Fortress go, yep, definitely still interested (at least I am and I know of several others). And really, those are covered by what we can support now. All that remains is adding more modules, logic systems, and content For instance over the summer one of our GSOC students wrote the DynamicCities module, which adds growing cities that simulate based on population count and so on. We just need to get the actually creatures added to make it more visible!
Haha Thanks!
Well I guess I will have to get myself through all the odds I am thinking about, unfortunately there are always other tasks to do, but I plan to dedicate some time into the topic in the near future to get some ideas tested.
When I get to anything useful I might come back to share it, because I find it a bit sad that there are so many good ideas out there but decent and complete ECS frameworks for games are still hard to find.
For getting your original game plans in code, I might be even able to help/contribute a bit once you get there, since I got some experience with certain game mechanics of DK like games and I would be curious how they translate into an entity system.
But I fear in a full 3D world it could easily become a bit cumbersome or clunky and it will be hard for the user to keep the vista and not get lost in the own mess he created. So this might require some break throughs in game design first
However I have a fulltime job and thus not too much time, but let me know when you get to tackle this part
This book-piece of yours definitely needs a tl;dr or a similar warning
Going through all the reference and hints will take me some more days, and I just finished reading through your post… At this time you are definitely more involved in this context than me. As you mentioned function programming, this presentation [1] by Michael Shaw came to my mind - it's not overly detailed, but may be an interesting read nonetheless.
Sorry for the wall of text, I just came up with random thoughts and then started to unroll this entire mess.
I'll try to be more brief from now but will likely fail
First I didn't liked your link, but not because of its content, but because of the terrible UX of this website.
I tried all potential mouse movements and pressed key up and key down and page up page down and then I started to read multiple slides in pure HTML code before I realized the javascript and figured right arrow is the only way to see the next slide
Indeed an interesting read and this approach looks very elegant.
I have unfortunately not too much experience with functional programming, at least not with Scala.
But as far as I know it doesn't lazy evaluate by default (unlike Haskell) so I guess the "serialized delta" of the state transition (next to external events) in the code example is actually the delta of all of the changes performed on data inside all entities that were updated in tick?
But this would mean it is essentially sending a snapshot of the entire primitive data changes which could become quite big in a large dynamic world, so that one likely need to apply additional interpolation on the clients to make that smooth [1].
However I think one can get quite far with this. It's very intersting there is a way to switch between mutable and immutable code that easy.
But with Entity systems there is choice either, the thing is that they allow state in a way that does not necessary destroy your attempts in being flexible while clean and support parallel programming and networking.
In an Entity System we could do quite similar, we are just not updating entity by entity but entity aspect by entity aspect (err system) while all the changes are done on the specific components each system needs.
Now we could run all systems without overlapping component types in parallel while those with overlaps can run sequential and get data flow programming (we could also lock if we would like to as we are flexible).
To get the deltas in the same way we would need to do some work in OOP though, so we would need to grab it behind setters on components to accumulate it in a buffer which needs to be send before external events.
However it should be also the possible to describe internal changes as external events as well which do then perform concrete changes and leave as much as possible to simulation on clients and if the internal simulation would be deterministic we not need direct deltas and thus these events could be rather small in total bandwidth [2].
But as said right now I not worry too much about multiplayer development even though its an interesting topic in general.
But the handling of aspects through systems querying and modifying certain component types is unique to ECS and something which does not contradict the functional approach and makes it easier to handle "state" elegantly.
While going through the slides I realized this game prototype looks quite similar to Terasology and one screenshot [3] even looked exactly like leaning quite exactly towards your original idea MC + DK & DF.
T-Machines first big (huge really) ECS article is out - although password protected with the password given for $4+ Patreon backers (he's looking for a better way to share the articles due to size vs limited formatting options on Patreon).
It looks pretty good and the approach is pretend-implementing a simple example without an ECS in Unity then updating it with an ECS instead. So sort of like converting legacy code to an ECS setup while still connecting to any good old stuff. Thought that might be interesting for you @v0id
I recently contacted him on reddit and he knew about Terasology Will point him to this thead if interested, otherwise I'll come up with some questions related to Scala dev
Hey are we about to create an Entity Systems Assoziation?
I was a bit disappointed with Adams article and feel like wanting to criticize parts of it.
Unity physics is not really good but for completely differnt reasons than pointed to (eg. it's non deterministic) but he blames it while using it in a wrong way and this is the one and only reason he needs this strange correction factor 1.1f times magnitude.
He should either use FixedUpdate to do own position updates directly in physics tick or he should let Unity physics (via RigidBody) drive the cubes by just specifying velocity outside physics tick, in either way the results would be much better (if not fully correct), but what is done there instead is prone to fail.
Then the other thing is the style of the article which is a bit confusing, the code is often unelegant and not formatted very well so it often spans multiple lines for a single line of code that could have been formatted and even the little bit of code the article contains is not very well done.
I mean things like
Code:
pos.x -= 2f * CreateScene.planeWidth / 2f;
make me just smile, but things like
Code:
_pooled_Cubes_disabled.RemoveAt( 0 );
make me cry.
(Ever seen a (De)Queue ADT??)
And why inconsistent coding/naming conventions everywhere?
There is unfortunately not much to be learned in this article which I didn't read elsewhere more consistently formalized.
At least there is hope it establishes a base for a second article which might enlighten us.
So let's not be picky and see we learned how to become engine agnostic.
I am looking forward (hoping) for a good (better) second article
Allowing myself a quick cross-post, I just noticed the announcement of SpatialOS going to public Alpha with backing from Google. And they are using an ECS to host MMO-scale worlds. Hmm!
SpacialOS looks quite interesting, let's see where it goes in the future. They mention workers for other platforms/languages coming soon, and I'd like to test it out in the future (waiting for more time to be available...). In the meantime, I'll keep the tab open to remember checking it out again
@v0id thanks for sharing your thoughts on Adams article. I was tempted to have a look myself, but decided against it after reading your comment. I feel that he often has a very negative attitude, and it feels like he's trying to just find the spots where things are not working as he wants them to. That put aside, he sometimes has some good hooks for further discussions...
