React公式チュートリアルの次に最適！マインスイーパーをつくる【設計編】

Reactの公式チュートリアルを読み終わったけど、個別に説明されているトピックの定着に不安がある、具体的にどんな感じでHooksを使うのかしっくりこない。

そんな人に最適な実践形式のチュートリアルとして、Reactで出来るマインスイーパーのつくりかたを紹介します。

デモページ / Github

チュートリアルは、設計編（本記事）と実装編（後日投稿）に分けています。自信のある人は、設計編とGithubのコードを照らし合わせながら自力で実装できると、より良いですね。

記事の内容を理解することで、バニラReactのSPAでできることの大半を網羅できるかと思います。

ゲームのコアになる部分と実装の方針を考えよう

スクラッチから作る際には、最初に主要なロジックは何であり、どのように実装するべきか方針を立てましょう。

これを明確にしておかないと、どこから手をつけていいか分からなくなってしまいます（筆者が最初そうでした）。

必須のstateとコンポーネント

まず、マインスイーパーのルールのコアな部分を確認し、実装の方針を立てられるように適宜言い換えていきましょう。

そうすると、ゲームを作る上で必須のstateとして、

の2つを設計する必要がありそうです。

ユーザーがマスを開けた時、そのマスが爆弾マスかどうか判定する必要がありますが、例えば、

と分けておけば、マスの種類もvalueに含む形で表せますね。

以上から、ゲームの最も重要なロジックは、

とすれば良さそうです。

また、ユーザーがマスを開ける度に、（ゲームオーバーにならない限り）ゲームのクリア判定が必要です。判定には開いたマスの個数が必要なので、

ということも分かります。したがって、必須のコンポーネントについても、以下のように考察できますね。

以上で、ゲームの最も重要なロジックについて実装の方針が立ちました。

シバセンセー

なんとなく、マインスイーパーの実装が出来そうになってきたね。

難しそうなところ　つながっている０のマス

これまでの説明で、

というマインスイーパー独特の挙動をどうするのかと思った方は鋭いですね。開いた範囲がパッと広がる、あの気持ちいいやつですね。

一見難しそうですが、このとき1個1個のマスがどう開いていくかに着目して考えると、

といえます。

本題のReactではなくアルゴリズムの話になってしまうのですが、これは初歩的な 深さ優先探索（DFS）で実装可能です。

ダテネコ

自力で考えるんじゃなくて、DFSを理解して使う方が近道になるんだぜ。

<Board />コンポーネントの実装の一部を掲載します。コード中のコメントを参考にしてください。

// 先に、移動方向をベクトルのような形で用意しておく
const dx = [1, 0, -1, 0, 1, 1, -1, -1];
const dy = [0, 1, 0, -1, 1, -1, -1, 1];

