FEZ. Frankenstein Entity Zystem.

[ljdp]

YWPMM.png (22.38 KiB) Viewed 814 times

FEZ is a lua library to help you get started with component based programming.

In component based programming, entities are made up of components, the entity itself is just a number that identifies a collection of components.
The components hold the data and do the logic.

In the FEZ, there are four kinds of components:
- Attributes
- Behaviours
- Controllers
- Renderers

Attributes hold data about an object and nothing else, they mainly consist of getters and setters to the data. Some attributes might do validation to the data or perform transformations. The point of the attribute is to separate data from logic.

Behaviours perform logic code, usually using the data from the entities attributes. Behaviours belong to an entity and that entity is passed to it's update method.

Controllers don't belong to any entity, you need to update controllers explicitly. Controllers have an updateEntity method which is by default run for every entity. Controllers can set a filter so they only perform logic on entities with the given components.

Renderers are the same as controllers, we just use this term to separate logic from rendering.

Components can invoke methods in other components directily, but the best practise is to use events. FEZ comes with a class called EventDispatcher, components can 'subscribe/listen' to events and 'publish/send' events, this reduces coupling between components.

Take a look at the example on github: https://github.com/perky/FEZ

If you're new to entity systems take a look at this blog http://t-machine.org/index.php/2007/11/ ... nt-part-2/

[vrld]

I really like the idea of component based design, but did not yet encounter a game project big enough to apply it to. You library certainly makes it easier to try it sometimes. Good work!

Only two comments (not to be taken too seriously):

1. Lua-Entity-System sounds too serious. It deserves a catchier name. Maybe Frankenstein? Or a clever acronym?
2. The code looks quite enterprisesy. Are you by any chance a Java developer?

[ljdp]

I really like the idea of component based design, but did not yet encounter a game project big enough to apply it to. You library certainly makes it easier to try it sometimes. Good work!

Only two comments (not to be taken too seriously):

1. Lua-Entity-System sounds too serious. It deserves a catchier name. Maybe Frankenstein? Or a clever acronym?
2. The code looks quite enterprisesy. Are you by any chance a Java developer?

I've dabbled in a bit of java but no, it's inspired by a java component libartemis.
I guess I could give it a funner name, but I like things that do exactly what they say on the tin.

[Kingdaro]

Lua Entity System

yes, i know i'm trying too hard lawl

[kclanc]

I vote to keep the name Lua Entity System. This looks pretty solid; however, I find it strange that PlayerCollisionController obtains a reference to the player by filtering out entities without ShapeCircle components. I think it would be more straightforward to make the player entity global or pass it by reference.

[ljdp]

I vote to keep the name Lua Entity System. This looks pretty solid; however, I find it strange that PlayerCollisionController obtains a reference to the player by filtering out entities without ShapeCircle components. I think it would be more straightforward to make the player entity global or pass it by reference.

Code: Select all

self:addComponentFilters( Collidable, ShapeCircle, Transform )

It doesn't filter out, it selects entities with Collidable AND ShapeCircle AND Transform AND/OR any other component.
Approaching it this way makes it simple if you want to have multiple players if you implemented multiplayer etc..

[SudoCode]

LËSbian?

[kclanc]

OR any other component? Wouldn't that include everything? It's plausible that something other than a player would have Collidable, ShapeCircle, and Transform components, right? Wouldn't this cause a problem?

[ljdp]

OR any other component? Wouldn't that include everything? It's plausible that something other than a player would have Collidable, ShapeCircle, and Transform components, right? Wouldn't this cause a problem?

The example on github needs more work, but essentially you would have a Player attribute and only player entities would have this attribute.

So you can just

Code: Select all

setComponentFilter( Player )

. It will only select entities that have the Player attribute, it doesn't matter if that entity also happens to have whatever other attributes.

See this link for a more detailed description on entity systems http://t-machine.org/index.php/2007/11/ ... nt-part-2/

[kclanc]

You might want to consider programming this using metatables; the added flexibility would likely be beneficial for something like this. For example, you could require the programmer to explicitly list all of a component's dependencies. That said, I read article you linked to as well as all of the other posts in the series. I have to say: they seemed a bit psuedo-scientific to me.