Evaluacion-Cacho Turns a Dice Game Into a Rules Engine
A WinForms student project hides a surprisingly thoughtful scoring system, including dice flips, first-roll bonuses, and brute-force move suggestions.
- The most interesting part of Evaluacion-Cacho is not the WinForms shell, but the rules engine that searches for legal score states by flipping dice and re-running evaluation logic.
- The project encodes Cacho Alalay as a set of scoring rules with natural bonuses, major combinations, and turn-state logic that separates first-roll success from later play.
- Its helper logic already behaves like a tiny decision aid, recommending the best available move instead of merely reporting raw scores.
- The codebase is prototype-shaped, but the core idea is real: a local game becomes a combinatorial problem, and the program treats it that way.
The interesting trick is not the UI. It is the dice-flip search.
Most student game projects stop at roll, score, repeat. This one does something more interesting. It asks whether a hand can become valid if some dice are flipped to their opposite faces, then runs the scoring logic again on each variant.
That is the heart of `Evaluacion-Cacho`. The code does not just judge the current hand. It explores a small space of alternate hands, which turns a tabletop rule into a compact search problem.
Cacho Alalay, translated into code
The game logic is rooted in Cacho Alalay, a dice game with categories, special hands, and a first-roll bonus for natural outcomes. That matters because the scorer is not generic. It needs to know when a hand is just a hand, and when it is a special result earned immediately on the first throw.
That structure explains why the project’s scoring code feels more like a rules engine than a simple if-else ladder. It is tracking both the category and the context of the roll, especially whether the result was achieved de mano, on the first throw.
`CalculadoraPuntajes.cs` is the real engine
The most interesting file is `CalculadoraPuntajes.cs`. It uses LINQ to recognize patterns in the dice, which is exactly what you want in a scorer. Group the values, count them, and test for combinations like poker, full house, straight, and grande.
var grupos = dados.GroupBy(d => d).ToList();
var esPoker = grupos.Any(g => g.Count() >= 4);
var esFull = grupos.Count == 2 && grupos.Any(g => g.Count() == 3) && grupos.Any(g => g.Count() == 2);
var esEscalera = dados.OrderBy(d => d).SequenceEqual(new[] { 1, 2, 3, 4, 5 }) ||
dados.OrderBy(d => d).SequenceEqual(new[] { 2, 3, 4, 5, 6 });The real surprise is the vuelcos logic. Rather than hardcoding one special case, the scorer generates flipped-dice variants and re-evaluates them. That means the code is not just checking a hand. It is searching for the best legal hand inside a tiny state space.
The turn state is simple, but not elegant
`ControladorDados.cs` handles the physical side of the game. It keeps the current dice values, rerolls only the dice the player did not hold, and tracks how many attempts have happened in the turn. That is enough for a game loop, even if it is not the cleanest object model.
`Form1.cs` does the glue work, and it shows the project’s prototype shape. A large set of booleans tracks which scoring categories each player has already used. It works, but it ties the UI to the rules more tightly than a larger codebase would want.
| Current repo shape | Cleaner long-term shape |
|---|---|
| Many booleans in `Form1.cs` | A `Player` object with a structured scorecard |
| Variant generation inside the scorer | A separate rule-evaluation pipeline |
| UI and logic closely coupled | State, rules, and presentation split apart |
| Turn tracking by flags and arrays | Explicit turn and hand objects |
The helper system is a tiny hint of AI
The suggestion logic, `MarcarMejorJugada`, is a small but useful touch. It scans the available scoring options and points the player toward the best one. That is not machine learning, but it is decision support, and for a classroom project that is a meaningful step up from a passive scorer.
This is where the repo quietly stops being just a game UI. It starts behaving like an assistant that understands the rules well enough to recommend a move.
A student project with a real architectural smell
The codebase reads like a late prototype, and that is not a criticism so much as a diagnosis. There is redundancy, there is hardcoding, and there is a lot of state pinned directly to the form. Those are signs of a project built to work, explain itself, and submit cleanly.
But the interesting part survives the rough edges. Even with the prototype shape, the project contains a genuine rules engine and a brute-force search idea that feels more ambitious than the average course submission.
What this project would look like with a cleaner model
A more scalable version would probably separate `Player`, `Turn`, `Scorecard`, and `RulesService`. That would make the code easier to test, easier to extend, and easier to read without carrying the entire UI state in one file.
Still, the current design has a useful honesty to it. You can see exactly where the logic lives, exactly where the state changes, and exactly how a hand gets evaluated. For an explainer, that transparency matters.