tzlaine wrote:Can someone please explain to me the advantage of having a per-project yes/no model for researching thoeries and applications, and having a semi-automated category-queue percentage-spending model for refinements? I have asked this several times now, and no one has responded.
I don't see the advantage in that combination, which seems rather over the top. I do see the advantage in the combination of
An ordered queue model for theories and applications (since I felt the ordering information would be required in order to decide what to do if you had a shortfall in RP income) which spends in discrete chunks (X RP/turn for Y turns), with a single figures number of simultaneous projects
An ordered queue for refinement which spends in units of 1RP and typically has low single figures of simultaneous projects.
I felt the benefits included:
An increase in realistic player options as to how, when and to what end to do research.
An elimination/minimisation of player perception of wastage or excesive opportunity costs resulting from the limitations on research spending flexibility imposed by the HOI model without requiring us to compromise either the benefits of that model (i.e. designer control over research pace making balancing easier, encouragement of strategic planning by players, natural and clear implementation of the diminishing returns of research) or impose limits on the economy system (i.e. requiring the conversion rate of RP to something else to be the same for all empires if we had straight return of RP into the economy as a solution to opportunity costs, or requiring Research buildings to have low or no maintenance costs to minimise wastage, or even disallowing research infrastructure investment at all.)
A nice aesthetic split between pure research and development.
That said, I'd be perfectly happy with this option:
2) You can start one extra project that you can't quite afford, and every time you accumulate X RPs, one turn of progress is made on it. So in essence, you can partially fund one project to eat up the excess RPs. It will just take more than the usuall Y turns that it takes to research the project at full funding.
Since it's simple, solves the shortfall/surplus RP problem (with one proviso, see below) and if anyone desperately wants refinements we could always implement them simple as series of low cost application projects arising as a result of developing a parent application.
The only condition on this is that we will have to ensure that it is fairly rare for a reasonable player to be caught in a stituation of overcapacity (more RP income than you can spend on all available projects) for a short period. Overcapacity in the long term would obviously be an issue that the player should deal with, but if it were a common short term problem, they'd be back to minmaxing again, and it would be a game design issue.
This could reasonably be achieved with by ensuring a wide tree, so that you're only reseaching part of it at a time, and always have plenty of options, or many have smaller projects that players are likely to skip but leave on the end of their list as soak projects, or by other methods, but at least in this case the constraints are all within the research system.
One question, roughly how many projects are we envisaging players will typically have running and available at one time? i.e. about 3 and 5, or 3 and 20, or more like 10 and 30, what kind of scale?