In the OOP world the compiler can help you find out which components you need to complete an aspect of your games system, allowing you to migrate OOP systems knowing that these linkages will be flagged up by the compiler.
I don’t think DOTS has any way to check what subsystems use and consume data, so you will only find out what sub-systems and code you need to complete a full featured system from one game to another, when you run and test the systems.
Should Unity or DOTS have a system that checks for the inter-system links and what systems create and consume the data generated, providing a dependency graph of the interlinked systems?
Sure, would be nice. Isn’t this what they are working on with the visual scripting thing or a more advanced version of the current Entity Debugger?
I guess one day we will just drag systems/jobs around graphically and treat them as nodes, same as with data. Much of ECS lends itself great to code generation and graphical representations.
They said they have no plans to do it as a two-way street. Which means the VS will only be capable of generating code from the graph but not the other way around.
They may change their mind later and build the code->graph generator too, but as of today it is not planned. AFAIK
I don’t totally get the topic of this thread. You can find all dependencies by finding all usages of any particular ICD or friend. If you need interfaces and callbacks in your logic, you can still have interfaces and callbacks in your logic. That’s what Unity.Physics does. In that case it isn’t really any different from traditional OOP. Any looser coupling should probably be completely decoupled and then you really aren’t worried about the “complete system” anymore.
I actually think ECS makes it much easier to migrate systems than OOD as it promotes a much more modular approach.
You can easily break up all your work into individual packages that can be reused between multiple projects, for example this is a quick snap of my Packages/ folder in one of my projects.
Each of these are just a separate repo which I can pull into a new project as needed and I do this a lot.
Ideally you shouldn’t even have inter-linked systems as they should be completely decoupled from one another and only care about data. This is not always practical but I find that is when SystemGroups come in handy as it lets you easily loosely couple of systems together. Even then I think the only couple should be a UpdateBefore/UpdateAfters and they’re only linked together by data and purpose.
So let’s say we have a 100 system game and we need about 20% of the systems in this game for the core framework of our next game what would you have to do to find “all usages of any particular ICD”, could you explain the steps to take in the Unity IDE to link up the first set of systems, lets say system A is the first one we need…?
I would find an assembly, namespace, or directory that has the bulk of the functionality I would need. If I architected my previous project correctly, that’s it. Just a couple of directories that migrate over and I’m done. If there’s a couple of glue systems between two major directories, I can usually tinker with the namespaces of the directories to get compile errors to show up for the dependents. For individual systems that I have identified that I want but want to know what other systems it plays with, I identify an ICD and find all references to the type in my IDE.
It is ultimately a matter of being organized and being clever about that organization to find stuff.
Most of the time I just copy the directories that have the core functionality and then rewrite the glue specific to the new project.
Life lesson for you. Be more organized. Use good naming conventions and namespaces so you can use the search features of your IDE to find what you need.
I call such migrations “code shopping”. I dig around the code until I find a piece that looks like it does what I want. I put it in my virtual shopping cart and then lookup the references to the ICDs and other data types it relies on. If those systems seem useful, I will also put them in my cart.
But really, if you don’t know what the code is doing and don’t have code organization, then you need to fix those two problems first rather than rely on the compiler to tell you how to write code. It isn’t really designed for that.
What is this [quote=“DreamingImLatios, post:9, topic: 752966, username:DreamingImLatios”]
ICDs
[/quote]
as it’s the first time I’ve heard the acronym used?
In a game jam I did to learn ecs when I started I was able to easily port those systems over to my main game. since then I’ve built a large codebase in ecs. I’ve done two small prototypes for replacing how networking works or platform switching (in ecs) and was able to port those to a back to the main project really easily as well.
I then went ahead and started a side project to test out some more networking ideas with ecs and dynamic asset streaming through it. Again it was super easy to just copy systems over to the new project and get using them right away. I usually only have to write init code or UI to start creating the same data.
I think single responsibility systems is why it’s so dang easy.
I’m using process models to manage dependencies. Each process defines system boundaries, and they can be decomposed into sub-systems and jobs. Data on flows (Components) define transient entities, and datastores define persistent entities. Flow conditions work pretty good for filters. The advantage of a tool is that is can hold meta data and generate code. It’s especially helpful right now when there is so much boiler-plate code.
