Dependency Graph for RPG project

,

I am near the beginning of the “Abilities” section of Shops and Abilities. Still, I thought it was a good time to start adding assembly definitions to the project. Took a few hours, given the need to link those that refer to others, then fix the circular dependencies.

As far as I recall, only two circles came from the course: aggro group caused a circular dependency between control and combat, which I resolved by putting aggro in its own namespace and assembly, and the IHandleRaycast depended on PlayerController, and was used all over the place, so I extracted an interface IPlayerController (that had one method to return its gameObject) and put the interface in Core.

The other dependencies I managed to put in myself. One was hard to find: the Unity error message didn’t point anywhere close to where it was. I had introduced it by using a third-party AStar pathfinding (you can see it in the dependency graph) and in making it switch off when the character was dead, I managed to put a cycle between Health (attributes) and Control (AiController). Took a while to find that and use an event “on death” to turn off the Ai to break the cycle.

After several hours, finally it compiled!

So, here is the final graph, generated by Rider (which only graphs assemblies, not namespaces).

The thickness of the lines is supposed to indicate the strength of coupling. I don’t know exactly how that’s computed (number of includes? Number of classes using another assembly?). The dotted green lines, I’m not sure, but would guess mean the CSharp assembly dependency was automatic, maybe.

It seems upside-down to me. It seems the deepest stuff should be…deepest, or lowest.

Edit: now that I think of it, the things with the most dependencies are on the bottom. That makes sense from the perspective of a talk I attended where a programmer likened a software project to Dante’s Inferno, and the “dependency hell” was 9th level, but first level was stuff with few or no dependencies.

And I realize the green lines seem backward now: I don’t think the Assembly-Csharp depends on my code!

This is one of those namespace issues we missed in the first run of the course. My own solution puts IHandleRaycast and Cursor in RPG.Core and passes a GameObject instead of a PlayerController (in most cases, we don’t use the PlayerController anyways, or if we do, it’s just for the GetComponent

Privacy & Terms