What changed in this revision
The earlier note mixed design proposals with descriptions of the game. This revision separates source observations, mathematical illustrations, and future experiments. No player-study dataset, solved opening position, benchmark win rate, or peer-reviewed result is claimed.
The public release history now includes Magic Match and Rush changes. Those variants require a wider model than ordinary alternating moves on a board of permanently used edges. Their exact behavior should be tied to an app version when reporting experiments.
Implementation snapshot: the native Brutal bot
A September 5, 2026 review of DotballNativeView.swift in the local Dotball checkout (HEAD d59d890) found a 9-row, 7-column board and moves to unused adjacent edges, including diagonals. The rankedMoves entry point evaluates Brutal candidates with a depth parameter of 6. Its helpers resolve scoring and penalty continuations, order candidate moves, apply alpha-beta bounds, and use a position cache. This is a source snapshot, not confirmation that all store releases use identical code.
The position heuristic combines goal distance, central placement, available exits, side to move, and immediate scoring opportunities. This explains the implementation's tactical intent, but does not establish its playing strength. The reviewed search does not establish an MCTS or reinforcement-learning engine. Those approaches below are proposals only.
Important validation work remains: compare cached search with uncached minimax on small positions, including narrow alpha-beta windows. A node that does not cut off locally can still inherit bound-valued child results. A transposition table should distinguish exact values from upper and lower bounds rather than assume every stored score is exact. This note does not certify the current cache or solver as correct.
A reproducible size illustration, not a solved state count
For an R-by-C rectangular grid with horizontal, vertical, and both diagonal adjacencies, the undirected edge count is E = R(C - 1) + C(R - 1) + 2(R - 1)(C - 1). A 9-by-7 grid has 63 nodes and 206 such edges; a 7-by-5 grid has 35 nodes and 106 edges. These are geometric counts before scoring rules or reachability restrictions, not counts of valid game states.
For a simplified ordinary-play state containing only ball location, side to move, and a used-edge subset, 2RC times 2^E bounds the number of encodings. Most encodings need not be reachable. Scores, penalty phases, variant state, and rule-specific transitions require additional variables. The formula is neither an exact Dotball state-space count nor a complexity-class proof.
Similarly, a hypothetical branching factor of six produces 6^10 = 60,466,176 depth-ten sequences before pruning. Actual branching changes near borders, used routes, and scoring states. This arithmetic illustrates growth; it is not a measurement of the shipped bot's workload.
Abstract
Dotball Beat The Ball is easy to understand because each turn moves the ball through a visible field of dots. It becomes difficult because every move is also a graph decision: a player chooses an edge, changes the local geometry of the position, and creates future access or denial for both players. A small board can feel casual, but the underlying problem quickly becomes a search problem with combinatorial growth.
The reviewed native implementation uses a 9-by-7 board, several bot difficulty settings, Game Center integration, and legal-move indicators. The public App Store history also records Magic Match and Rush updates. These observations motivate the model; they do not establish fairness or optimality.
This note explores candidate algorithms and testable design questions. A depth-limited evaluation estimates a position; only a complete, validated solver for a specified ruleset could justify a perfect-play claim. We have not provided such a solver here.
The board as a graph
The cleanest way to model Dotball is as a graph. Each dot is a node. Each legal move between nearby dots is an edge. The ball's current location is the active node. A turn selects one legal edge from the current node to a next node. Goal lines or goal regions are terminal areas where scoring can occur.
If an edge can be used only once, the game becomes a dynamic graph where every move removes or marks an edge. If dots can become blocked, occupied, or directionally constrained, the state must also track those restrictions. The full state is therefore more than the ball position. It includes the board dimensions, the used edges, any blocked nodes, the score, the player to move, penalty-kick spots, Game Center side assignment, and match rules such as first-to-3.
This matters because two positions that place the ball on the same dot may not be equivalent. The surrounding path history can completely change whether the next player has a winning route, a trap, or no meaningful attack.
Why the game becomes difficult
The difficulty comes from branching. If the ball has several legal moves at each turn, the number of possible future lines grows quickly. A position with six plausible moves per turn has 6 to the power of 10 possible ten-move lines before pruning. Many of those lines are bad, illegal later, or strategically redundant, but the raw tree becomes large fast.
The game also has delayed consequences. A move that looks defensive may open a scoring lane three turns later. A move that looks aggressive may trap the player by giving the opponent a forced sequence. This makes Dotball more interesting than a simple race to the goal, because the best move is often the one that improves future geometry rather than the one that moves closest to scoring immediately.
Difficulty also depends on the scoring rule. Automatic scoring when the ball reaches the opponent's goal makes threats clearer and faster. It reduces the need for a separate shoot action, but it increases the importance of preventing forced arrival routes. In other words, the strategic question shifts from can I shoot now to can I force the ball into a scoring node before the opponent can redirect it.
The latest move-choice design also changes perceived difficulty. Replacing ambiguous colored dots with pulsing choice rings makes legal moves easier to read. That does not reduce the mathematical complexity, but it reduces cognitive friction, which is important for a game where the strategy should be hard but the interface should not be.
Perfect play as a search problem
A perfect-play algorithm tries to answer one question for every position: with best play from both sides, is this state winning, drawing, or losing, and which move gives the best outcome. For very small boards, this can be solved by exhaustive search or retrograde analysis. The algorithm enumerates all reachable states, labels terminal scoring states, and works backward to classify earlier states.
For realistic mobile boards, exhaustive search may be too expensive. The engine should then use minimax: the bot assumes it chooses moves that maximize its result while the opponent chooses moves that minimize it. Alpha-beta pruning can remove branches that cannot change the decision, making the search much faster without changing the final answer at a fixed depth.
A practical scoring function can evaluate non-terminal positions by combining distance to the opponent goal, number of available routes, defensive coverage, trap risk, center control, forced-move opportunities, and whether the opponent has an immediate scoring threat. This lets the bot search several turns ahead and still make a decision before the player feels a delay.
A production mobile bot should also use rule-aware terminal detection. If a move creates an immediate goal, it should be evaluated before positional heuristics. If a player has no legal move, the evaluator should test whether a penalty kick is available. If the marked PK spot is also blocked, the awarded player receives the goal automatically. If the center has no unused exit and no scoring or PK continuation exists, the round can end because the graph is locked.
Candidate algorithms
The simplest strong algorithm is heuristic minimax with alpha-beta pruning. It searches possible move sequences to a fixed depth and scores the leaf positions. It is predictable, tunable, and good for difficulty levels. Easy mode can search shallowly with a noisy evaluation. Clever mode can search deeper. Brutal mode can search deepest, check immediate tactics first, and use better ordering to prune faster.
A practical brutal mode should use a priority stack before ordinary search: first take a guaranteed goal, then prevent an opponent goal, then prefer moves that force a penalty kick, then prefer moves that reduce the opponent to one or zero exits, and only then optimize ordinary territory. This makes the bot feel intentional because it wins through visible pressure rather than random-looking movement.
Monte Carlo tree search is a candidate alternative that allocates simulations across a search tree. Browne and colleagues survey its methods and tradeoffs. For Dotball, its strength relative to the existing bot must be measured under equal time budgets; simulation-based search is not inherently more human-like or a guarantee of optimal play.
Reinforcement learning is a third path. A model can play many games against itself and learn which board states lead to wins. This is attractive for future versions, but it needs careful training, evaluation, and guardrails. For an early App Store game, a tuned minimax engine is more explainable and easier to ship reliably. A hybrid approach may be best: minimax for tactics, Monte Carlo or learned evaluation for strategic judgment on larger boards.
Penalty kicks, center locks, and edge cases
The penalty-kick rule is important because it gives no-move positions a tactical consequence instead of treating them as dead ends. If a player blocks the opponent so completely that the opponent cannot move, the opponent does not simply lose the turn. The blocking player earns a marked PK opportunity, and that PK becomes part of the search tree.
If the awarded PK spot is full or has no legal continuation, the cleanest rule is to count an automatic goal for the awarded player. This avoids ambiguous ties and rewards the player who created the pressure. It also gives the bot a concrete objective: force no-move states that convert into PKs or automatic goals.
Center lock is different. If the center has no unused exit, the game should not stop while the ball is still in a live attack or while a PK or goal can still happen. The round should end only when there is no legal ball move and no remaining scoring or PK resolution. This distinction keeps the rules fair and avoids ending a point before the visible strategy has resolved.
Toward the highest score
If the match is first-to-3, the highest score in a single match is bounded by the rules. The optimization problem is therefore not infinite scoring, but maximizing expected scoring advantage: win as quickly as possible, allow as few opponent goals as possible, and avoid risky lines that turn a likely 3-0 into a 3-2.
The algorithm should treat a goal as a terminal reward and score differential as part of the match state. A move that wins the current point is usually best, but if no immediate goal is available, the best move is the one that maximizes expected future goals while minimizing opponent arrival routes. In tournament or ranking modes, the objective can expand to expected win rate, average goal differential, shortest win length, or resilience against different player styles.
A perfect solver for a fixed board could produce an opening book: for common early positions, the bot already knows the best move without searching. This would make high-difficulty play feel crisp while preserving battery life and responsiveness on mobile.
What changes when length changes
Increasing the board length makes the game more about tempo and long-term route control. The ball has farther to travel before scoring, so a single move rarely decides the point. Players can recover from small mistakes, and the bot needs stronger planning to choose between advancing, redirecting, and building future pressure. The current 9-by-7 arena family is a practical mobile compromise: long enough for route planning, but short enough that a point still resolves quickly.
Shorter boards make the game sharper. The distance to goal is small, so immediate threats are more common and mistakes are punished quickly. This can be exciting for casual play, but if the board is too short, first-player advantage or forced scoring lines may dominate. Short boards need careful balancing, such as symmetric starting positions, restricted opening moves, or wider lateral space.
A longer board also expands the search horizon. If the goal is many moves away, a shallow bot may undervalue moves that create future attacks. This makes board length directly connected to AI difficulty: longer boards require better evaluation, not only deeper brute-force search.
What changes when width changes
Increasing width creates more lateral choices. This usually increases creativity because players can route around blocks, set traps on one side, or switch fields. Wide boards support more strategic variety, but they also increase the branching factor, which makes perfect play harder to compute. On mobile, width also has a user-interface cost: too many columns can make touch targets smaller and legal choices harder to see.
Narrow boards create forced races. There are fewer escape routes, so blocking and direct pressure matter more. This can produce fast, tense games, but it may reduce replayability if too many positions collapse into the same forced paths. A narrow board works best when the game wants speed, pressure, and easy readability.
Width also affects fairness. If one lane becomes obviously dominant, a bot or experienced player may repeatedly force that route. Good board design should make multiple lanes viable, with some routes faster but riskier and others slower but safer.
The combined possibility space
Changing length and width together creates different game families. A short and narrow board is tactical and fast. A short and wide board becomes a quick puzzle with many lateral tricks. A long and narrow board becomes a pressure corridor. A long and wide board becomes a strategic territory game where route planning matters most.
From a complexity perspective, the number of nodes grows roughly with length times width, while the number of potential edges grows with the movement rules around each node. Because each turn changes which edges or nodes remain useful, the reachable state space grows much faster than the visible board size suggests.
This means a small adjustment in dimensions can have a large effect. Adding one column may create several new legal paths from many rows. Adding one row may lengthen every scoring race. The best way to tune the game is to measure not only board size, but average legal moves per turn, average point length, first-player win rate, comeback rate, and how often games end by forced routes versus creative decisions.
Recommendations for making Dotball more fun
The game should keep multiple arena identities while controlling the board dimensions carefully. Different city themes can change the feel of the match without making the rules harder to learn. Each arena should be tested for first-player advantage, average point length, comeback rate, and how often goals come from route skill versus accidental traps.
Beat the Bot becomes more interesting when difficulty changes behavior, not only search depth. Easy should make understandable mistakes. Clever should block obvious threats and set short traps. Brutal should search deeper, defend first, hunt PK pressure, and recognize forced scoring routes. This makes the bot feel like three opponents rather than one opponent with different delay settings.
The highest-value improvement is analysis after scoring. The board should stay visible, the winning route should remain readable, and the user should be able to pause long enough to understand how the point happened. That turns Dotball from a simple mobile game into a learnable strategy experience, which helps players improve and gives the game a stronger identity.
For online multiplayer, Game Center should reduce setup friction. Quick Match is naturally strong because it starts with minimal coordination. Invites require clearer acceptance state, player identity, and board orientation so both players understand whether they are Player A, Player B, red, blue, attacking up, or attacking down.
Magic and Rush need separate experimental rulesets
The reviewed Magic implementation can offer an extra move, clear a used line, or arm protective effects. Clearing a line breaks the ordinary assumption that every move monotonically consumes the graph. Extra turns mean the next player cannot always be inferred by flipping sides. Model remaining effects, activation state, choices, and any random outcomes explicitly.
Rush adds a move deadline and helper mechanics. Treat timeout behavior as a transition, and separate engine thinking time from a human player's time limit. Do not combine ordinary, assisted, and timed matches in one headline win rate. They test different tasks.
A finite-state model is not automatically an acyclic game tree. If rules permit cycles or edge restoration, a solver needs explicit repetition or termination semantics. Any randomness calls for chance-node treatment or a stated stochastic policy rather than plain deterministic minimax alone.
Evaluation protocol for the next research update
Freeze the ruleset, source revision, board dimensions, scoring target, and variant before collecting results. Build fixtures for immediate goals, own goals, no-exit penalties, blocked penalty spots, and special-move transitions. Validate legal moves and terminal outcomes independently of the bot's evaluation function.
On small boards, compare a reference exhaustive solver with alpha-beta results at the same horizon, first without caching and then with it. Record disagreements rather than treating a plausible move as proof. Test mirrored states only when the transformation preserves goals, player roles, and every special rule.
For strength comparisons, use a fixed opening suite, swap sides for each pairing, fix random seeds where applicable, and give algorithms equal per-move time budgets on the same device. Record the number of matches, wins, draws, goal differential, legal-move failures, search nodes, and median and tail latency. Report uncertainty and paired outcomes rather than cherry-picking impressive wins.
No results from that protocol are reported yet. The next meaningful milestone is a versioned fixture set and baseline results, not a claim that Brutal is unbeatable. Human testing would separately assess comprehension, enjoyment, and accessibility; bot-vs-bot scores cannot establish those outcomes.
Conclusion
Dotball's appeal comes from the gap between simple rules and deep consequences. A player sees dots and a ball, but the engine sees a changing graph with threats, traps, forced moves, and terminal scoring states. That makes the game a strong candidate for AI opponents and research-driven tuning.
A small, precisely specified ruleset may be a useful starting point for exhaustive solving. For the mobile game, the reviewed depth-limited bot is a baseline to validate and benchmark, not evidence of perfect play. Alternative search methods and board shapes should earn their place through reproducible comparisons.
Board length and width are not cosmetic settings. They reshape the entire strategic character of the game. The right version of Dotball is therefore not only a game implementation, but an ongoing balance problem: adjust the graph, observe player behavior, tune the bot, and keep the rules transparent enough that every loss feels explainable.