As talked about within the remark above, you possibly can’t virtually eradicate all branches in an ECS written in C#. By the character of an ECS, you are going to be looping over arrays of parts. Each loop has a department to resolve whether or not to maintain looping, and each array entry in a managed language like C# has bounds checks to ensure you’re not indexing past the bounds of the array.

Thankfully in appropriately written code, these bounds checks all the time move, so they need to be predicted appropriately by the department predictor and have virtually no value. There’s some proof I noticed just lately from examples in Rust that backs that up. Equally, the department in a loop will be reliably predicted as “all the time loop”, and it solely will get it incorrect on the final iteration. (You’ll be able to cut back this overhead additional utilizing Span<T> as a substitute of Checklist<T>, or fetching a Span<T> model simply in time)

So, not all branches are equally dangerous. What you wish to keep away from are random-looking branches that may incessantly mis-predict and trigger pipeline stalls.

Some of the widespread methods to get that is in case your arrays of parts can include empty slots from destroyed entities, or entities quickly disabled. Then each system replace must have a department that checks whether or not this element is legitimate to behave on it earlier than it acts. Since entities will be disabled/destroyed randomly (as much as the whims of your sport mechanics), these branches will be exhausting to foretell. One good approach to remedy this, when you can, is to defer entity destruction to the tip of a body, and swap parts of destroyed entities to the ends of their respective arrays, holding dwelling ones densely-packed on the head of the array (and updating ID lookups as vital on this cleanup step). Then your liveness examine simply turns into your loop bounds examine, and it predicts appropriately till the final iteration. This additionally helps you get optimum cache utilization, since you do not waste valuable cache line house on parts that will probably be ignored.

That is more durable if only one element must be disabled out of a bigger multi-component entity. In that case, you would possibly want to only eat the department value (particularly if it is a uncommon incidence), or have a look at methods you may make its operation a no-op when you discover the department is a major efficiency value in your profiling. Or you can transfer the entity to a different archetype which has the Disabled<ComponentType> element as a substitute of the unique ComponentType. This may have all the identical fields to retailer the info/state for later re-enabling, however will probably be ignored by techniques trying to replace ComponentType.

Including and eradicating entities needs to be a lot much less widespread than iterating them, so that is unlikely to be a significant efficiency sink. In circumstances the place you might be including/eradicating many entities without delay, and your profiling exhibits a major value from all of the checks, it is possible you are including/eradicating lots of the similar archetypes. In that case, you possibly can have a look at batching up these operations. 300 new bullet entities have been requested this body? I will do my reminiscence checks and allocations as soon as to make sure there’s room for 300 extra, then bulk-fill that house with certainty that it is there, reasonably than repeatedly checking and incrementally increasing 300 occasions.

Queries are ripe for pre-computing. Initially of your sport or at the beginning of a brand new scene, initialize every system that is going to be lively in that scene, and have it register every of the queries it makes use of. Hand it again an object with an inventory of matching archetypes (initially empty). Now, every time you spawn a brand new archetype (not a brand new entity of an archetype – solely do that the primary time a brand new archetype is used), you run via that record of pre-registered queries and examine which of them it matches, including it to the response lists for these queries. Virtually all of this work will be performed at scene start-up, with zero matching value per system replace, as a result of all of the archetypes they want are already listed. Solely sometimes will you introduce a brand new archetype mid-scene, and also you solely pay its matching value as soon as.

Your entity lookups may very well be a single array reasonably than a dictionary, mapping a sequential ID counter to its present archetype and index in that archetype (updating that book-keeping everytime you do a swap). You need to use a free record to fill holes in that array as entities are created and destroyed. A technology quantity may also help you detect when an ID you are holding refers to a now-destroyed entity that is been changed.

Conditional logic inside your element updates is an entire totally different ball sport, however now you are exterior of what is particular to an ECS, and into common gamedev challenges.

Simply keep in mind: branches are usually not the best evil. It’s best to expend solely as a lot effort avoiding them as your measured profiling information confirms they’re inflicting issues. A pipeline stall sucks, however so long as it is not taking place consistently you possibly can nonetheless get wonderful efficiency.