Higher Number of Max Players?

[Gorman]

Having 64 as an arbitrary max is just as bad as 32.

Why not just allow any number of players (of course as it is now, you can pick any number below that limit).
If a server wants to allow 9001 players then good luck filling that, and good luck with your bandwidth, but technically there is no reason to prevent them.

[ChaosTLW]

I want 256 players.

[Jest]

Having 64 as an arbitrary max is just as bad as 32.

Why not just allow any number of players (of course as it is now, you can pick any number below that limit).
If a server wants to allow 9001 players then good luck filling that, and good luck with your bandwidth, but technically there is no reason to prevent them.

I've always wondered this as well.
If allowing mods, why not allow any number of max players? Hardware and maps can be scaled for this.
Perhaps not wanting the game to be about 128 frag fests in small maps, but with a large enough map and the right mods it could enable some grand battles.

[DrSandwich]

At the moment, the more players idea is sounding pretty good,
128 players, sound terrific but too many players can ruin a game
64 sounds more reasonable, IMO

[Paratrooper]

If I remember correctly, games usually use powers of 2 to determine the max number of players. (16, 32, 64, with some exceptions)

[Triplefox]

There are two (technical) reasons for a hard cap.

One is to ensure that servers are running within computationally-possible limits. An extra player tends to cause a super-linear increase in bandwidth and cpu usage; if all players are visible to each other, that means that every client has more data transmitted. Without a special round of optimization to counter this and make sure that all the algorithms scale up well at large player counts, the load of each additional player can become enormous; our current practical limit may not be much more than 32. When you hit the practical limits, the quality of the game will become terrible; people will experience lag and disconnects until the population shrinks again.

The other is that additional UI becomes necessary as player counts grow. If there are only a few players, you can use a single screen for the scoreboard and a global and team chat. Even at 64 players, it becomes hard to cram in information for every player into one screen and the chat becomes a lot more spammy.

Even without considering the cap size as a technical concern, there are design problems in making the game feel good as the server ramps player count up and down. Every server has to start empty, and the game has to be entertaining at low player counts. But we know that small maps tend to become meatgrinders if we put too many players into them. So now we have to think about how to make the map dynamically expand, or change the game's rules with the player count, or other complicated things.

So while it's cool to want more players, it introduces numerous problems across the board. Why not focus instead on features that could make the game "feel" bigger without literally introducing more players?

[Gorman]

^
- Servers can set their own limits, some servers aren't using 32 max at the moment anyway.
- Just add a scroll bar...
- Chat log and scroll bar (hopefully both will come in next version anyway)
- None of the things you mention are technically difficult. It is trivial to limit players to a certain area or swap maps as player count increases. For a ridiculously trivial solution: use assault as the map and have water damage turned on, as the player count increases keep decreasing the water damage until it is 0. How amazing!
- Is 32 really *THE* perfect number? I don't think so.

I don't think those points are really valid, the real reason why the limit is set to 32 is just because Ben didn't think there would ever be enough players to really fill many servers, so he hardcoded it in. I think that is more accurate...

If I remember correctly, games usually use powers of 2 to determine the max number of players. (16, 32, 64, with some exceptions)

Yes, because then you can represent the number of players with the minimal number of bits.
Eg to have 10 takes as many bits as 16, 20 takes the same as 32, 100 takes the same as 128, etc.

Games could just as easily use 65536 max players, or infinite.

[Triplefox]

Gorman: It's easy to think up the rules in your head. It's not easy to create a test case for that situation. We don't have testing infrastructure for launching and monitoring mass numbers of dummy clients, and all the code related to those features will be a "shot in the dark" with almost no ability to verify until such infrastructure is built. Performance presents even more of a problem since synthetic testing can lead us astray, optimizing the wrong things. The difficulty of testing this stuff is why MMOs routinely fall over in their early post-launch period.

Lastly, iterating on a massively multiplayer design, if any tuning is needed, always entails large live tests. With a feature like modifying the map boundaries, that tuning is going on the map's content, not on systems that are only driven in code, so the testing has to be duplicated each time a map is made intended for large numbers of players. Hours of iteration time.

We can let server admins impale themselves on all the problems, of course, and let mappers simply guess about how boundaries should change. But simply uncapping the count is still going to put the burden back onto the pyspades devs to get everything else done. It won't happen until mat^2 feels it can be handled.

With regards to the scrollbar - the Voxlap engine doesn't have any point-and-click UI at all; the OpenGL has basic buttons but AFAIK no scrollbars or sliders yet(notice how it uses paging buttons for the server browser - that's indicative of the engine missing a scrollbar widget). Of course this stuff can - and should - be built at some point, but it only became an "obvious must-have" because it can solve UI with larger scales of players.

I know you weren't asking for a pony, but that's what we have to build to do it properly.

[Gorman]

Sure it would be nice to be able to do a complete real world test, but you can't because... err, well I don't know why you don't do real world tests... Would it be so hard to have a beta client so people could help test? Hm, I don't think so. It is simply a matter of having a client connect to the master server and download any new updates from the latest build, then people can play and help you test. So long as you have decently decoupled system this wouldn't be a problem.

But as you said with your comment about how simply removing the 32 cap would cause a lot of issues, this is because some parts of the code are very hackish... Reusing player IDs for other purposes for example... It's ok for me to say "sure if the system is well deigned then it should scale without any problem", but we both know the code is a long way from that point at the moment.

What is wrong with letting admins and mappers play around? You will find that they come up with far better, more diverse and more creative solutions than you could with 100 release cycles. If they screw up some times then it may even cause interesting results.

Saying "it can't be done because of bandwidth, resources, too many players on scoreboard, chat would be spammed, it may not feel good, need to make it play good with 1 player and 100" is one thing, but later admitting "actually this would be a lot of work because of poor design and so we can't handle it right now" is another thing ENTIRELY, don't you think?


So, in short, I'm ok with you saying that the effort is too great because of poor design, but don't use false reasons to cover it up >_> Even if you are not meaning to do that, it sure seems like it. Why even post such reasons in the first place if you knew that it would be too much effort to implement?

[Triplefox]

Gorman: Every time you try to address my concerns, new tasks appear, in this instance the idea of a beta client and auto-updater - features which by their very nature need some ongoing support. Illuminating what work has to be done is not helping your point.

Fortunately, I've had some time to sleep on this. There is a feature that will motivate most of the dependencies needed to smoothly increase player count, and do so in a more direct and incremental fashion. Simultaneously, it will motivate new possibilities for the gameplay, and attract new contributors to pyspades. It is a feature that has not entered this discussion once, and it may not even look directly related. I'm going to stop now, and leave you wondering what it is, but if I ever get it done, you'll know :)

[Gorman]

Well, good reply :)

Sorry about the mildly aggressive reply I made before.

But updater should be added, and beta client wouldn't be hard, you already have alpha clients right? It should just be a matter of releasing the client.

[MegaDeuce]

Full sized maps tend to feel empty because you can usually make it pretty deep into enemy territory w/out getting killed. 64 players would be enough to "fill the gaps" and you could have a solid front established that crossed the map.

[runHarder]

And even occasionally have those quiet times when everyone sort of calms down at the same time and thinks for a bit about what they are going to try next.

[Tigershield]

Well higher numbers would be great. Needs to be server option.

[Habsburger]

Full sized maps tend to feel empty because you can usually make it pretty deep into enemy territory w/out getting killed. 64 players would be enough to "fill the gaps" and you could have a solid front established that crossed the map.

Just like in real wars ,linear fronts , not some randomness party.