Forem: Syed Ali Mansoor

Component Breakdown & State Management ⚙ - Building a tic-tac-toe game with React from scratch

Syed Ali Mansoor — Mon, 04 Jul 2022 05:41:35 +0000

Welcome! 👋

ℹ️ This post is part of a series, where I pen down my journey as I plan and build a tic-tac-toe game from ideation to release

In the previous post, we designed the app's UI, from displaying the start screen to displaying the result of a tic-tac-toe game:

The React mindset dictates that user interfaces be broken down into individual components, each of whom performs a single task. This will help us abstract away irrelevant logic while developing the app and reuse code whenever possible. Let's understand this with an example:

In this screen, we can see some repetition happening in the form of a piece of UI that displays a player's name and mark (inside the dotted square).

We can either write code to display both player's details separately, or we can create a single component that accepts a player's details as parameters, and then handles displaying those details itself. We can then use that component twice, telling it to display a different player each time:

Hence we only need to write the code to display details once and can reuse it for both players!

Seeing the clear benefit of this approach, let us go ahead and break our app's UI down into individual components. We will start off with the three screens:

Start
Settings
Game

All other components would be children of these, and each of these represents a different section in the user flow. Therefore we could also call them page/layout components.

1. Start

The Start page will consist of only two components: StartButton, and Attribution. Displaying the X and O in the background can be handled by Start itself.

2. Settings

The SettingsForm component will house and lay out the SelectGameMode, SelectGridSize, and EnterPlayerNames components, each of which will enable the user to edit the game settings. EnterPlayerNames will house 2 instances of PlayerNameField, which will allow editing the name of a single player.

When the game mode is PvP, both fields will be editable, whereas in PvC, only the player 1 field will be editable and the player 2 field will contain the uneditable text "A.I."

3. Game

The top section of the game screen will be contained in GameHeader and the rest of the components will be direct children of Game.

Grid will render a square grid of GridCell components, and each GridCell will update its background color and image appropriately when it is clicked or when there is a match.

When the game ends, the Result component will be displayed, stating the outcome, and RestartButton will become highlighted, to probe the player(s) to play another game.

Let us now think about the data that our game will need to keep track of.

Defining data

React applications work with data that may frequently change and the UI needs to update in respond to these changes. Such data is called state, and it can be stored either in the global scope, where it is accessible to all components, or in the component scope, where it is accessible to only a single component and optionally its children. State management libraries like Redux allow us to store data in the global scope and write methods to access and change it.

It is good practice to store data that is related to the business logic in the global scope, and that which is related to UI/component logic in the component scope.

We can understand this with the example of an online shopping site. The items in your cart would be stored in the global scope, but whether the cart is currently open/visible or closed/hidden would be stored in the component representing the cart itself.

Using this convention, we can extract the following data to be stored in the global scope of our application:

Game mode: string containing either "PvC" or "PvP"

type GameMode = "PvC" | "PvP"

Grid size: the number 3, 4, or 5

type GridSize = 3 | 4 | 5

Players: array containing 2 player objects, where each player object stores the type of player ("human"/"ai"), the name of player, and their score

type Players = [Player, Player]

type Player = {
  type: "human" | "ai"
  name: string
  score: number
}

Grid: array containing child arrays, each of which contains cell objects, where each cell object stores its mark (""/"X"/"O") and whether it is part of a match

type Grid = Cell[][]

type Cell = {
  mark: "" | "X" | "O"
  match: boolean
}

Current player: number, either 0 or 1, representing the index of the current player

type CurrentPlayer = 0 | 1

Game end: object representing whether a match has been made, whether there has been a draw and whether the game has ended

type GameEnd = {
  match: boolean
  draw: boolean
  end: boolean
}

We now have ourselves the following global state tree:

{
  gameMode,
  gridSize,
  players,
  grid,
  currentPlayer,
  gameEnd
}

Now that we have a solid component hierarchy, as well as a global state tree, we can finally start the development process.

⚡ Join me in the next post in this series, where we will set up our development environment and build the first two pages of the app

❤️ Remember to like this post and leave your thoughts in the comments!

Wireframing & Design 🎨 - Building a tic-tac-toe game with React from scratch

Syed Ali Mansoor — Mon, 20 Jun 2022 07:58:57 +0000

Hello there! 👋

ℹ️ This post is part of a series, where I pen down my journey as I plan and build a tic-tac-toe game from ideation to release

