Home› General

My attempt at a code map for 0.0.5-alpha

mbgmbg
in General
I'm a visual thinker and I need to wait for Godot 4.0 for the bulk of my project (need asteroid selection), so in the interim I decided to have a crack at making a code map:


Please let me know how far off base I may or may not be. I had to oversimplify a little, obviously, but I think I managed to capture the genereal flow of things. I've attached the diagrams.net file if anyone wants to play around with it and/or hopefully improve it.

(The native diagrams.net extension is ".drawio" but for some reason I couldn't attach it as such, so I added a ".txt" for upload purposes.)


Comments

  • Charlie WCharlie W
    Wow! It's bigger than I thought...

    Is this all manually done? Or is it somewhat automated?

    Just a couple things at first glance: 

    ProjectBuilder in theory should touch almost everything since it defines almost all the classes (except GUI widgets and some other GUI children) and inits all the non-procedural classes. Could it just be omitted? Or shown in some "uber" position above everything with implied connections? It seems more confusing to show some connections here rather than none (I do see the problem showing all, however).

    Global isn't aware of any other program classes (the shaders and outside resources, yes, but not GDScript classes). On the other hand, almost all GDScript classes grab something from Global, or use it to send/listen for signals. Shouldn't the arrows be pointing to Global? (I'm a bit ignorant on these diagrams, so I might be wrong on this. But, for example, Global has the "table_data" dictionary. TableReader grabs table_data and populates it. Then many other classes grab table_data from Global for read. Analogous situation for TimeKeeper and the Global.time_array.)

    Your color coding follows directory structure, but that makes me wonder about our directory structure. Unfortunately, we have a lot of "builder" classes together with "runtime" classes. It would be clearer if generation was separate from operation. And we have more "factory" classes in 0.0.6 since I've been busy pulling out long init functions (and deleting 4 or 5 classes that had an init function and nothing else). This makes me think we need a new directory specifically for these builder/factory classes.

    Hold off on doing too much more work though. I'm pressing hard to get 0.0.6 out and there is a lot of API breakage. New classes, deleted classes, and some dependency changes. I've sort of gone crazy in the last 3 weeks breaking stuff -- since I don't want to do that after we are in official beta.

    But I'm amazed you diagrammed all the parts! Hopefully it can inspire me to do some structural improvements...

  • mbgmbg

    Charlie W said:
    Wow! It's bigger than I thought...

    Is this all manually done? Or is it somewhat automated?

    It began as a pencil sketch of my own project, starting with the res://<name>/<name>.gd structure per project guidelines. Then I looked through the tscn trees and grepped each class to map out the relationships on app.diagrams.net.

    Just a couple things at first glance: 

    ProjectBuilder in theory should touch almost everything since it defines almost all the classes (except GUI widgets and some other GUI children) and inits all the non-procedural classes. Could it just be omitted? Or shown in some "uber" position above everything with implied connections? It seems more confusing to show some connections here rather than none (I do see the problem showing all, however).

    Yeah, I'll probably drop ProjectBuilder or stuff it into a simplified little side-graph.

    Global isn't aware of any other program classes (the shaders and outside resources, yes, but not GDScript classes). On the other hand, almost all GDScript classes grab something from Global, or use it to send/listen for signals. Shouldn't the arrows be pointing to Global? (I'm a bit ignorant on these diagrams, so I might be wrong on this. But, for example, Global has the "table_data" dictionary. TableReader grabs table_data and populates it. Then many other classes grab table_data from Global for read. Analogous situation for TimeKeeper and the Global.time_array.)


    No, that makes perfect sense. A code map can't show every inheritance or function call, otherwise it would rapidly become an incomprehensible mess, so it comes down to choices of what to show and how to show it. Basically, a code map is nothing more than one man's thoroughly codified opinion.

    Your color coding follows directory structure, but that makes me wonder about our directory structure. Unfortunately, we have a lot of "builder" classes together with "runtime" classes. It would be clearer if generation was separate from operation. And we have more "factory" classes in 0.0.6 since I've been busy pulling out long init functions (and deleting 4 or 5 classes that had an init function and nothing else). This makes me think we need a new directory specifically for these builder/factory classes.

    This was precisely the type of insight I wanted to inspire. I can only hope my visual OCD would contribute in some way to the betterment of the project =)

    Hold off on doing too much more work though. I'm pressing hard to get 0.0.6 out and there is a lot of API breakage. New classes, deleted classes, and some dependency changes. I've sort of gone crazy in the last 3 weeks breaking stuff -- since I don't want to do that after we are in official beta.

    But I'm amazed you diagrammed all the parts! Hopefully it can inspire me to do some structural improvements...



    I'll probably just clean this up a bit, given your advice and a few minor mistakes I just noticed. But I eagerly await 0.0.6 (and Godot 4 thereafter)!
  • Charlie WCharlie W
    OK, new directory structure in the master branch.
    • prog_builders - single instance Reference classes that import data, save/load, or build stuff.
    • prog_refs - single instance Reference classes involved in program operation.
    • prog_nodes - single instance Node classes involved in program operation.
    All of the procedural* solar system is still in tree_nodes (Spatials, etc.) and tree_refs (References).

    (*procedural in that they are built from data tables. We don't have true procedural anything yet.)
Sign In or Register to comment.