Djangoでブラックジャックを目指す　24　勝敗判定の不具合修正1

今回やること
退出処理の時の不具合とその解決方法の洗い出し

前回まででやったこと

Djangoのプロジェクトを作る
start appでacounts ,game の2つのappのひな型を作成
accounts （app）にログイン用のCustomUserのモデルを作成
settings.pyを編集ログインユーザーを作成したCustomUserに変更
game に（app）にモデルをセットする
game （app）にforms.py(という空のファイル)を作成
formをセットする
allatuthを使ってログイン周りのアカウント部分を作成
ゲーム画面までのルーティング
表示用のベーステンプレートの複製
テンプレートとViewを連携させる
エントランスページ最低限の機能を考える
部屋作成機能　の実装
entrance →　gameroom へのルーティング
カードの一覧作成処理
カードの一覧のIDを取得
カードリストをシャッフル→DB格納
初期デッキ生成処理の組み込み
ゲームボタンの生成
ゲーム準備完了ボタンの処理
全員参加意思が行われた時のターン進行処理
エントランス表示処理の変更
元の部屋に帰るメゾット追加
元の部屋の戻る処理の確認
２ターン目の流れの確認
カードをドローする処理の動作確認
フェイズを進行させる
手札の表示
点数処理
役の確認チェック
プレイヤーの行動処理
ルームに内のプレイヤー全員の手札を表示
全プレイヤーに得点情報の追加
勝利者判定
前回勝利者判定時の確認に使用したviewを説明
ゲームを終了し部屋を閉じる処理

現状の問題点

終了処理でプレイヤーが抜けたとき
残ったプレイヤーで勝敗判定がされてしまう

解決アイディア

・履歴用のＤＢを作ってそこに格納してしまい決着時点で履歴を読み込む
・ターン進行と同じように退出を押したフラグを付けて全員押し終わったら削除する
・部屋を削除せずフラグのみの論理削除にして勝敗判定は削除フラグを無視して判定する

アイディアのメリット・デメリット

履歴用のＤＢを作ってそこに格納してしまい決着時点で履歴を読み込む
メリット
４ターン目以外はコードの変更が不要
後からでも参照が可能
省略した情報のみ記録できるためそのまま残すよりはＤＢ容量が削減できる

デメリット
新しくＤＢを作る必要がある
ほかの方法よりＤＢに対するアクセスが多くなる
登録用の情報を新しく全別する必要がある

ターン進行と同じように退出を押したフラグを付けて全員押し終わったら削除する

メリット
実装が一番楽変更も少なくて済む

デメリット
部屋に新しく入るときにも元の部屋情報を削除処理しているので
そちらの対処がひつようになる

部屋を削除せずフラグのみの論理削除にして勝敗判定は削除フラグを無視して判定する

メリット
３ターン目以降の処理だけで実装可能
部屋そのものを削除する必要がなくなる

デメリット
ＤＢにカラムを追加する必要がある
すべての情報が残ったままなのでＤＢが肥大化するのが早い
まだ現行ゲームでも同じＤＢを使用するため肥大化時のパフォーマンスに影響が出る可能性が高い

今回は案１の履歴用のＤＢを作成する方針に決める

履歴用のModelを作る

<appFolder>/models.py

class GameHistroies(models.Model):
   room_id =IntegerField();
   user_name=ForeignKey(CustomUser,on_delete=CASCADE);
   hands=CharField(max_length=255);
   point=CharField(max_length=255);
   win=CharField(max_length=255);
   

基本的にはroomIDによって情報を取得してすべてＤＢに入れてしまう
本来であれば計算させたりしたほうが楽かもしれないが
基本的にここを参照するときは終了時のみのためそこまで負担にならないはず

次回予定

今回決めた方針と作成したmodelを利用して勝敗履歴の登録機能の実装