Simple Entity Component System

[ecbambrick]

Simple Entity Component System (SECS) is an entity component system for general game development, but designed with LOVE2D in mind. If you're unfamiliar with the concept, check out these links for more information:

• http://t-machine.org/index.php/2007/11/ ... evelopment
• http://www.richardlord.net/blog/why-use ... -framework
• http://cowboyprogramming.com/2007/01/05 ... -heirachy/

To put it briefly, SECS is a framework for managing game entities and separating data from logic. Each game entity is simple a table of data which gets fed through various logical systems that modify its data. A game loop consists of calling the update function of each logical system in some specified order. Each system then queries for game objects and runs game logic.

This means that systems don't need to know about each other or the entities they're modifying. If you were to create a health system that manages damage and healing, you only need to worry about a health component. It doesn't matter what the entity actually is; as long as it has a health component (or resistance component, or invincibility component), that's all you care about. A physics system only needs to care about physics related components (velocity, position, gravity) and, thus, does not need to communicate directly with any other system.

SECS currently consists of five different types of objects:

• Entities
  A game entity. It contains no logic itself and is literally just a table of components. Any behaviour an entity contains is determined entirely by the components it has.
• Entity Factoties
  Factory functions for creating instances of specific entities.
• Components
  While entities are tables of components. Components are tables of simple data. The data within a component should be related. For example, you should keep positional data such as x and y coordinates within a "position" component.
• Entity Types
  An entity type is defined with a list of component names. The type will contain a list of all entities that contain all of those components. This acts as an easy way to query for specific entities. For example, if you want to draw entities to the screen, you would create a type for that contains all entities with a position and sprite component.
• Systems
  None of the above objects have any game logic. Systems are where the logic is contained. Each system has an update function that is called in a specific order within the game loop. Each system queries for entities based on their type, applies logic, and then modifies the state of those entities.

Code: Select all

function love.load()

    -- initialize Secs and individual systems
    secs = require "secs"
    
    -- create components with some default values
    -- these can be instantiated to hold data for entities
    secs.component("position", { x = 0, y = 0 })
    secs.component("text",     { text = "" })
        
    -- create an entity type that requires the position and text components
    -- this will be used by systems to query for entities
    secs.type("textEntities", "position", "text")
   
    -- create an entity
    -- this is a game object/token
    secs.entity(
        {"position", { x = 100, y = 100 }},
        {"text",     { text = "Hello World" }}
    )

    -- create a system to handle drawing
    -- query for all textual entities and draw them by accessing their components
    secs.rendersystem("draw", 1, function()
        for i,entity in ipairs(secs.query("textEntities")) do
            love.graphics.print(entity.text.text, entity.position.x, entity.position.y)
        end
    end)

end

function love.update(dt)
    secs.update(dt)
end

function love.draw()
    secs.draw()
end

You can try out SECS here: https://github.com/ecbambrick/SimpleEnt ... nentSystem
You can read the wiki here: https://github.com/ecbambrick/SimpleEnt ... ystem/wiki

This is still in the early stages of development, so I will continue to add/modify functionality as I need it. There are a lot of ways to implement an entity component system and I don't know the best way, so any comments/criticisms would be appreciated.

Code: Select all

TO DO:
    implement weak tables for certain objects
    improved error handling
    game states
    scenes

[Davidobot]

Great library, but you should change the name: http://www.love2d.org/wiki/Simple_Educa ... ass_System

[Robin]

"You should change the name. Not because it's work-inappropriate and unprofessional, but because it's already taken."

I love this community.

[ecbambrick]

Great library, but you should change the name: <a href="http://www.love2d.org/wiki/Simple_Educa ... _System</a>

Ah, I didn't see that. Thinking of the name is the hardest part.

[Towerfiend]

This all sounds incredibly SECSy, and I'll definitely consider it for projects.

[pauljessup]

Huh. Never heard of the entity system pattern, but it sounds almost exactly like an MVC framework pattern. But for games.

Neat.

[ecbambrick]

Huh. Never heard of the entity system pattern, but it sounds almost exactly like an MVC framework pattern. But for games.

Neat.

It's a bit like MVC but I think that one important aspect is that game objects are all generic. You never really define what a player is explicitly, you just add the right components (ie - input, physics, attack) and it ends up being a player.

One of the cool things you can do is completely change the behaviour of an entity by modifying its components. If an enemy dies, you can remove the AI component, replace the sprite, and add a loot component and now your enemy is a pile of loot. Likewise, if the only difference between an enemy and a player is that the player has an input component (so it can be processed by the input system) and an enemy has an AI component (so it can be processed by the AI system), removing the player's input component and replacing it with an AI component will suddenly turn your player entity into an enemy.