Unaltered Gameplay Mantra

[Roland Johansen]

Building a deduction function into BUG would certainly do it, and might not be as hard as you think.

Another solution is write a mathematical proof that it CAN be determined, then go ahead and display the information without performing any deduction. Assuming the proof is valid, it will be just as effective for auditing the "unaltered gameplay", as the source code of a deduction function.

I think I can mathematically prove that it cannot be always determined. For instance in a dual game, when you meet your only opponent, it will not always be possible to determine the value of the random variable. Only when the relation slowly shifts will you be able to determine the value of the random variable once you cross the threshold value that changes the relation with an opponent. But you cannot mathematically prove that relations will shift (allthough they typically do during a game).

Programming BUG to determine the value of the random variable per opponent is possible if the programmer has good deductive reasoning skills and knows the exact formula being used by the game and is willing to do the effort. Taking into account all factors can be more of a bookkeeping task than a deductive reasoning task.

I guess that a way to program such an algorithm to determine the random variable would be along the following lines:
A) calculate sum of non-random attitude modifiers
B) check diplomatic relations ingame(furious, annoyed, cautious, pleased and friendly)
C) determine the value of the attitude modifier that is linked to the current diplomatic relations (for instance attitude is between -3 and +3 for cautious)
D) compare the value of A and C and determine the interval of the random modifier (for instance between 0 and 4)
E) repeat every time A or B changes and try to narrow the interval you get in D with each itteration.

 

[ruff_hi]

EF and I chatted last night and we will probably release a BUG-FE (BUG Fully Exposed) version that has several levels of exposure.

Level 0 - BUG
Level 1 - BUG + basic XML stuff, not leader specific
Level 2 - leader specific stuff (real relationships, too advanced, etc)
Level 3 - include random stuff too (forgetting tech trades)

Current thinking is that there will be a value in an ini file that turns on BUG-FE that is not available from the BUG option screen (ie you have to manually edit the ini file and set a value from FALSE to TRUE).

Once that option is TRUE, a new espionage mission will be shown (BUG-FE) that controls what level of information (see above) you can see. The more you spend on espionage, the more BUG-FE will reveal.

So - thoughts? You like / You hate? What about this linkage to espionage? What elements should be in which level? Is 3 levels enough? Should we have more?

 

[DaveMcW]

Well, my opinion is that stupid hidden variables are a correctable user interface error, just like the lack of WHEOOHRN on the player list is a correctable user interface error.

I'd hate to have to pay espionage to get the fix.

 

[ruff_hi]

I'd hate to have to pay espionage to get the fix.

Just to clarify - you wouldn't have to spend EPs. They BUG-FE 'missions' would act in a similar way to other passive spying (ie 'city visibility' or 'see research'). You gain it after you accumulate enough EPs against an AI. You lose it if you fall below a threshold.

 

[obsolete]

Note that I do feel that you should be given the AIs actual disposition toward you when you have vassals. That the interface can flagrantly lie to the player is obscene, and it's usually quite simple to gauge.

This problem threw me for a big loop when I first stumbled into it. Yes, Firaxis doesn't tell you ANYTHING that is the source of the problem.

I don't think Firaxis purposly tries to lie, it's just their terrible lack of polish on the GUI causes a lot of misleading conclusions.

This reminds me back to the weehorn. Years ago I noticed this happens just before someone gets backstabbed. I THOUGHT this was supposed to be super-secret stuff, and that I had stumbled upon a bug. I thus tried not to TAKE advantage of it, and tried to not check this feature. But then I noticed everyone else on the higher levels was checking this constantly... as though it were not a big exploit. And then Bug ended up making it a regular feature, and NOT an exploit.

I don't know the word on Firaxis about this, if weehorn is supposed to be secret or not but hell.... I just decided to lump it into the rest of the features now that perhaps were NOT supposed to be secret at all, it's just Firaxis' was so damn lazy with the GUI again....

I think now a LOT of what I THOUGHT was supposed to be a secret, really wasn't, it's just laziness in regards to their GUI coding.

 

[EmperorFool]

I don't want to make excuses for anyone, but keep in mind that designing a functional and easy-to-use-and-learn UI is hard as $#@&%. Most game programmers never get a chance to learn good UI skills.

 

[ruff_hi]

The other issue is that the people designing and coding the screen only get 1 or 2 weeks to do it and once they finish they find that the people coding the underlying dynamics have changed things. Just ask Impaler[WRG] who worked on Colonization.

 

