I love your idea how to handle stuff not in a district, as well as your multi-tab display, but have a different idea for the “overview” tab as you called it, but I’ll loop back to all this at the end.
I’m working on my masters in CS rn and after further thought have more ideas for “how much work it would be to change the production info window to a system like this” than I did when I wrote my original post. I’m coming from the perspective of object oriented programming, where there are different “things” that hold data and functionality and can interact with other “things”.
Let’s start with our focus on the functionality of the production overview object.
The production overview object allows you to view the input/output requirements for a collection of buildings. By adding this functionality for individual districts (as has been done), each district could now contain a unique production overview object. It is possible the game still uses a single production overview object, but in this case each district object must have the functionality to pass it unique data (what buildings are in the district and what their input/output requirements are) such that the single production overview object can change display when individual districts are clicked.
Since displaying this data isn’t actually changing the state of buildings (it just requires data be collected), it isn’t necessary to store this data for future use (it can be collected again when it is needed). This is why districts may send data to a single production overview object to be displayed rather than having a unique production overview object of their own.
Phrased bit more clearly, when districts are clicked the game is either switching which production overview object is displayed or changing the input to the display of one production overview object.
All that needs to change to implement the suggestion, if districts already have unique production overview objects, would be to connect this unique object’s sliders to the buildings in the district, rather than the global production overview object’s sliders. In the case district objects don’t have unique production overview objects, it may be necessary to rework it to such since district objects wouldn’t have unique sliders to connect to and a place to store the unique data of the sliders as the player tweaks them.
Looping back to your ideas, the tab for stuff not in a district would be no extra work to handle. With the suggestion implemented, each district knows what buildings are in it, knows their input/output requirements, and can tweak the sliders; we can obtain the functionality you described by simply considering all buildings not in a district to be a part of an implicit district. This implicit district would have its own unique production overview object and would function identically to other districts, but would be invisible to the player.
As for the “overview” tab, which I think should be kept as the “global” tab, I could see it working in two ways:
The first being the way you described, where it displays the global input/output requirements but doesn’t allow you to edit sliders. This is the easier option to implement, as you would only have to disconnect the global sliders from buildings. I can imagine scenarios where the resulting gameplay would be a bit annoying, especially as the number of districts in a map grows and new buildings are added to existing districts. All buildings start with full production, but if you lower productions of certain goods in districts, the only way to raise them in the future is to click on the district again. Say you just expanded your city and all of the supporting districts to provide enough goods; you may have to click on every single district to ensure enough raw material to supply all these new products instead of being able to quickly set all ore production to the max and optimize down later if need be. In other words, I think this implementation takes away too much from the casual player, forcing everybody to tweak each district if they want to tweak at all. A “reset” button could be added to instantly reset a resource’s production to 100% globally, but that feels a little clunky.
The second way I could see the global tab working is the same way it works now for the player, with a bit more going on under the hood. If the global sliders are tweaked, they override the per-district tweaks. Delving deeper, I propose two ways to handle this override:
The first being a hard override, where if a global slider is moved, all buildings that produce that good inherit the value of the global slider. Say you have two districts with equal capacity for iron production, and you tweak one district to be at 25% production and the other to be at 75% production. Globally, your iron production will be 50%, but if you raise the global slider to 60%, both districts will now be at 60% production. This implementation is very simple, but completely disregards per-district tweaks. In the example provided, despite raising the global production, the district that actually needs the largest production fell by 15%, and the district that needs the smallest production rose by 35%. This may go unnoticed by more casual players, but could be a nuisance for those that prefer to optimize but also want to use global sliders sometimes. Using a hard override for global sliders is essentially providing two different tweaking systems for a player to choose from, but that don’t play well together unless you’re trying to reset/normalize all districts at once (which honestly is plenty sufficient, gives an avenue for all play styles is just isn’t as elegant as it could be).
The second way I can see the global sliders working is by changing each building’s production starting from the values of its district slider. By determining how much higher or lower the goal global percentage is from each district’s slider’s current percentage, it’s possible to adjust each slider more or less quickly/significantly and in different directions (make each percentage move either toward OR away from the goal global percentage, the hard override forces percentages to always move toward the goal global percentage) to achieve a global balance more resemblant of the per-district tweaks. We will use the same example as above, two districts producing iron, one at 25% production and the other at 75% production. When the global slider is moved to 60%, the district at 25% production is 35 percentage points lower than the target of 60%, while the district at 75% production is fifteen percentage points higher. Depending how you use this information, you can generate various new production percentages for the two districts. Take 40% and 80%, respectively, for example; These two districts would still have a global average of 60% production, but the district that was at 25% production (lowest demand) increased by only 15 percentage points (instead of increasing by 35 with hard override) while the district that was at 75% production (highest demand) increased by 5 percentage points (instead of decreasing by 15 with hard override). While this would not preserve pre-district tweak ratios exactly, it would allow the ratios to be much more similar after tweaking globally than a hard global override. There’s a ton of tricky maths and edge cases to consider with this, but that’s the general idea.
To reiterate, this second implementation of the global sliders is an attempt to improve functionality that doesn’t exist yet; using the hard override would be perfectly playable in my opinion and would allow version one of per-district tweaking to be implemented more quickly. Focus on the core of it then get fancy (the per-district tweaks are getting fancy with the original core of production overview, the mantra works ha)!
After this further exploration of thought, I feel the original suggestion along with Lodrik_Bardic’s tabs idea wouldn’t be all that difficult to implement, having most of the complicated functionality already working from the existing production overview and district objects. If my assumptions on the utilization and structure of objects is inaccurate, it is certainly possible the suggestion is more difficult to implement.
What do you think of my deeper exploration / brainstorming?