Redefine difficulty levels

[TiborB]

Well, I suggest renaming current AI modes to easy/moderate/strong (or alike). In addition to the effect of current defensive - aggressive settings, we could add limitations of number of buildings by tribe&mode.

F.e. easy mode of barbarians would impose these limitations:

farms: 2
wood hardener: 1
battlearena: 1
trainingcamp: 0

This would be implemented via ai_hints section for init.lua for each buildings and I would modify the current AI - the change would be quite simple and would do no harm to current AI - aggressive/strong mode would be inaffected of course.

Of course there might be good objection that this would not scalle well for big maps

Opinions welcomed

Related forum threads:

https://wl.widelands.org/forum/topic/1867/

https://wl.widelands.org/forum/topic/1861/

[GunChleoc (gunchleoc)]

Maybe the limitations could be a factor that changes with map size?

[TiborB (tiborb95)]

Or maybe the limitations should depend on gametime - but all this would only bring complexity to this.

I suggest configuration like this, f.e. in smelting_works/init.lua

   aihints = {
      prohibited_till = 400,
      easy_limit = 1,
      moderate_limit = 3
   },

This is trivial configuration, everybody can tinker with it.

This should not stop expansion, only make it slow... and it would simulate poor player that does not have enough buildings of some type.

Of course, I would do a lot of testing with AI and compare teritorry expansion and military strength (during time) of various difficulty levels.

[GunChleoc (gunchleoc)]

I think this would be a good design for the AI hints.

As to a progression according to map size, I was thinking something like

    building_limit = easy_limit * 2 * 64 / (map.width + map.height)

with 64 being the smallest map dimension. Or maybe

    building_limit = easy_limit * sqrt(64^2 / (map.width * map.height))

[TiborB (tiborb95)]

Well, what I dont like about this is that understandability is lost.
'easy_limit = 1' is clear and obvious.
Moreover, more reasonable would be to tie it with actual size of controlled territory, but again this should be done within AI C++ code. Or make it dependable on number of player's buildings. But I dont like complexity here.

With static limitation ai will still be allowed to conquer entire map, only it will take much longer.

I will implement it as a static limit and do some tests and see if it is viable. I will present results of my testing...

Anyway there is still another AI branch waiting for review....

[GunChleoc (gunchleoc)]

I agree - let's start with a static limit.

I have tested the other branch, but not looked at the code yet.

[king of nowhere (lainluigi86)]

well, i brought my point to the forum thread, I should post it here too.

I don't like it because it depends too much on the size of the map and the lenght of the game. on a large map, those limitations mean using a tenth of one's potential, or less. on a small map, they hardly matter. right now, in many small maps the ai is unable to fit a full economy, and cannot produce new soldiers; giving limits to some buildings may even help it, for it won't waste space for useless buildings. similarly, that limitation means that the ai will be just as strong in early game, but it will reach a cap and become useless later.

I see only two ways to make difficulty levels that are equally valid for large and small maps, for early and late game. One is changing the delay times of buildings; if an imperial farm normally produce a wheat in 80 secconds, at easy it may take 100, at hard 60. similarly to all buildings. A second way would be to change the evasion levels of all ai soldiers; currently, barbarian soldiers evade 25/40/55. It may become 32/46/60 (10% less chance to be hit at all levels, rounded) for hard, and 18/34/50 for easy.

Yes, I realize setting hard limits to ai number of buildings is MUCH easier than rewriting a lot of code to make the working time of buildings be difficulty-dependent. although I think evade levels may be easy enough. however, they are the only ways to make difficulty levels that will feel balanced all the way throughout the game. I don't like how some games (civilization the main example) try to balance the ai by giving it starting bonuses, making a computer that is an unstoppable machine in early game, while still being a pushover later.

However, if no one is willing to make all the code changes, then having difficulty levels defined that way would be better than nothing.

P.S. another problem of the limit-oriented difficulty settings is that you'd only be able to define easy difficulty levels. which are fine for beginners, but you can't give good players a better challenge, because as it is ai already has no limits on the buildings it makes.

[TiborB (tiborb95)]

Well, so far I have some C++ changes done and testing it. If they will be used and how, it is secondary as long as the functionality is there. We can do changes as king of nowhere proposed as well, there is no exclusivity.

