Glorious Alpha Two Testers!
Alpha Two Phase II testing is currently taking place 5+ days each week. More information about testing schedule can be found here
If you have Alpha Two, you can download the game launcher here, and we encourage you to join us on our Official Discord Server for the most up to date testing news.
Alpha Two Phase II testing is currently taking place 5+ days each week. More information about testing schedule can be found here
If you have Alpha Two, you can download the game launcher here, and we encourage you to join us on our Official Discord Server for the most up to date testing news.
Node Secondaries
11segfault
Member, Alpha Two, Early Alpha Two
I thought I would suggest a feature to be added to the long-term pipeline:
I think it would add a great amount of depth to the game to add a mayor-selectable secondary/flavor system for node types.
What I mean is a system that functions in a similar capacity to the secondary archetype/class system.
For example, a primarily scientific node might have a player-selectable military flavor that modifies its primary scientific type services to reflect attributes of the secondary military node type.
This would drastically improve player agency and further reinforce the ethos of a player-shaped world, where player choices really matter. It would also increase the total possible distinct node types to 16 rather than 4, so the growth factor (and thus balancing dev-load) would not be too burdensome.
Potential Complexity/Issues:
With respect to complexity, though, it would create an incredible new geolocation-nodetype based interaction graph that might prove difficult to balance for.
Under the assumption that every node interacts with every other node equally (i.e. equal weight of interactions, irrespective of node distance), and each node interaction is counted as a single unit of interaction (not counting sub-node micro-service interactions) the napkin calculation for the increase in the magnitude of interaction possibilities that need to be balanced for seems to be something along the lines of:
If you weight nearer nodes (i.e. assume that nodes farther from each other interact less and need to be worried about less when balancing the system), the load would be less.
If interaction instances are counted unidirectionally (i.e. an interaction between node A and node B is distinct when it originates at node A and runs to node B from when it originates at node B and runs to node A), then that increases complexity. In the calculation, I computed bidirectional.
Also, as mentioned above, none of this includes balancing of interactions between different individual services of the nodes. I just counted each node as a single interactable unit.
Either way, the full increases in magnitude would not correlate directly to development hours, since there are efficiencies that can be captured by ingenuity, rather than less-than-intelligently hardcoding balance for each interaction case.
Anyway, just thought I'd drop the idea and this napkin stuff here in case anyone else thinks it's a viable idea.
I think it would add a great amount of depth to the game to add a mayor-selectable secondary/flavor system for node types.
What I mean is a system that functions in a similar capacity to the secondary archetype/class system.
For example, a primarily scientific node might have a player-selectable military flavor that modifies its primary scientific type services to reflect attributes of the secondary military node type.
This would drastically improve player agency and further reinforce the ethos of a player-shaped world, where player choices really matter. It would also increase the total possible distinct node types to 16 rather than 4, so the growth factor (and thus balancing dev-load) would not be too burdensome.
Potential Complexity/Issues:
With respect to complexity, though, it would create an incredible new geolocation-nodetype based interaction graph that might prove difficult to balance for.
Under the assumption that every node interacts with every other node equally (i.e. equal weight of interactions, irrespective of node distance), and each node interaction is counted as a single unit of interaction (not counting sub-node micro-service interactions) the napkin calculation for the increase in the magnitude of interaction possibilities that need to be balanced for seems to be something along the lines of:
102 ∑16r == 84048 r=1Rather than the current:
102 ∑4r == 21012 r=1So, a 4x increase. Sorry if my math is off, it has been a long time since uni.
If you weight nearer nodes (i.e. assume that nodes farther from each other interact less and need to be worried about less when balancing the system), the load would be less.
If interaction instances are counted unidirectionally (i.e. an interaction between node A and node B is distinct when it originates at node A and runs to node B from when it originates at node B and runs to node A), then that increases complexity. In the calculation, I computed bidirectional.
Also, as mentioned above, none of this includes balancing of interactions between different individual services of the nodes. I just counted each node as a single interactable unit.
Either way, the full increases in magnitude would not correlate directly to development hours, since there are efficiencies that can be captured by ingenuity, rather than less-than-intelligently hardcoding balance for each interaction case.
Anyway, just thought I'd drop the idea and this napkin stuff here in case anyone else thinks it's a viable idea.
0
Comments
It isn't the same as taking some effects of a different node type, but it does mean that not all scientific metropolis nodes will have the same set of services.
Giving them access to 2/4 Node types just reduces the weight of the decision of where to settle, which is a step into the wrong direction imo. (even if the secondary Node Type can only be utilized to a reduced degree).
I'd argue, if implemented correctly, it can make player decisions matter even more.