When program big(12000 lines code and more), very hard manipulate parts of code.

Idea we do graphics blocks , and conect this blocks to big code. We more draw and manipulate mouse and very less write code hands !

If we change parameters block then automaticly we get changes in code !

And we easy look any block and do not need find all parts in all code.

We see graphics blocks. Press mouse on block and get info about this block. And correct all parameters this block.
Second window main program consisting of blocks.

The paradigm of working on fragments is in many development environments, and I don't see it going away. Search for "node based programming". All the major game engines are moving in this direction, and the 3D packages have had it for a long time, and image compositions software, as well.

It's like the folder view moving into 2D or 3D - allowing the user to zoom in and focus on a subset.

2D using Direct2D for drawing.

Haw 3 windows (flip windows on tabstop). For small block, for big block and for main code.

One big block consists of smalls blocks. In main code we only paste this big block for !

For example block for consists of:
1) block For
2) block MessageBox 'Hi ! Its for !'
3) block inc data
Many smalls block in one block for ! And we have 100 or 1000 lines asm code in one block !

In main code blocks look like lines of code ! But not conected lines.
https://i.pinimg.com/originals/c0/10/c3/c010c3e385f9abc42a780e4b69a40ff8.jpg
All blocks have name and we understood whatch is this block do.

And we simple scroll up and down main code.
And simple(check box ) on\off block in main code.

We see(10) how loops do. How smalls blocks(3) in this big block.
In green place we see name(for or any user print name) this big block.

And we fast chopped main code like salad !


https://www.youtube.com/watch?v=EvASnEgRMmM#t=19

"node-based programming" is probably incorrect.

https://en.wikipedia.org/wiki/Flow-based_programming.

People on the net seem to relate the paradigm to a particular piece of software. Without looking at large projects it's difficult for me to tell if the scheme is hindering the work, or helping. It needs to scale - encapsulating fragments for utility at a higher scale. One should be able to assume the environment of a node.

What I've used of Unity, I like. In contrast, Blender can seem like a complete mess - coming back to a project after a few days. Systems mostly rely on the user to organize - match their workflow to the design of the software. Whereas a more flexible/open design allows the user's workflow to direct the organization.

I write Directx 11 game.

Believe me , a lot of code.
And it’s hard to read all the code later.
When you have 80 000 lines asm code, very easy do mistake or put code in wrong place.
Or in several places correct code.
Hard read and remember whatch this part asm code do.

My practice is 10 years

Graphics blocks very easy write,edit, read and understood.
You see the block you need, and not spend time looking for a piece code in all program.

When I work on large project I use simple object-oriented approach.
Every module in the program has a name, like:

String
Application
File
Allocator
etc.

All code for every module is placed in the file named by module name plus ASM extension:

String.Asm
Application.Asm
File.Asm
etc.

All functions in the files are named by the module name plus underscore plus the function name, like:

In File.Asm I would place functions dealing with file:

File_Open
File_Create
File_ReadBytes
File_WriteBytes
File_ReadLine
File_WriteLine
File_Close
File_Seek
etc.

this way you know where the code is.
Of course the good IDE is of great help, like you can explore the files and functions inside the files by
looking at it in a tree. Double click tree item and get to a function in an instant.
There are plenty of IDE programs for FASM, choose one.

But, I guess all that is late for your large game?
Code is already written.

I grow up and feel the power!

what about 3D-trees, all in all?