[feat]: allow user to interact with the examples through cli #112
Conversation
There was a problem hiding this comment.
First, thank you for taking a look at the code. I appreciate it. I also like your input and attention to user-friendliness.
I think there is a naming issue with what's there, which I have left you. Most of the code you have touched is Mote Carlo simulations for Texas Holdem (game_simulate.rs). We also have agent simulations for Texas Holdem (agent_battle.rs). If the plan is to combine all examples into a single cli (I like this plan), then we should group sub-commands by the simulation type.
Suppose the plan is to keep separate examples but make them much more user-friendly (A plan I also see the benefits of). In that case, we should name separate examples with either simulation type and game type or simulation type (I'm curious when more game types will be asked for).
| let game_type = | ||
| Select::new("Type of game:", vec![GameType::MonteCarlo, GameType::Omaha]).prompt()?; |
There was a problem hiding this comment.
Game Types
For now, I wouldn't worry about game types. Game type options would be Texas Holdem or Omaha. Omaha would be great to have, but it's an unscheduled feature at this point.
Simulation Types
In addition to different types of poker we have three different simulation types:
- Monte Carlo simulation.
- ICM Simulations
- Agent Simulations
Monte Carlo
Monte Carlo simulation is our simple hand simulation. It doesn't include betting or rounds. It's handy for things like "Tell me how often some hand beats some other hand" or "What are the odds that the flush happens?"
ICM
ICM stands for independent chip model. It's important for poker tournaments. Many players join poker tournaments by paying an entry fee. The players are given stacks of chips disconnected from the entry fee, and they play games of poker in an elimination style. When doing this, there's a schedule of payouts. Since there are large jumps in payouts (the first might make 10x more than the second, who made 5x more than the third), the value of chips changes.
For example, if you are second in chips by 10 chips, losing 11 chips would move you down. Drastically changing the expected payout of the tournament.
Our ICM code helps developers get the expected value of different stacks so they can determine the value of each bet/fold/call in a tournament setting. It doesn't take in hands or cards. All it takes in is different stacks and the payout schedule. There's no limit on number of players or stack size.
Agent Simulations
These are the newest and the most complicated. We have automatic agents that can play whole games. Everything from the dealer, betting, rounds, all ins', ties, and multi-way pots. Because of this each agent has different configuration. The hands have to be input. The stacks have to be input.
So adding this to the cli will be hard since it's so much input. We will likely need to have some file format for all the settings. All of this to say that Agent Simulations are a big hairy unknown.
| .with_validator(|input: &str| { | ||
| match input.parse::<Hand>() { | ||
| Ok(_) => Ok(Validation::Valid), | ||
| Err(RSPokerError::UnexpectedValueChar) => Ok(Validation::Invalid("Value can only be a char from [`A`, `K`, `Q`, `J`, `T`, `9`, `8`, `7`, `6`, `5`, `4`, `3`, `2`]".into())), |
There was a problem hiding this comment.
Can we make RSPokerError::UnexpectedValueChar and the rest more descriptive and use that string here?
A quick prototype of the "interaction with examples" functionality, as far as i understood. I'll flesh things out from here if this seems fine.
Not trying to push for a merge, but creating this PR to track the discussion related to issue #111
Currently this allows the user to:
GameMode.MonteCarloandOmahafor now (TBH, i have no clue what any of those are).Omahaactually does not do anything for now.This functionality is isolated inside a helper
libin the examples folder for now. I suspect that this might be useful in other parts of the lib as well. I have also made thegame_simulationexample as a separate rustbinpackage. (So now to run an example, you would have to usecargo run --package game_simulationI also notice that you are moving towards decoupling the core poker functionalities and the different modes of games which sit on top of the core layer. A workspace based crate organization might help with that.. But anyways i digress.
Feel free to raise any particular issues related to architecture, design or anything.