I’ve recently been working on a little framework for DOTS to help with making roguelikes, but I’ve run into somewhat of a problem. The current Entities API allows us to create singleton entities, but it’s extremely limited when trying to leverage it as a store for mutable resource data that lives in a per-world context.
Components and buffers just don’t quite cut it when trying to compose something a little more complex and when systems have to write to this data it quickly gets unwieldy. The framework I’m working on has an example of how I tried to address this here. Note that I’m abstracting away the actual component and entity types used, but as soon as I have a job that needs to write to say the Tiles collection my system needs more intimate knowledge of the backing types that define the data.
I looked into using BlobAssets, but I quickly saw that blob assets are intended for readonly data, not mutable data. Ultimately I would like to have a nice clean way for a system to express intent in a specific type of resource being available and then being able to describe if it should be readonly, read/write or write only access to the resource. This could then ultimately be leveraged by the job system to know when specific pieces will be contending with one another.
A very good example I can think of where this would be useful as well would be the Physics package. The Physics world, in this case, is a resource that’s shared by many other systems and can be read/written to by these systems and all of them still have to play nicely with the job scheduler. Attaching the resource to a system and injecting that system seems like a hacky way to “solve” this problem.