NECS - full client-server ECS implementation with incremental entities synchronization and simple scalable delimitate data exchange between entities based on simple GDAP(GroupDataAccessPolicy) interfaces. Fast entity serialization based on https://github.com/tomba/netserializer show perfomance 3x faster then NewtonsoftJson serialization and 9x faster then BinaryFormatter serialization, and optimize traffic size by exclude fields name(in future may be implemented traffic zipping). ECS objects packer mechanism provide high efficient caching techniques for reduce serialization costs even more.
To address the issue of maintaining entity state (specifically, the presence/absence of certain sets of components) during the execution of specific sets of instructions that depend on the state of the entities they process (hereinafter referred to as contracts), a per-component locking mechanism for the entity component storage was implemented. This mechanism allows freezing the presence/absence of specific components while executing code that depends on these conditions for specific entities.
This led to the creation of contract-systems that are deeply integrated with entities and their components, formalizing these relationships into entity-processing mechanisms that are resilient in a multithreaded environment.
Additionally, since component locking does not block the entire component collection (it remains available for deletion, writing, and replacement of components that are not currently locked), there is no performance loss due to waiting for collection unlocking, which would occur if the collection were completely frozen. Furthermore, the risk of deadlocks is reduced because the LockedDictionary, which underlies this implementation, completely avoids full collection locks, except for the Clear method.
This implementation also uses the so-called “ECS Bridge” option for synchronizing the ECS data program space and the non-ECS program space through the use of different types of managers, which ultimately provides flexible management of external semi-autonomous game objects without the need to process low-level components that provide entity representation on the screen, shifting this responsibility to the visualization tools and relieving the ECS system itself, while providing complete control over what is happening.
In project included network realization from https://github.com/sunduk/FreeNet.
Restrictions:
- Not serialize concurrent types and any other collection types including inherit types of List<> and Dictionary<,>, serialize only List<> and Dictionary<,>. For syncronize access to non thread-safe collections (List<> and Dictionary) was realized extension class InterlockedCollection with integration to core ECS serialization mechanism.
- Not serialize properties, but was relized methods for signalize object about serialization start and you can cache property values in code of serializable ECS object.
- Unlike other ECS implementations, my task was primarily to optimize network data exchange and focus on the versatility of ways for objects to interact within the system in order to simplify and speed up the writing of game logic. This is a completely data-centric implementation of ECS, which does not use standard optimization methods such as managing the location of components in memory and abandoning classes in favor of structures. Thus, if you want to use this implementation only to improve the performance of your game logic, it is better to use other implementations, for example https://github.com/Doraku/DefaultEcs or https://github.com/RevenantX/LiteEntitySystem.