[Roland Johansen]

This problem threw me for a big loop when I first stumbled into it. Yes, Firaxis doesn't tell you ANYTHING that is the source of the problem.

I don't think Firaxis purposly tries to lie, it's just their terrible lack of polish on the GUI causes a lot of misleading conclusions.

This reminds me back to the weehorn. Years ago I noticed this happens just before someone gets backstabbed. I THOUGHT this was supposed to be super-secret stuff, and that I had stumbled upon a bug. I thus tried not to TAKE advantage of it, and tried to not check this feature. But then I noticed everyone else on the higher levels was checking this constantly... as though it were not a big exploit. And then Bug ended up making it a regular feature, and NOT an exploit.

I don't know the word on Firaxis about this, if weehorn is supposed to be secret or not but hell.... I just decided to lump it into the rest of the features now that perhaps were NOT supposed to be secret at all, it's just Firaxis' was so damn lazy with the GUI again....

I think now a LOT of what I THOUGHT was supposed to be a secret, really wasn't, it's just laziness in regards to their GUI coding.

I personally still believe that it is a buggy feature. I think the designers didn't want the AI to be able to be dragged into a war while it was preparing for another war or was actually in another war. They didn't really think it through that creating a unique refusal message for this case would alert the player to the spoiler information that the AI was preparing for a war. It's a pity actually as it takes away part of the tension about war declarations and makes the AI war preparations much easier to counter for the human. It could also have been easily avoided by making the AI refusal message a non-unique one, one that is also used in other cases. You might still guess that the AI is preparing for war in some obvious cases, but you wouldn't know.

However, since the information has been readily available for everyone since the first implementation of civ5, I think it's great that it is more easily accessible in the BUG Mod.

 

[obsolete]

I personally still believe that it is a buggy feature. I think the designers didn't want the AI to be able to be dragged into a war while it was preparing for another war or was actually in another war. They didn't really think it through...

I think you hit the nail right on the head there... That's exactly what it feels like.

 

[EmperorFool]

Except if that's all they wanted, it would have been far less work to assign an existing DenialType. Instead, they had to create a new type, get a writer to come up with something descriptive but nebulous, and have their translators translate it.

That's a lot of work to be done by accident in my view.

 

[Roland Johansen]

Except if that's all they wanted, it would have been far less work to assign an existing DenialType. Instead, they had to create a new type, get a writer to come up with something descriptive but nebulous, and have their translators translate it.

That's a lot of work to be done by accident in my view.

I think that the existing DenialTypes just didn't fit, not general enough. Maybe it was added in a late stage of development when they realised that getting an AI to declare war when it already was at war or was planning a war was a bad thing.

 

[EmperorFool]

Sure, but they had a much simpler solution: make it cost a lot more. If they'd DoW for 3 techs, make the price 6 techs. Can't pay it? Then they just give you the "not enough" denial. You'd rarely have that many techs over an AI, and if you did you wouldn't care if they went WHEOOH. Problem solved.

No, I think it was entirely intentional. It doesn't really matter, though. BUG has exposed it for the masses.

 

[Roland Johansen]

Sure, but they had a much simpler solution: make it cost a lot more. If they'd DoW for 3 techs, make the price 6 techs. Can't pay it? Then they just give you the "not enough" denial. You'd rarely have that many techs over an AI, and if you did you wouldn't care if they went WHEOOH. Problem solved.

No, I think it was entirely intentional. It doesn't really matter, though. BUG has exposed it for the masses.

Okay, I understand your reasoning, but don't think that's an ideal solution either. So I can put forth reason why I think so, but I guess that we'll keep disagreeing. So let's agree to disagree. In the end, we can't look into the minds of the program designers.

Oh, and I fully agree with adding it to the BUG mod, but I have said that already.

 

[EmperorFool]

Fair enough. I think being a coder myself I tend to give other coders the benefit of the doubt. I often see users whining about how "easy" it would have been to add feature X or Y and how the coders were stupid or lazy for not doing it.

I always imagine these are the same people who would yell at firefighters for getting there stuff wet after saving their burning house.

 

[Roland Johansen]

Fair enough. I think being a coder myself I tend to give other coders the benefit of the doubt. I often see users whining about how "easy" it would have been to add feature X or Y and how the coders were stupid or lazy for not doing it.

I always imagine these are the same people who would yell at firefighters for getting there stuff wet after saving their burning house.

