Makes matches with up to 16 players possible (and a upper limit set to 16 in c++).
Details
- Reviewers
elexis vladislavbelov - Trac Tickets
- #4004
If we want to support more than 16 we will have to discard the use of the u32 masking given that the CalcPlayerLosMask uses 2 bits per player.
Diff Detail
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Event Timeline
binaries/data/mods/public/gui/gamesetup/gamesetup.js | ||
---|---|---|
1082 ↗ | (On Diff #6956) | Can it somehow be dependent from the global max number of players ? |
I initially wanted 32 for game setup too but the list won't visually fit nicely more than 24 slots.
This patch would be fun with a Max pop of like 25 XD
binaries/data/mods/public/gui/gamesetup/gamesetup.js | ||
---|---|---|
1082 ↗ | (On Diff #6956) | As a ratio of g_maxNumberofplayers. |
binaries/data/mods/public/gui/gamesetup/gamesetup.js | ||
---|---|---|
1082 ↗ | (On Diff #6956) | Ah I see, you mean. Yes could be done. ex: height = Math.min(Math.max(30*currentNumPlayers/maxNumPlayers,30),15) |
That'd be awesome, because we need to avoid a code duplication.
Also, isn't there any other place with the hardcoded max number of players?
I think the rmg library has some hardcodings too.
About the xml files with <repeat> tags, the hardcoding can't be avoided unless we add Engine.MatchGetMaxNumberOfPlayers() or similar that defines <repeat n="number"> in some way before the parsing or in the parsing.
How can it be made so CCmpRangeManager.cpp and Player.cpp share the same #define MAX_NUMBER_OF_PLAYERS 32 ?
Patches that should be committed should be correct and complete. I expect this to break on most random maps and in many GUI pages.
So it would probably be safer to first unify all constants in the engine to support arbitrary numbers and then only expose the > 8 in the UI if the UI and maps support it properly.
Also atlas.
Ultimately the maximum number of players should not be limited, so that game designers can use the Pyrogenesis engine for any games they come up with.
I see that you chose 32, since the RangeManager is limited to that, so that may be an improvement already.
The real question is whether those are all files that need this change (I wouldn't be surprised if there are many more cpp files surrounding the RangeManager or anything else that stores values depending on playerID).
binaries/data/mods/public/gui/common/settings.js | ||
---|---|---|
5 ↗ | (On Diff #6957) | This should be received from the engine, through JSInterface_... probably the Game one |
binaries/data/mods/public/gui/gamesetup/gamesetup.xml | ||
106 ↗ | (On Diff #6957) | 100% height if this has to be changed |
binaries/data/mods/public/gui/session/selection_panels_middle/multiple_details_area.xml | ||
39 ↗ | (On Diff #6957) | <!-- MaxPlayers --> so people find it when editing it. (Would be ideal to have this a constant somewhere that is filled in in the C++/XML engine) |
binaries/data/mods/public/gui/common/settings.js | ||
---|---|---|
5 ↗ | (On Diff #6957) | Not sure if that shouldn't be the other way around and being sanitized by cpp if it's above 32 ? |
I made a blunder not seeing that LOS needs two bits per player. Given that the type is uint32_t that makes the upper bound in reality 16.
If the engine already supports 16 max, then it should be documented well and propagated. New sim components should be written without being possible to assume that its max 8.
About exposing this to the players, I'm not sure, it would have to be very polished.
Currently 2-8 players is well known to produce good results, we don't to water down the experience.
It should be tested well that 16 max doesn't produce less entertaining results (not only random maps, but the entire match experience).
I'm sure it will work for 10 players max ingame, not sure about the dialog boxes. Beyond that it would require some testing to see if there are some problems or quality loss arising.
For example the current team chat is already difficult, how are players supposed to communicate with that many players.
(Pyrogenesis should support limit removals for sure, but increasing max for 0 A.D. needs separate consideration.)
binaries/data/mods/public/gui/common/settings.js | ||
---|---|---|
5 ↗ | (On Diff #6957) | The important part is that devs dont think they can just replace this one variable and their task is done. |
binaries/data/mods/public/gui/gamesetup/gamesetup.js | ||
1083 ↗ | (On Diff #6961) | Can you show a screenshot how the gamesetup looks with 1024*768 for 16 playerslots with this patch? |
source/simulation2/components/CCmpRangeManager.cpp | ||
82 | Don't think it should. Here 32 is used because it's u32. It's also not 2 * max number of players, but it should be capped by max_players. |
Changes concerning the number of players' limit in the 0ad public mod files should be made in a different diff.
This diff will only state the current engine players limit.
binaries/data/mods/public/gui/gamesetup/gamesetup.js | ||
---|---|---|
1083 ↗ | (On Diff #6961) | The patch is not meant to change the GUI. |
I am a bit skeptical that the rangemanager is the only thing which needs change. There could be stray 8 or 16 s too.
As mentioned in the lobby, you have to keep in mind the territory manager limitation. Posting here just for the record.
https://code.wildfiregames.com/source/0ad/browse/ps/trunk/source/simulation2/components/CCmpTerritoryManager.cpp$86
I guess that is Gaia + 31 players.
source/simulation2/components/CCmpRangeManager.cpp | ||
---|---|---|
72 | It doesn't sound sane to do that. |
Seems m_Territories only gives 4 bits to player ID mask (owner value) , which was defined originally as a player_id_t (uint_32) in CCmpRangeMangaer.cpp giving the false impression that there can be 30 players.
In the end the maximum number of players seems to still be 8 with no margin for more due all player ID masking done with uint8 or uin16 depending of the case.
I think that as long as all data of each player is stored/packed into a single value it will not be really possible to do anything more given the current implementation.
Grid<u8>* m_Territories; could become one player_id_t sized grid for the owner and one u8 grid for the remaining flags. (But yes, noone said it would be easy.)