If I am not mistaken Lightable uses it as well. There is also a plug in for it which helps with the ECS.
Hope that helps. Thomas On Wednesday, 16 August 2017 02:52:38 UTC+2, Didier wrote: > > I recently stumbled upon the entity-component-system design pattern which > is popular in game engine design: > https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80%93system, > and really liked what I saw, thought it could be a good fit for Clojure. > > Basically, it has three concepts: > > 1) Components are pure data grouped together as per a given domain. In a > game engine that would be for example the 3D positional data related to > positioning of objects in the 3D scene. So one component would be > PositionComponent and it would have :X, :Y. > > 2) Entities are collections of Components with a unique ID. > > 3) Systems are processing functions that take an entity, transforming > their components' data, or performing side effects from them. > > Generally, in games, they inverse the entities, so instead of having > entities contain components, they have components stored in an array with > the index being the entity ID, and another array which contains the set of > components for the entity at that index. All of this is kept track of by a > world container. > > (def world > {:entities [] > :comp1 [] > :comp2 [] > ...}) > > > So say you want to create an entity which is composed of comp1 and comp2, > you would just add to the world :entities at index 0 a set #{:comp1 > :comp2}, and to the world :comp1 and :comp2 vectors at index 0 an initial > component1 and component2 data structure. In games, for performance, they > use a bitmask instead of a set for the entry of :entities. > > > I'm not sure this structure is necessary if trying to use the pattern not > for game, but it doesn't hurt either I think. > > What I like about this, is I'm thinking its possible to use it to do > data-driven functional object modeling in Clojure. A problem I face, and I > feel other faces in Clojure, is how do you model entities without OOP? I > find this creates a kind of OO that is functional and data driven. > > You would spec a bunch of component, they're pure data. Then you'd define > systems (aka functions) which take an entity, and operate on the entity's > components (aka its data). At first glance, this appears to just be OOP, > but there's no inheritance here, and functions that operate or related data > are decoupled from the data. Systems are implicitly mapped to components, > based on what they work on. So you can extend all entities with more > functionality easily. You can also create entities from components on the > fly. > > On second glance, I wonder what's different about this from just functions > operating over data. I think its just a more rigid means to do so when you > need the concept of entities. In a way, entities act as a class, in that > they're a template of data. A system works over that template. > > Has anyone experimented with this in Clojure? > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
