Rock paper Scissors bot algorithm
ML System Design practice on Codemia
Design recommenders, ranking systems and training pipelines the way ML interviews actually ask for them, with worked solutions.
Introduction
A Rock Paper Scissors bot can be trivial if it plays random every turn, but stronger bots exploit predictable opponent patterns. The core challenge is balancing exploitation of observed behavior with enough randomness to avoid becoming predictable yourself. A practical bot usually combines several lightweight strategies and adapts as match history grows.
Start with Correct Game Logic
Before strategy, ensure move evaluation is correct and testable.
Return convention in this example:
1means bot wins,0means draw,-1means bot loses.
Stable scoring logic prevents strategy evaluation bugs later.
Frequency-Based Predictor
A simple non-random strategy assumes opponent repeats certain moves more often.
This works well against naive humans and scripted bots with biased distributions.
Short-Context Pattern Predictor
Some opponents follow local patterns, such as alternating moves. A context model can exploit that.
This one-step Markov style method remains lightweight and often beats pure frequency when local patterns exist.
Mixed Strategy to Avoid Exploitability
A deterministic bot can be reverse engineered. Add controlled randomness.
This preserves exploitation while preventing opponents from fully predicting the bot.
You can tune exploit_prob based on match length. Early rounds can be more random, later rounds more exploitative once behavior signal is stronger.
Evaluate Bot Performance with Simulation
Always evaluate strategy against multiple opponent types.
Extend evaluation to random opponents and scripted pattern opponents. A strong bot should outperform predictable opponents while not collapsing against random play.
Practical Improvements
Useful upgrades beyond baseline logic:
- maintain recent-window statistics instead of full-history,
- detect strategy drift and reset model state,
- ensemble multiple predictors with weighted voting,
- use confidence thresholds before exploiting predictions.
Avoid overfitting to one test opponent. Build a small benchmark suite with diverse behaviors.
Dynamic Strategy Switching by Confidence
A useful extension is confidence-aware switching. If predictor confidence is low, play closer to random. If confidence is high, exploit aggressively.
This prevents overreacting to noise in short or inconsistent histories.
Common Pitfalls
- Using deterministic logic without randomness, making bot exploitable.
- Evaluating only against one opponent style and overestimating strength.
- Letting stale history dominate when opponent behavior changes.
- Mixing scoring and strategy code in one function, which hurts testability.
- Ignoring draw rates when comparing strategy quality.
Summary
- Build a correct, testable game core before strategy work.
- Frequency and short-context predictors are strong lightweight baselines.
- Add controlled randomness to reduce exploitability.
- Evaluate against multiple opponent models, not a single script.
- Treat bot design as adaptive decision-making, not one fixed rule.
Related reading
- Run a Tensorflow model without having Tensorflow installed
- Run inference using Onnx model in python?
- Run Multiple Keras Models In A Cluster Like OAR2
- Run prediction from saved model in tensorflow 2.0
- Rolling median algorithm in C
- Rolling variance algorithm
- Run TensorFlow 2.0 on CPU without AVX
- Run Tensorflow unit tests

DSA Fundamentals
Master algorithmic patterns and data structures through hands-on LeetCode-style problems - from arrays and hashing to dynamic programming and advanced graphs.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
ML System Design practice on Codemia
Design recommenders, ranking systems and training pipelines the way ML interviews actually ask for them, with worked solutions.