Beta Street Cricket Simulator - Back to basics

@ShamiLoverGlipGlops
I Have Some Concern over Pitches Like Damp, Wet and Grass.
Always Produced Scorecard Like These
I am Simming A Tournament , Solve these Problems65dcd52055707_scorecard (1).png65dcd52055707_scorecard (2).png
 

Attachments

  • 65dcd52055707_scorecard.png
    65dcd52055707_scorecard.png
    1.2 MB · Views: 3
  • Daddys_Army_vs_ADMIN_AVENGERS_65f1d1d662f81_scorecard.png
    Daddys_Army_vs_ADMIN_AVENGERS_65f1d1d662f81_scorecard.png
    1.2 MB · Views: 3
Last edited by a moderator:
What is This ?
A Bowler Scoring Half of the team Run
 

Attachments

  • IMG_20240404_002140_214.jpg
    IMG_20240404_002140_214.jpg
    27.6 KB · Views: 6
  • IMG_20240404_002141_712.jpg
    IMG_20240404_002141_712.jpg
    42.5 KB · Views: 6
Update - 05/14

I just want to say to those who have supported this development all along a BIG THANK YOU. Without the support and motivation there is no SCS. I have not stopped working on this and whenever and wherever I could, I would think on improving this.

I would like to say no body is perfect and that includes me at 1st position. What started out as a project for myself and only a Street Cricket Simulator soon became a big thing with T20 and T10.

I have been struggling off late with time management. Those of who know, I have a dog who was detected with cancer, along with handling him and his needs like all managing full time job has been a tough ask. In between obviously you cannot forget to live your life.

All personal things apart, I have a little update and future roadmap for this project. I do not know if this is exciting, boring or just meh not interesting but I would like to share.

Over the last 3 months, I have completely re-written the ball simulation engine. The current tech stack it uses is PHP and I wrote the newer engine in Python. Along with new ball simulation engine, I have also rewritten something that most do not pay attention and that is toss - a crucial part of a cricket game.

So having said the above, here is what has been written and now is in test mode.

  • Both toss and a simulation of a single delivery would now be served via a Rest API.
  • I have created API's for both using Flask.
  • The reason I did this is so that I can still reuse the same GUI and just change the backend.

1. Simulating Toss - API​

JSON:
{
  "team1": "Team A",
  "team2": "Team B",
  "team1_strength": "Batting",
  "team2_strength": "Bowling",
  "boundaries": "Short",
  "dew_factor": "Yes",
  "pitch_condition": "Grass",
  "weather_condition": "Sunny"
}

Response returned back

JSON:
{
  "TossCalled": "Heads",
  "TossCommentary": "Team A called for Heads and won! Team A has elected to bat first . They considered that the dew factor making bowling tricky. This decision could prove vital in today's game.",
  "TossDecision": "Bat First",
  "TossLost": "Team B",
  "TossWon": "Team A"
}

Toss Factors Explained​

Team Strength​

  • Batting: Indicates the team is stronger in batting.
  • Bowling: Indicates the team is stronger in bowling.
  • All Round: Indicates the team is balanced in both batting and bowling.

Boundaries​

  • Short: Short boundary lengths favoring aggressive batting.
  • Medium: Medium boundary lengths providing a balanced game.
  • Long: Long boundary lengths favoring bowlers.

Dew Factor​

  • Yes: Presence of dew, which can make bowling tricky due to a slippery ball.
  • No: No dew factor affecting the game.

Pitch Condition​

  • Grass: A green pitch that usually assists bowlers.
  • Hard: A hard pitch favoring batsmen with consistent bounce.
  • Damp: A damp pitch that can be unpredictable.
  • Dusty: A dusty pitch that often assists spinners.
  • Wet: A wet pitch that can be challenging for both batsmen and bowlers.
  • Artificial: An artificial pitch with consistent behavior.

Weather Condition​

  • Sunny: Clear weather, usually favoring batsmen.
  • Humid: Humid conditions that can affect swing bowling.
  • Cloudy: Cloudy weather that can assist bowlers with swing.
  • Overcast: Overcast conditions that typically favor bowlers.
---------------------------------------------------------------------------

2. Simulating Single Ball​

