the more players there are, the more frequently people will meet the enemy, and thus the more deaths and respawns occour. on a 20vs20 game, this means that maps like canyon are on one ticket in about 20 minutes, long before either team is clearly winning. would it be possible that the game starts with an amount of tickets depending on the number of total players when the map starts? so ->5 per team: 150 ->10 per team: 200 ->15 per team: 300 ->20 per team: 400 ->25 per team: 500 that sorta thing.
this idea is stupid.. i think certain maps just need more tickets.. its not like a game with only 5 people is gonna end because of tickets
what dubee said, and also there's the problem of connection speeds, does everyone connect to the map in time for the start of the game, when tickets would be decided? My experience has been that the # of players tends to stay stable for each map, it's changing maps that causes the massive drop off in attendance (b/c each game is long and intense) so this idea seems plausible if technical issues could be overcome. But I think the simplest solution is just base the number off what could be considered the ideal server size for each map.
so it wouldnt be able to tell how many people join a game instantly for tickets.. and then you gotta factor in all the people who leave.. and what if tickets come down to 1 and then a bunch of people join.. more features/changes = more bugs.. lets remember that
I was thinking that the tickets could change as you play. Lets say you have an amount of players that gives the map 100 tickets. 4 tickets on each side get used, so now you have 96. When enough people join for 200 tickets, bump the 96 up to 192, so you still have the same percentage of tickets of your "starting" value.
playercount could also be useful in deciding what map to put next... as in, it favours smaller maps for smaller player numbers and is more likely to do SoF and Duststorm with high numbers.
We have scripts for that. If server has 32 slots and default tickets are for 16, server admin can change tickets for each map separately. There's no need to introduce anything new.
nono, I think this would be best as a percentage gain or loss depending on player count. I thought of this earlier, but everything has changed based on new player limits. Here's what I was thinking though. When we were at 30ish players a team, each player would have 10 tickets out of 150 (150 for each team of 15). Now, it would be fine to have a team of 5 start a match with 50 tickets. That sounds like plenty to me, but will also allow flexibility. The question is what to do next? Can you add 10 tickets easily? Not really. What would happen if the game winds down to 5v5 tickets? one player joins and its 15v5? nope. Equally, you cannot take 10 tickets away from a team which loses a player. That means we need to have a percentage system then. Start Game: 10 tickets per player (based on 30 person server) and calculated one minute into the game (30 seconds of comm vote, 30 of me throwing a number out there). [The total could be based on the number of players on the smallest team, or simply 10 tickets more, I'm not sure about this idea, still to be worked out] During the Game: When a player joins or leaves, they affect their team's tickets by 10% (to a max of 10 tickets) End Game: The game is over, start the process over I like this quite a bit.
Biology--> Regenerative Medicine--> Regen Armor + Cloning Machines XD Here's a thought: set number of tickets as per the system right now, BUT make it so if there are fewer people on the server, one death and you lose more tickets. If the ideal server number is 30 you might lose 1 ticket per death with 30 people, but if there are like 5 people, you'd lose 10 tickets per death. Or something. I'll put it in an equation: it could be as simple as this: Ideal Number of Players on Map (constant value set by server or map)=X Current Number of Players on server=Y Ticket Cost per 1 Death=Z and X/Y=Z Therefore with a 30 person map that had 5 ppl on it, if you die, you lose six tickets. Example: # Players | Ticket Cost | Rounded Value 30. . . . . . 1. . . . . . . . . 1 25. . . . . . 1.2. . . . . . . .1 20. . . . . . 1.5. . . . . . . .2 15. . . . . . 2. . . . . . . . . 2 10. . . . . . 3. . . . . . . . . 3 5. . . . . . . 6. . . . . . . . . 6 1. . . . . . . 30. . . . . . . . 30 If the equation is (X/Y)^2=Z for a 30 person map, then the tickets are as follows: # Players | Ticket Cost | Rounded Value 30. . . . . . 1. . . . . . . . . 1 25. . . . . . 1.44. . . . . . . 1 20. . . . . . 2.25. . . . . . . 2 15. . . . . . 4. . . . . . . . . 4 10. . . . . . 9. . . . . . . . . 9 5. . . . . . . 36. . . . . . . . 36 1. . . . . . . 900. . . . . . . 900 Obviously the exponent can be whatever value you want it to be to match any pattern of ticket loss you ever want. The downside is that revives or things that ADD tickets would add an equal number on small games- so revives would add six tickets too. So maybe this wouldn't do anything. Idk. This is all mental gymnastics, seeing as i dont think the problem is that big an issue or something that can't be resolved with more tickets and ALL of these systems would be too complicated and confuse the hell out of newbies, to the point where they just think 'screw tickets! I'ma do my own thing!' Then where's your revive NOW, huh?! WHERE?!
