Opened 8 years ago
Last modified 4 years ago
#4004 new enhancement
Increase playerlimit
| Reported by: | elexis | Owned by: | |
|---|---|---|---|
| Priority: | Nice to Have | Milestone: | Backlog |
| Component: | Core engine | Keywords: | |
| Cc: | Patch: | Phab:D1662,Phab:D2667 |
Description (last modified by )
Currently the engine has an 8 player limit, but it could be entertaining to play with even more.
This is a non-trivial change as probably many data structures in C++ components rely on that limit and maps being designed for at most 8 players.
The performance shouldn't be affected significantly if the mapsize stays the same and the population limit is reduced proportionally. As of r17881 the network code already supports up to 24 clients without a noticeable performance impact.
Change History (9)
comment:1 by , 8 years ago
| Type: | defect → enhancement |
|---|
comment:2 by , 8 years ago
comment:3 by , 8 years ago
Regarding random maps: Perhaps we can implement a lower and higher limit for the available map sizes and the supported number of players? So not all existing maps have to be tested and edited...
comment:7 by , 5 years ago
| Description: | modified (diff) |
|---|---|
| Patch: | → Phab:D1662 |
| Priority: | If Time Permits → Nice to Have |
Notice the feature would also be useful for 8 players + scripted enemies that aren't gaia (danubius, jebel barkal)
comment:9 by , 5 years ago
Scripted enemies are only one use case. The other obvious use case is multiplayer with more than 8, on larger maps without adding more total entities.
So the scripted enemy topic, including my elaboration below is kind of offtopic of the feature described in this ticket other than demonstrating one of its use-cases:
The current "Gaia" scripted enemy is supposed to become more than a nuisiance in future maps, for example oppidum map, even if not a real opponent, so it's a problem for future maps with scripted enemies to not be able to use separate player IDs. It should be considered a workaround to script gaia rather than a separate player.
The difference between a simulation/ai/ implementation and a scripted enemy is that the scripted enemy doesn't immitate a human player, but that the map comes with prebuilt cities where the terrain was modified for that city, and the match itself becomes scripted with its own map specific events and conditions occuring throughout the match.
Example use cases for scripted or AI enemies not using gaia:
- gaia buildings currently have to be marked as uncapturable or have to be garrisoned with units to not decay unintentionally. Gaia has no territory influence, players do.
- it isn't possible to have two scripted enemies that may also attack each other, or become defeated independently on different conditions or events.
- the scripted enemy isn't meant to be the same player as flora, fauna and geology. One couldn't add a simple aura that affects all units with health points without taking special care to exclude those other gaia classes.
- it isn't possible to change diplomacy to neutral to the players if some scriptevent took place.
- A scripted enemy with a custom playerID could trade and gather resources in order to simulate an economy. This would allow the human and AI players to raid the economy of the scripted enemy too for instance.
comment:10 by , 4 years ago
| Patch: | Phab:D1662 → Phab:D1662,Phab:D2667 |
|---|
This is certainly not a trivial task. Next to the many data structures that depend on the number of players (they aren't all limited to 8 players, but most are limited to some number between 8 and 16), there's also the GUI (setup screen, statistics screen, diplo screen, ...).
Having to create scenario and skirmish maps for more than 8 players is to be expected, but player placement on random maps is currently also only tested for 8 players. So all random maps should be retested.
And for every extra two players added, you need to add an extra team possible.