デバッグ作業がめんどいな...てかそもそもデバッグ作業ってどんなことするんだ？w適当に遊びまくってるだけじゃダメだよね？

「できること」と「できてはいけないこと」を確認してプログラムの不具合を発見する。プログラムに不具合がないことを確認するのがデバックの目的かな。 だから、テキトーにゲームで遊んでるだけではダメ。 例えばシューティングの場合 できること：ボタンが押されたら自機が上下左右に動くこと できてはいけないこと：自機が画面外に移動してしまってはいけない こんな感じで、動かしながらプログラムの動作に誤りがないかを確認する。 バグが見つかったら、いつどこでどういうことをしたら起きるかを頭の中にメモって直ぐ直したり後で直したり、それをゲームの仕様として諦めたりする。 ゲームの規模が大きくなると、頭の中では整理しきれないのでExcelとかでテスト項目一覧表とか不具合一覧表とかを作って、デバック作業をする ゲーム会社の人ではないけど、多分こんな感じかな

デバッグが大変なら楽になるようにデバッグオプションつけてみるといいかも。 開発者用メニューか何か用意しておいて、呼び出したらそこでいろんな数値をいじくれるようにするとか。

なるほど開発者オプション作ってみよっとw そもそもテスト内容が思いつかないw(MYLIFEだいぶ複雑になってきたから...)

私の場合、単体テストという手法を使って関数のテストしてます。 確認項目が1200近くある作業が、わずか数秒で終わる。 まあでも最終的には手を動かして目視確認が重要ですが。

何それかっこいいw

単体テストの事を簡単に説明した過去記事です。 興味がある人はどうぞ。 https://miiverse.nintendo.net/posts/AYMHAAACAAADVHjY1ocsbA

ゆっくり見てみます！！

うーむ...難しい

難しいか…… 実際にテストが動いてる様子を見たらイメージし易かったりするのかな。

百閒は一見にしかずですかね？（バカでも見て理解できるかな）

実際の動きを見たい場合、 ミーバースにて私の活動から「音楽つくろうぜ！」の公開キーを探してみてDLしてみて下さい。 スロット0に"ONTUKU"をロード スロット1に"UNITTEST"をロード そして…… RUN 1 を実行。これでテストが動いているのが確認できるはずです。 (おそらく、全て成功するはず)

これが実際のテストの一部分です。

3325行はtrim(トリム)という自作関数のテストです。 このtrimという関数は文字列の前後の空白を取り除く事ができる関数だとします。 3327行目で前後に空白のあるテスト用の文字列を作り、 3328行目でtrim関数を呼び出しています。 3329行目が検証部分です。assertEqualsで等しいかを調べています。等しい場合は成功。等しくない場合はテスト失敗です。 後はこの繰り返し。ひたすら自問自答を行いテストパターンを充実させていきます。

むっ難しいけど出来たら面白そう...