ゲーム（仮称）_メニュー(街)_ステータス・ショップ
メニュー
画面の大きさをそろそろ決めよう
一般的なゲームソフトは？
Wiiは4:3と16:9
3DSは上画面800*240 (10:3)
独自規格なんだな〜
16:9にしてみようか？
検証用のApp.vueのバーは換算しない
比率一覧
1600 * 900
1440 * 810
1280 * 720 ←ちょうどいいかも？
今の設計が大体横幅1140pxくらい。
高さが足りないかもしれないが。
4:3の方が合ってるのではないか？
比率一覧(融通がかなりきく)
1600 * 1200
1500 * 1125
1400 * 1050
1300 * 975 ←いいかも
今の画面的に4:3が合っている気がするのでこれで。
絶対さっさと決めとくべきだよこれ
1300 * 975で！
975が思ったより長すぎる
パソコンの標準の比率は16:9なので、やっぱり16:9にしようか。
16:9で進めて、予備情報とか（バトルログ）必要な時は引き伸ばしちゃおう
できた
メニュー画面の右col-10部分は、containerで再び区分けするような形で管理する。
ステータス画面
成長をものすごく自由にする
個性のあるスキルをたくさん作る。
バトルメイジとかのスキルは良さそう。その系統のスキルを各職業に持たせる(役割2種ある感じで)
自由に振り分けられるパラメータ|スキルポイントを作る。
自由パラメータについて考える
APに振り分けられるのは個性がなくなり、まずいかな？
一旦あり前提で考え、不味ければ後で調整すれば良い
1Lvごとに成長性5のパラメータなら、7くらいずつ上がるわけだ
1Lvごとに自由パラメータを4ずつ渡してやるとどうだろう？
HPだけ恩恵を感じにくい気がするので、2ポイント上げてやるか
11lv時点で40Pたまるので、結構大きい気がする
スキルポイントについて
3Lvごとに1Pもらえる
カラム
こんな感じで良さそうである
freely_status_point
freely_skill_point
スキルについて
このスキルを何ポイント以上！とか、レベル幾つ以上！とか条件をつけたい。どう管理すればいいだろう？
skill_requirementsテーブル
acquired_skill_id 取得したいスキルのID
requirement_party_level
requirement_skill_id 必要なスキルのID
requirement_skill_levelとかで管理できそう
descriptionに静的に取得条件を入れておけば管理が楽になるかも。後目視確認も。
【条件】ファイアボール スキルレベル1以上みたいな感じで。
画面
https://scrapbox.io/files/672b5b8345471c1d3b0e6856.jpeg
街のデフォルト画面を用意する
三分割で。
１２３はキャラの名前を出して、その後ステータス/スキルボタンで管理する。
選んだあとはモーダルで調整すれば良い。
とりあえずフロントエンドから作って、マイグレーションファイルという感じで。
いい感じである
https://scrapbox.io/files/672b81d117a23f17eecd2b14.png
これはショップやその他画面でも汎用性のありそうだ。
かう/うる とか。
わかりやすいから入れ子を実現したい。
parent_skill_idカラムを作る
code:html
<ul v-for="parentSkill in allSkills">
<li>{{parentSkill.name}}</li>
<li>{{childSkill.name}}</li>
...
これで行けそう。
必要なカラムのマイグレーションをする
カラム
rpg_parties
freely_status_point
freely_skill_point
rpg_skill_requirements
acquired_skill_id 取得したいスキルのID
requirement_party_level
requirement_skill_id 必要なスキルのID
requirement_skill_levelとかで管理できそう
その他
descriptionに静的に取得条件を入れておけば管理が楽になるかも。
一応作っといても良さそうと思ったがいらないと判断。
? このテーブルがあれば↓のカラムの必要はないかな？
rpg_skills
parent_skill_id ※上のテーブルで事足りる気がするので一旦保留。必要になったら作れば良い。
作る
マイグレーションファイルも一気にまとめちゃうか
$ php artisan make:migration add_columns_to_rpgs_table
タイムスタンプ全部のテーブルに適当につけてたけどいらないかもな〜
まあ規約を統一する意味も込めて、一応つけておく
職業のスキル整理
10個ずつとりあえずなんでもいいから作る
スキル50とかそういう名前で効果とかも適当で良いので。
Seederを埋めまくる！
埋めた。
rpg_skill_requirementsテーブルに情報を入れる
とりあえず検証のために、mage関連の情報だけ入れることにする。以下の通りで。
mage
プチヒール plv1以上
ポップヒール plv10以上, プチヒールlv2以上
プチブラスト plv1以上
クラッシュボルト plv1以上, プチブラlv1以上
マナエクスプロージョン plv10以上, プチブラlv1以上
バトルメイジ plv15以上
スキル46 plv1以上
スキル47 plv2以上 スキル46 lv1以上
スキル48 plv2以上 スキル46 lv2以上
スキル49 plv2以上 スキル46 lv3以上
$ php artisan make:seeder rpg/SkillRequirementTableSeeder
$ php artisan make:model /Game/Rpg/SkillRequirement
入れ子できるか試す
とりあえずjsonを返すエンドポイントを作って、そちらでためしてみれば良い
入れ子は実装できた。
とりあえず作成しているjsonデータを、実際にデータを見て決定するようにする。
スキル画面の実装
作ったスキルツリーを含む情報から、vueにデータを出す
パーティメンバーの名前
スキルツリー
スキルのタイプに合わせてボタンの色を変えられると可愛いかも
回復は緑、ダメージは赤、バフは黄色とか。
特定の条件だけクラスを付与するのは、:class=""で実現できる
そのスキルが習得可能かどうかとか画面に出そう
スキル振り分けのためのモーダル画面の作成
完了
スキルポイントを使用した振り分け, 取得処理の実装
スキルレベルを上げるため、中間テーブルのレコード更新が必要
updateExistingPivotを使う。
スキルツリーの再反映
ステータス画面のテンプレート作成
クリスタで書いてみるか。
表示にドット絵あったらいいな〜欲しいな〜
装備とかもまだ曖昧なので最悪あとでもOK
ステータス振り分けの実装
できた！
別画面に遷移したのちの画面を崩したくない
なぜか
stateがskillの状態でショップ→ステータスと遷移させると、一瞬画面が崩れる
これはショップに遷移しても、stateがskillのままだから。
ショップなど別ページに遷移したとき、各stateをリセットする処理を用意したいところ
getPartiesInformation()する前に、stateを'start'に指定したら治った。
todo
装備とかドット絵とかをステータス画面に出すなら、そうする
25.3.31
画面を小さくする
transform.scaleした時のモーダルの不具合を直す
結構大変そうだけどめっちゃ直したい！
無理かと思ったが、Vue3のTeleportでmodalをbodyの外に出したらうまく行った。
ショップ画面調整対応
ショップのUIを、フィールド選択のものと同じようになるよう調整する。
できそうなら、買った後のテーブル格納処理も済ます。
まず何も読み込んでいない場合は、白紙のページを出したいが、全てを思い出す必要がある
store.jsのmenu.shop.statusを呼ぶにはどうすればよかったか。
mapStateをimportする
code:js
computed: {
// menu.shop.status == 'start' の値がcomponentで呼べるようになる
...mapState({
status: state => state.menu.shop.status,
}),
},
computedで頑張る
レイアウト調整
まずは、フィールド画面と同じようにhoverで黄色になるようにする
した
モーダル画面調整
最大所持数を表示させる
最大所持数以上は、フォームに記入できなくする
status側のモーダルが参考になる。
ショップの一覧のAPIに以下を用意する
お金
現在の自分の所持数
用意した
「買う」画面作成
statusはbuyableとする
モーダルの数字調整
最大所持可能数を超えないような設計にする
Status.vue側は、どのような設計だったか？
code:html
<input type="number"
v-model.number="inputFreelyStatusPoints"
@input="validateStatusInput"
min="0"
placeholder="振り分けるポイントを入力"
v-model.number="inputFreelyStatusPoints"として、input中の数字をinputFreelyStatusPointsとして扱う
maxを指定
@input="validateStatusInput"
inputされるたび、この関数が走る。エラーメッセージなどを出している
モーダルのUIを合わせる(Adventure側のモーダルも)
キャンセルを消す
btn btn-infoにする
とか
購入処理の実装
paymentItem
アイテムを増やして、お金をそのぶん下げる
Adventure画面 startの"読み込み中"をつけて、他と統一しておく？
→した。
進行度に応じてショップのアイテムが並ぶようにする
required_clearsカラム
これでショップに並ぶアイテムを調整する
ここですでにマイグレーションファイルは作成済み。
実装。
? 「売る」画面作成
→優先度低く考えてしまって良いのではと思った。
工数の割にと言う感じ。必要そうならやるといいと思う。
ステータス・スキルポイントの再振り分け実装
ステータス
rpg_partiesに、allocated_hpなどの要素を追加
PARTY_TEMPLATEでjsonとしてデータを入れるときに、value_hp + allocated_hpというデータ格納にすればOK
またステータス画面に出すHP: 46などの表記も同じように、情報作成時に+とすれば良い
すぐできそう
スキル
これはすぐできる
マイグレーションを作る
$ php artisan make:migration add_column_to_rpg_parties_table
振り分けたスキルポイントが、allocatedの値に格納されるようにする
/api/game/rpg/status/increment
すでに関数化している。優秀
party->allocateStatusPoint()を編集。
ステータスの画面に反映させる
した
戦闘関連
開始時
createPlayersCollectionを調整し、戦闘のデフォルトステータスにallocatedの値を考慮させた
戦闘終了後、切り上げた時
ステータス反映のステップがある
考慮させたjsonの値で、value_hpを上書きしている処理がある
これは、allocatedの値で引き算してやればよさそう
value_strとかで検索して、そのほかの部分も一旦問題ないか。
振り直しを実装する
? HPだけ倍上がる仕様なので、HPの再分配時にはちゃんと半分のステータスポイントとしておく。
できた
ステージを進めたご褒美で開放してもいいかもなあ
savedataにフラグ作って。
アイテム
最大所持数を10個までとかにして、制限をつけたい
つけた
売る機能
いる。つけた。