JSON:
{
  "ball_number": 1,
  "batsman_rating": 80,
  "batsman_fatigue": 20,
  "pitch_conditions": "good",
  "weather_conditions": "clear",
  "chasing_target": false,
  "bowler_rating": 75,
  "bowler_fatigue": 10,
  "inning_part": "PowerPlay",
  "format_type": "T20",
  "wickets_left": 5,
  "deliveries_bowled": 10,
  "bowler_name": "Starc",
  "batsman_name": "Kohli",
  "batsman_type": "Aggressive",
  "bowler_type": "Wicket Taker",
  "wind_conditions": "moderate",
  "time_of_day": "day",
  "batsman_hand": "Right",
  "bowler_hand": "Left"
}

JSON:
{
  "outcome": "single",
  "runs": 1,
  "wicket": false,
  "wicket_type": null,
  "commentary": "Ball 1: Starc to Kohli (single) Quick single taken."
}


Simulation Factors Explained​

1. Realistic Delivery Simulation

The API simulates a single cricket delivery by taking into account multiple parameters:
  • Batsman's Rating: A higher rating increases the chances of scoring runs.
  • Batsman's Fatigue: Higher fatigue reduces the batsman's effectiveness.
  • Bowler's Rating: A higher rating increases the chances of taking a wicket.
  • Bowler's Fatigue: Higher fatigue reduces the bowler's effectiveness.

2. Match Context Consideration

The simulation adjusts probabilities based on match context:
  • Pitch Conditions: Good conditions favor the batsman, while poor conditions favor the bowler.
  • Weather Conditions: Clear weather generally favors the batsman, while overcast conditions favor the bowler.
  • Part of the Inning:Different phases (PowerPlay, Middle Overs, Death Overs) have distinct characteristics:
    • PowerPlay: Higher chances of scoring due to fielding restrictions.
    • Middle Overs: Balanced conditions where building an innings is crucial.
    • Death Overs: Higher chances of scoring or getting out due to increased risk-taking.
  • Format Type:Adjusts based on whether the match is T20, ODI, or Test:
    • T20: High scoring and higher risk of getting out.
    • ODI: Varies by phase with a balanced approach.
    • Test: Lower scoring rates with a focus on batting long periods.

3. Player Types

The simulation considers different types of players:
  • Batsman Type:
    • Aggressive: Higher chances of hitting boundaries and getting out.
    • Defensive: Higher chances of playing dot balls and lower risk of getting out.
    • Accumulator: Higher chances of singles and doubles.
    • Tail Ender: Higher chances of getting out and lower chances of hitting boundaries.
  • Bowler Type:
    • Wicket Taker: Higher chances of taking wickets.
    • Runs Holder: Higher chances of dot balls.
    • PowerPlay Specialist: Better performance during PowerPlay.
    • Death Over Specialist: Better performance during Death Overs.
    • Economical: Lower run rates and higher dot balls.

4. Environmental Factors

  • Wind Conditions:
    • Windy: Higher chances of misses and edges.
    • Moderate: Neutral effect.
    • None: No wind effect.
  • Time of Day:
    • Day: Standard conditions.
    • Day Night: Adjustments based on changing conditions.
    • Night: Higher chances of wickets and dot balls.

5. Player Orientation

  • Batsman Hand: Left or Right-handed batsman.
  • Bowler Hand: Left or Right-handed bowler.

6. Additional Outcomes

The API can also return additional outcomes:
  • Wide: Extra run and re-bowled delivery.
  • No Ball: Extra run, free hit on the next delivery.
  • Leg Bye: Runs taken off the pad.
  • Edge: Edged to the slips or keeper.
  • Miss: Batsman swings and misses.

7. Dynamic Probability Adjustments

Probabilities are dynamically adjusted based on the input parameters:
  • Effective Ratings: Adjusted for fatigue to reflect the current performance level.
  • Contextual Adjustments: Based on pitch, weather, inning phase, format, and match situation.

8. Commentary Generation

For each delivery, the API generates a random commentary line:
  • Commentary Lines: Predefined lines for different outcomes (dot, single, double, triple, four, six, wicket, wide, no ball, leg bye, edge, miss).
  • Wicket Types: Specific lines for different wicket types (LBW, Bowled, Stumped, Run Out, Caught).

