Color Code Production and Research Queues?

For what's not in 'Top Priority Game Design'. Post your ideas, visions, suggestions for the game, rules, modifications, etc.

Moderators: Oberlus, Oberlus

Post Reply
Space Floater
Posts: 45
Joined: Thu May 09, 2013 4:46 am

Color Code Production and Research Queues?

#1 Post by Telos » Sat Jan 05, 2019 6:57 pm

As a compulsive queue-optimizer, one challenge I often run into in reshuffling the production and research queues is wondering whether the progress I'm planning to an item this turn is enough to get "past a tick mark", i.e., to reduce by 1 turn the minimum number of turns it would still take to finish that item.

Sure, the game shows progress meters, but it's sometimes hard to see whether they quite reach the tick mark. And sure, the game tells me the number of turns it would take to finish the item *if* I left the queue unchanged, but often what I want to know is whether I can shuffle an item lower down, give it partial progress past a tick mark this turn, and then shuffle it up to complete it on schedule, or whether shuffling it down would instead not quite reach the tick mark and hence would make it impossible to complete it as fast as I'd like. I also know that the research queue tooltips tell you the amount of research that has been done, so I can work out the math to figure out whether I'll pass a tick, but that's a big pain, and it's even more of a pain trying to do this with the new percentage-based progress in the production queue.

This challenge always arose in deciding which item to put at the very bottom of the active queue to receive partial progress within each supply zone. It also arises more often now that the Stockpile system effectively places a second threshold where an item might receive partial progress, depending upon whether it is situated high enough to take advantage of the Stockpile, or low enough that other items will hog the available Stockpile this turn instead.

It would make my life much easier if more background-color shadings were added to these queues, rather than the mere two tones that are used now (grey = making some progress this turn, dark grey = no progress at all this turn). Here's what I would propose:
  1. Dark Grey: still means making no progress this turn.
  2. Reddish grey: means making progress this turn, but not enough to get past a tick mark.
  3. Yellowish grey: means making enough progress this turn to pass a tick mark
  4. Greenish grey: means completing this turn (also indicated by the white progress bar completing though that's hard to distinguish from near-completion, and by the "1 turn" display).
Under this system, it'd be very easy to see when an item will be passing tick marks on schedule, versus when it will have surplus progress not immediately needed to pass a tick mark, and hence is a good candidate for either moving up so it can make more progress, or demoting to effectively let something else take advantage of this surplus.

I'd make these shades fairly similiar to the current greys, so this shouldn't affect the overall aesthetic very much, but will make highly relevant information easily available to people who want it.

Posts: 851
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

Re: Color Code Production and Research Queues?

#2 Post by Ophiuchus » Sun Jan 06, 2019 2:59 pm

I am not sure I am completely grasp the implications from the textual description. Could you mock up an example?

I think you were asking about more control of efficiency. I have the feeling that your use case may not warrant the extra introduction of more semantics to the UI.
Maybe you could think of a more valuable use case. E.g. only show the extra colors if there is actually the opportunity for optimization.

What i mean by efficiency? The underlying problem is that there are multiple topics rolled into one:
  • the priorisation: you specify what is most important to build/research
  • timing: you specify by which turn things need to be finished
  • efficiency: completing buildings and techs earlier usually
In my opinion timing is the most important. The UI allows you to directly specify priorisation, but for a asap-timing priorisation and timing are actually the same. In that case you can also do some automatic efficiency checking/optimisation.

E.g.: For the tech queue automatic checking/optimisation is of course easier (only one input of resources). Sometimes shifting techs does improve completion times of some items without changing completion times of other items, so it is always preferred.

If priorisation and timing are not the same there is place for slack and more optimisations.
E.g. lets say the most important tech for you is researching robocruisers, but your PP are bound in more important projects - history analyser and a colony ship. So researching the new ship hull can slack, as you wont be able to build it anyway. So you maybe research a growth tech inbetween because that is always nice. This optimisations of course cant be automated if you cant specify the timing.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

Furthermore, I propse... we should default to four combat rounds instead of three ...for the good of playerkind.

User avatar
Cosmic Dragon
Posts: 1250
Joined: Mon Apr 10, 2017 4:25 pm

Re: Color Code Production and Research Queues?

#3 Post by Oberlus » Tue Jan 08, 2019 9:06 am

Side note: I've noticed that the calculation of remaining turns to complete does not take into account the effects of the future increases or decreases in PPs/RPs, and so I very offen find that something that was due on turn T+3 will be finished on turn T+2 because I will have some extra PPs/RPs from a tech/building finished in turn T+1. For example, placing Quantum Networking up in the research queue may indicate that you will get Contragravitational Maintenance a few turns later, but in the end I get it sooner than expected.
After many games I've learnt to know intuitively when something will be finished and I pay less attention to the turn number shown for each item of a queue.

Post Reply