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.