In the previous post, we set the foundations for our tic-tac-toe game by planning the entire app ahead of time. We broke down the app's functionality into a list of specific objectives and goals. These will now help us in creating the look of the game.

Step 1: Wireframing

Before delving too much into the colours, animations, and fine details, we need to draw up a low-fidelity wireframe which will provide a basic layout for the different screens in our app, and help visualize user flow.

My tool of choice for this job is Whimsical. It has a lot of customizable UI elements and controls built-in which allow for quick wireframing.

The app can be broken down into three major views:

Displaying game settings
The actual game
Displaying the game's result (win/draw)

Let's start with the first view. In the previous post we decided to allow setting the following game settings:

Game mode (PvP/PvC)
Grid size (3 - 5)
Player name(s)

The layout is centered on the screen, so that the user doesn't have to move their eyes much to the sides. It also presents a top-to-bottom hierarchy, wherein focus will first fall on the heading/logo, then on each option, and then finally on the action button, which will start the game.

For the second view, we need to have the following elements be visible to the user at all times:

Tic-tac-toe grid
Current player indicator
Players' names
Players' scores
An option to reset the grid
An option to adjust the settings

Let's add them:

The toggle switch in the bottom will not be an actual input control, but rather an indication of the current player, whose name will be present on the switch's thumb. I made the reset and settings buttons smaller and moved them to the top right since they are a secondary part of the interface and the user's focus will lie on the grid for a larger part of their time on the app.

Now for the third screen, we need to display buttons to restart the game and edit settings, and information about the result of the game, i.e. whether someone won or there was a draw, and if someone did win, who was it?

Nice and simple! 👌

Creating wireframes before jumping into designing has helped us lay a foundation for the next step and make core design decisions beforehand. Notice how they don't depict too much, but show only what is absolutely necessary, and that is enough for us to make a mental model of the app.

Step 2: Designing

Now we will really get into the finer details and design an interface that looks beautiful, and is functional. My tool of choice for this task is Lunacy, a free design app for Windows, macOS and Linux.

Here is a list of the things we need to design:

Game logo
Splash screen
Settings screen
- Hover/active states for:
  - Game mode selector
  - Grid size selector
  - Player name fields
  - Start button
Game screen
- X/O symbols
- Hover/active states for:
  - Grid (cells)
  - Reset and settings buttons
Result screen

Each screen has to be designed for both mobile and desktop viewers. Let's get to it! 🖌️

Splash screen

This screen consists of the logo inside a button which can be pressed to start the game. Also a little attribution to the app's eventual developer.

Settings screen

I switched up the layout for this one a bit and for the grid size selector, I dropped the slider in favour of buttons to improve consistency.

Game screen

The game screen is nearly the same as in the wireframe, although while experimenting with hover states, I thought of a feature where the user could reset the score by simply clicking on it. Additionally, each cell should show the mark of the current player on hover.
Hover state:

Game result

I dropped the idea of a separate game result screen in favour of an overlay stating the result. This would prevent too many layout shifts and re-renders, would allow the user to see the end game state, and may also allow us to add some neat animations.

The overlay should display either "xxx takes the game!", or "It's a draw!"

View all the designs, including hover and active states on an infinitely zoomable canvas here!

Now that we know how the app is supposed to look on a screen, we have to get just a few more things done before we can start the development process.

Firstly, a component breakdown, wherein we will identify small sections of the app that can be isolated and developed on their own.

After that, we will decide what data our app will store, where we will store it, and how each component will access and modify it.

⚡ Stay tuned for the next post in this series, where we will perform a component breakdown and define our app's data.

❤️ Remember to like this post and leave your thoughts in the comments!

Ideation 💡 - Building a tic-tac-toe game with React from scratch

Syed Ali Mansoor — Wed, 01 Jun 2022 12:48:49 +0000

Greetings, fellow human! 👋

ℹ️ This post is part of a series, where I pen down my journey as I plan and build a tic-tac-toe game from ideation to release

Every project needs a space where you can jot down your thoughts, gather resources, and plan ahead. Some demand a robust project management system with all the latest features, some need nothing more than a todo list, and some do just fine with traditional pencil and paper.

The project hub of my choice is Notion, a great app/website that does it all—or at least, all that I need. I start off the planning process with a new project page, inside of which I have just two sections, nothing more. An inline database called Bucket will store everything I prepare to assist the process, and a Links section will be where I place articles and resources from the internet that I find useful.