const Board = () => {
// ...
  function dfs(Graph, seen, h, w, x, y){
    seen[x][y] = true;
    
　// 今見ているマスの値が0ではないなら、これ以上周囲を探索しない
    if (Graph[x][y] !== 0 { return; }
    
　// 今見ているマスの周囲8方向を探索
    for ( let direction = 0; direction < 8; ++direction){
      const nx = x + dx[direction];
      const ny = y + dy[direction];
      
      if (nx < 0 || nx >= h || ny < 0 || ny >= w){
        continue;
      }
      if (seen[nx][ny]){ continue; }

      // 次に進むマスをセットして、再度関数を呼び出す（再帰）
      dfs(Graph, seen, h, w, nx, ny);
    }
    return seen;
  }
// ...
}

マインスイーパーの動作では、０のマスだけでなく、0のマスの塊を囲むようなvalue= 1 〜 8のマスを1重だけ開ける必要があります。そのため、seen[x][y] = trueの後にGraph[x][y]の値を判定する順になっていることを押さえてください。

DFSの背景や応用までを丁寧に理解したい方は、以下の記事が大変分かりやすいです。

関数dfs()が返すseen配列は、0のマスの”島”を囲むような範囲について値がtrueになっています。

0のマスを開ける前のisRevealedとseenの論理和をとり、その結果でstateを更新しようという目論見で実装しています。

ここまでで、ゲームのコアとなるロジックについて、問題なく実装できそうだと確認できました。

次章で、他に必要そうなstateとコンポーネントを考えていきましょう。

完成イメージから、他に必要そうなstate, コンポーネントを考えよう

コアのロジックについて方針が立ったので、完成イメージを考えて、必要そうなコンポーネントとstateを挙げていきます。

コンポーネントから考えていきます。

コンポーネントの列挙

ゲーム本体の完成はこんな感じです。

コンポーネント間の関係は以下のようになりますね。

コマリブル

コンポーネントが多くて困った、実装できるかな

シバセンセー

主要な部分は<Board /> とその周りのロジックだから、コンポーネントの多さにびっくりしなくても大丈夫だよ。

<GamingHeader /> は、他のミニゲームを作って追加したときに、ページ移動を実装するためのナビゲーション用コンポーネントです。マインスイーパー単体を作る際にはナビゲーション機能を実装しませんので、おまけ程度に思ってください。

stateの列挙

ミニゲームとして全体を協調させて機能させるために、

の状態をstateとして持ち、gameStatusとdifficultyはゲーム全体で共有することにします。

そのため、主要なロジックを持つ<Board /> の親コンポーネントとして<Minesweeper />をつくり、最上位コンポーネントとしてこれらのstateを管理させます。

なぜこのようにするのか、次節に詳細を書きますが、納得できている人は飛ばしてください。

ゲーム全体で共有するべきstateの保持と更新は、useReducer()とuseContext()の組み合わせが使えそうですね（実際にそうしています）。

<Minesweeper />コンポーネントの必要性

実際の状況を考えてみましょう。

例えば、<StatusMessage />は、ゲームクリア、ゲームオーバー等のstateに応じたメッセージを表示するコンポーネントですが、ゲームクリア・ゲームオーバーの判定は<Board />が行うため、<StatusMessage />単体ではgameStatus を取得することができません。

もちろん、<Board />の下位コンポーネントに<StatusMessage />を押し込めば<Board />から<StatusMessage />へpropsとしてgameStatusを伝達できますが、

ことを考えると、<Board />と<StatusMessage /> は同じ階層に設置する方が簡潔な実装になりそうです。

以上から、

としておくのがベターです。

実際に、今回の実装では<StatusMessage />の他に、<ControlButton />もgameStatusを利用するので、共通の親コンポーネントに持っておく方が良いのです。

経過時間をstateで表す

次に、ゲームの経過時間（マインスイーパーのスコア）ですが、これは実装上の都合から、現在時刻を表すnow と、ゲームをスタートした瞬間の時刻startTimeの2つのstateを設定して、引き算で求めます（実装は非常に簡単です）。

※ 実装が気になってモヤモヤする人は、公式チュートリアルとほぼ同じなので先にご覧ください。

<Timer /> からstartTimeを取得する方法について考えましょう。

ゲームがスタートするのは、スタート前の状態で<ControlButton />が押されたタイミングです。すると、<Timer />単体では取得できません。

前節と同じ議論で、<Timer />と<ControlButton />の共通の親コンポーネント<Minesweeper />で経過時間を計算し、ボタンが押された瞬間の経過時間で<Timer />を更新すればよいですね。

以上で、ゲームに必要なコンポーネント・stateの列挙が（ほぼ）終わりました。

実際のコード（Github）には上記で紹介していないコンポーネント・stateが2,3個あるのですが、純粋に実装上のテクニックとして変更・追加したものになります。

開発環境の構築

0からのモダンフロントエンド環境の構築方法については、本記事では書ききれませんので別記事に譲ります。

ここでは、マインスイーパー制作時の（筆者の）開発環境についての要点として、

について記載・補足します。

※ 筆者の開発環境では、上記を🐳 Dockerコンテナ内で動作させて開発を行なっています。

package.json

・sass-loader : SASS（公式）をCSSに変換するためのローダー

・babel : Modern JS → ES5の変換を行うローダー

をwebpack経由で起動することで、npm run webpackorwebpack-dev-serverのコマンド1発でビルドできることを主眼に置いた環境です。

{
  "name": "webpack5-react-babel",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "scripts": {
  "build": "webpack",
  "dev-server": "webpack-dev-server",
  },
  "dependencies": {
    "@babel/cli": "^7.13.16",
    "@babel/core": "^7.14.2",
    "@babel/preset-env": "^7.14.2",
    "@babel/preset-react": "^7.13.13",
    "@emoji-mart/data": "^1.2.1",
    "@emoji-mart/react": "^1.1.1",
    "@fortawesome/fontawesome-svg-core": "^6.5.2",
    "@fortawesome/free-brands-svg-icons": "^6.5.2",
    "@fortawesome/free-regular-svg-icons": "^6.5.2",
    "@fortawesome/free-solid-svg-icons": "^6.5.2",
    "@fortawesome/react-fontawesome": "^0.2.2",
    "babel-loader": "^9.1.3",
    "css-loader": "^7.1.1",
    "emoji-mart": "^5.6.0",
    "react": "^18.3.1",
    "react-dom": "^18.3.1",
    "react-router-dom": "^6.23.1",
    "sass": "^1.77.1",
    "sass-loader": "^14.2.1",
    "style-loader": "^4.0.0",
    "webpack": "^5.38.1",
    "webpack-cli": "^5.1.4",
    "webpack-dev-server": "^5.0.4"
  }
}

webpack5 + babel＋scssはややレガシー環境と感じられる方も多いかと思いますが、2024年現在動作できております。マインスイーパーのビルドに関してbabelの遅さが問題になることはありませんので、カスタマイズできない方はこのままご使用いただいて大丈夫です。

Vite（＋SWC）等をお使いの方は、ご自身の環境に合わせて読み替えをお願い致します。

webpack.config.js

const path = require('path');

module.exports = {
  entry: './src/app.js',
  output: {
    path: path.join(__dirname, 'build'),
    filename: 'bundle.js'
  },
  mode: 'development',
  module: {
  rules: [{
    loader: 'babel-loader',
    test: /.js$/,
    exclude: /node_modules/
  },{
    test: /.scss$/,
    use: [
    'style-loader',
    'css-loader',
    'sass-loader'
  ]
  }]
},
  devServer: {
    static: {
    directory: path.join(__dirname, 'build'),
  },
    host: '0.0.0.0',
    port: 8080
  },
  devtool: "source-map"
}

devServerのhost, port設定ですが、筆者がDocker環境で開発を行なったため必要になった設定です。Docker環境はそれ自体は「閉じて」おり、外部アクセスを受け付けませんので、ローカルPCからビルド結果を確認するためにはポートの設定が必要です。

まとめ

設計編で、以下のことを確認できましたね。

設計編で、実装に必要なコアな情報は全て説明されています。

自信のある人は、Githubのソースコードと照らし合わせてここから手を動かしてみましょう。

以上でマインスイーパーの設計は終了です。お疲れ様でした。