デッキ評価画面レイアウト

糸冬さんからデッキ評価画面の画面レイアウトが上がってきたのでUnityに実装しました。
クリア時のデッキが豪華であればあるほど評定が上がる仕組みです。
レアカードを手に入れるため、死地に赴くのだ……！
（基本的に危険の大きい探索ほどリターンも大きくなります）

リファクタリングと行動前・行動後イベント

先週はリファクタリング（プログラムの構造改善）と発注資料作成をやっていました。
発注資料のためにスクショを取ろうとする→バグに気付いてしまう→小手先で直すより一度該当箇所をリファクタリングして直しやすくする覚悟を固める
の流れ。
副産物として、行動選択前イベントや行動選択後イベントを実装しました。

それにしても、まだまだランダムイベントや連続イベント、探索イベントなんかの量が全然足りないので書きまくらないと……。（ちょこちょこ出るバグの修正とかゲームバランス調整もあるし、システム自体は完成してても先はまだまだ長い）

NintendoSwitchでも出したいよね（PlayerPrefsや入出力の分離設計）

今日はプログラミングの話。PlayerPrefsの分離について。

今回のゲームは最終的にニンテンドースイッチでも出したいと思っているので、データリポジトリを噛ませることで簡単にPlayerPrefsを取り除けるように設計しています（リポジトリパターンと呼ばれるヤツね）。ニンテンドースイッチ用ソフトはスマホアプリ同様にunityで開発できるので元々Unityで開発していれば比較的移植しやすいのですが、他プラットフォームと違ってplayerprefsが使えなかったり入出力回りが特殊だったりします。
（加えて、個人で任天堂のデベロッパー申請を受かるのは結構大変なので、申請がリジェクトされたらツテを頼らないといけないという問題がある）

さて、こういうデータ周りや入出力の設計を始めとするマルチプラットフォーム対応はアーキテクチャ（設計理論）の活躍しどころです。
整頓して粒度を細かく作っておくと、環境依存の因子を分離しやすくなります。
初心者～初級者のプログラマは動くことを優先して整頓を疎かにするので、移植や変更が入った時に地獄を見るのですよね。（昔の自分を振り返りながら）
特に対応プラットフォームを広げる野望がある場合はアーキテクチャを意識することを心がけましょう。最初は概念的にも簡単なMVCから自分のものにしていくとGOOD。
（まぁアーキテクチャは常に意識しといた方がいいんだけど、特にね）

移植を意識して開発する時は、データアクセスを直接行わずにリポジトリクラスを噛ませること、また入出力も専用クラスを用意しておくと移植時の修正箇所を限定することができて後々楽なので覚えておくと便利かも。

曲とBGMの発注が決まりそう

今日はテーマ曲＋ＢＧＭ用の発注資料作りとシナリオ作成。
youtubeで曲を聞いて気になっていた方に作曲依頼を打診してみたら受け付けてもらえたので、動いてみるものだなぁと。元々依頼受付を表明されてない方だったので駄目元だったのですが、快くご対応いただきました。
この辺りの飛び込みをやる度胸は、長年事業を続けている親戚の行動力を見習おうと意識している部分です。私自身は「迷惑だったらどうしよう」と二の足を踏んでしまうタイプなのですが、実際に１から何かを立ち上げている人たちと比べて自分が弱気すぎるのを感じるので、改善しなければいけないという思いが強くあります。
自分から出せる対価を全力で出せば相手にとっても良い話になるはずと信じて、最後は自分を洗脳するくらいの気分で……！（本当は、「迷惑だったらどうしよう」と不安になる心の方が幼少期から植え付けられた洗脳なのかもしれない）

狂気カードシステムの修正

狂気カードの調整完了。これで千日手問題は解決です。
さて、次はシナリオイベントを作りこんでいこうか……。