I can tell that no cap/plato will be achieved, but growth of territory will be slower but continuous. Also prohibiting some buildings we can make sure soldiers are not promoted, or promoted slowly....

I am doing a lot of tests, becouse some aspects must be tested (limitations of specific buildings) because it is hard to say beforehand what results will be. I will keep you informed....

[GunChleoc (gunchleoc)]

Maybe we could also make the prohibited_till/forced_after AI hints dependent on the difficulty? E.g. in easy mode, delay the building of the buildings by a factor.

[TiborB (tiborb95)]

Well this is not bad idea, but generally I dont like modifying silently something that is set explicitly in conf files. but I can imagine additional flags like weak_ai_prohibited_till_ and so on...

It would be trivial to code....

Also I spent some time tweaking these values so, exemptions would be very carefull and should be tested beforehand.

[TiborB (tiborb95)]

In trunk now, of course some attention to lua conf files (limits of buildings) is welcomed.

[king of nowhere (lainluigi86)]

since the previous tags of "offensive/normal/defensive" have been changed to "strong/normal/weak", I have a few things to add about naming of the difficulty levels.

1) until actual difficulty levels are implementing, using terms like strong or weak to indicate the aggressive/defensive behavior is totally misleading. an aggressive ai is in no way stronger than a defensive one. in fact, unless one is playing solo against several ai, aggressive ais are even weaker, because they will suicide troops attacking stronger position. if one is playing a free for all, aggressive ai will kill each other and let the human scoop them up easily. One who does not read the forum will set ai as strong thinking to have a more challenging game, and he will have an easier game instead. So the modification on the treshold to attack should still be named aggressive/defensive. And, if it's not a problem, i think we could keep that option while still introducing difficulty levels.

2) In every single game I can think of, "normal" difficulty means that the ai has neither bonus nor penalties compared to a human. hard levels mean ai is advantaged, easy levels mean ai is disadvantaged. So, if difficulty levels are set by limiting buildings, they should not be named "normal" or "hard". Normal level is the one where the ai has no limitations. Hard (and eventual very hard, insane, godlike, masochistic, or any fancy name we may come up with) level means the ai is getting some specific advantage over a human. All levels where the ai get some limitation should be called easy, very easy, feeble, weak, or something like that.

[king of nowhere (lainluigi86)]

also, may i suggest that, instead of trying to rush this feature to build19 - which will almost certainly cause a few bugs - we leave it out for future trunks, so there is more time to playtest it?

[TiborB (tiborb95)]

So first, limits currently introduced in trunk:

atlanteans dungeon normal_ai_limit 1
barbarians trainingcamp normal_ai_limit 1
empire trainingcamp normal_ai_limit 1
empire arena normal_ai_limit 2
empire winery normal_ai_limit 2
atlanteans sawmill normal_ai_limit 2
atlanteans smokery normal_ai_limit 2
empire brewery normal_ai_limit 2
empire sawmill normal_ai_limit 2
atlanteans labyrinth normal_ai_limit 2
barbarians lime_kiln normal_ai_limit 2
empire colosseum normal_ai_limit 2
atlanteans weaving_mill normal_ai_limit 2
barbarians wood_hardener normal_ai_limit 2
atlanteans smelting_works normal_ai_limit 2
barbarians smelting_works normal_ai_limit 2
empire smelting_works normal_ai_limit 2
empire stonemasons_house normal_ai_limit 2
barbarians battlearena normal_ai_limit 3
atlanteans dungeon weak_ai_limit 0
barbarians trainingcamp weak_ai_limit 0
empire trainingcamp weak_ai_limit 0
empire arena weak_ai_limit 1
empire winery weak_ai_limit 1
atlanteans sawmill weak_ai_limit 1
atlanteans smokery weak_ai_limit 1
empire brewery weak_ai_limit 1
empire sawmill weak_ai_limit 1
atlanteans labyrinth weak_ai_limit 1
barbarians lime_kiln weak_ai_limit 1
empire colosseum weak_ai_limit 1
barbarians battlearena weak_ai_limit 1
atlanteans weaving_mill weak_ai_limit 1
barbarians wood_hardener weak_ai_limit 1
atlanteans smelting_works weak_ai_limit 1
barbarians smelting_works weak_ai_limit 1
empire smelting_works weak_ai_limit 1
empire stonemasons_house weak_ai_limit 1

But generally I dont mind renaming difficulty levels to normal/easy/very_easy.

We had at least one user complaining about the game being too difficult. So if you (king of nowhere) will play on default/stronger mode no difference for you.

Alternatively we can add special bonus of initial wares for strong mode, so levels would be like
Strong = no_limitations_for_buildings + aggressive_attacking + material_bonus
Normal = no_limitations_for_buildings + normal_attacking
Weak = limitations_for_buildings + defensive_attacking

Sounds better?

Yes we need to playtest and finetune this, but AI test shows that even with building limitations, AI is expanding nicely

> ...aggressive ai will kill each other...

AI does not make any difference if enemy is human or AI. Should it do? I think apart of "team mode" which is available even now....

[TiborB (tiborb95)]

Well, I probably have not mentioned but old aggressive=current strong. Absolutely....

[GunChleoc (gunchleoc)]

I have set this back to "Confirmed", because we want to further tweak this. I also linked 2 current forum discussions, but I can't find the original forum discussion.

[king of nowhere (lainluigi86)]

ok, i have observed this new ai in action during some playtesting.

First of all, the limits are malfunctioning. For some reason, the limit of one smelting work seem to apply also to "strong" ai, which should not have any limitation at all. Furthermore, it seems that the ai is building arenas, but it is not using them. I assume the new coding introduced some error somewhere.

Second point about those limits: the only really meaningful limit there is 1 smelting works. smelting works are the slowest buildings after farms. they take around 70 seconds to make a piece of metal. limiting the smelting works to 1 or 2 is a really big blow. even in a small map, where i can afford only one copy of each building, the moment i have 3 or 4 farms, if i have one more space i use it for a second smelting works. so i suggest they are increased to 2 for weak and 4 for normal. except, in small or medium-small maps 4 smelting works are the most you can make work. difficult to balance fixed number independent from map size. but i'd still say 1-2 is too little smelting works.

Other limits are not important, or they are even helping the ai. limit to one lime kiln and one weaving mill? i don't remember, even in the bigger maps, ever needing more than 1. by limiting those to one,, you're actually doing the ai a favor: it won't waste space on useless buildings. same goes for two sawmills - although on occasion i made three of those, even in large maps 90% of the times 2 are enough. if the map is not large, one is perfectly fine. same goes for 2 battle arenas, you need a really big economy to make 2 battle arenas work at full productivity. I remember needing two in one single game.

So, my suggestion would be to increase the limits on smelting works to 2-4 or 2-3 (or 1-3, if we want the weak ai to be really weak), while dropping all the other limits except the one on training camps/dungeons

Re: the names of the levels, I am not complaining about the existance of easy levels. I suggested that we made them myself already 6 onths ago (original link: https://wl.widelands.org/forum/topic/1739/?page=1#post-13757). I merely want it to be clear for a player which is the "default" difficulty level. Alternatively (or additionally), we may add some specific explanations of what the difficulty levels actually do. Just like in many roleplaying games if you hover the mouse over a difficulty level, you'll see explanations like "monsters deal 200% damage" or "player character is immune to paralysis and critical strike", then we could add a similar functionality that will state "ai limited to x smelting works and forbidden to make training camps".

[TiborB (tiborb95)]

Well, I think limits are working appropriately, but I see two issues here:

scoring of trainingsites was affected badly - I have to review this
balance of expansion vs economy building must be reviewed as well

But I dont think this should be done within this bug as it does not relate directly.

But what would be welcomed - review of limits in init.lua files. Volunters welcomed...

What can be done on C++ part is renaming the level names - I am open for this....

NOTE: when AI is being initialized it prints out what limits are set. Look at them if you are unsure whether limits are properly applied.

[GunChleoc (gunchleoc)]

I can take care of the renaming of levels.

[SirVer (sirver)]

What of this is still to be done before b19?

[TiborB (tiborb95)]

I think difficulty levels are not differentiated enough, but this is perpetual task...

[GunChleoc (gunchleoc)]

@Tibor: Do you think that we can set this to "Fix committed" now?

[TiborB (tiborb95)]

Yes, this was more-less implemented

[GunChleoc (gunchleoc)]

Fixed in build20-rc1