Write an introduction for working on thrive (overall architecture introduction)

[hhyyrylainen]

I suppose I'll repurpose this issue for tracking writing some stuff for the game with Godot now.
In addition to some general godot help: #991

Some kind of overall architecture and where things should go, is probably good as a starting point.
It shouldn't be too detailed, though as there would be a big risk that it gets outdated quickly.

[hhyyrylainen]

Here is some info I have collected that should be formatted properly (and written more clearly) and added to thrive / leviathan documentations:

thrive clarification (maybe in leviathan documentation): Basically the
generator file has a list of all the components (including their
constructor arguments) and a list of all the systems (including
arguments to their Run method, possible init method, and potential
nodes {a node is a list of components}). Then an entity is created
with id = GameWorld::CreateEntity() and then components are added to
it with calls to CellStageWorld::Create_CompoundCloudComponent(id, rest of parameters to component constructor). The world object keeps
track of these created components and before the next tick it goes
through the added components and creates (and destroys if components
have been removed) nodes for all systems that an entity has all the
required components for (this is in the individual systems'
CreateNodes method). This isn't done for systems that haven't
specified that they use nodes in the ruby generator file. Then in the
tick method each system is ran starting with the systems defined in
the super classes first.

also this: Nodes are just a way of caching references to components
for systems to not have to search through all the components again. A
better name for it might be CachedComponentCollection

Note about threading and invokes
But it still does run invokes so you need to be careful whenever using them as the object you want to update with the background calculated result may have been destroyed

linux thrive running (in the build folder): cmake .. && make -j 20 &&
(cd bin && ./Thrive) Windows: manually run cmake if you changed any of
the assets or recompiled some of the dependencies. Then build and run
from visual studio.

[hhyyrylainen]

thrive artist notes:

I don't think there is a poly limit as such, but we'd like somewhat old laptops to still run the game fine. For the pilus a single spike will be fine, we can just put more of the models together if needed. Ogre3D uses its own model format. Doing models works like this make model in blender (or import to blender, supports a lot of of formats) -> use blender to ogre exporter -> use ogre mesh tool to make it a binary. And then heavily tweak the barely adequate automatically generated .material file to select shaders etc. the model uses
No worries. I think this should be written down somewhere, I'll just paste it to my todo list for now

[OBPSG]

I can draw up some UML activity/sequence diagrams to help shed some light on the code generation for the ECS engine, and how systems keep records of components they use through nodes for faster reference.

[NicholasDM]

More documentation on working with the codebase and how the systems come together would be truly fantastic.

Commenting due to many months without update/resolution.

[hhyyrylainen]

I'm going to guess no one is ever going to want to write documentation. I did write a kind of ECS architecture documentation info that kind of fulfills this purpose but doesn't cover the overall architecture really (missing stuff like how stuff is split into folders).