## [Library] tiny-ecs - Fast Simple Entity Component System

bakpakin
Party member
Posts: 114
Joined: Sun Mar 15, 2015 9:29 am
Location: Boston

### Re: [Library] tiny-ecs - Fast Simple Entity Component System

This is the book keeping I mentioned. Sorted systems have an onModify method that sorts the system. The system is only sorted when entities are added or removed. This is why should one still call world.update once per frame no matter what.
((_((_CRAYOLA_((_((_> GitHub <_((_((_CRAYOLA_((_(()

Dr. Peeps
Citizen
Posts: 57
Joined: Sat May 28, 2016 12:57 am

### Re: [Library] tiny-ecs - Fast Simple Entity Component System

bakpakin wrote:
Fri Apr 06, 2018 12:59 pm
This is the book keeping I mentioned. Sorted systems have an onModify method that sorts the system. The system is only sorted when entities are added or removed. This is why should one still call world.update once per frame no matter what.
It is. I should have mentioned: world:update(dt) is still being called every love:update(), in both cases. Does it matter that I'm calling it in love:update() and updating my system in love:draw() (after)?

BTW no entities are added or removed after the initial setup. All the entities exist, they just aren't being processed in order unless that system is active = true.

EDIT: A quick look though your source code and it looks like everything for world updates is wrapped in "if system.active" checks, so maybe inactive systems never have their "book keeping" done?

bakpakin
Party member
Posts: 114
Joined: Sun Mar 15, 2015 9:29 am
Location: Boston

### Re: [Library] tiny-ecs - Fast Simple Entity Component System

Yes It does seem like that. In any case, I would recommend against relying on this behavior. I’m guessing your use case is that you have some rendering systems, and some logic systems, and you want to update the drawing systems in love.draw, and the rendering systems in love.update.

You can pass a filter to world.update which will select the systems to update. The filter works much like an entity filter but on systems instead. This is probably what you want to update drawing systems in love.draw, and logic systems in love.update. You can see the demos for an example of this.
((_((_CRAYOLA_((_((_> GitHub <_((_((_CRAYOLA_((_(()

Dr. Peeps
Citizen
Posts: 57
Joined: Sat May 28, 2016 12:57 am

### Re: [Library] tiny-ecs - Fast Simple Entity Component System

bakpakin wrote:
Sat Apr 07, 2018 4:48 pm
Yes It does seem like that. In any case, I would recommend against relying on this behavior.
OK. So you mean calling system:update() on inactive systems probably isn't supported.
bakpakin wrote:
Sat Apr 07, 2018 4:48 pm
I’m guessing your use case is that you have some rendering systems, and some logic systems, and you want to update the drawing systems in love.draw, and the rendering systems in love.update.
Yes, this is what I'm doing, but different sets of rendering systems are called in each gamestate.
bakpakin wrote:
Sat Apr 07, 2018 4:48 pm
You can pass a filter to world.update which will select the systems to update. The filter works much like an entity filter but on systems instead. This is probably what you want to update drawing systems in love.draw, and logic systems in love.update.
I was doing exactly that, and it worked well. As more sets of systems were added to different gamestates though, things got a bit complicated, filter-wise - so I thought I'd just call each system:update() where needed.

I can go back to using filters though. And maybe it's easier in my case to just set active = false for all the systems I don't want to run! Thanks for the help.

ryanzec
Prole
Posts: 11
Joined: Sat May 05, 2018 3:37 pm

### Re: [Library] tiny-ecs - Fast Simple Entity Component System

@bakpakin

So I was looking into ECS for a game I am trying to prototype and was wondering how performant tiny.ecs would be for my game.

For my game, I am going to be rendering a lot of sprites (20k - 30K) however probably about 90 - 95%% of those can be grouped into 2-3 sprite batches and don't need to be updated on every frame so that seems good.

My concern more lies with that I can going to want to have a lot of entities in the game. It is an open world turn based survival roguelike (can't think of any other buzz words to put in there ) that is going to have a seemingly "infinite world" which could contain 10 's to 100's of thousands of entities. Obviously I can't load and simulate that many entities at once (not on the average computer at least), my naive plan from someone who has not built a game of this scope before is:
• split the world into small chucks (maybe something like 16x16) that will store all the data related for that chuck (map data, entities, etc.)
• only load X number of chunks that surround the player (maybe something like 7x7 or 9x9 with the players location being the center chunk)
Now most of the entities should have relatively simple logic that needs to be simulated, only a subset (maybe 100 at most 99% of the time) will need more complex things (the most complex things being a* path finding).

Do you think that is something the ECS in Lua can handle in general or more specifically tiny.ecs? Maybe I am thinking too grand for using a higher level language (or ECS) and maybe I need to dig into C++ to be able to get the features I want with the performance I need.

ryanzec
Prole
Posts: 11
Joined: Sat May 05, 2018 3:37 pm

### Re: [Library] tiny-ecs - Fast Simple Entity Component System

Another that I have noticed is that, in the examples world:update() is called in love.update and love.draw doesn't that means all the logic for the entities is being executed twice which seem highly inefficient. Am I understanding this correct or am I missing something?

bobbyjones
Party member
Posts: 675
Joined: Sat Apr 26, 2014 7:46 pm

### Re: [Library] tiny-ecs - Fast Simple Entity Component System

ryanzec wrote:
Sat May 12, 2018 1:46 am
Another that I have noticed is that, in the examples world:update() is called in love.update and love.draw doesn't that means all the logic for the entities is being executed twice which seem highly inefficient. Am I understanding this correct or am I missing something?
He stated that you can set a filter for systems. So in the update call back you will filter for only update systems and in draw only filter for draw systems.

### Who is online

Users browsing this forum: No registered users and 2 guests