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.

Reply via email to