The links already there helped inspire my planning process

With the project hub all set up, it is time to proceed. ⏩

Defining the app's functionality

With every programming venture, it is important to first identify and break down the app's functionality. What are the minimum necessary objectives that our app should be able to perform?

This helps plan out features extensively beforehand and assists in researching solutions to problems that we may encounter. It also provides a checklist of goals to mark off during development.

To implement this practically, we start off with broad objectives and then work our way backwards until we end up with highly specific, actionable goals.

Essentially, the app's objective is this:

Play game(s) of tic-tac-toe

But this doesn't help much when you're building it from scratch, and so we need to think more specifically. I would preferably want my app to have three stages:

Define game settings
Play a game or multiple games of tic-tac-toe
Keep track of scores

Now that the app has been broken down into three separate stages, we can identify the major objectives in each stage. Let's start by breaking down the first stage

Define game settings

What settings must the game require?

Game mode (PvP or PvC?)
Grid size (3 - 5)
Player name(s)

These are the three things I deem essential to have before the game can start. I am limiting the grid size to a maximum of 5x5 to avoid the cells from becoming too small on certain screens.

Play a game or multiple games of tic-tac-toe

What are the specific steps in each game?

Display empty grid
Allow the player to make a move
Switch players
For PvC: Deduce the optimal move for the computer
Identify a game result (win/draw)
If there is a result, display it
If there is a result, repeat from 1.
Otherwise, repeat from 2.

The game has now been outlined and each step is highly specific, which allows us to move towards the next and final objective.

Keep track of score

Initialize scores for both players to 0
If there is a win, increment the score of the winning player
If the settings are changed, repeat from 1.

Although this objective was not as in-depth or complex as the previous one, it is still a basic feature of our app and therefore equally important.

Final list of objectives

Let's see the complete list altogether

Define game settings
1. Game mode (PvP or PvC?)
2. Grid size (3 - 5)
3. Player name(s)
Play a game or multiple games of tic-tac-toe
1. Display empty grid
2. Allow the player to make a move
3. Switch players
4. For PvC: Deduce the optimal move for the computer
5. Identify a game result (win/draw)
6. If there is a result, display it
7. If there is a result, repeat from 1.
8. Otherwise, repeat from 2.
Keep track of score
1. Initialize scores for both players to 0
2. If there is a win, increment the score of the winning player
3. If the settings are changed, repeat from 1.

We now have a set of specific, actionable steps that can be implemented separately. Great!

Tackling logic problems beforehand

With the game broken down into individual pieces, let's talk about two important problems that I foresee to be especially complicated and my approach to solving them.

Deducing the game's result

Key question: How do you identify when a player has won the game?

There have been many approaches to this, and most people initially think of using loops coupled with conditional statements to check for matches. This results in code which looks something like this:

for row <- 1 to 3
    for col <- 1 to 2
        if grid[row][col] != grid[row][col + 1] then
            next row
    next col
    return true
next row
return false

Here, we are essentially looping through each row and then checking whether adjacent cells in each row contain the same value. If not, we skip to the next row. Once all cells in a particular row have been checked and there were no skips, this implies that there is a match in said row.

I do not like this approach as it involves a lot of looping and nesting, and even after the previous code, we still have to check for column matches and diagonal matches, leading to more lines, more bugs, and ultimately more headaches.

Instead, I prefer the use of counters, which will store the number of X's and O's in each row, column, and diagonal, and are updated after every move. This is illustrated below:

Each pair of values in this diagram is keeping a count of X's and O's in it's row/column/diagonal. As an example, there is 1 X and 1 O in the main diagonal, therefore the main diagonal counter stores the values (1, 1).

Main diagonal??? Which one is that?
All rectangular grids and matrices have two diagonals, joining the opposite corners of the rectangle. The diagonal from the top-left corner to the bottom-right corner is called the main, principal, major, or leading diagonal. Similarly, the diagonal from the top-right corner to the bottom-left corner is called the anti, counter, minor, or trailing diagonal. Look at the illustration below for a better understanding:

After every valid move, these counters need to be updated.

The row and column counters will always be updated based on the row and column of the chosen grid cell.
The main diagonal counter will be updated when the chosen grid cell lies on the main diagonal. This can be tested using the condition, row === column.
The anti diagonal counter is similarly updated by testing the condition, row + column === size - 1, assuming that row and column are zero-indexed, and size stores the number of cells in any row/column.

