Implementation of the Schotten Totten game in the C++ language.
Project created by:
- Ayoub El Hatri Link to his github
- Mohamed Hachelef Link to his github
- Yahya Atouf Owner of this repository
Sources: English:
- Schotten Totten (Base version): https://cdn.1j1ju.com/medias/d5/72/2f-schotten-totten-rulebook.pdf
- Schotten Totten 2: https://cdn.1j1ju.com/medias/77/76/71-schotten-totten-2-rulebook.pdf
- Schotten Totten (Version de base): https://iello.fr/wp-content/uploads/2022/07/schottentotten_regles.pdf
- Schotten Totten 2: https://iello.fr/wp-content/uploads/2020/11/SchottenTotten-2_rulebook_FR_Light.pdf
Implementation of the strategic card game Schotten Totten in modern C++.
(Repository: ZTOUF/SchottenTotten_CPP)
Replace (or keep) any placeholder sections after validating the actual project structure and code.
- Overview
- Game Rules (Brief)
- Features
- Project Structure
- Design & Architecture
- Core Concepts
- Build & Run
- Usage
- AI / bot logic (if applicable)
- Testing
- Configuration
- Roadmap / TODO
- Contributing
- License
- Acknowledgements
Schotten Totten is a two‑player tactical card game about capturing boundary stones by forming stronger formations (sets) than your opponent. This project aims to provide:
- A clean, extensible C++ implementation.
- Separation of core game logic from UI.
- Potential hooks for AI opponents or network play (future extensions).
Each player competes over 9 boundary stones.
On your turn:
- Play one card to one stone (on your side).
- (Optionally) Claim a stone if you can prove your formation is stronger.
Typical formations (from strongest to weakest):
- Straight Flush (Consecutive ranks, same color)
- Three of a Kind
- Flush (Same color)
- Straight (Consecutive ranks)
- Sum (Highest total value if none above applies)
A stone is won when:
- Both players have placed 3 cards on that stone and one side is higher, OR
- One player can prove the opponent cannot surpass their formation.
Victory:
- First to claim 5 stones total, OR
- First to claim 3 adjacent stones.
(Adjust according to the exact variant your implementation supports.)
- Core rule engine (deck, stones, formations, scoring).
- Deterministic resolution of formation strength.
- Turn sequencing & move validation.
- (Planned / Optional) AI opponent.
- (Planned / Optional) CLI or GUI layer.
- Clean abstractions for future expansion (e.g., online play).
Update this section with the actual implemented features.
(Adapt after verifying actual folders.)
SchottenTotten_CPP/
├─ src/
│ ├─ core/ # Core game logic (cards, stones, formations)
│ ├─ engine/ # Turn manager, rule arbitration
│ ├─ ai/ # AI strategies (if implemented)
│ ├─ ui/ # CLI/GUI front-end (if any)
│ └─ main.cpp # Entry point
├─ include/ # Public headers (if using an include/ layout)
├─ tests/ # Unit / integration tests
├─ assets/ # (If any: e.g., card art placeholders)
├─ CMakeLists.txt # Build configuration (if using CMake)
└─ README.md
If the structure differs, update accordingly.
- Card: (rank, suit/color)
- Deck: Shuffled container producing draws
- Stone: Holds up to 3 cards per player + claim status
- Player: Hand, moves, perspective
- GameState: Aggregate of players, stones, draw pile, turn
- FormationEvaluator: Compares formations and tie-breakers
- Separation of concerns: logic vs. presentation
- Minimal global state—pass immutable references where possible
- Potential for deterministic seeds (for reproducible games)
- Prefer exceptions for fatal rule violations (or status codes if performance-critical)
- Validation before mutating state
| Concept | Responsibility |
|---|---|
| Move Validator | Ensures a card placement meets rules |
| Claim Evaluator | Determines if a stone can be legally claimed |
| Formation Ranker | Assigns comparable strength tuple |
| Rule Engine | Orchestrates turn flow |
A typical formation strength tuple might be:
(primary_category, primary_value, secondary_value, kicker_sum)
Adjust per implementation details.
- C++17 or later (adjust if using C++20/23 features)
- CMake ≥ 3.16 (if applicable)
- A supported compiler: GCC, Clang, MSVC
git clone <private-repo-url>
cd SchottenTotten_CPP
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build -j
./build/bin/schotten_totten (example)
If not using CMake, document your actual build commands (e.g., Makefile, Meson, Bazel, etc.).
- Launch the executable.
- (If CLI) Follow prompts to place cards.
- (If GUI) Interact with board/hand.
Your hand: [G5][B3][R7][Y2][G9]
Select card to play: G5
Select stone (0-8): 3
Card placed. Opponent thinking...
Add real usage samples as implemented.
Potential strategies:
- Greedy: Maximize immediate formation strength
- Probabilistic: Evaluate unseen cards likelihood
- Heuristic scoring of stones (threat level, adjacency)
Document actual heuristics once finalized.
- Deck integrity & uniqueness
- Formation ranking edge cases
- Tie-break correctness
- Claim proofs (including “impossible to beat” logic)
- Victory conditions (5 total vs. 3 adjacent)
- Deterministic seed reproducibility
ctest --output-on-failure
Add badges or coverage tools (gcov/llvm-cov) if integrated.
Environment variables / config file (if any):
ST_SEED: deterministic RNG seedST_LOG_LEVEL: verbose / debug / quiet
If not present, remove or update.
- Finalize formation evaluator optimization
- Add full AI opponent
- Implement GUI (SDL2 / ImGui / Qt?)
- Add serialization (save/resume game)
- Add network multiplayer (WebSockets / TCP)
- Performance profiling & cache-friendly layout
- Internationalization (messages, logs)
Update according to actual priorities.
- Fork & branch:
feature/<short-description> - Format code (e.g., clang-format)
- Add / update tests
- Submit pull request with description of changes
Coding style suggestions:
- Use
#pragma oncein headers. - Avoid raw new/delete; prefer smart pointers or value types.
- Keep functions short and intention-revealing.
No license specified yet.
Add a LICENSE file (MIT / Apache-2.0 / GPL / etc.) so others know permitted usage.
- Original game design by Reiner Knizia (credit required for public distribution of implementations referencing his work).
- Inspiration from community rule clarifications.
- Any libraries or assets used (list here once integrated).
Given three cards, compute:
- Category (enum)
- Highest rank ordering
- Auxiliary sums
- Tiebreak chain
Example tuple ordering (descending compare):
(category, primaryRank, secondaryRank, tertiaryRank, sum)
To prove opponent cannot surpass:
- Enumerate remaining unseen cards.
- Check if any combination could reach a strictly higher category OR equal category with higher tie-break.
- If none possible -> claim allowed early.
Optimizations:
- Prune by max theoretical category first.
- Cache remaining card multiset.
(Examples)
- Build:
- Coverage:
- C++ Standard:
Feel free to refine sections once the repository contents are fully established.