Future Road Map​

  1. Integrate the new toss and ball simulation engine into existing application
  2. Move the hosting from AWS to something else (Not expensive as I am paying anywhere between $3-$5 a month)
  3. TEST TEST TEST
  4. Release
  5. PLEASE NOTE I do not have any fixed dates on when will this be implemented. I just wanted to provide an update.

If anyone wants to test the API directly, please let me know by messaging me. I would prefer tech friendly people only since this is directly testing API using Postman or other tools.

Thank you
 
Update - 05/14

I just want to say to those who have supported this development all along a BIG THANK YOU. Without the support and motivation there is no SCS. I have not stopped working on this and whenever and wherever I could, I would think on improving this.

I would like to say no body is perfect and that includes me at 1st position. What started out as a project for myself and only a Street Cricket Simulator soon became a big thing with T20 and T10.

I have been struggling off late with time management. Those of who know, I have a dog who was detected with cancer, along with handling him and his needs like all managing full time job has been a tough ask. In between obviously you cannot forget to live your life.

All personal things apart, I have a little update and future roadmap for this project. I do not know if this is exciting, boring or just meh not interesting but I would like to share.

Over the last 3 months, I have completely re-written the ball simulation engine. The current tech stack it uses is PHP and I wrote the newer engine in Python. Along with new ball simulation engine, I have also rewritten something that most do not pay attention and that is toss - a crucial part of a cricket game.

So having said the above, here is what has been written and now is in test mode.

  • Both toss and a simulation of a single delivery would now be served via a Rest API.
  • I have created API's for both using Flask.
  • The reason I did this is so that I can still reuse the same GUI and just change the backend.

1. Simulating Toss - API​

JSON:
{
  "team1": "Team A",
  "team2": "Team B",
  "team1_strength": "Batting",
  "team2_strength": "Bowling",
  "boundaries": "Short",
  "dew_factor": "Yes",
  "pitch_condition": "Grass",
  "weather_condition": "Sunny"
}

Response returned back

JSON:
{
  "TossCalled": "Heads",
  "TossCommentary": "Team A called for Heads and won! Team A has elected to bat first . They considered that the dew factor making bowling tricky. This decision could prove vital in today's game.",
  "TossDecision": "Bat First",
  "TossLost": "Team B",
  "TossWon": "Team A"
}

Toss Factors Explained​

Team Strength​

  • Batting: Indicates the team is stronger in batting.
  • Bowling: Indicates the team is stronger in bowling.
  • All Round: Indicates the team is balanced in both batting and bowling.

Boundaries​

  • Short: Short boundary lengths favoring aggressive batting.
  • Medium: Medium boundary lengths providing a balanced game.
  • Long: Long boundary lengths favoring bowlers.

Dew Factor​

  • Yes: Presence of dew, which can make bowling tricky due to a slippery ball.
  • No: No dew factor affecting the game.

Pitch Condition​

  • Grass: A green pitch that usually assists bowlers.
  • Hard: A hard pitch favoring batsmen with consistent bounce.
  • Damp: A damp pitch that can be unpredictable.
  • Dusty: A dusty pitch that often assists spinners.
  • Wet: A wet pitch that can be challenging for both batsmen and bowlers.
  • Artificial: An artificial pitch with consistent behavior.

Weather Condition​

  • Sunny: Clear weather, usually favoring batsmen.
  • Humid: Humid conditions that can affect swing bowling.
  • Cloudy: Cloudy weather that can assist bowlers with swing.
  • Overcast: Overcast conditions that typically favor bowlers.
---------------------------------------------------------------------------

2. Simulating Single Ball​

JSON:
{
  "ball_number": 1,
  "batsman_rating": 80,
  "batsman_fatigue": 20,
  "pitch_conditions": "good",
  "weather_conditions": "clear",
  "chasing_target": false,
  "bowler_rating": 75,
  "bowler_fatigue": 10,
  "inning_part": "PowerPlay",
  "format_type": "T20",
  "wickets_left": 5,
  "deliveries_bowled": 10,
  "bowler_name": "Starc",
  "batsman_name": "Kohli",
  "batsman_type": "Aggressive",
  "bowler_type": "Wicket Taker",
  "wind_conditions": "moderate",
  "time_of_day": "day",
  "batsman_hand": "Right",
  "bowler_hand": "Left"
}

