2024-04-08 - Week 02 - Afternoon

Back to Software Construction, Spring '24

Link to 2024-04-01 Afternoon

• Get paired up randomly with a classmate and a prototype-xx where xx is from 00 to 15
• Open up your GitPod workspace for upper-division-cs monorepo on main branch or use your local laptop.
• Create a directory for your prototype

cd <monorepo_dir>
mkdir -p sc-24sp/prototypes/
cd sc-24sp/prototypes
cargo new prototype-xx

• Type the tic-tac-toe solver from this morning by creating empty files and directories in your src folder according to this tree

and filling them in with screenshots from below.

Feel free to improve and refactor any of the code as you go along to use more idiomatic Rust and best programming practices.

As you go along, please document your work for this prototype in a README.md file using dev diary guidelines.

This will be asked for as part of SC Homework 02, and help other teams continue your work when we switch prototypes.

Choose a driver who will type the code in their preferred development environment, while the navigator reads out code from the screenshots below.

Feel free to pause and ask questions and discuss anything that seems interesting or unclear (or both) about the code and Rust.

Empty for now.

The impl Board<'static'> at the bottom in gray is not to be typed in. That was added by rust-analyzer.

The driver should add, commit, push, create a pull request, and merge according to our Git Workflow.

Switch drivers and navigators here.

This is roughly the halfway point.

The new driver will pull from main on their preferred development environment, and the new navigator will read to them the remaining files.

Build and run your project to uncover any typos, logical errors, or other learning opportunities.

cargo build
cargo run

Play a game of tic-tac-toe to try and make sense of how the console input and output relate to the code that you just typed. It will look similar to this game transcript from class this morning

Board { cells: [[None, None, None], [None, None, None], [None, None, None]], next_to_move: O }
Input your move as a tuple: (y,x) where x,y are 0 1 2: 
1,1     
Input your move as a tuple: (y,x) where x,y are 0 1 2: 
(1,1)
Board { cells: [[None, None, None], [None, Some(O), None], [None, None, None]], next_to_move: X }
Board { cells: [[None, Some(X), None], [None, Some(O), None], [None, None, None]], next_to_move: O }
Input your move as a tuple: (y,x) where x,y are 0 1 2: 
(2,2)
Board { cells: [[None, Some(X), None], [None, Some(O), None], [None, None, Some(O)]], next_to_move: X }
Board { cells: [[None, Some(X), Some(X)], [None, Some(O), None], [None, None, Some(O)]], next_to_move: O }
Input your move as a tuple: (y,x) where x,y are 0 1 2: 
(0,0)
Board { cells: [[Some(O), Some(X), Some(X)], [None, Some(O), None], [None, None, Some(O)]], next_to_move: X }
Board { cells: [[Some(O), Some(X), Some(X)], [Some(X), Some(O), None], [None, None, Some(O)]], next_to_move: O }
diag1 was winning
🏆 GAME WON 🏆 
 by O

The driver should add, commit, push, create a pull request, and merge according to our Git Workflow.

Switch drivers and navigators here.

The new driver will pull from main on their preferred development environment, and the new navigator can look up documentation or help guide the discussion.

• Rust Interactive Book
• Rust-by-Example

Your goal this afternoon, and part of SC Homework 02, is to make progress on improving and refactor your assignment prototype to fix these two issues:

• Illegal moves cause the solver to misunderstand whose turn is next. You should handle these two kinds of illegal moves:
  • Unparseable moves from the human player
  • Either human or solver trying to make a move on a board cell that is not Empty.

The overall goal is complete the solver so that it either always draws against a human player, or wins if a win is possible when the human player deviates from the optimal strategy.

You have complete freedom to modify the code, introduce new modules and functions, to solve this problem.

Here is one suggested approach

In validators/mod.rs we have a function that checks for all known win conditions on a tic-tac-toe board.

If we express these win conditions as a Vec of Sets of three Moves,

let win_

then we can make use of this Vec of Sets in two ways.

1. We can directly compare a current board if it contains the Moves of a Set all matching the same player, and return a win in a more uniform way than checking columns three down first, rows three across first, etc.
2. We can measure how close each

As discussed in class, no matter which player goes first, it should always be possible for the other player to end the game in a draw or a win.

To make progress in this direction, add in ranker.rs with a pub function that takes in a board, and all available moves (created from list_moves in crate::moves::enumerator module) and returns a new

pub fn ranked_moves_iter(board: &Board, move_list: &Vec<&Move>) -> Iter