とりとめ
失敗談1
player.stateの管理がだるくなってきた。
imageの更新と分離させてるから余計にね。
禁止行動とか一元管理したくなる。
必要なもの
input triggerで。押されたものだけ処理。
派生条件(
state(idle, jump, crouch等), 発生持続硬直,
禁止行動(ダメージモーション中ならジャンプできない等)
)
state切り替え
作用(dx, dy, hitbox, attackbox)
持続作用(画像更新、エアリアル系の継続dx等、state切り替え)
だめでした。jump + moveは起こり得るので、moveはstateに含んではいけない。
結局は実装したいことが出てくる度に、遷移図を書き足して、その通りに実装したほうが早いわ。それだけの地力があるもんね。ああ驕り驕り
それより事前の到達点を明確に定めないと、納期とかはないけどだらだらやり続けることになる。それはいやだ。他のこともしたい。
手記
フィールド移動そのものが大事なんで、はじきダッシュはないっすね。
空中で向いてる方向変わるのはナシで。
ウォールキック
方向による制限ってのが、割といいかもしれない。
反対方向に初回くっつかないのがちょいあれかもしれない。
敵つくんのめんどいー
雑魚敵は無視できる敵。弱いとは言ってない。
ボス敵は無視できない敵。もちろん強い。
他人の言ってることは聞くもんだ
衝突応答のデータ構造であれこれ考えてたときに見つけた1ページ。
「移動する床」などは無理にマップデータの配列では持たず、「当たってもダメージを受けない敵キャラ」として実装する
いいアイディア。今まで悩んでたのは何だったんだろう。早速実装しよう。
縦幅がキャラと同じ高さしか無い場所でもジャンプが出来た
要は入力に対して何らかの応答があるってこと。
すごく気にしてる部分。これが丁寧に作り込まれていると，ああ，いいゲームだなあって思う。
個人的にSMBから学べることはもっとあって、
入力のホールドではアクションがリピートしない応答性とか
レベルデザイン全般も見習うことがたくさんある。
巷にあふれかえる境界線
ことプラットフォーマー(サイドビューアクション)の当たり判定について。
点，円，矩形の当たり判定は容易に実装できた。
というかここまでは特に何かをお手本にするでもなく自力で実装できた。
いよいよこれだけじゃ無理そうなところにさしかかってきた。
階段，昇降リフト，スウィープボリューム，
そんな，判定後の処理を考えたときにベクトルを使うと楽そうなのまではわかった。
いよいよ独創+αで他人から吸収しないと無理そうな領域まできた。
思えばこんな境目ばかりだった。
8分目までは大体のものを器用にこなせる器量があることは自覚してる。
その先の，アマとプロの線引きみたいなところで，今まではなにもかもを諦めてた。
ゲームはもっと本腰入れてやってみたいと思える。やっぱり自分にとってゲームって一番の存在なんだなって。
ギミック？フラグ？
フラグ管理の進行ルートは極力つくらない。
設けるとしたら明確にギミックでは開閉不可能なことを伝える。
イーガ団のアジトね，あれはないわ。
かなりロクゼロ意識してる
ただ壁張り付きは横入力には納得してない勢。
段差の上に敵がいると張り付き時に反対を攻撃するでしょ。あれがどうもね
アクションスキル
自分でも区別つかなくなるから整理
walk 歩く
run / dash / sprint / strafe 走る
FPS的にはストレイフはジャンプ中の視点移動
step / side step / slide 横小加速
低姿勢になるほうがスライド
aerial step / aerial slide / 空～ / エア～
ステップが空中で化ける。y軸を維持するとエアスラ
dodge roll 回避移動。空で化けるとエアドッジ。回避はパッシブスキルにするつもり
楽しそうなこと
破壊可能な地形
マップ外地形
シーケンスブレイク
わかったこと
円のプログラムは流用できない。
アニメーションは面倒くさい。
ミサキチはかわいい。
JKの呼吸とか歩行時速の平均に詳しくなった。
html5のaudioがわりとしっかりしてる。ただ環境差があるらしいから乱用厳禁かな。
空ジャンを判別するために音声が必須。重要ファクターなんやなあ。
ファクトリ？よくわかんない
MVCとかMVVMとかどの順番でもってくるかって話。
ModelViewってのがいまいちしっくりこない。Controllerを言い換えただけじゃないってのは見たことあるけど，
フローが変わった感じじゃないんだよね。勉強不足ですまそ。
ああ，思い出した。ModelとViewの疎密関係だった。MVVMが完全に離れてるほうだ。
Fluxってのがトレンドらしい。
View → Action → Dispather → Store → View なる。
ここからオレオレ理論。
入力 → 処理 → 表示 → 判定で。
入力 → 処理 → 判定 → 表示だと起承転結の転を見せないのに次いかれた感じで納得いかないじゃん。
入力 → 処理 → 表示 → 判定(受付不可=true) → 入力とばして処理
1フレのせめぎあい。
「魅せてあげよう，1フレームのエクスタシーを」みたいなキャッチコピーなんだっけ？PCとかアケゲーだったと思う。
違う1ドットだ。レイドックだ。MSX2だあああ・・・・・・ふぅ。
さて，いいたかったのはゲームにここらへんのアーキテクチャパターンが当てはまるかってことよ。
自分で書いてて悪いんだけど入力 → 処理 → 表示 → 判定って見にくい。
Input → Process → Draw → Judgmentで。
Fluxとすり合わせ。起点はどこだっていいから順番変えて，
Draw → Judgment → Input → Process → Draw
View → Action → Dispather → Store → View
やっぱJudgment位置があれかー。
てかJudgmentとProcess離れてるのおかしいよなあ。
DispatherとStoreも，，，これはDBとかの意だからいいのかあ。
表示のあと入力の隙きもなくジエンドってほうがいやだわ。やっぱ
Draw → Input → Process → Judgment → Drawだ。
そもそもProcessにJudgmentは包括されてるよな。序破急っすね。
なんだったんだこの20行くらい。本当に自分の中で整理するためだけでした。
2020/04/01 追記
なに書いてんだこいつ、Input -> Judge -> Processだろ
キー入力から移動処理してからcollision detectして押し戻しとか本質と違うでしょ
そんでもってviewは独立なんだからこの輪廻にいれんなや。
ついでだからいつかに書いたポエムのっけとくお
modelもviewも間違いなくあって、他は取り扱いの哲学
input = user action
依存関係は疎に徹したほうがいい
ならviewはactionをするか、ないだろう
ユーザーフォームと決められたmodelがviewされるのであって、
viewがユーザーフォームを持っているわけではない
view firstではなく(model) input first
こんなことやってるんだったらview, model内のhierarchy練ったほうが生産的
あとは各々のクオリティを満たしているかのみ
MVCのなにが悪かったって、一方向でしかなかったから
viewはrecieverでありsendしない
model <-> controller -> view
あとmodelもcontrollerをいじらない
model <- controller -> view
viewはユーザーへの視認containerであり実体はない
今そのものでありそれ以上以下でも未来過去でもない
modelは過去であり、controllerがそれを今に近づける
modelとviewはまさしくアキレスと亀である
あとで見返したらまた何言ってだこいつってなるやつだこれ
ドット絵
別にレトロフィーチャーでドット絵が好きなわけではないんだな。
レトロゲーは好きだけど，それはその時代の遺物として好きなわけで，懐古主義ではないし。
ディベロッパーとプレイヤーの視点の違いとかも言及されてたけど，それ言うなら，さらに，
今昔を交えた4つの視点で語らないと解決しないでしょ。
個人的にはダンパー線とか見づらくて仕方ないし，とにかくプレイ感が損なわれるものは徹底して排除してほしい。
という今のプレイヤーとしての視点。
ロムハックとかに憧れてた自分としては，楽しめるバグと楽しめないバグは大きな焦点のひとつ。
全く触ってないけど，マリオメーカーとかは当時の，
浮いてるように見えるから1ドット沈ませた所為でもろもろ...の仕様は受け継がれてるのかとかすごく気になる。
「昔のドット絵はブラウン管の滲みを前提にデザインされていた」に疑問の声