2024 ソフトウェア設計及び演習用の班Wiki

活動内容

• 班決め及び作成するソフトウェアの内容の検討を行った。
• 作成するソフトウェアの内容としてポーカーが挙げられた。
• 計画的に、可能な範囲で作成していきたい。

メモ

• ポーカーについてのアイデア(ポーカーにするとは決まっていない)
  • カードの絵柄の工夫
  • 対人戦 or bot(個人的には後者)
  • アイテムの導入(マーク・番号を変える、自分・相手のカードを引き直す/させる/交換などの効果)
    • それに伴う影響は十分把握しないとバグの温床に(山札を使い切ってしまう、マーク・番号を変えたカードの扱いなど)
  • 報酬について
    • 勝利して持ち点が上がっていくだけでは面白くない(いずれ点数の価値が希薄になる)　→　点数に応じて報酬を与える
      • プレイヤーのアイコン
      • カードの絵柄
      • テーブルの柄
      • など
  • nゲーム制(n回を行って最終ゲーム終了時点での持ち点で成績をつける)
    • 終わりがないとゲームが進むにつれてプレイヤーに限界が来る　→　必ず終わらせる
    • 途中で持ち点が 0 になったら強制終了にする or 最後までやる
  • botについて
    • botの強さ(性格)　→　与えられる情報をどこまで活用するか(自分の手札、相手の手札(ルールに依存)、相手の賭け点、自分・相手の持ち点など)
      • 自分・相手の手札　　→　山札(あるなら捨て札も)にどのカードが残っているかを推測し、カードを交換するか決める
      • 相手の賭け点　　　　→　考慮させることでブラフの意味をもたせる
      • 自分・相手の持ち点　→　レイズするか(ブラフ含む)の判断、相手の持ち点から、相手がレイズしたときにブラフかどうか判断できるかも(仮説による)
      • などいろいろ
  • 敗北時のリスクを高めにする　
    • 緊張感をもたせる
      • 敗北の演出などで
  • ポーカー中の演出
    • 飽きさせないように(スイカゲーム, ブレスオブザワイルドのbgmのような中毒性、ランダム性(bgmを入れろというわけではない))

