[todo] Different card distribution algorithm

Wishes get here when they grow up.
Locked
mikekchar
Posts: 16
Joined: Sat Jan 24, 2009 3:21 pm

[todo] Different card distribution algorithm

Post by mikekchar »

I'm really enjoying this game (actually too much... but I digress). However there is one part that bugs me: red/yellow card distribution.

It's not that the percentage chance is wrong, it's that the distribution is wrong. Looking at the code it seems that the distribution of cards is uniform. In other words, there is a uniform chance that a foul will happen at any given time, there is a uniform chance that it will be a red or yellow card, and then a fouled player and fouler are chosen (uniformly, I think, but I didn't check).

This means that I can go a whole season without a red card, or I can get 3 red cards in a game. These events are very low probability, but happen occasionally. However, in real life it just doesn't happen at all.

In real life, when a player gets a yellow card, they stop playing so aggressively and are less likely to get another one. The referee is also trying to limit the number of cards in the game, since cards break the flow of the game. If the referee sends someone off, they are less likely to send another player from the same side off.

Also, straight reds are much less likely to occur at the beginning of a match then at the end.

I could go on for a long time but I think you get the point. So here's how I would propose to implement a change:

Continue to uniformly determine if there is a foul. Next, check the fouler and fouled player. If the fouler already has a yellow card give them a percentage chance to "back off". If they back off, the fouled player gets some positive result (a shot, good pass, etc).

Next check the severity of the foul. Use a random number to determine the severity and then put the result through a (referee) filter:

If it's a first yellow card, decrease the probability of giving it based on the time (less likely near the beginning of the game).

If it's a second yellow card, decrease the probability of giving it based on how much time has elapsed since the first card was given. The longer since the first card was given, the more likely to give the second card.

If it's a straight red, significantly decrease the probability based on how long the game has gone. Give a yellow card instead.

New commentary could be given for each event, "PlayerA is forced to back off and PlayerB shoots!", "PlayerA fouls PlayerB, but the referee lets him off with a warning", "Will this be PlayerA's second yellow? The referee tells him to calm down", "The referee decides it's too early for a sending off and gives PlayerA a yellow card instead."

Then the overall red/yellow percentage could be increased to balance out the decrease of the other filters. I really think this would result in card distributions that will be much more realistic and fair.
gyboth
Site Admin
Posts: 1421
Joined: Sat Dec 18, 2004 8:42 am
Location: Passau, Germany
Contact:

Re: Different card distribution algorithm

Post by gyboth »

mikekchar wrote:In other words, there is a uniform chance that a foul will happen at any given time
True.
there is a uniform chance that it will be a red or yellow card
Untrue. The probabilities, given that there was a foul, are

Code: Select all

float_live_game_foul_red_injury 1500
float_live_game_foul_red	3800
float_live_game_foul_yellow	28000
(divide by 10.000 to get percentages). Taken from the constants file "bygfoot_constants".
and then a fouled player and fouler are chosen (uniformly, I think, but I didn't check).
No, it depends on the area of the field the ball's in. A defender is of course less likely to foul in the attacking zone of his team.
This means that I can go a whole season without a red card, or I can get 3 red cards in a game. These events are very low probability, but happen occasionally. However, in real life it just doesn't happen at all.
It does happen, just really really rarely. But probably you're right and in Bygfoot it happens also very rarely but more often.
In real life, when a player gets a yellow card, they stop playing so aggressively and are less likely to get another one. The referee is also trying to limit the number of cards in the game, since cards break the flow of the game. If the referee sends someone off, they are less likely to send another player from the same side off.
True, I hadn't thought of this. Of course, I was intent on finishing the live game algorithm without any flourishes and was really glad when it worked as planned, more or less. And haven't really touched it since.
Also, straight reds are much less likely to occur at the beginning of a match then at the end.
Agreed.
Continue to uniformly determine if there is a foul. Next, check the fouler and fouled player. If the fouler already has a yellow card give them a percentage chance to "back off". If they back off, the fouled player gets some positive result (a shot, good pass, etc).

<snip>

Then the overall red/yellow percentage could be increased to balance out the decrease of the other filters. I really think this would result in card distributions that will be much more realistic and fair.
I agree that it'd be nice to tweak the card distribution, but
  • your suggestions on how to do it would mess up the live game algorithm too much. A cleaner approach that comes to my mind and is better suited to the rest of the live game algorithm would be to calculate the red/yellow probabilities dynamically for each foul, taking into account the players involved and the card history of the game. This would also mean that your new events and commentary ideas won't work, a yellow will just be a yellow, only less likely to occur, and that's it.
  • I'm not really back as a developer. I worked quite some time on 2.3.1, but that was mainly because I didn't have a lot to do in my job, which has changed since then, so I'm back to my previous state of having not so much energy and motivation for Bygfoot. Fortunately, I'm not the lead developer anymore, so we can hope that Gunnar'll take up our suggestions; unfortunately, he not only has a job of his own, but also family, so the implementation (and 2.3.2 in general) could take quite some time.
Anyway, thanks for your suggestions and insights :-) I'm happy you're enjoying our game.

P.S.: You're welcome to dig into the code yourself, of course, if you're not inclined to wait until we manage to find the time to do the changes (provided other development steps don't take precedence).
Press any key to continue or any other key to quit.
gunnar
Site Admin
Posts: 233
Joined: Wed Oct 19, 2005 11:13 am
Contact:

Post by gunnar »

This is a nice idea and I hope to get it implemented in 2.3.2. I'm not promising anything though.
mikekchar
Posts: 16
Joined: Sat Jan 24, 2009 3:21 pm

Post by mikekchar »

I'm glad you guys like the idea. It's funny, gybooth, but I thought of the solution you suggest too, and it's definitely the better way to go (IMHO). I just thought it would be too hard :-). It just goes to show that the author knows his code a lot better than the guy who is just poking around.

I really wish I could work on this. But unfortunately I've rather buried myself with other projects at the moment. :-(
Locked