JSON:
{
  "outcome": "single",
  "runs": 1,
  "wicket": false,
  "wicket_type": null,
  "commentary": "Ball 1: Starc to Kohli (single) Quick single taken."
}


Simulation Factors Explained​

1. Realistic Delivery Simulation

The API simulates a single cricket delivery by taking into account multiple parameters:
  • Batsman's Rating: A higher rating increases the chances of scoring runs.
  • Batsman's Fatigue: Higher fatigue reduces the batsman's effectiveness.
  • Bowler's Rating: A higher rating increases the chances of taking a wicket.
  • Bowler's Fatigue: Higher fatigue reduces the bowler's effectiveness.

2. Match Context Consideration

The simulation adjusts probabilities based on match context:
  • Pitch Conditions: Good conditions favor the batsman, while poor conditions favor the bowler.
  • Weather Conditions: Clear weather generally favors the batsman, while overcast conditions favor the bowler.
  • Part of the Inning:Different phases (PowerPlay, Middle Overs, Death Overs) have distinct characteristics:
    • PowerPlay: Higher chances of scoring due to fielding restrictions.
    • Middle Overs: Balanced conditions where building an innings is crucial.
    • Death Overs: Higher chances of scoring or getting out due to increased risk-taking.
  • Format Type:Adjusts based on whether the match is T20, ODI, or Test:
    • T20: High scoring and higher risk of getting out.
    • ODI: Varies by phase with a balanced approach.
    • Test: Lower scoring rates with a focus on batting long periods.

3. Player Types

The simulation considers different types of players:
  • Batsman Type:
    • Aggressive: Higher chances of hitting boundaries and getting out.
    • Defensive: Higher chances of playing dot balls and lower risk of getting out.
    • Accumulator: Higher chances of singles and doubles.
    • Tail Ender: Higher chances of getting out and lower chances of hitting boundaries.
  • Bowler Type:
    • Wicket Taker: Higher chances of taking wickets.
    • Runs Holder: Higher chances of dot balls.
    • PowerPlay Specialist: Better performance during PowerPlay.
    • Death Over Specialist: Better performance during Death Overs.
    • Economical: Lower run rates and higher dot balls.

4. Environmental Factors

  • Wind Conditions:
    • Windy: Higher chances of misses and edges.
    • Moderate: Neutral effect.
    • None: No wind effect.
  • Time of Day:
    • Day: Standard conditions.
    • Day Night: Adjustments based on changing conditions.
    • Night: Higher chances of wickets and dot balls.

5. Player Orientation

  • Batsman Hand: Left or Right-handed batsman.
  • Bowler Hand: Left or Right-handed bowler.

6. Additional Outcomes

The API can also return additional outcomes:
  • Wide: Extra run and re-bowled delivery.
  • No Ball: Extra run, free hit on the next delivery.
  • Leg Bye: Runs taken off the pad.
  • Edge: Edged to the slips or keeper.
  • Miss: Batsman swings and misses.

7. Dynamic Probability Adjustments

Probabilities are dynamically adjusted based on the input parameters:
  • Effective Ratings: Adjusted for fatigue to reflect the current performance level.
  • Contextual Adjustments: Based on pitch, weather, inning phase, format, and match situation.

8. Commentary Generation

For each delivery, the API generates a random commentary line:
  • Commentary Lines: Predefined lines for different outcomes (dot, single, double, triple, four, six, wicket, wide, no ball, leg bye, edge, miss).
  • Wicket Types: Specific lines for different wicket types (LBW, Bowled, Stumped, Run Out, Caught).

Future Road Map​

  1. Integrate the new toss and ball simulation engine into existing application
  2. Move the hosting from AWS to something else (Not expensive as I am paying anywhere between $3-$5 a month)
  3. TEST TEST TEST
  4. Release
  5. PLEASE NOTE I do not have any fixed dates on when will this be implemented. I just wanted to provide an update.

If anyone wants to test the API directly, please let me know by messaging me. I would prefer tech friendly people only since this is directly testing API using Postman or other tools.

Thank you
leonardo-dicaprio-clapping.gif
 

Users who are viewing this thread

Top