Opened 11 years ago

Closed 6 years ago

#1834 closed enhancement (wontfix)

[PATCH] Allow random maps to restrict the gamesetup mapsize choice

Reported by: FeXoR Owned by:
Priority: Should Have Milestone:
Component: UI & Simulation Keywords: patch
Cc: Patch:

Description (last modified by elexis)

Some RMS are not working properly with many players on small maps. The same is true for some maps generated with only 1 or 2 players. So we decided to add a maximum and minimum possible number of players for RMS: http://www.wildfiregames.com/forum/index.php?showtopic=16242&st=120#entry262340 It's now an additional possible attribute "MaximumPlayersByMapSize" and "MinimumPlayers" in the RMS json files. This is handled in gamesetup.js that has some new global constants to handle things if the map does not define player caps. luziferius helped by testing all the RMS if default max player caps [4, 6, 8, 8, 8, 8, 8] are still to high so he might be added to the contributor list. Lower player caps are not set properly yet. Still testing.

Attachments (3)

gamesetup_playerCapsForRms.diff (36.4 KB ) - added by FeXoR 11 years ago.
SVN diff
gamesetup_playerCapsForRms.zip (33.0 KB ) - added by FeXoR 11 years ago.
All changed files in a zip
Timy8Players.jpg (119.5 KB ) - added by FeXoR 11 years ago.
Screenshot of a Tiny map with 8 Iberian players

Download all attachments as: .zip

Change History (30)

comment:1 by FeXoR, 11 years ago

Description: modified (diff)
Keywords: patch added

comment:2 by FeXoR, 11 years ago

While I edited gamesetup.js some parts seam kludgy to me. I tried to make things more sane and assuming less. Still some things wont work like setting the number of players combobox data and values to something like [2, 4, 6, 8] because some values are skipped.

The function onGameAttributesChange() seams quite messy to me so I stood away from it as far as I could.

comment:3 by FeXoR, 11 years ago

Just set the minimum players to 2 for Canyon.

This is also good for testing if everything works properly.

AFAIK everything works. Still comments/suggestions/mentioning of flaws welcome.

Last edited 11 years ago by FeXoR (previous) (diff)

comment:4 by FeXoR, 11 years ago

Made all changes to player caps as said in the forum:

http://www.wildfiregames.com/forum/index.php?showtopic=16242&st=160#entry262859

I wait for a team member to decide what to do about RMS problems arise with the Iberian civ bonus walls on Small size (as said in the above linked post). NOTE: On Tiny maps by default no Iberian civ bonus wall is placed ATM.

Last edited 11 years ago by FeXoR (previous) (diff)

comment:6 by FeXoR, 11 years ago

The maximum player caps by map size are now automatically added to the RMS description in gamesetup.js.

comment:7 by FeXoR, 11 years ago

Minimum player caps (if present) are now automatically added to the RMS description as well. Should be quite readable/understandable now.

comment:8 by FeXoR, 11 years ago

Now player caps description should be understandable.

Last edited 11 years ago by FeXoR (previous) (diff)

by FeXoR, 11 years ago

SVN diff

by FeXoR, 11 years ago

All changed files in a zip

comment:9 by FeXoR, 11 years ago

Found typo in gamesetup.js line 468: "by map size" (always referring to the line in the patched version)

To line 147: players[0] is not so bad. Changing DEFAULT_NUM_PLAYERS_RMS to 2 and line 143 to i = 2 will work without additionally changing line 147. This would set the default minimum number of players to 2 in RMS. IMO assuming less in code is not a bad idea.

Line 1163 and 1165 is at least hard to read...

Version 4, edited 11 years ago by FeXoR (previous) (next) (diff)

comment:10 by O.Davoodi, 11 years ago

Keywords: review removed

Thank you for the patch. I studied it and here is the result:

in line -137/138 we have: numPlayersSelection.selected = DEFAULT_NUM_PLAYERS_RMS - players[0]; Is there any reason behind having "players[0]" instead of number "1"?

in line -518: "parseInt" is unnecessary I think because list_data is integer by itself.

in line -795: As Math.min(DEFAULT_NUM_PLAYERS_RMS, playerCaps.max) should always return 2, you can replace the line with: PlayerData: g_DefaultPlayerData.slice(0, Math.max(2, playerCaps.min)),

Other than these, it seems OK.

comment:11 by historic_bruno, 11 years ago

Keywords: RMS numPlayers player caps gamesetup gamesetup.js removed

Yeah, please don't use e.g. parseInt in any case per the coding conventions. We prefer using the '+' operator to convert a string to a number, if needed.

