Design Patterns for Games Stephen Wong Dung Nguyen Rice University

Let’s Play a Game  Sun’s Tic-Tac-Toe Sun’s Tic-Tac-Toe  What can we learn from this? What can we learn from this? –Arrays –For-loops –Nested Conditionals  What aren’t we learning? –Delineation of concepts from implementation –Abstraction –Design

Something Different…  It’s not really about TicTacToe… –It’s a vehicle to teach something BIGGER.  Abstraction  Design Process  Fundamental Principles

What’s in a Game? XX O O Controller Model Rules Players Strategies View Buttons, etc. Display outputs adapter Install adapters

Game Model  Rules of the Game –Board configurations –Legal moves  Next Move Strategies –Random –Min-Max –Etc.  Player Management –Turn taking –Win/lose/draw notification –Fault handling Decouple these components! Abstract these components!

The Rules of the Game IBoardModel IBoardStatusVisitor makeMove(player, row, col), chkMoveCmd) IUndoMove, bdStatusVstr) ICheckMoveCmd validMoveCase() invalidMoveCase() player1WonCase(…) player0WonCase(…) noWinnerCase(…) drawCase(…) IUndoMove apply(…) commands host/visitor Object execute(bdStatusVstr, param) // other methods

State Diagram Invalid Move State Valid Move State Non-Terminal State (no winner yet) Terminal States Player #0 Wins Draw Game Player #1 Wins

ABoardState state State Design Pattern TicTacToeBoard Player1WonPlayer0WonDrawGameATerminalStateNonTerminalState IBoardModel execute(IBoardStatusVisitor v, …) v.player0WonCase(…) state.execute(v, …) v.player1WonCase(…) v.drawCase(…) v.noWinnerCase(…)

Playing the Game ComputerPlayer takeTurn(…) INextMoveStrategy Point getNextMove(…) RandomAlphaBetaMinMax The next move process is decoupled from the rules of the game!

Facade APlayer takeTurn(…) IBoardModel makeMove(…) TurnControlIView IRequestor

What the player sees: public interface IRequestor { public abstract void setTokenAt( int row, int col, int player, IRejectCommand rejectCommand); } public interface IRejectCommand { public abstract void execute(); }

Player Factories IView GameModel Set of APlayer factories Selected APlayer factories Only displays the toString() of the factories. The factories are treated as Objects! private interface IMakePlayer { public APlayer create(int playerNo); }

The Set of APlayer Factories public Vector getPlayers() { Vector v = new Vector(); v.addElement(new IMakePlayer() { public APlayer create(int playerNo) { return new HumanPlayer(requestor, playerNo, turnAdmin); } public String toString() { return "Human player"; } }); return v; } Anonymous APlayer factory IView only cares about this! Factory method

Min-Max Principle V(s) =  For terminal state  +1, if s is a winning state for that player  0, if s is a draw state  -1, if s is a losing state for that player  For non-terminal state  max{V(c) | c is a child valid move state of s}, if that player moves next  min{V(c) | c is a child valid move state of s}, if the other player moves next. The best next move for a given player, m, is determined from max{V(c) | c  S} where S is the set of available moves for that player. How max is computed is a variant. Application of a process over a set!

Mapping and Lambda  Math/FP: Map(, S) = { (x) | x  S}  Express our algorithm in terms of mapping, not iteration: –min(…)  map(, min-accum) –max(…)  map(, max-accum) Both accumulators are abstractly equivalent!  Backtracking is automatically handled by mapping.

IBoardLambda Mapping Abstraction IBoardModel makeMove(player, row, col), chkMoveCmd) IUndoMove, bdStatusVstr) command Object execute(bdStatusVstr, param) void map(player, lambda, param) boolean apply(board, param, row, col, cell-val) void noApply(board, param) Controls continuation of mapping Called when there are no valid moves. Called on all valid moves.

Min-Max Abstraction INextMoveStrategy MinMaxaccFac:IAccFactory AAccum makeAcc(player) minMaxEval:IBoardLambda boolean apply(…) void noApply(…) Point getNextMove(model, player) AAccum acc = accFac.makeAcc(player); model.getBoardModel().map(minMaxEval, acc); return acc.getMove();

private IBoardLambda minMaxEval = new IBoardLambda() { public boolean apply(board, acc, row, col, cell-value) { IUndoMove undo = host.makeMove( row, col, acc.getPlayer(), validMvVstr, new IBoardStatusVisitor() { player0WonCase(...) {…} player1WonCase(…) {…} drawCase(…) {…} noWinnerCase(…) { undo.apply(validUndo); return acc.isNotDone(); } Update accumulator Update accumulator Update accumulator AAccumulator nextAcc = acc.makeOpposite(); host.map(nextAcc.getPlayer(), minMaxEval, nextAcc); acc.updateBest(row, col, nextAcc.getVal()); return null; } }); Try a test move. Undo the move. Declarative style programming! to be mapped over the available states. Called by map on each valid (row, col) What to do in each situation Stop mapping?

Alpha-Beta Pruning public class AlphaAcc extends MaxAcc { public AAccumulator makeOpposite() { return new BetaAcc() { { this.modelPlayer = AlphaAcc.this.modelPlayer; } public boolean isNotDone() { return AlphaAcc.this.getVal() < this.getVal(); } }; } } Just a new accumulator! Override the creation of the next level’s accumulator Accumulator for the opposite player as an anonymous inner class. Stop mapping if pruning condition is met. Abstraction isolates the essence and provides extensibility Inner class gives the scoping we need!

Player Management Event-loop for turn-taking Call-back techniques for asynchronous processing Abstract players

Design Patterns In Action  MVC separates model from view  Commands and Visitors isolate rules from behaviors  State pattern models game behavior  Calculating the next move is a Strategy Design patterns express abstractions

Concepts in Action  Abstract functions – lambda’s  Higher order functions – Mapping  Declarative programming  Invariant: Min-Max Principle  Variant: –Full depth-first search –Alpha-beta pruning

More Information…  Design Pattern for Games:  Patterns for Decoupling Data Structures and Algorithms: