Hacking the monolithic entity system

So I'd like to see some discussion in the article about *how* to accomplish this type of scheduling.

Let's say I have 10,000 entities in my world. do I need to maintain an external list of potentially 10,000 items that desire updates? Do I give every entity a needsUpdate() function, and call it on every entity every frame? Do I give every entity a updateFrequency() function, which is read at entity creation, and used to partition a sorted list of entities?

arn't you still doing work on each entity to determine if you need to actually work on it?

I mean, it saves work for some examples you gave(such as a far off unit animating), but woudn't most interactive objects already be doing little to no work?(such as doors/items)

or as swift asked, are you sorting the objects into different lists for work loads?

I suppose the trick of this all is how you partition the entity list such that you know which entities are in the immediate location of the player.   You'd have to have entities that can still appropriately function with infrequent update calls (probably those entities offscreen with little interactivity with the surrounding world). 

Nice idea :). Some kind of dynamic priority entities queues.

Great info!

As far as I understand it, this time slicing is the same idea already used in Valve's Source engine for entity thinking. If you have a look at the free SDK, each entity has a Think() function, and a flag indicating whether it should think this frame or not. Inside Think(), each entity can inform the engine of the next time it needs to think (e.g. 1 second later) via a SetNextThink() function, and the Think() function will not be called until then. Internally the engine maintains a priority queue based on the next time of thinking.

I also read about the idea of a LOD-based (spatial or other) priority list recently, probably on entity-systems-wiki.t-machine.org, although I do not know of any actual implementation. But it seems promising indeed.

Yup, thats how i do it. Have your entities return a 'time until next think'. Note that this is actually Very similar to an Actor Model (http://en.wikipedia.org/wiki/Actor_model). You can implement a scheduler in your engine which schedules these 'think' calls Jerome mentions. Using the actor model way of thinking you could even make this updating multithreaded with some additional restrictions on your think methods.