comment:12 by FeXoR, 11 years ago

Thanks for the review.

The main question however is: Do you want to allow RMS to limit player settings?

If this is the case do you whant it to be capped in the gamesetup.js? And if so do you want the global DEFAULT_NUM_PLAYERS_RMS removed and replaced with 2 whenever it is used?

in reply to:  12 ; comment:13 by O.Davoodi, 11 years ago

Replying to FeXoR:

Thanks for the review.

The main question however is: Do you want to allow RMS to limit player settings?

If this is the case do you whant it to be capped in the gamesetup.js? And if so do you want the global DEFAULT_NUM_PLAYERS_RMS removed and replaced with 2 whenever it is used?

Yes, yes, and no. There is no problem with that global constant. I don't want to use unnecessary functions like min and parseInt.

in reply to:  13 ; comment:14 by historic_bruno, 11 years ago

Replying to FeXoR:

The main question however is: Do you want to allow RMS to limit player settings?

Replying to Spahbod:

Yes, yes, and no. There is no problem with that global constant. I don't want to use unnecessary functions like min and parseInt.

This is being semi-officially discussed in IRC from time to time, I haven't seen a firm decision on player caps yet. I personally oppose the idea for several reasons, I think quantumstate is leaning against it, while some others think it's a good idea, here's the latest discussion: http://irclogs.wildfiregames.com/2013-02-23-QuakeNet-%230ad-dev.log @ 20:51.

