Major problem with Focus (6281)

Describe your experience with the latest version of FreeOrion to help us improve it.

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.
Message
Author
User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Major problem with Focus (6281)

#31 Post by Geoff the Medio »

Hihoo wrote:If someone really wants to shoulder the burden of micromanaging
focuses, he should get something out of it.
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.

shawndream
Space Kraken
Posts: 124
Joined: Fri Nov 22, 2013 8:47 pm

Re: Major problem with Focus (6281)

#32 Post by shawndream »

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.
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!

wheals
Space Squid
Posts: 88
Joined: Sun Mar 24, 2013 3:56 pm

Re: Major problem with Focus (6281)

#33 Post by wheals »

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.
Geoff the Medio wrote:
Hihoo wrote:If someone really wants to shoulder the burden of micromanaging
focuses, he should get something out of it.
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.
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.
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.
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?
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.

Hihoo
Space Kraken
Posts: 142
Joined: Wed Oct 23, 2013 8:50 am

Re: Major problem with Focus (6281)

#34 Post by Hihoo »

Especially since an ideal AI player would never have that problem
An ideal AI-player does not and will never exist for any game with this complexity, not by far.

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-
(Excess) micromangement, particularly in large empires, is often given as a problem with many 4X games.
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.

User avatar
Bigjoe5
Designer and Programmer
Posts: 2058
Joined: Tue Aug 14, 2007 6:33 pm
Location: Orion

Re: Major problem with Focus (6281)

#35 Post by Bigjoe5 »

Hihoo wrote:But some players get somehow fun out of micromanagement and I say let them have it - definitely.
No.
Warning: Antarans in dimensional portal are closer than they appear.

shawndream
Space Kraken
Posts: 124
Joined: Fri Nov 22, 2013 8:47 pm

Re: Major problem with Focus (6281)

#36 Post by shawndream »

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.
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...

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!

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Major problem with Focus (6281)

#37 Post by Vezzra »

FreeOrion Design Philosophy
  • 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.
Sorry to disappoint, Hihoo, but what you're suggesting is something we specifically try to avoid.

However, if you are one of those who get a kick out of micromanaging things, you might take a look here :D

Hihoo
Space Kraken
Posts: 142
Joined: Wed Oct 23, 2013 8:50 am

Re: Major problem with Focus (6281)

#38 Post by Hihoo »

if you are one of those who get a kick out of micromanaging things
Look, who really is and who cares?
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

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: Major problem with Focus (6281)

#39 Post by MatGB »

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).
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

wheals
Space Squid
Posts: 88
Joined: Sun Mar 24, 2013 3:56 pm

Re: Major problem with Focus (6281)

#40 Post by wheals »

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.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Major problem with Focus (6281)

#41 Post by Geoff the Medio »

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.
Such a parser wouldn't be overly complicated. The larger issue would be the necessity to track all the additional historical focus change issue.

User avatar
Bigjoe5
Designer and Programmer
Posts: 2058
Joined: Tue Aug 14, 2007 6:33 pm
Location: Orion

Re: Major problem with Focus (6281)

#42 Post by Bigjoe5 »

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.
Warning: Antarans in dimensional portal are closer than they appear.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Major problem with Focus (6281)

#43 Post by Geoff the Medio »

Bigjoe5 wrote:How about each resource has three meters associated with it instead of just two?
My initial reaction is very no. A bunch more data to track, confusing for players, hard to display in the UI.

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.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Major problem with Focus (6281)

#44 Post by Dilvish »

Bigjoe5 wrote:Here's a suggestion ...
I'm not understanding how that suggestion is really supposed to help.

**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

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: Major problem with Focus (6281)

#45 Post by MatGB »

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.
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... ;-)

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.

Post Reply