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.
signature.asc
Description: PGP signature