(Just stating this so we're all on the same page)

in reply to:  14 ; comment:15 by FeXoR, 11 years ago

Replying to historic_bruno:

Replying to FeXoR:

The main question however is: Do you want to allow RMS to limit player settings?

Replying to Spahbod:

Yes, yes, and no. There is no problem with that global constant. I don't want to use unnecessary functions like min and parseInt.

This is being semi-officially discussed in IRC from time to time, I haven't seen a firm decision on player caps yet. I personally oppose the idea for several reasons, I think quantumstate is leaning against it, while some others think it's a good idea, here's the latest discussion: http://irclogs.wildfiregames.com/2013-02-23-QuakeNet-%230ad-dev.log @ 20:51.

(Just stating this so we're all on the same page)

Thx!

I'll hopfully be able to update the patch within a weak. Guess the discussion will take longer anyway.

My point of view: This patch (or something similar) is meant to allow the RMS designer to restrict map size to player ratios the map does not support. Most of the times this settings will result in a map quite similar to other RMS that may be playable with this map size to player ratio anyway because with many players on small maps there is not much space left to design. The player caps we choose seam reasonable to me though we have indeed not checked if some of the random maps can support more players like the default [4, 6, 8, 8, 8, 8, 8]. That could be done ofc. to make sure player caps are as unrestrictive as possible while still all possible settings working well. I don't think however that all RMS has to support 1-8 players on all map sizes. RMS not supporting 1 player can still be tested alone by setting the AI of the second player to noone (Not sure about the name). Tiny maps with 6+ players are quite crowded and the request to grant the players a base with only resources as obstructions with a radius of about 25 RMS tiles leave little room for map design. Debugging those edge cases seam a waste of work for me.

The common approach for RMS in commercial games is one of those:

  • Symmetric: Most RMS are symmetric and thus quite unnatural. This is not the best way for a game claiming to be as realistic as possible so at least some maps should go more irregular ways of generation.
  • Mainly empty: The other alternative (like most maps in e.g. Empire Earth) are mainly empty though much more natural than symmetric ones. On such maps its much harder (to impossible) to guarantee that players are placed fair. In 0 A.D. specifically map sizes are quite small compared to the space a player needs for his buildings. So it's even harder because maps are far from empty.

I think both types should be present in 0 A.D.. Variety is good in this case though some categories like "Multiplayer Optimized" and "Realistic, might not be fair!" might help the user.

However, saying things like "again, that's the map designer's responsibility. on a land map, the enemy should always be reachable, it should be enforced by constraints" does not fit because not all RMS work with constraints.

On the one side saying "it's the map designer's responsibility to make sure a map is at least playable on any settings it accepts, IMO" and on the other hand oppose player caps chosen by the map designer seam a bit strange to me.

A setting in the config file like "capPlayersAsSuggested" would be the best way IMO that is turned on by default and can be turned off. I don't have any idea though how to get this setting in the gamesetup.js file though.

Sidenote to quantumstate: Sensibly define "ugly", plz (so not "yucky" or "http://trac.wildfiregames.com/attachment/ticket/1834/gamesetup_playerCapsForRms.diff"). This word alone does not help me in any way to make the patch "less ugly".

Last edited 11 years ago by FeXoR (previous) (diff)

in reply to:  15 ; comment:16 by Jonathan Waller, 11 years ago

Replying to FeXoR:

Sidenote to quantumstate: Sensibly define "ugly", plz (so not "yucky" or "http://trac.wildfiregames.com/attachment/ticket/1834/gamesetup_playerCapsForRms.diff"). This word alone does not help me in any way to make the patch "less ugly".

I said this was ugly because you are creating a map which loads other maps. It seems much cleaner to keep the maps as map generators and keep the random map selection code with the rest of the map selection code in the GUI area. (Hopefully I have correctly interpreted what you meant in (3)).

in reply to:  16 comment:17 by FeXoR, 11 years ago

Replying to quantumstate:

Replying to FeXoR:

Sidenote to quantumstate: Sensibly define "ugly", plz (so not "yucky" or "http://trac.wildfiregames.com/attachment/ticket/1834/gamesetup_playerCapsForRms.diff"). This word alone does not help me in any way to make the patch "less ugly".

I said this was ugly because you are creating a map which loads other maps. It seems much cleaner to keep the maps as map generators and keep the random map selection code with the rest of the map selection code in the GUI area. (Hopefully I have correctly interpreted what you meant in (3)).

Ah, my fault, thought you meant the patch (I wouldn't blame you for that but for not saying anything specific). Yes, you perfectly answered my question, thx!

in reply to:  15 comment:18 by historic_bruno, 11 years ago

Replying to FeXoR:

However, saying things like "again, that's the map designer's responsibility. on a land map, the enemy should always be reachable, it should be enforced by constraints" does not fit because not all RMS work with constraints.

I'm using "constraints" in the general sense, every RMS should have constraints, the alternative is just totally random distribution of everything which would be an awful map :) You need constraints like minimum base size, distance between players, distance to resources, water, etc. And if it's an island map, they should be connected be water, but if it's a land map, they should all be connected by land. The technique used to do that is part of the implementation, but every good RMS needs those considerations. I don't see why we need to cover up bad RMS scripts with confusing arbitrary match setup restrictions.

AFAIK in the AoE series, random maps didn't have these problems because even on tiny maps with 8 players, it had logic to ensure paths existed between players and spacing was adequate. Whether the resulting map looked natural or ugly is a different matter and completely subjective, and why it's possible to abort a game and try again with a different seed :)

It's not feasible to determine every combination of good or bad map settings let alone define them, that's why we provide options, so let's keep providing those options instead of fixing problems that don't exist and ignoring the ones that do.

comment:19 by FeXoR, 11 years ago

Reply to historic_bruno: Generally I agree but I'm also certain that realistic looking maps have a place in this game. ATM I think the most realistic RMS is Belgian Uplands but it fits your "totally random distribution" case and so would be considered an awful map by you? Just to make it clear: This map does not need any player restrictions and in general its just not as fair as other maps but player distance etc. is checked. However, it is not guaranteed that players are not separated by water or wood though I never saw that appear.

For most maps it would indeed be better to fix the issues there (like Canyon with one player). However, I'm not able/willing to go through all the maps I didn't even make and fix bugs. I am trying to specify all bugs and get someone to fix them though. If no one reacts I might indeed fix many of them myself but this would take much longer.

AoE 2: AoK/AoC had no problems with 8 players on a tiny map because a base in AoK/AoC had about 10 tiles radius (Tiny maps have about the same size in tiles as in 0 A.D.). I thought I said this before in the last comment. Not sure about AoE 1. Part of the problem is that you can't "snap" buildings together due to non-tile based foundations (For me a disadvantage of 0 A.D.).

I'm not so sure about the player caps but I am sure that e.g. Iberian Civ Bonus Walls does not work on Tiny maps with 8 players with the wanted base radius of about 20 tiles (Some of the team e.g. Mythos would like to have even more space for bases): The map radius on a tiny circular map is 64 tiles. The distance of the map border to the center of the players bases have to be at least 20 tiles. If players start positions are placed in a circle of radius 44 (maximum) it has a circumference of about 280 tiles. Distributed equally among the players that makes 35 for each player. They need at least 40 though. So in my book 8 players do not really fit on a tiny map. Because of this we (mainly Spahbod and me) decided not to place Iberian Walls on tiny maps. This could be considered a bad decision because the bonus should not depend on map size. I'm not sure but it works better IMO so it's reasonable.

A screen shot of a tiny map with 8 Iberian players (NEW RMS Test with Iberian Walls enforced): http://trac.wildfiregames.com/attachment/ticket/1834/Timy8Players.jpg

Last edited 11 years ago by FeXoR (previous) (diff)

by FeXoR, 11 years ago

Attachment: Timy8Players.jpg added

Screenshot of a Tiny map with 8 Iberian players

comment:20 by wraitii, 11 years ago

Chipping in: the problem of maps where some players can't reach the others exists even on huge maps (worst offender might be alpine valleys) and is mainly caused by the map being wrong). In the case of alpine valleys, it probably should be redone, it's too slow to generate and the result is mildly ugly. But that is not related to what is being discussed here, ie whether to allow a human to play all maps on any size with X players.

About the actual problem discussed here: some maps might not generate properly with 8 players on a tiny map. These should probably either be changed, or if they can't, not support such a number of players (I'm thinking most could be changed. Even Corsica&Sardinia gives a mostly sound result, although it's really really really crammed). Maps with 8 players, as long as they generate soundly, should be allowed. But in some cases, it might make no sense. If this is properly advertised (perhaps next to the map name), I don't see it as an issue to disable some player numbers on some maps, so that they remain true to themselves.
(what I mean by 'not generate properly' is both that they will simply do something dumb, or that the result will be so different from the expected biome that it's basically just a different map that should be used, to give the same result in better. Alpine Valleys, again, is basically a flat snow map with a sort of hill in the middle. Not what it should be. Contrarily, Pyrenean Sierra remains what it should be. It is crammed, but it's what it should be, so I say it works.)

Now about the "types of maps" you discussed, FeXoR, I'm not sure what point you're trying to make. "Realistic" maps in 0 A.D. are fundamentally flawed because the maps are too small for really random distribution, and would be really unfair. I'm thinking unfairness should really not be allowed too much in random maps (to some extent, of course. But not too much).There are ways to ensure this: creating resources not too far from the player bases, creating some elements of symetry… Using the RM constraints properly to distribute resources semi-randomly. We should probably stray away from maps that could be completely unfair (ie one side has all the gold, the other all the silver). But this is also another problem than the one at hand here.
(basically, if a map is fair for the first 10/15 minutes, it's fair enough. Beyond that, free game).

Last edited 11 years ago by wraitii (previous) (diff)

comment:21 by FeXoR, 11 years ago

I try to explain:

  • Tiny maps can not be generated fitting the "Design Tips and Conventions" for 8 players (mainly the players base size): http://trac.wildfiregames.com/wiki/Random_Map_Generator
  • "Totally random" realistic maps fit to the basic idea of 0 A.D. (being as realistic as possible) but not the "taste" of some players. So both - "Realistic" and "Optimized to be played" RMS types - have there place in 0 A.D. IMO.
  • Player restrictions might be not the best idea but expecting RMS to be unproblematic with many players on small map sizes is just unrealistic.
Last edited 11 years ago by FeXoR (previous) (diff)

comment:22 by wraitii, 11 years ago

imo, tiny maps need not have "enough" space in regards to the design tips and conventions. They're obviously crowded. So that's a non-issue, to me. The real issue is wether the map "works" or not.

About totally realistic (ie random) maps. I agree that they could suit the tastes of some players. I would however suggest grouping them in a specific category.

(again, I am not against player number restrictions. I just think we should only use them if the map fails. If it's simply too crowded, but there are no bugs, then I'm fine with it).

Last edited 11 years ago by wraitii (previous) (diff)

comment:23 by FeXoR, 11 years ago

I agree to add a "More realistic but less balanced" category or such. ATM there's only a note in the map description of Belgian uplands saying "An experimental map with its hightmap generated by erosion to look more natural. Not all seeds will be fair though! Tiny maps with 8 players may take a while to generate.".

Making the player caps less restrictive so they only avoid bugs would be OFC possible but in this case I agree fixing the bugs in the maps is more suitable. Still not sure especially when the "bug" is caused by the Iberian Civ Bonus Walls or Towers. Those can be fixed by just not placing them but that would also defeat the idea of the Civ Bonus for Iberians. I have not much time ATM otherwise I'd started looking into/fixing/mentioning/delegating some RMS issues to get a better overview.

Last edited 11 years ago by FeXoR (previous) (diff)

comment:24 by historic_bruno, 11 years ago

I think most of the random maps need an overhaul and possibly the random map generator itself. For one thing, they shouldn't take more than about 10 seconds to generate on even the largest settings on moderate hardware. It's ridiculous if it takes 30 seconds, 1 minute, or longer. They also need improvements aesthetically and for strategy. Mythos' example biomes topic on the forums should be a guide for how the maps are to look.

It wouldn't be terrible to start over with only 2-3 random maps that are good, providing a blue print for adding others. That's a big challenge but worth it IMO. If we can make them fast enough, we could even have a "live" preview of the map in match setup. One of the reasons games don't have random maps: it's really difficult to do well.

It might also be worth investigating the impact of a newer Spidermonkey on random map generation, especially a more advanced GC. And when writing RMSes and the random map generator API, we need to be mindful of how JS and the Spidermonkey GC works.

in reply to:  24 comment:25 by FeXoR, 11 years ago

Replying to historic_bruno:

I think most of the random maps need an overhaul and possibly the random map generator itself.

That's what the discussion took it's way, yes, and I agree. But how exactly?

For one thing, they shouldn't take more than about 10 seconds to generate on even the largest settings on moderate hardware. It's ridiculous if it takes 30 seconds, 1 minute, or longer.

I agree. But is that a major issue? In-game speed is much more important IMO.

They also need improvements aesthetically and for strategy.

This is not helping at all. Please specify.

Mythos' example biomes topic on the forums should be a guide for how the maps are to look.

Most maps are designed like mentioned in http://www.wildfiregames.com/forum/index.php?showtopic=15562 . Guess that's what you mean? Not all maps fit to this document perfectly though.

It wouldn't be terrible to start over with only 2-3 random maps that are good, providing a blue print for adding others. That's a big challenge but worth it IMO. If we can make them fast enough, we could even have a "live" preview of the map in match setup. One of the reasons games don't have random maps: it's really difficult to do well.

So you mean it's better to have a small amount of fast generating maps that fit the design document than many maps - most fitting the design document - but taking longer to generate and some not mentioned in the design document at all? I strongly object. To use a generated preview instead of a screen shot will "force" all RMS to generate in a few seconds though the generation time compared to the time a match on it lasts should be "small" IMO. This is for sure the case ATM and that is OK IMO.

It might also be worth investigating the impact of a newer Spidermonkey on random map generation, especially a more advanced GC. And when writing RMSes and the random map generator API, we need to be mindful of how JS and the Spidermonkey GC works.

Any specific suggestion what to do to make the API faster?

I'm not sure what you want to say in general. I agree with most things but they are not helping to solve the other general issues mentioned here and in the forum (http://www.wildfiregames.com/forum/index.php?showtopic=16242) in any way. Your focus on clean, fast RMS is valid but not a big issue from my point of view. Using a generated preview, however, would make it an issue. So that would be a bad idea IMO.

comment:26 by elexis, 7 years ago

Description: modified (diff)

Is this ticket still valid and needed?

A civic center and starting entities is the only thing that the player must receive on every mapsize for every playercount. This seems to be the case already.

Enemies starting on tiny maps right besides each other, having few space to build or gather of the few resources without being attacked is differently is challenging, but was perceived entertaining (refered to as "pizza maps" from the resulting territory shape). Various gamesetup options (regicide, diplomacy, last man standing) also alleviate the drawbacks and add to the experience.

comment:27 by elexis, 6 years ago

Description: modified (diff)
Milestone: Backlog
Resolution: wontfix
Status: newclosed
Summary: [PATCH] Add player caps for random maps by map size option to their json files handled in gamesetup.js[PATCH] Allow random maps to restrict the gamesetup mapsize choice

As stated above, all maps except Caledonian Meadows and Wild Lake support all map sizes already.

So currently the gamesetup supports persistance of user settings when changing any other setting. This meets the current user expectation from random map settings - players browse through the map while having the player assignments, victory condition - and for this matter mapsize persisted.

For example players willing to play a "pizza" game on a tiny map size and then see which map they would ideally like to play. They can chose freely until they come across that one map that resets the size to Normal.

Multiply that with any gamesetting we have and we end up with scenario and skirmish maps which overwrite each setting when changing the map, making it impossible to fine-tune settings in consensus.

So this feature would have devastating effects on the gamesetup in my opinion.

So these two maps must be fixed to work with all mapsizes instead. We already have a way to prevent resource collisions (tile classes + retry loops). One should expect that even on tiny maps with limiting area there is enough space for starting bases. But if a map is exotic, it could still fallback to nomad starting units instead of dropping setting independence in the gamesetup.

Note: See TracTickets for help on using tickets.