A while ago, I wrote a library called *brute *as an ECS library for Clojure + ClojureScript.
Articles: http://www.compoundtheory.com/category/brute/ Github: https://github.com/markmandel/brute https://github.com/markmandel/brute-play-pong Mark On 15 August 2017 at 18:49, James Reeves <ja...@booleanknot.com> wrote: > I wrote Ittyon <https://github.com/weavejester/ittyon> a little while > ago, which is a database partially inspired by the entity-component model, > but uses a more clojurey architecture. > > There are also experiments with trying to make rule systems like Clara > fast enough to use in games. > > On 16 August 2017 at 02:05, Jeaye <cont...@jeaye.com> wrote: > >> Alex Kehayias gave a talk about designing a functional game engine in >> ClojureScript, using components, here: https://www.youtube.com/watch? >> v=TW1ie0pIO_E I thought it was a superb talk. >> >> There's also Arcadia, here: https://github.com/arcadia-unity/Arcadia >> which wrap's Unity3D in Clojure, but Unity takes about the most imperative >> approach to components as possible. >> >> In general, and as Alex shows, the entity-component approach can work >> very well with game engines. The issues of coupling can either be tackled >> with explicit dependency declaration or by a more flexible async >> notification/inbox system. I haven't yet built something like this, though >> I'd like to, but, if/when I do, my design would be very much along the >> lines of Alex's. >> >> J >> >> On Tue, Aug 15, 2017 at 05:52:38PM -0700, 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. >> >> -- >> 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. >> > > > > -- > James Reeves > booleanknot.com > > -- > 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. > -- T: http://www.twitter.com/neurotic W: www.compoundtheory.com -- 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.