In a tic-tac-toe grid of arbitrary size, a win is possible after exactly (size × 2) - 1 moves. This is because on the very next move, the starting player will have made enough moves to make a match. Let's denote this value by minMoves.

Following every move after minMoves, we will check the current state of all counters and check if any one contains a value equal to size. This would mean that a match has been made!

After size × size moves, we will do this check for the last time, and if there is still no win, a draw is declared and the game ends.

This approach has a time complexity of O(n), because the only looping required will be to go through the row/column counters to detect a match.

Compare this to the previous approach, which had a time complexity of O(n²) since it would loop through each row and each column to detect a match. We have ourselves a winner! 🥳

Deducing the optimal move for the computer

Key question: How can you identify which move promises the most favourable outcome on a given grid state?

This will be implemented through an application of the Minimax algorithm, which attempts to traverse all possible moves for the computer as well as the human player repeatedly until it reaches a terminal state, i.e. a win, draw, or loss. It then backtracks all moves and chooses the one which results in the most favourable outcome with the least number of moves.

Let's assume that it is X's turn and the current grid state is as follows:

X can make either of the following 3 moves:

We can see that move #3 is resulting in a win for X, and therefore we assign a value of +1 to that move. For the other two moves however, we have not reached a terminal state, therefore we shall keep traversing possible moves, but this time for O.

We can see that moves #1.1 and #2.2 are resulting in a loss for X, therefore we assign a value of -1 to those moves.

Since it is obvious that the the other two moves (#1.2 and #2.1) are a win for X, we assign a value of +1 to those moves. There is no need to illustrate further moves.

We now have the following tree of possible moves with their respective score values:

X will now make the most optimal move from the options it has using each possible move's score value. We still however haven't assigned a score value to moves #1 and #2. This can be tackled by assessing the very next set of moves and choosing the score value of the optimal move (here -1).

This brings up an important idea, that an optimal move for X is one with a higher score value, while the optimal move for O is one with a lower score value. X is therefore the maximizing player and O is the minimizing player. Hence the name, minimax.

The possible moves for X on the next turn, along with their respective score values are now as follows:

X thus chooses it's optimal move, and since it is a maximizing player, it chooses the move with the highest score, leading to a win for X.

There are further edge cases to this algorithm such as resolving ties using the number of moves until we reach a terminal state, but what we want right now is a general understanding and a good grasp of how the algorithm works. Implementation details can come later.

💭 Please comment on the job I did at explaining these algorithms. Are they understandable?

We now have a set of objectives for the game, as well as the knowledge essential to building tic-tac-toe in theory. What comes next?

⚡ Stay tuned for the next post in this series, where we will use these objectives to wireframe and design the look of our game.

❤ Remember to like this post and leave your thoughts in the comments!

Cover photo by Matthew Davis on Unsplash
Learn more about the Minimax algorithm

Weather app built with Svelte on Vite

Syed Ali Mansoor — Tue, 10 May 2022 15:30:12 +0000

Welcome! This web app is designed to display weather data (current and forecast) based on the user's location.

Links

Live site
Github repo

Features

Display current and forecast weather data for the given location
Retrieve the user's location automatically
Search for a different location by city name
Switch the temperature unit between Celsius and Fahrenheit
Toggle forecast weather data between hourly or daily forecasts
Responsive layout
Loading skeleton

Screenshots

Searchbox

Loading state

Tech stack

Svelte, bundled with Vite
Typescript
Sass for styling
Axios to make requests
Notion + Whimsical for planning

Please do check the app out and leave your reviews below!

Forem: Syed Ali Mansoor

Component Breakdown & State Management ⚙ - Building a tic-tac-toe game with React from scratch

1. Start

2. Settings

3. Game

Defining data

Wireframing & Design 🎨 - Building a tic-tac-toe game with React from scratch

Step 1: Wireframing

Step 2: Designing

Splash screen

Settings screen

Game screen

Game result

Ideation 💡 - Building a tic-tac-toe game with React from scratch

Defining the app's functionality

Define game settings

Play a game or multiple games of tic-tac-toe

Keep track of score

Final list of objectives

Tackling logic problems beforehand

Deducing the game's result

Deducing the optimal move for the computer

Weather app built with Svelte on Vite

Links

Features

Screenshots

Tech stack

Acknowledgements