FreeOrion

Forums for the FreeOrion project
It is currently Tue Dec 12, 2017 9:27 pm

All times are UTC


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.



Post new topic Reply to topic  [ 14 posts ] 
Author Message
 Post subject: Molecular cloud sequence
PostPosted: Sun Jan 08, 2017 9:41 pm 
Offline
Vacuum Dragon

Joined: Wed Aug 26, 2015 6:15 pm
Posts: 506
At what point in turn processing does molecular cloud interference with ship shields take place? Let's say a fleet is at planet A, where the edge of a cloud has caused shields to go down. Adjacent is planet B, which is not in the cloud, so fleets there still have shields up. If a fleet moves to attack at A, will cloud effect on shields take place before combat?


Top
 Profile  
 
PostPosted: Sun Jan 08, 2017 10:29 pm 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12041
Location: Munich
defaultuser wrote:
At what point in turn processing does molecular cloud interference with ship shields take place? Let's say a fleet is at planet A, where the edge of a cloud has caused shields to go down. Adjacent is planet B, which is not in the cloud, so fleets there still have shields up. If a fleet moves to attack at A, will cloud effect on shields take place before combat?
I believe effect updates don't happen until after combat, and combat happens after movement. So any location-dependent effects should have values from before movement during combat.


Top
 Profile  
 
PostPosted: Mon Jan 09, 2017 2:20 am 
Offline
Creative Contributor
User avatar

Joined: Fri Jun 28, 2013 11:45 pm
Posts: 3291
Yup, in addition if you leave a field and enter combat shields won't be restored until you have a turn combat free. The same is true of variable affects on Stealth, if you leave an Ion Cloud to attack someone you get the stealth bonus in the combat (or if you turn a Spatial Flux hull to aggressive to initiate a combat).

_________________
Mat Bowles

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


Top
 Profile  
 
PostPosted: Mon Jan 09, 2017 4:26 pm 
Offline
Vacuum Dragon

Joined: Wed Aug 26, 2015 6:15 pm
Posts: 506
Interesting. Thanks.


Top
 Profile  
 
PostPosted: Mon Jan 09, 2017 7:28 pm 
Offline
AI Contributor

Joined: Tue Feb 17, 2015 11:54 am
Posts: 224
Is there actually a design reason to not trigger effects before combat?

Taking into account effects of the system where the actual combat happens seems both more intuitive and logical to me. It would also allow ship parts to be scripted that weaken enemy ships in / before combat (e.g. reducing shields in the system or even some "bomb" which explodes and deals damage to all the ships in the system).

_________________
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0


Top
 Profile  
 
PostPosted: Mon Jan 09, 2017 7:35 pm 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12041
Location: Munich
Morlic wrote:
Is there actually a design reason to not trigger effects before combat?
It has to happen at some point. If it happens before something, then the results of that something can't affect the results of the effects... So if effects happened before combat, you might say it's more intuitive for the results of combat to have some impact on whether a ship can use some effect in that system and that defenders should get a turn to attack anything incoming before it can use any such effects. Having more stuff happen after effects are evaluated also means there will be more discrepancies between the results of effects calculated on the server and what the client thinks the situation should be from its own local evaluation of known effect causes and targets.


Top
 Profile  
 
PostPosted: Mon Jan 09, 2017 8:27 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4288
Location: Sol III
Geoff the Medio wrote:
Having more stuff happen after effects are evaluated also means there will be more discrepancies between the results of effects calculated on the server and what the client thinks the situation should be from its own local evaluation of known effect causes and targets.
Well, considering the case in question here that discrepancy would actually be expected by the player: the shields of their ships are shown as down, but after the movement and before the combat the effects would trigger, raising the shields (which creates the discrepancy), combat takes place, final results are seen in the next turn. It's very unlikely that any player would be confused by that discrepancy.

However, that doesn't hold true for a lot of other effects of course.

The basic problem here is, that all effects are evaluated/triggered in the same turn processing phase. However, the type/kind of effects vary widely, some effects would make more sense to be executed before combat, and some would make more sense being executed after combat. To solve this, we'd have to have probably several effect execution phases during turn execution, and specify for each effect/effectsgroup at which phase it should be executed.

That of course will add a new level of complexity to effect execution. But if we want to avoid suboptimal/counter-intuitive effects like the one brought up here, there is no way around that.


Top
 Profile  
 
PostPosted: Tue Jan 10, 2017 3:18 am 
Offline
Creative Contributor
User avatar

Joined: Fri Jun 28, 2013 11:45 pm
Posts: 3291
I like and prefer the current setup (and one tweak I think we need for fighters is to standardise things this way). Ship stats during the orders phase when you're looking at your and your enemies fleets are as they will be for combat the next turn, changes take place after that.

This makes it both easier to explain and, crucially, easier to balance, there are enough other things going on without having to have two different effects phases with uncertainty as to when they'll trigger, etc. Clouds, terrain, etc are applied after movement and combat, stats for the next fight are as displayed: then it's nice and simple.

Sure, it can appear 'wrong' in some cases, but that's a matter of explaining things better.

_________________
Mat Bowles

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


Top
 Profile  
 
PostPosted: Fri Jan 13, 2017 2:48 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4288
Location: Sol III
An approach that is technically simpler isn't necessarily easier to understand. When it comes to how easy or difficult something is to understand, IMO the most important factor is how close it is to what a player intuitively expects. And the farther something is from these expectations, the more explaining you have to do.

Which is why I disagree with your assessment (at least to a certain degree) that sticking with the current setup is "nice and simple". Technically maybe, but the average player does not think in terms of implementation, or the phases in which things are resolved during turn execution. What they know is, a Molecular Cloud reduces your shields. Hence, the natural expectation is that when ships are within that cloud, shields are reduced, when you're not in the cloud, shields are normal. Consequently they'd expect that a shield reducing effect applies to all ships at the same location.

Now, if what happens in the game deviates from that expectation, they are likely to become confused. Considering the case where a fleet jumps out of a system covered by a Molecular Cloud into one that's not covered, meeting enemy ships there and do battle, having the shields of the arriving fleet still down is the lesser issue, because the average player will most likely say: oh, ok, it takes some time for the shields to recover. However, if a fleet jumps into a system covered by a Molecular Cloud, it's very strange that the defenders have their shields down, but the attackers have their shields still up.

While you can probably can come up with some fluff explanation for that case (the shield reducing effect of the Molecular Cloud not taking effect immediately, only after a time of exposure or somesuch), there are most likely other cases, where it's more difficult to come up with reasonable explanations. Mines for example. That an attacking fleet can jump into a system and do battle still at full strength and only after the battle suffering damage from system wide minefields is very counter-intuitive to put it mildly.

Aside from how difficult it is to come up with a reasonable explanation, point is, you have to do additional explaining, as you said yourself:
MatGB wrote:
Sure, it can appear 'wrong' in some cases, but that's a matter of explaining things better.
Which IMO is a bit of a contradiction to what you stated before, that the current setup makes things "easier to explain", and that it's "nice and simple". No, it's not, the moment you need to explain things better obviously things are not so simple and/or close to what a player would intuitively expect that things don't need extra explanation.

I'm not saying that we should change the current setup. I'm just pointing out issues/weaknesses/limitations, which we need to take into consideration when implementing content with that current setup. To bring up the System Defence Mines example from above: in this case I think we either need to implement mines differently, or extend the current setup like I proposed. But having mines that only damage an attacking force after the battle is just plain silly.
MatGB wrote:
This makes it ... easier to balance, there are enough other things going on without having to have two different effects phases with uncertainty as to when they'll trigger
On both accounts: why? I'd expect things to be easier to balance when you get the choice when to trigger them (because you get more fine-tuned control). And why would having two phases introduce uncertainty as to when effects trigger? You'd have to specify for each effect/effectsgroup when they trigger, no uncertainty here?

It will make scripting more complicated, I give you that. In addition to effect priorities, which requires you to keep track of the order in which effects fire, this would get multiplied by the number of phases we'd decide to have. That obviously has the potential to get quite confusing, and IMO that's the biggest issue I see with several effect execution phases.


Top
 Profile  
 
PostPosted: Mon Mar 06, 2017 4:07 pm 
Offline
Vacuum Dragon
User avatar

