My usual approach, thus far, has been to play around with techs.ruleset and see the changes rendered by the client in the appropriate view/section. It soon becomes a tedious exercise, and sharing the results for discussion,require no small effort.
After trying out different methods (including several procedural ones),
I eventually concluded that a 'mechanical approach' by means of graphviz (dot) was the 'path-of-less-resistence', a decent template that could be further customized, once all the tiles of the mosaic are 'defined'.
The boring part is to have the full set of the tiles one wants to play around with.
Updating/adding the edges (the links, if you prefer) that binds them together, becomes (almost*) trivial.
One can get creative and convey additional information (like specific requirements). Showing and hiding information is a matter of changing the appropriate attributes of a node or edge... Yes, dot language is flexible (and quite potent).
I am attaching the current template I am using for my custom orxperimental ruleset and a preview image.
One advantage of dot is that it can render the result in different formats... I have included a .svg just for example (it can be opened and rescaled on the fly using any image manipulation program that understands .svg).
Code: Select all
dot -Tsvg techtree.htmltables.2023-06-25.0b1.dot > techtree.htmltables.2023-06-25.0b1.svg
Code: Select all
dot -Tx11 techtree.htmltables.2023-06-25.0b1.dot
Notes:
#1) The 'anchor/ghost' nodes are placed where needed to 'influence' the general layout rendering according to one intentions, not the dot language preferences.
#2) The various 'stages' or clusters, are there to help scaling research costs and upkeeps (an often overlooked step during custom ruleset design).