Trouble understanding Grease while comparing to other entity systems

86 views
Skip to first unread message

Hemebond

unread,
Dec 15, 2011, 1:30:33 AM12/15/11
to Grease Users
Hi, I've been reading about entity and component-based systems for a
few days and trying to use Grease to make some simple things. I'm been
going through the Artemis (http://www.gamadu.com/artemis/) source and
demo games and found it very easy to understand what was going on. Now
I'm looking at Grease and it seems to do things very differently (to
most entity systems I've found)

Going through the Blasteroids it appears the worlds, not the entities,
contain the components. Instead entities just have properties. The
Blasteroids example (and tutorial) also seem to have the systems
inside the entities instead of separate.

My understanding of entity systems was that entities contain
components and then all logic and processing was contained in systems
that were called each tick.

Also, does Grease contain a sprite renderable? I couldn't find any
mention of one.

Thanks.

James

Casey Duncan

unread,
Dec 15, 2011, 12:14:09 PM12/15/11
to grease...@googlegroups.com
Grease takes a pretty strict interpretation of entity systems, and it
is different than other ones I have seen, by design. In a nutshell:

Entities are little more than typed identifiers. They contain no data,
however they are instances that can inherit methods, and they have an
api that allows entity-wise data access from components, as though the
components were part of the entity. This is just a facade for
convenience, however.

Components are basically like tables with entities as their keys. This
is intended to allow component data to be modified and queried in
batch which is often vastly more efficient than manipulating
individual entities. Components have no application logic.

Systems are behavioral aspects that apply to some or all entities in a
world. They generally do their work by querying and manipulating
entities. Systems are generally stateless, but may contained cached
data if needed (i.e. collision pairs).

I would consider grease in it's current state as a prototype of these
ideas. It trades data encapsulation for efficiency and flexibility,
and strongly encourages a composition-heavy application design as
opposed to inheritance, though it still supports inheritance between
entity classes.

Looking at Artemis, it looks quite similar to Grease, the major
difference I can see is that the components are configured via the
entities rather than via the world. Also the components seem to be
fixed classes, whereas in grease they are more like database tables
where the schemas can be specified declaratively. I think some of
those decisions may stem from the implementation language. In Java
doing something with that level of runtime dynamism would be pretty
complicated and likely awkward to use. In Grease things are bound
together by convention rather than strict typing, again I think this
reflects the choice of implementation language more than anything.

Currently there is no sprite renderer, though obviously one is needed.
The project is currently in hibernation while I've been fiddling
around with some other things. There's a chance I might yet revive it,
but I've kinda lost my enthusiasm for this sort of game development in
Python, unfortunately.

Thanks for writing, it's always good to hear from folks like yourself.

-Casey

hemebond

unread,
Dec 15, 2011, 4:55:35 PM12/15/11
to grease...@googlegroups.com
Hi, thanks for the great reply. I think the main part I'm having
trouble getting my head around is the world having all the components.

My understanding was that in an ES each entity contains the components
it needs and then systems iterate over the entities containing the
components the system manipulates. I'm able to follow that flow.

I've been reading the Grease source itself and I see that setting the
attribute e.g., self.position.blah, automatically adds the components
to the entity. Would that be correct?

I'll going to have another go at implementing some systems and components.

I hope you pick this up again, it's been very helpful to me. I reckon
if people contributed components and systems it could become a very
good game framework for newbie Python coders like myself.

Thanks.

James

Casey Duncan

unread,
Dec 15, 2011, 5:43:00 PM12/15/11
to grease...@googlegroups.com
I think you have picked up on a key difference between Grease and
other interpretations of enitity-component systems.

The main reason is that Grease wants to avoid iterating over entities
at all costs. Actually it wants to avoid iterating in python at all,
though the currently released implementation is not there yet. This is
made possible by keeping the component data in arrays and exposing an
api that automatically maps entities to their corresponding component
array elements. It is also allows systems to think about things at
different levels of abstraction.

For example, a "movement" system, (In grease parlance, a
EulerMovement) doesn't actually care about entities. It only cares
about position, velocity and possibly acceleration. The fact that
movements correspond to entities is irrelevant to the system, it just
wants to perform the integration math each time step. The Grease API
allows a system to simply "join" the components, thereby returning all
common elements in both the position and movement components, perform
a bulk operation that does the math, and update the position component
in bulk.

The same goes for rendering. The typical rendering logic wants to take
a big array of positions, map them into an array of vertices, map
texture coordinates based on some other info (i.e, sprite image, and
color), etc., and blast it out to the GPU. Some of that stuff might
not even change every frame, thus could be cached on the graphics card
anyhow. This is much easier and more efficient to do if the input data
is in simple contiguous arrays to begin with, rather than scattered
throughout the heap in a bunch of objects, or even in a complex array
of structs. The struct case is particularly difficult too because in
just about any game the entities all have different data attributes,
so trying to apply the same code across heterogenous entities that
contain their own data is complex at best, and certainly inefficient
due to the necessary abstractions, and lack of cpu cacheability.

It also allows for multiple instances of the same component. There is
nothing that says that an entity has only one position. If you require
more, you can simply add more position components with different names
and configure new systems to use them. Granted this is not a common
use case, but it creates some hopefully useful symmetry that prevents
having to rethink everything when odd requirements emerge later.

You are correct that setting the value of a component to an entity
also adds the entity to the component. I deliberately combined these
two actions for convenience, because I figured it made no sense to
split them. This seems quite complementary to how Artemis works. Given
a set of entities, you should also be able to set their component
values en masse, but that probably has limited usefulness since
setting a bunch to the same value is uncommon.

I wanted to make it easy to create new components and systems, and
hopefully be able to reuse and share them. Certainly they would be a
cool thing for other folks to contribute 8^)

-Casey

Reply all
Reply to author
Forward
0 new messages