Polymorphism in DOTS

Has anyone worked with a DOTS solution that benefited from polymorphism? I’m playing with an ECS/DOTS implementation of Blizzard’s Statesript design language they used in Overwatch. Implementing a system like this purely inside the ECS world of entity lookups and system pipelines seems like a poor fit due to the random nature the machines can transition between states with varying behavior.

I looked a bit into how Unity.Physics handles their generic collider structures, using a simple enum/switch table to invoke type specific methods, but this approach seems more suited to a small fixed number of possible types and is not a great solution for letting users extend behavior with their own types. Rightfully so for the physics requirements but maybe not so in this case.

You can get a basic idea of what Blizzard’s Statescript setup looks like here: http://twvideo01.ubm-us.net/o1/vault/gdc2017/Presentations/Reed_Dan_NetworkingScriptedWeapons.pdf

I’m interested to know how others with some moderate DOTS/ECS experience might solve something like this.

 

It would be nice if you can provide us a specific use case / example and what you are expecting.

 

Last few months, I spent time recreating StateScript loosely based on all the knowledge I could find on the web/developer posts/gdc talks. Although their way of doing scripts is pretty exciting, the sheer amount of work, optimizations required was too overwhelming, not to mention it was costing too much precious development time for a sole developer so I stopped midway and went with a different approach.

You are right about making statescript work entirely in ECS is way too difficult and challenging, even they mentioned that.

That part is actually pretty easily achievable and would cover a lot of cases, why wouldn't that be a great solution?
That's kind of how they do it.

Think of each property (e.g. "Get Entity Facing Vector" ) as as system, which requires an entity + component data with params, on which the system operates and fills in the result in a separate component data struct, then all you have to do is inside your statescript just get the result component data from that entity.

If you're thinking of making it as moddable as possible, remember that you can always compile code at runtime. I haven't tried this, but I do remember reading that it was possible.

 

Compiling at runtime, may not always be desirable solution, even for modding.
Enum need to be respectively extended in code, which means, need to remember about it, while modifying/ adding significant part of the code.

 

I've used a system in the past where you can hook a 'pointer' (index/reference/something) to a generic class instance that is held in a registry that is responsible for doing polymorphic execution inside of ECS systems.

 

I came across a post that mentions FunctionPointer<T> inside the burst package that you can unlock with a compiler directive. My wonder is if something like this is possibly going to be removed down the line or, if not, what the side effect of using this might be on the compiler?

My concern was over this was about deserialising this data at runtime. I was trying to find a solution that would let me deserialise the blob directly without any additional processing required, but I think now this may not be a valid concern. Looking at the serialised .entities data, there is information in the header that details what components/archetype the deserialised entity would match and it makes sense that I could so something similar. Graph loading would just need some additional behaviour around the blob deserialiser to rebuild function pointers where polymorphic behaviour makes sense.

 

I feel like this has been answered already somewhere but I cannot find it: Will the burst compiler be something that could be distributed with with the standalone player so that it could be executed on code built at runtime?

 

I don't think you are permitted to distribute Unity compiler within a game. You may better check the Unity license.

 

Well, since eventually the DOTS-based Visual Scripting tool will compile code in runtime, I guess eventually they will allow the Burst to apply as well. The keyword is eventually.

 

But this is still in editor? I mean you can't edit visual scripts without doing it on editor in the first place..

 

I guess we will find out when the time comes. Either in the editor or you can read up serialized graph and compile it in run-time. Will see which path they choose and/or allow.

It would make sense to provide real run-time compile, since they started to mention modding more and more in their talks (GDC), so they _may_ invest in these more.

 

You could then probably still compile the mods code in editor though Just tell your players which version to use for modding.

 

I know. And the roadmap just contained the "runitme compile" or something very close to this, so it can mean any of these or anything in between.