• ポーカーの実装について思いつきで
  • 主にホーム画面、プレイ画面、(チュートリアル(説明)
  • カードの要素は、番号(13個)　と　スート(4個)の２つ
  • 役は９種類(URL https://www.nintendo.com/jp/others/playing_cards/howtoplay/poker/index.html )で、優先順位は　役 > 番号 > スート
    • 判断方法
      • 役、番号、スートを数値化し、その合計で判断(優先順位が逆にならないように)
        数値表現は10bit二進数で、上位4bitは役(9種類)、次の4bitは番号(1~13)、下位2bitはスート(4種類)で表せば干渉しない
    • 評価方法
      1. ソートする
      2. 右隣のカードの番号と比較し、差をとる
         0ならば、同じ番号であるとしてカウントし、注目しているカードの番号を記憶(最大2つ) 1ならば、連番としてカウントし、カウントが４で役成立(ロイヤルストレートフラッシュは別処理)

• JavaScriptの勉強をしよう!(戒め)
• ポーカーのルールは任天堂のホームページで確認しよう!(他でも可)

活動内容

• 作成するソフトウェアの内容はポーカーに決まった。
• ポーカーについて、ゲームの流れやシステムの内容をだいたい決めることができた(詳細は企画書)。
• ゲームの流れやシステム、ユーザインタフェースといったゲームの基幹部分について、詳細な仕様を考えていきたい。
  また、特殊なルールといった拡張機能の案及び仕様についても考えていきたい。

メモ

• 第１回目のメモで考えていたポーカーのルールとは異なるので注意
• 単調な内容にならないように注意する(計画的に進め、拡張機能をつけられるように)

活動内容

• 作成するソフトウェアについて、大体のユーザインタフェースを決めた。
• 作成するソフトウェアについて、モノと操作の洗い出しを行った。

メモ

• 班wikiで画像を載せる際にサイズが大きすぎた場合の解決手段の１
  1. 画像をGIMPで開く(画像が手持ちにない場合(特殊)は Edit >> Attachment >> 指定画像のdownload から画像をダウンロードする。開くと、右上に横三本線のボタンがあるので クリック>>別のアプリケーションで開く で、GIMP選択)
  2. GIMP画面で 左クリック>>画像>>画像の拡大・縮小 でキャンパスサイズを変更(下画像のサイズは500×667)
  3. 画像保存時は、ファイル>>名前をつけてエクスポート でファイルの拡張子を変更(下画像はjpeg)し、保存(保存場所の指定を忘れずに)
     画面上部の名前の部分で拡張子を変えるか、画面下部のファイル形式の選択で拡張子を選択
  4. 画像を載せる
     
     
• GIMPの拡張子.xcfのままで保存すると、掲載時にリンクのような形になってしまう(下記のIMG_9204.xcfがそれ)

IMG_9204.xcf ← コレ

• モノと操作について
  • モノ:山札
    • 山札のカードをランダムに配置する操作
    • カードを配る際の、配る順番について
  • モノ:手札
    • 手札のカードを番号順に並べ替える操作
    • 手札のカードの番号を把握する操作(手札の役を決める操作)
      番号順に並べ替える操作と切り離したほうがいいと思う(何となく)
  • モノ:ディーラー
    • 手札をもとに、交換する手札を決める操作
      交換のアルゴリズムは未定(役によって場合分けをするのが無難(大変だけど))
  • モノ:残りチップの表示
    • 残りチップを出力する操作
    • 賭けるチップ数に応じて残りチップを増減させる操作
  • モノ:ラウンドの表示
    • 現在ラウンド/全ラウンドを出力する操作
    • ラウンド終了時(次ラウンド開始時)に,現在ラウンドをインクリメントする操作
  • モノ:プラスボタン
    • 賭けるチップを増やす操作
  • モノ:マイナスボタン
    • 賭けるチップを減らす操作
• モノのデザイン
  • カード
  • チップ(あったほうが良い)
  • テーブル
  • 各画面とボタン

活動内容

• ものと操作の洗い出しとモジュール分けについて行った。また、山札のカードのランダム配置の方法や役の判定方法などについて話し合いを行った。

メモ

• カードについて、スートを含めるかを次回までに決める
• ディーラーのカード交換について
  • 4カード：交換しない
  • 3カード:ペアじゃない２枚のカードを交換
  • 2ペア:ペアを持たない１枚のカードを交換
  • 1ペア:ペアを持たない３枚のカードを交換
  • ストレート:交換しない
  • フルハウス:交換しない
  • ノーカード:数字が最大のカード以外を交換

活動内容

• モジュール分けについて行なったが、終わらなかったので次週までにまとめ、プロトタイプの作成に取り組んでいきたい。

メモ

• モジュール分け
  • 画面制御
    • 各画面での戻り値をもとに画面を制御
      • タイトル画面、ゲーム画面、リザルト画面、メニュー画面、ルール画面
    • タイトル画面では、ハイスコアを記憶したデータを渡す
  • タイトル画面
    • スタートボタン、ハイスコアボタン、ルールボタン
      • スタートボタン：ゲーム画面へ遷移する値を返す
      • ハイスコアボタン:渡されたデータを出力
      • ルールボタン:ルール画面へ遷移する値を返す
  • ゲーム画面
    • 一定のターン数に達したらリザルトに遷移する値を返す（ゲームオーバーは？）
    • プレイヤー、ディーラー(bot)、カード、チップ、メニューボタン
      • カード(数値処理):
        1. 山札のカードを生成する関数
        2. 生成されたカードから1~13の数字を取り出す関数
        3. プレイヤーまたはディーラーにカードを渡す関数
        4. カードを降順にソートする関数
        5. カードを入れ替える関数(swap)
        6. 山札からカードを一枚引く関数
        7. カードを追加する関数
        8. カードを削除する関数
      • カード(画像処理):
        1. 山札からプレイヤーまたはディーラーへカードを渡す関数
        2. 手札をゴミ箱(正式名称忘れた)に移動する関数
        3. カードを表にする関数
        4. カードを入れ替える関数(これは任意)
      • プレイヤー:
        1. カードを交換する関数
      • ディーラー:
        1. 役に応じて交換するカードを選択する関数
      • チップ:
        1. 賭けチップを増加させる関数
        2. 賭けチップを減らす関数
        3. 役の倍率から報酬チップを計算する関数
      • 役:
        1. 役の判定を行う関数
        2. 役の強弱を判定する関数　　　
      • メニューボタン:メニュー画面に遷移・・・?!
  • リザルト画面
    • リスタートボタン、終了ボタン
    • ゲーム画面でのチップ数とか勝利数とか渡す
      • リスタートボタン:ゲーム画面に遷移
      • 終了ボタン:タイトル画面に遷移
  • メニュー画面に遷移
    • ルールを出力
    • タイトルボタン:タイトル画面へ遷移
    • 終了ボタン:ゲーム画面へ・・・?!
    • 警告:メニュー⇄ゲームの遷移で途中のゲームの情報が失われる
      提案:ゲーム内の情報(データ)をすべて渡すのは困難(復元作業)
      メニュー画面は画面制御で扱わず、ゲーム画面内で制御

活動内容

• モジュール分けが完了した。
• 画面と内部のインタフェースについて、渡す引数など具体的に定まっていないため早急に決めたい。
• ゲーム内部の処理の担当に決まった。データの処理についてはある程度煮詰まったが、画像の処理については不確定の部分が残ったため、可能な範囲かどうか十分見極められるようにしたい。

メモ

• 画像処理について、enchant.jsの導入を検討中...
• 画面と内部のインタフェース
  • タイトル画面　→　プレイ画面
  • プレイ画面　→　リザルト画面
    • 渡す引数
      • 総チップ数
      • 勝利数

活動内容

• プロトタイピングを行った。enchant.jsについて必要な画像処理を行えるように学習を進めていきたい。

活動内容

• カードモジュールとジャッジモジュールについてある程度作り終えたので、デバッグなどを行い修正部分は修正していきたい(修正済み)。

メモ

• ディーラーの動作については未実装

活動内容

• 中間発表を行った。
• カードモジュールとジャッジモジュールについて、デバッグが完了した。
• 画面表示の作業が少し難航しているため、解決策の模索を進めていきたい。

• 活動内容
• ディーラーのカード交換のアルゴリズムについて、基礎的な動きは完成できた。ディーラーの強さに応じた動作について考えていきたい。
• 各モジュールの統合について、宣言が必要な変数や各関数の配置について考えた。

メモ

• ディーラーの動き
  • 4カード：交換しない
  • 3カード：２枚交換
  • 2ペア：１枚か３枚
  • 1ペア：３枚
  • フルハウス：交換しないか２枚（リスク大）
  • ストレート:交換しない（交換時のリスクは極めて高い）
  • ノーペア：ランダム枚数交換または、一番大きい数字を残して４枚、または５枚

• 考慮する情報
  • プレイヤーの手札交換枚数（１回目のときの情報だけ）　→　あまり意味ないかも
    • プレイヤーは揃った役を崩さないかつ意味不明な行動をしないと仮定した時の交換直前のプレイヤーの手札の推測
    • ０枚：４カード、フルハウス、ストレート
    • １枚：２ペア、ノーペア
    • ２枚：３カード
    • ３枚：１ペア（フルハウス狙いでないなら２ペアも（ただ役は崩れる））
    • ４枚：ノーペア
    • ５枚：ノーペア
  • 捨てたディーラーのカード
  • 捨てたプレイヤーのカード　→　チート
  • 山札　→　チート
  • プレイヤーの手札　→　チート
  • 使える健全な情報はあまりないかも（simpleの弊害）

活動内容

• カードモジュールについて、役に応じてソートする関数の、ペアが揃っていないカードを降順に並べ替えるよう変更した。
• モジュールの統合を進めた。

活動内容

• 引き続きモジュールの統合を進めた。ゲーム全体の流れはほぼ完成したと言えるので、細かい部分を詰めていきたい。
• プレイヤーのカードを最後に並べ替えるときに使う関数を作成した。
• 役が揃ったときのカードのハイライトをどうすべきか考えていきたい。

メモ

• カードのハイライト：enchant.jsのプラグインであるgl.enchant.js（３次元みたいだけど）

活動内容

• カードのハイライトの実装を行った。当初はC++によってアニメーションに用いる画像を用意したが、最終的には１枚の画像の透明度を変更させる処理を行うこととなった。
• 掛けられるチップについて、バグが見つかったので修正を行った。

メモ

• ハイライトに必要な画像の準備に時間はかからなかったが、アニメーションの実装には時間がかかった。結果使わなかった。

活動内容

• 最終発表を行った。

メモ

• 獲得チップ総数が100,000を超えるとスコア表示に不具合が生じたため、スコアのフォントサイズを変更した

担当

• カードモジュール
  • Makedeck
    　山札を生成する関数。1〜13までの数字を１セットとし、それの４セット分の数字がランダムに格納された配列を作成する
  • Makehand
    山札から手札を入手する関数。今回は五枚入手する
  • Sort_descending_order
    　渡された配列の中身を降順にソートする関数。この関数は役判定などを行う際の前処理として用いられた
  • Hand_sort
    　役に応じて手札を並べ替える関数。揃った役は左詰め
  • Hand_add
    　山札からカードを一枚手札に追加する関数。この関数では追加したカードの番号を返す。そのため、先にこの処理を行ったあとにカードの移動が行われる
  • Hand_delete
    　交換時に選んだカード１枚を手札から消去する関数。この関数は未使用

• ジャッジモジュール
  • Handcheck
    　手札から役を判定する関数。この関数では手札の配列と、独自に作成した構造体を渡す。構造体の中身は、主に役の種類とその役で最も評価が高い数字が格納されている。処理終了時点で、判定結果が構造体に格納されている
  • Judge
    　プレイヤーとディーラーの手札から、勝敗を決める関数。この関数ではHandcheckで更新された構造体を渡す。戻り値はconst.jsであらかじめ定義された値を返す

• スキン開放の処理
  • skinalert.js
    
    • スキン開放条件が満たされた際に、その旨を通知する
    • 一度に複数のスキン開放条件が満たされることを考慮した設計を行った

• その他
  • card_move(card_move.js)
    
    • 移動先のカードの位置を格納した配列を返す関数
    • 内部でのカードの操作だが、この関数はカードの画面表示の処理のために実装されたので、カード描画モジュールとなっていると推察される
    • しかし、関数一つでひとつのjsファイルを使用しているため、他のjsファイルにまとめたかった（どこにまとめるのが良いのかは不明）
  • モジュールの統合に参加
    • モジュール結合の一連の流れの考案やバグなどの修正を行った

本講義で得られたこと

• チーム開発の面白さ
  
  • １人でプログラムを作成するときとは異なり、開発に詰まった際に意見交換を行うことができるため、作業効率を向上することができるということを実感した
  • 共通の目的を持って開発を進めるのが楽しかった
• 自分で調べる力
  • 開発中にGitlab関連の不具合が多発した（git pushできないなど）。この際に、解決手段を調べることを通して力が身についたと思う
  • この他にも、javascriptやHTML、enchant.jsなど調べる機会は大いにあった
• バックアップをとることの重要性
  • Gitlabの不具合解消の途中でデータを２回飛ばしたため
• デバッグ
  • 自身が担当したカードモジュールやジャッジモジュールはシステムの根幹に関わるので、各関数が正常に動作するように品質を上げる必要があった。今回はブラックボックス法を用い、テスト用のチェックを行う関数の作成を行った。C言語と異なり、javascriptは変数の型などに注意する必要があるため、テストの重要性はより一層感じられた

今後

• Gitlabについて
  • Gitlabの不具合について、完全な対処方法は確立できていないため、体系的な勉強が必要だと感じた。今後も利用していくと考えられるため、取り組んでいきたい
• CSSについて
  • 使っていないことに気づいた（忘れていた）。CSSを使えばプログラムとデザインを分離でき、また、ボタンなども工夫できるようなので扱えるようにしたい
• ポーカー以外にもブラックジャックなどゲームを追加したい（個人的に）

開発で得られたいろいろ

• Gitlab使用の注意（以下の内容は自己責任でお願いします）
  • リモート側で作業しない
    • git cloneしているんだからローカル側でやってください
  • 同じファイルに対して同時に複数人で作業しない
    • 対策なしだと衝突する
  • git statusで常に確認
    • git pushでパスワードを間違えるとコミットがなかったことになっている。常に状況確認。
  • 作業前にgit pull
    • 常に最新の状態を保つ。あと、衝突を防ぐ
  • git commit -a -m　の順番
  • バックアップを取る
    • 不具合解消でデータが飛んでもいいように
  • git reset --soft HEAD^で直前のコミットをなかったことにする
    • git pushできなかったら試す（自己責任で）
    • softをhardにしたらデータが飛んだ気がする
  • git rebaseでブランチを戻す
    • ブランチが進んでいるときに戻せるかも（完全ではないが）
  • 色々罠が仕掛けられているので十分注意する

• javascriptのファイル操作
  • ハイスコアをローカルファイルに保存して、htmlを終了してもデータが保持されるようにしたかった
  • 利用者自身がファイル選択しないとファイルにアクセスができない
    • javascript側で自動でファイル操作ができるとウィルスばらまき放題だとか
  • C言語を組み込もうと思い調べたが、うまくいかなかった（実装できなかった）
  • console.log
    • console.logで出力されるのは最終的な変数の値
    • その時点での変数の値が知りたいなら、console.log(JSON.parse(JSON.stringify(hogehoge)));　//hogehogeは変数

• html
  • パス名に注意

• enchant.js
  • 画像の透明度は.opacityで変える
    • 画像が単色ならば明滅しているように見せることができる
  • アニメーションはスプレッドシートで
    • アニメーションを１つの画像にまとめたもの
    • .assetsで使用するスプレッドシートの位置を変えられる
    • スプレッドシートの作り方は色々（c++で手続き的に作成してみたが結局使わなかった）
  • 遅延はsetTimeoutPlugin not found.;
    • timeにマジックナンバーは使わないほうがいい（使ったけど）。時間の管理が非常に煩雑になるため
    • 遅延に用いる変数を準備して、setTimeoutを使うたびに、setTimeoutの前に遅延させたい時間を変数に加算するとか（試していないが）
    • ただし、時系列ごとに並べるのが前提
  • 文字幅の変更は.width
    • 改行されない最大文字幅
    • .fontで時の文字の大きさを変えられる。改行されるなら文字の大きさを小さくする