Various FreeOrion mechanics have been designed with the intent that micromanaging have little or no benefit, so that there is no obligation to do so to play optimally. (Excess) micromangement, particularly in large empires, is often given as a problem with many 4X games.Hihoo wrote:If someone really wants to shoulder the burden of micromanaging
focuses, he should get something out of it.
Major problem with Focus (6281)
Moderator: Oberlus
Forum rules
Always mention the exact version of FreeOrion you are testing.
When reporting an issue regarding the AI, if possible provide the relevant AI log file and a save game file that demonstrates the issue.
Always mention the exact version of FreeOrion you are testing.
When reporting an issue regarding the AI, if possible provide the relevant AI log file and a save game file that demonstrates the issue.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Major problem with Focus (6281)
-
- Space Kraken
- Posts: 124
- Joined: Fri Nov 22, 2013 8:47 pm
Re: Major problem with Focus (6281)
Wasn't the real original problem that by gaming the fact that industry and research are often very different in scale, but they only change by a tiny static amount per turn allows micromanagers to mantain industry almost as high as the max industry, AND also research almost as high as the max research?
The -2/+1, -1/+1, -1/+1... pattern reduces the benefit to micromanaged pumping but does not eliminate it.
For example, imagine someone with 10 planets that could produce 200 industry or 40 tech (with say half of that if they are not focused on the resource).
Someone who left 10 planets set at one or the other could get between 2000pp/200rp and 1000pp/400rp per turn, or anywhere in between with a tradeoff of 5pp per 1 extra rp.
Someone who "pumped" each planet, starting at 200/20, then flipping to research until 179/40, then back to industry until 200/20 again would be averaging better than 189/29 on each planet for the whole 40 turn cycle. Across 10 planets that is 1890pp/290rp.
That is 90 extra rp for a loss of only 110pp.
If a non-pumper wanted the same extra 90rp they would need to sacrifice 90*5, or 450pp, an exchange ratio more than 4 times worse.
The root of the problem is the fixed x point per turn change, regardless of the size of the target.
This causes an exploitable imbalance when the targets are significantly different in scale.
I did some modelling and the closest I could come to a reasonable system that did not seem to reward micromanaged pumping was:
Reduce current by 10% until at target, or increase by 5% target until at target.
if(current > target){
current = max(target, current*0.9)
}else{
current = min(target, current+ (0.5*target))
}
But I haven't fully tested that to make sure there are no situations that reward micropumping (except nonstacking special rotations, but that is an entirely seperate exploit which is made more expensive by this I think).
This design change also increase the overall speed large planets reach their targets, but I think that is for the better.
The -2/+1, -1/+1, -1/+1... pattern reduces the benefit to micromanaged pumping but does not eliminate it.
For example, imagine someone with 10 planets that could produce 200 industry or 40 tech (with say half of that if they are not focused on the resource).
Someone who left 10 planets set at one or the other could get between 2000pp/200rp and 1000pp/400rp per turn, or anywhere in between with a tradeoff of 5pp per 1 extra rp.
Someone who "pumped" each planet, starting at 200/20, then flipping to research until 179/40, then back to industry until 200/20 again would be averaging better than 189/29 on each planet for the whole 40 turn cycle. Across 10 planets that is 1890pp/290rp.
That is 90 extra rp for a loss of only 110pp.
If a non-pumper wanted the same extra 90rp they would need to sacrifice 90*5, or 450pp, an exchange ratio more than 4 times worse.
The root of the problem is the fixed x point per turn change, regardless of the size of the target.
This causes an exploitable imbalance when the targets are significantly different in scale.
I did some modelling and the closest I could come to a reasonable system that did not seem to reward micromanaged pumping was:
Reduce current by 10% until at target, or increase by 5% target until at target.
if(current > target){
current = max(target, current*0.9)
}else{
current = min(target, current+ (0.5*target))
}
But I haven't fully tested that to make sure there are no situations that reward micropumping (except nonstacking special rotations, but that is an entirely seperate exploit which is made more expensive by this I think).
This design change also increase the overall speed large planets reach their targets, but I think that is for the better.
Everything I post is self-created unless noted otherwise. It is simultaneously released under GPL 2.0 or later, CC Attribution-Share Alike 3.0, and GNU Free Documentation 1.2. Make something awesome with it please!
Re: Major problem with Focus (6281)
MatGB wrote:No, you misunderstand the mechanic.
You lose 1 per turn, but this thread is about a change that, on the first turn you change focus, you now lose 2 per turn, to stop a supposed abuse of focus that let players micromanage to get an optimum output (not something I, personally, thought was a problem as that level of micromanaging struck me as pointless).
So now, on the first turn you change focus, you lose 2, but from then on you lose 1.
Except if you've got a planet that changes focus regularly from industry to Send, Receive, Logistics and then back to industry, which will lose 2 for every change it makes until it goes back to industry, so by using tech as it's designed you lose more than is intended.
Oh, OK, I never really noticed that.
I definitely agree that we should never make anybody have to make a tradeoff with tedium. Especially since an ideal AI player would never have that problem and thus would either have to be crippled or force players to micromanage to beat it.Geoff the Medio wrote:Various FreeOrion mechanics have been designed with the intent that micromanaging have little or no benefit, so that there is no obligation to do so to play optimally. (Excess) micromangement, particularly in large empires, is often given as a problem with many 4X games.Hihoo wrote:If someone really wants to shoulder the burden of micromanaging
focuses, he should get something out of it.
This seems like a reasonable enough change, but how would techs that change the rate affect it? Could the 5% number being increased be counterbalanced by increasing the 10% loss?shawndream wrote: Reduce current by 10% until at target, or increase by 5% target until at target.
if(current > target){
current = max(target, current*0.9)
}else{
current = min(target, current+ (0.5*target))
}
But I haven't fully tested that to make sure there are no situations that reward micropumping (except nonstacking special rotations, but that is an entirely seperate exploit which is made more expensive by this I think).
This design change also increase the overall speed large planets reach their targets, but I think that is for the better.
All my code and content provided herein or on GitHub is released under the GPL 2.0 and/or CC-BY-SA 3.0, as appropriate.
Re: Major problem with Focus (6281)
An ideal AI-player does not and will never exist for any game with this complexity, not by far.Especially since an ideal AI player would never have that problem
The winning strength of the human player will always be superior, flexible strategy.
Quite to the contrary: Let the poor AI-devils do what they are best at: crunching numbers.
No need to be afraid of that. But some players get somehow fun out of micromanagement and I say let them have it - definitely. No tedium for them there.
Should anyone develop a fair AI strong enough to beat a really experienced player regularly,
s.o. at ibm+co will raise an eyebrow. Crippling it would be of course one of the options then-
Meaning what? Not that the "to-be-crippled" AI, in spite of assumedly beating all human micromanagement with ease, can't win?? I think what's up here is rather finely tuned human microstrategy. Which is the whole fun discovering.(Excess) micromangement, particularly in large empires, is often given as a problem with many 4X games.
Re: Major problem with Focus (6281)
No.Hihoo wrote:But some players get somehow fun out of micromanagement and I say let them have it - definitely.
Warning: Antarans in dimensional portal are closer than they appear.
-
- Space Kraken
- Posts: 124
- Joined: Fri Nov 22, 2013 8:47 pm
Re: Major problem with Focus (6281)
I don't know about anyone else, but crunching the math to show that flipping a switch at each colony every 40th turn may give me a minor momentary thrill...Hihoo wrote: Meaning what? Not that the "to-be-crippled" AI, in spite of assumedly beating all human micromanagement with ease, can't win?? I think what's up here is rather finely tuned human microstrategy. Which is the whole fun discovering.
but knowing that I will LOSE that efficiency unless I keep track of that and twiddle my colonies focus all the time instead of SUBTRACTS from my enjoyment by making that quickly mundane task compete with the new microstrategy questions arriving freshly each turn like:
- Which fleet can I use to defend these worlds without leaving myself at risk elsewhere?
- Is the war with these guys worth it, or could we have peace instead?
- Which technology should I pursue next?
Everything I post is self-created unless noted otherwise. It is simultaneously released under GPL 2.0 or later, CC Attribution-Share Alike 3.0, and GNU Free Documentation 1.2. Make something awesome with it please!
Re: Major problem with Focus (6281)
FreeOrion Design Philosophy
However, if you are one of those who get a kick out of micromanaging things, you might take a look here
Sorry to disappoint, Hihoo, but what you're suggesting is something we specifically try to avoid.
- What is "micromanagement" ?
- Micromanagement = Evil
- The player should spend his time making interesting and significant decisions: i.e. not making slight tweaks to a huge number of variables.
However, if you are one of those who get a kick out of micromanaging things, you might take a look here
Re: Major problem with Focus (6281)
Look, who really is and who cares?if you are one of those who get a kick out of micromanaging things
why battle something noone around is interested in AFAIK ...
Look up wikipedia on micromanagement and 4X: the "evil" lies with a game getting boresome
cause mm would be NECESSARY, not because it would give a weird kick to some fanatics
So what you SHOULD do is avoid the necessity of mm, don't waste your time otherwise
Re: Major problem with Focus (6281)
K, 2 different issues.
1) was the point of this thread an issue worth coding time. I say no, but Geoff took the decision otherwise and wrote the code. I agree with those that argue micromanagement is bad, but it's something I would never have bothered doing and I never saw it as anything other than a tiny side issue, others disagreed and a change was made.
2) The change made has unintended consequences. That is why I bumped the thread.
I have a planet in my current game that's populated by Nymnh, and is therefore normally set to research. But, I'm playing on low/low/low/low and when conquered it was both at the extreme edge of my empire and outside of supply. As I had Adaptive Automation I told it to, slowly, build a space elevator. And then build a transformer. Because it is now a staging area for my current invasion, and the next AI is more than 15 jumps away, it varies on its settings between Research, Receive, Send (colony ships going back) and Logistics (combines hideously with the Elevator).
Every time that focus changes, the planet loses 2 research output unless it's moving towards research again. Before this change it would only have lost one for each change. I find myself doing maths in my head to decide whether I should make a change this turn, or wait until more ships are planning to change again—jugglign between logistics and research, which would be the ideal choice given the way logistics works, becomes problematic, etc.
So, is this a different micromanagement problem worth worrying about, and if so can it be solved in some way?
(essentially, I'm sorry I raised point 1 in a post about point 2, it's sidetracked the discussion to a solved, done, deal).
1) was the point of this thread an issue worth coding time. I say no, but Geoff took the decision otherwise and wrote the code. I agree with those that argue micromanagement is bad, but it's something I would never have bothered doing and I never saw it as anything other than a tiny side issue, others disagreed and a change was made.
2) The change made has unintended consequences. That is why I bumped the thread.
I have a planet in my current game that's populated by Nymnh, and is therefore normally set to research. But, I'm playing on low/low/low/low and when conquered it was both at the extreme edge of my empire and outside of supply. As I had Adaptive Automation I told it to, slowly, build a space elevator. And then build a transformer. Because it is now a staging area for my current invasion, and the next AI is more than 15 jumps away, it varies on its settings between Research, Receive, Send (colony ships going back) and Logistics (combines hideously with the Elevator).
Every time that focus changes, the planet loses 2 research output unless it's moving towards research again. Before this change it would only have lost one for each change. I find myself doing maths in my head to decide whether I should make a change this turn, or wait until more ships are planning to change again—jugglign between logistics and research, which would be the ideal choice given the way logistics works, becomes problematic, etc.
So, is this a different micromanagement problem worth worrying about, and if so can it be solved in some way?
(essentially, I'm sorry I raised point 1 in a post about point 2, it's sidetracked the discussion to a solved, done, deal).
Mat Bowles
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Re: Major problem with Focus (6281)
Maybe the best solution would be to add a "TurnsSinceFocusChangeFrom <Focus>" valueref that accepts a focus as a parameter? I don't know all that much about the parser so I don't know if you could do that or whether you'd have to create a separate valueref for each focus.
All my code and content provided herein or on GitHub is released under the GPL 2.0 and/or CC-BY-SA 3.0, as appropriate.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Major problem with Focus (6281)
Such a parser wouldn't be overly complicated. The larger issue would be the necessity to track all the additional historical focus change issue.wheals wrote:...add a "TurnsSinceFocusChangeFrom <Focus>" valueref that accepts a focus as a parameter? I don't know all that much about the parser so I don't know if you could do that or whether you'd have to create a separate valueref for each focus.
Re: Major problem with Focus (6281)
Here's a suggestion - it makes things a bit more complicated, but if the alternative is having a TurnsSinceFocusChangeFrom valueref then I don't think that this is any worse.
How about each resource has three meters associated with it instead of just two?
Current meter: Determines how much of a resource is produced, as it does now. Value is set to the minimum of Target and Max.
Target meter: Value is determined by the same rules by which the Current meter value is determined now.
Max meter: Value is determined by the same rules by which the Target meter value is determined now.
The whole reason, IIRC, that we don't just have max meters, but target meters for resource production, is that it's too harsh of a penalty for a player to make a focus change, then decide one or two turns later that he wants to reverse it. But the problem with the current system is that the player still gets most of the bonus from his previous focus even after he changes to another one. This solution solves the problem by chopping off resource production as soon as the player changes focus, while still keeping track of the slowly-decreasing Target meter, allowing the player to regain most of his previous resource production if he changes his focus back. This prevents exploits from micro-focus-changes, while still giving the player leeway when changing focus. My sole concern is that it that it may not be easy or possible to convey the value of the new Target meter to the player in the bar graph, though I'm leaning towards saying that it's not really necessary to do so.
I don't mind implementing this change - it'll be a good exercise to get back into FO after the few months I've been away.
How about each resource has three meters associated with it instead of just two?
Current meter: Determines how much of a resource is produced, as it does now. Value is set to the minimum of Target and Max.
Target meter: Value is determined by the same rules by which the Current meter value is determined now.
Max meter: Value is determined by the same rules by which the Target meter value is determined now.
The whole reason, IIRC, that we don't just have max meters, but target meters for resource production, is that it's too harsh of a penalty for a player to make a focus change, then decide one or two turns later that he wants to reverse it. But the problem with the current system is that the player still gets most of the bonus from his previous focus even after he changes to another one. This solution solves the problem by chopping off resource production as soon as the player changes focus, while still keeping track of the slowly-decreasing Target meter, allowing the player to regain most of his previous resource production if he changes his focus back. This prevents exploits from micro-focus-changes, while still giving the player leeway when changing focus. My sole concern is that it that it may not be easy or possible to convey the value of the new Target meter to the player in the bar graph, though I'm leaning towards saying that it's not really necessary to do so.
I don't mind implementing this change - it'll be a good exercise to get back into FO after the few months I've been away.
Warning: Antarans in dimensional portal are closer than they appear.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Major problem with Focus (6281)
My initial reaction is very no. A bunch more data to track, confusing for players, hard to display in the UI.Bigjoe5 wrote:How about each resource has three meters associated with it instead of just two?
The scenario described by MatGB does not strike me as particularly problematic. If nothing else, it's isolated to a specific situation that is not expected to happen at most planets. Player attention being focused at a planet when it is involved in important stuff is OK; player attention being required at many / most planets every turn is different. IMO the solution would be to again make the penalty harsher, as this planet doesn't seem like one where substantial research activity should be taking place, if it's being used for stargate operations.
Re: Major problem with Focus (6281)
I'm not understanding how that suggestion is really supposed to help.Bigjoe5 wrote:Here's a suggestion ...
**edit** I see Geoff already answered, but I'll leave the post just to second his concern.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: Major problem with Focus (6281)
That at least answers my "is this an actual problem" question. It does so in a way that makes me wish I'd shut up, but...Geoff the Medio wrote: The scenario described by MatGB does not strike me as particularly problematic. If nothing else, it's isolated to a specific situation that is not expected to happen at most planets. Player attention being focused at a planet when it is involved in important stuff is OK; player attention being required at many / most planets every turn is different. IMO the solution would be to again make the penalty harsher, as this planet doesn't seem like one where substantial research activity should be taking place, if it's being used for stargate operations.
So, persuade you it's actually problematic. OK, according to somewhere, the Wiki I think, the current stargate UI is a placeholder for a more intuitive system that doesn't require focus changing. Ergo, if focus isn't, medium term, planned to be affected by stargate use, then the current placeholder system shouldn't, really, punish players overtly, surely?
In addition, a lot of stargate use is going to be going from a developed shipbuilding industrial centre-while you can build ships anywhere, the game design objective is to make shipyards a strategic target, etc. When I'm playing on High planets, I try to make sure that I put my transformers on the smallest, least useful world, not the shipyard/high industry, but on low planets that's not really possible.
So, my shipyards, being at developed systems, end up having less production as the transformer is turned on and off every few turns to send ships to the front.
Now, I can easily justify this in flavour text and in game realism, but is it intended or ideal, especially given the current stargate UI isn't meant to be permanent?
(aside: I've come to the conclusion that the current implementation of Intersteller Logistics is hideously OTT and even on very low planet galaxies devoting one world to give the entire galaxy purple lines is a lot easier than messing around with fueltanks, resupply outposts, multiple space elevators, etc. Strongly suggest changing it to be a doubling effect cumulative with space elevators, it'd still be powerful but not ensure the entire galaxy is covered)
Mat Bowles
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.