はじめてゲームプログラミング 関数化
-
cabbagestole
- 1398
- 0
- 0
- 0
-
- いいね！0
きゃべつ
@cabbagestole
引数、戻り値、関数部が定まったので多重度(同時出現数)を決める ６機=510 はい無理w 5機=463 残り50ノードンは心許ない ４機=416 残り96 ４機でほぼ確だな アンドアジェネシス、地上物、地上砲台、バキュラのコピペしなきやならん pic.twitter.com/4IPLaao7SN
2021-12-21 11:16:15
拡大
きゃべつ
@cabbagestole
仮に関数化せず４機をコピペすると総数は499ノードン 関数化する事で83ノードン捻り出せるのだからやる価値あり スターフォースみたいに空中地上敵の区別なくショットで全部壊せるゲームにして、背景無し(宇宙！便利！)なら敵６機〜７機出せる感じだな
2021-12-21 11:32:36
きゃべつ
@cabbagestole
WOさんの第九惑星を解析始めて素晴らしい考案が実装されているのを発見！ おめくり式は1fを16分割して動作する特性上、比較や論理演算のタイミングも1/16fに調整する必要がある タイミング取る為にNOP命令を挟みノードン増になってしまうデメリットも有る(続く
2021-12-21 11:47:51
きゃべつ
@cabbagestole
しかし1f内に多重度Mの計算を完了させる必要あるかと言うとそうでもない 昨日も言ったけど「小足見て昇竜余裕」なんて人はほぼ居ないので多重度分のMフレーム使ってもゲーム進行に影響はほぼ無い pic.twitter.com/JjhpSxKJJc
2021-12-21 11:50:50
拡大
きゃべつ
@cabbagestole
多重度Mの処理を1/16フレーム単位でタイムスライスするか1フレームでスライスするかの違いでしか無い 発信機も単純(カウンターのループ)だし引数、戻り値の掛け算ノードはM(P+O)でM一個分少ない 一番大きいのは関数部のアンコ詰めが不要なので見積もりから上振れしない事！
2021-12-21 11:54:20
きゃべつ
@cabbagestole
問題点は一巡するのにMフレームかかるので反応漏れが起きる事 とは言え今回のpicoXEVIOUSでは敵が直進したまま攻撃せず画面外へ出ていくだけになるので難易度低下が期待出来る笑 採用！
2021-12-21 12:00:30
きゃべつ
@cabbagestole
関数化部分の見直し中 共通化するにあたり0から変わった瞬間ノードンは危ないな 切替ながら関数使うとフラグOFFの奴とONの奴が混在すると、このノードンが暴れる ロジック見直し中
2021-12-21 14:19:41
きゃべつ
@cabbagestole
敵エネミーの固有部分をコピペしてワイヤー張りやすく再配置した 作業効率しか考えてないので地獄のような酷さ pic.twitter.com/fW8ljQ8IfE
2021-12-21 20:08:16
拡大
きゃべつ
@cabbagestole
遣り方は人それぞれだけど私のゴーストが「関数のインターフェースと内部結線を先にやれ」と囁く 結線で埋め尽くされ視認困難になるエリアを小さくしようとしている pic.twitter.com/Aqb82ajIV0
2021-12-21 20:20:59
拡大
きゃべつ
@cabbagestole
意味が同じだからとワイヤー繋ぐ端子を適当にしてるとコピペで死ぬ 訓練されたプログラマーはコピペに備えた実装を意識せずに実践する そのコーディング規約は己の魂に刻んである pic.twitter.com/DOljUroVyh
2021-12-21 20:35:53
きゃべつ
@cabbagestole
関数インターフェースと内部結線を終えた地獄絵図 再度見積したらエネミー5機で419となる (残り93ノードン) 欲出して5機分実装するぞー 1機あたり29+8 pic.twitter.com/SaAzoLNCJH
2021-12-21 21:32:25
きゃべつ
@cabbagestole
生死フラグを 死→生1(反応前)→生2(反応後)→死 生1→死 の状態遷移を取る変数に変えれば 生1 AND 反応FLG が正の時が0から変わった瞬間と等価 こっちだな 中間ノードンなら何でも使えると期待してたけど0から変わったは使わない方が良い、の学びを得た
2021-12-22 11:48:36
きゃべつ
@cabbagestole
最終稿、こうか？ タイムスライスを意識した関数化を行う際、 ・共通処理 入力値に対して「計算だけ行う」 ・インスタンス内部処理 「判定処理を行う」論理演算、0から変わった等 状態を持つ(カウンタやフラグ) 一般化にはまだ粗がありそうだけど、コレで組み直してみる pic.twitter.com/vfiFBk1AX8
2021-12-22 15:36:53
拡大
きゃべつ
@cabbagestole
何だろう 排他制御が使えない処理系でマルチスレッド、マルチプロセスに対応した共用関数設計してる気分 はじプロの要求する設計レベル…高い
2021-12-22 15:42:54
きゃべつ
@cabbagestole
関数の中で判定処理しちゃいけないとか言っときながら敵種類によって分岐(つまり判定)させてるんですけどね笑 敵のライフタイム中は変化しないグローバル変数の読取だけの前提を置けるからズルしてるけど これも禁止されたら関数化する価値が無くなる(削減効果が得られない)
2021-12-22 15:53:13
きゃべつ
@cabbagestole
敵の処理書き換えた 事前確認してテスト 1f切り替えしないと想定通りだが、1f切り替えすると想定外の動き 角度が90度狂う うーむ pic.twitter.com/1GjmyeY3EI
2021-12-22 19:30:31
きゃべつ
@cabbagestole
30回位テストして分かった 1/6位の頻度で正しく角度が設定されるが5/6は角度が設定されてない笑 死→生のフレームと角度決定のフレームがズレてるだけだ笑
2021-12-22 19:35:03
きゃべつ
@cabbagestole
単に関数切り出しだけでなく、生死イベントの判定もタイムスライスの間隔に合わせてイベント発生させろって事ね ちゃんと関数化に取組むの初めてなんだけど、色々課題があるもんだな
2021-12-22 19:37:39
きゃべつ
@cabbagestole
うーむ タイムスライス実行に対応するよう関数書き換えたが、はじプロ物理問題が絡んできた 自機を狙う射線が1サイクル前の角度の為、動かなければ当たらない現象 ヒンジで角度を変えて射線動かすのが定石だけど、これはなだらかに変化する連続した値(角度)だから成立してた話 (続く pic.twitter.com/rk77EHHeQ2
2021-12-22 21:14:20
きゃべつ
@cabbagestole
1f毎切替方式で6フレーム1サイクルで回してるんだけど、自機を狙う角度が109, 0, 0, 0, 0, 0, 110, … の様に0に角度が落ちる期間が長くなり銃身が荒ぶり、このまま角度を与えると狙いが定まらず使い物にならない (続く
2021-12-22 21:19:13
きゃべつ
@cabbagestole
緩やかな角度を維持する事を目的にグラディウスオプションのリングバッファ方式で過去値を保持させると 109,109,109,109,109,109,110 の様に出来るけど 敵の座標も変わっており更に6f前の角度を採用するので、自然ではあるが下手っぴな射撃になる 敵、優しすぎるだろ笑
2021-12-22 21:22:38