Glorious Alpha Two Testers!
Phase I of Alpha Two testing will occur on weekends. Each weekend is scheduled to start on Fridays at 10 AM PT and end on Sundays at 10 PM PT. Find out more here.
Check out Alpha Two Announcements here to see the latest Alpha Two news and update notes.
Our quickest Alpha Two updates are in Discord. Testers with Alpha Two access can chat in Alpha Two channels by connecting your Discord and Intrepid accounts here.
Phase I of Alpha Two testing will occur on weekends. Each weekend is scheduled to start on Fridays at 10 AM PT and end on Sundays at 10 PM PT. Find out more here.
Check out Alpha Two Announcements here to see the latest Alpha Two news and update notes.
Our quickest Alpha Two updates are in Discord. Testers with Alpha Two access can chat in Alpha Two channels by connecting your Discord and Intrepid accounts here.
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.