Nah, I would not say that. I often work together with programmers so I don't underestimate the amount of work a seemingly easy feature can be or how it could mess up other parts of the code.

However, designers often start a project with some big lines and ideas and some details and changes are added later. If a detail is added in a very late stage, then the decision that is taken at that point is not necessarily the best one and the one who takes the decision is not always the one most suited to take the decision (lack of knowledge about that part of the project). It's rarely the coders fault is something goes wrong at that stage of the project.

I just think the designers didn't think this one through long enough, maybe because it was added in a late stage. But that idea is also related to my personal preference for not knowing whether someone is planning to go to war.

The fact that BUG made the feature more readily available is very logical and I agree fully with that decision.

 

[EmperorFool]

In this post, Elkad requested that the list of buildings be shown in a hover when pointing at the city bar for rival cities. Does this fit into UG? The argument is that you can look at the graphics on the map if you zoom in and pan the camera around. I've done this, and it's iffy most of the time, probably because I've only done it a few times and don't recognize all the buildings.

• Are the graphics updated even when you cannot see the plot with a unit? IIRC, religions and corporations update even when the plot isn't visible.
• Are all building graphics shown regardless of the size of the city?
• Should we show the list in a hover?
• Should we require plot visibility, either by a unit or the city visibility espionage mission?

I'm pretty sure I can make it happen by making the city selectable. I'll have to make sure this doesn't have other ramifications like showing the city's build queue when you shouldn't see it.

Edit: Never mind, making the city selectable also makes the city bar show all the details: what the city is producing, turns until growth, etc. The code that draws the city bar is in the EXE, so I see now way to fix it.

 

[obsolete]

Fool, I'm thinking back now to the arguement regarding that you should be able to SEE INSIDE a city, before you make a decision to raze or keep it. This seems to be another not-well thought out procedure on Firaxis' part. You don't even get to look at your own city, you can only raze, or keep it BEFORE you even see what specialists are inside.

I suppose, it is possible that Firaxis MEANT it to be this way (gambling nature), but I don't think so. What does everyone else think? There is an exploit around this, if you turn off that quick-combat mode and other features you can hit the city view hotkey a split second after capturing the city, and the city view pops up before you have to make your razz decision. So weather this is a cheat or not is a good question. If we can agree it's not a cheat, then perhaps bug can add a city-view feature to pop up just before the raze request is due?

 

[EmperorFool]

I have requested a feature for PieceOfMind's Advanced Combat Odds mod that I want to run by you guys as to it's UGness. When you have a unit selected and hold-right-click on an enemy unit, it shows you the probabilities of the various outcomes. My idea is to allow you to hold down control or shift and see the stats as if the battle were in the other direction--the defender was attacking your selected unit. In fact, we would have it select the best attacker from the tile you hover over.

It doesn't show you any information you cannot get already (unit type, strength, promos, etc). But it does perform battle calculations that you'd have to do manually. Of course, ACO does this too, so I think we've already crossed that bridge.

 

[ruff_hi]

My idea is to allow you to hold down control or shift and see the stats as if the battle were in the other direction--the defender was attacking your selected unit. In fact, we would have it select the best attacker from the tile you hover over.

I'm not 100% sold on this. Sure, the player can calculate it by hand (peek into the AI stack, select the attacker, calculate the battle odds) but what player actually does that. More than likely, the player's action is something like ..

"Hmm - might defend here - should clean up"
"Ouch - this is going to hurt ... probably better to run away"

... or something like that. So, how about we either provide a general indication of stack v stack (somehow) or an approximate victory percentage (rounded to nearest 10% or 20%).

I see this as mainly useful for 1 v 1 units (ie scout v bear) and decisions on run away or hold and defend. It might also be useful in 1v1 attack situations (ie city defended by warrior with barb warrior at your gates - do you attack or defend?). I don't see it as useful when facing a huge stack of AI units - too hard to get a handle on.

 

[phungus420]

In fact, we would have it select the best attacker from the tile you hover over.

I tried getting this to work, and couldn't figure it out. Kept failing to compile the few ways I tried. For one, gc.getBestAttacker doesn't exist. I tried creating it in CV.Plot, but it said something about the Body already being full (presumably by gc.getBestDefender). I ran out of ideas. Of course you understand C++ infinatly better then I, but it's not a trivial thing to get to work by any means.

Having it show the best defender attacking is working flawlessly though, in the testing I've done.