Opened 4 years ago

Last modified 2 months 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 elexis)

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 Changed 4 years ago by sanderd17

Type: defectenhancement

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.

comment:2 Changed 4 years ago by elexis

The GUI part shouldn't be that problematic, a good number of places have been changed already: r16975 r18104.

comment:3 Changed 4 years ago by Palaxin

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:4 Changed 4 years ago by Palaxin

I mean this limits would be specific to each map

comment:5 Changed 4 years ago by Imarok

refs #3506

comment:6 Changed 3 years ago by elexis

In 19840:

Group starting positions of players by team on the new random map sripts in Alpha 20 and 21, making them much more playable.
Use stronghold starting position style with 33% instead of 50% probability.

Differential Revision: https://code.wildfiregames.com/D664
Reviewed but not accepted by: bb (everything) and fatherbushido (Heaps permutations)
Catch: This must become more efficient if the playercount will be greater than 8, refs #4004.

comment:7 Changed 19 months ago by elexis

Description: modified (diff)
Patch: Phab:D1662
Priority: If Time PermitsNice to Have

Notice the feature would also be useful for 8 players + scripted enemies that aren't gaia (danubius, jebel barkal)

comment:9 in reply to:  8 Changed 19 months ago by elexis

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 Changed 2 months ago by elexis

Patch: Phab:D1662Phab:D1662,Phab:D2667
Note: See TracTickets for help on using tickets.