Joined: Sun Sep 25, 2011 2:51 pm
Posts: 500
Vezzra wrote:
I'd expect things to be easier to balance when you get the choice when to trigger them (because you get more fine-tuned control).
One might argue, that increasing the number of degrees of freedom makes a system more complex, thus balancing the system becomes more complex.

Having said that, I believe increasing the number of effects execution phases might be a good idea.

_________________
[...] for Man has earned his right to hold this planet against all comers, by virtue of occasionally producing someone totally batshit insane. - Randall Munroe, title text to xkcd #556


Top
 Profile  
 
PostPosted: Tue Mar 07, 2017 8:37 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4288
Location: Sol III
em3 wrote:
One might argue, that increasing the number of degrees of freedom makes a system more complex, thus balancing the system becomes more complex.
Definitely. Balancing will become more complex, but that doesn't necessarily mean that it becomes also more difficult. Particularly in case a less complex systems means your ability to balance things becomes restricted, you can have more complex balancing still be easier. Those cases are probably the exception to the rule, but the issue we're discussing here looks like such a case to me.


Top
 Profile  
 
PostPosted: Thu Mar 09, 2017 6:12 am 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4390
I think that in the case of Molecular Clouds and the like, we could probably improve things by making their scripts a little more complicated with regards to non-stationary ships. It might not be so easy to get it perfect, but I am confident we could substantially improve the situation **edit: , at least from the player perspective. From an AI designer perspective, it is much, much easier to let the AI just consider the ships in their current status. Sure, no matter what it would be nice to have the AI consider the proximity of Molecular clouds, but for now they can get by with just considering current ship stats. If the ship stats were going to drastically change on the next turn but prior to combat resolution, the AI would have a much harder time dealing with that. So we should probably put off any such adjustments until such time as we code up the AI to be tracking and considering the presence of such fields. In the meantime we could edit the descriptions to explain that the field effects slowly build up and dissipate, so that when you enter or exit the effect does not change until after the combat resolution phase of the turn.

_________________
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0


Top
 Profile  
 
PostPosted: Thu Mar 09, 2017 7:06 am 
Offline
Creative Contributor
User avatar

Joined: Fri Jun 28, 2013 11:45 pm
Posts: 3291
Having the AI be aware of and able to take into account atmospherics in general is something that, medium term, I would love to see: I really want to setup a variety of nebula effects for example, but I know that it's pretty much not doable in the short term with everything else that's already planned or partially implemented.

Improving documentation of existing effects is of course an ongoing project, there's been a LOT added recently and I'm really behind on looking over it all.

It's correct to say that having multiple stage effects timings would make aspects of balancing both simpler/easier and more complex, but it would also make things far more contentious, right now the only timing consideration is in what order things are resolved in the same step, if we also have to choose in which step something is resolved there are going to be a LOT more occasions where some of us disagree strongly.

The current turn sequence Keeps It Simple, the stats of a ship displayed during the Orders phase are what will apply during Combat and then at turn end effects are applied and production happens, so if you've entered or left a cloud your stats are changed for display and decision making in the next orders phase and for the next combat round.

I, personally, really like that simplicity and it makes balancing decisions fairly straightforward: yes, more granular control would make getting the cost/benefit of some things easier, but it will take more testing and in some cases a LOT more discussion: if people think that that sort of change would be a good one it's way beyond me and we'd deal, but given existing complexities not sure it's an approach we want to move towards in the near future.

_________________
Mat Bowles

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


Top
 Profile  
 
PostPosted: Thu Mar 09, 2017 9:30 am 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4288
Location: Sol III
Dilvish wrote:
So we should probably put off any such adjustments until such time as we code up the AI to be tracking and considering the presence of such fields. In the meantime we could edit the descriptions to explain that the field effects slowly build up and dissipate, so that when you enter or exit the effect does not change until after the combat resolution phase of the turn.
I agree on both accounts.

I definitely don't want to even touch this for 0.4.7, and even afterwards we probably have enough other things we'd want to do first. That said, adjusting the fluff explanation for the fields like you suggest here sounds like a very good idea to me, and can and probably should go in for 0.4.7.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ] 

All times are UTC


Who is online

Users browsing this forum: Bing [Bot], EnLightning and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group