<-->


スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

現象の切り分けについて


※以下の内容はサイト「WOLF RPGエディター エラーコレクション - 非公式 -」
 からの移転記事になります




 はじめに

このページではウディタの不具合について、現象の切り分けについて簡単に説明します。
切り分けの極々基本的な内容しか記載できませんが、お役に立てればと思います。
なお、この項の内容は【基本的な対処法】をクリアしていることが前提です。

現象の切り分け内容は多岐に渡り、有効的な方法もケースバイケースのため
汎用的に言える事は少ないです。
ただし、要素をしっかり絞り込めば必要な計算・方法の算出は意外と簡単です。

A(環境/状態)+B(操作)=C(現象)

方程式があるとすれば、こんな具合でしょうか。
文章で言うとこうなります。

ある状態中に(A) 一定の操作をすると(B) 現象が発生する(C)

現象を確認した際に、上記のAとBが何を意味しているのか漠然とでも解るようになると、
それを確認するためにどういった計算や処理を行えばよいのか、自ずと導かれます。

以降、自作ゲーム中マップaからマップbに移動するとゲームが強制終了するという、
架空の現象を例題として進めます。



  第一歩

まず最初に行うことは、A・Bそれぞれに対して、要因を特定することです。
切り分けの基本は、確かめたい要素だけを変化させ、他の要素は何も変化させない
ことです。           

【 方法例 】
同じデータ上で同じ内容の、異なる操作を行ってみます。
マップの端にキャラが移動したら、「場所移動」でマップbに移動する処理を
設けているかと思います。
そこで、マップ移動を管理しているイベント上で、マップbではなくマップcに
移動するイベントに変更してみます。

A+B=C ならば A+B'=C が成り立つか確認する作業です。
これを行うことで、B(操作)の要因が「マップbに移動すること」かどうか判別します。

  ■マップcに移動すると現象未発生
   →「マップbに移動すること」に要因の可能性あり

  ■マップcに移動しても現象確認
   →「他マップに移動すること」に要因の可能性あり

「他マップに移動すること」に要因があると確認できれば、同様にマップd やe にも
移動処理を行って確認します。
その結果、特定のマップに移動することが要因ではなく「場所移動」コマンドに要因がある、
という結論に至るかもしれません。




 第二歩


続いて環境/状態の切り分けです。
異なる環境で同じ操作を行った際に現象が確認できなければ、元の環境による
問題の可能性があります。

A+B=C ならば A'+B=C が成り立つか確認する作業です。

【 方法例 】
手段の一つとして、改変の無いサンプルゲームで確認するというのは、有効な切り分けの一つです。サンプルゲームに同じイベントをおいて検証してみます。

  ■サンプルゲームでも現象が確認
   →環境/状態は要因ではない(全ての環境/状態で起こりうる可能性あり)

  ■サンプルゲームで現象が確認出来ない
   →自作された部分(AとA'の差分)に要因の可能性あり

結果より、上記の内容に結論付けることが可能です。
冒頭でも述べましたが、切り分けを行う際は A'+B'=C になっていないかどうかご注意ください。
「確かめたい要素だけを変化させ、他の要素は何も変化させない」ことが肝心です。

一度に二つの要素の切り分けは、要因をあやふやにさせるだけでなく、要因の誤認に
繋がりかねません。

必ず A'+B=C、A+B'=C を個別に確認するようにしてください。


 第三歩

A・Bの要因が特定できたら、確認した内容が正しいかどうか「逆」を使って確定させます。
たとえば要因が「マップa からb に移動する事」と認識したとします。
上記の場合、マップa からマップb に移動したときのみ現象が確認できなければ、
正確ではありません。

【 方法例 】
マップa → b だけではなく、マップb → a に移動した際に、現象が発生しないことを確認しておきます。

もし、マップb → a に移動した際にも現象が確認できれば、「場所移動」コマンドそのものに
要因があるのかもしれません。
少なくとも要因が「マップa からb に移動する事」ではなくなりますので、
認識を改める必要があります。

要因を特定できたなら、「逆」を使って要因を確定させるところまで試行できれば、ベストです。
               


 最終確認

A・Bそれぞれの要因が確定できました。
確定できたら、さらにもう一手指しておきます。

【 方法例 】
空データを用意して、最低限のイベントやグラフィックのみを置いて現象を確認
できるかどうか、検証します。

こうする事によって他要素から影響を受ける事なく、要因を検証することが可能です。

不必要な要素が存在すると、検証結果が異なったり正しい結果に繋がらなかったりします。
不必要な要素を排除することで、要因のみをダイレクトに一点検証することが可能です。
正しい認識と正確な切り分けが出来ていたら、最低限のデータだけで現象の確認が出来るはずです。

余計な要素を省いているので、それはシンプルで純度の高いソースになります。
シンプルで純度の高いソースは、「バグ報告スレッド」にて検証データをアップするにあたり、
申し分のないデータとなるでしょう。
また余計な要素を省いているので、製作者様も確認を行う際にスムーズに確認できるに違いありません。



 おわりに

以上、現象の切り分けについて思いつくままに記載しました。
話が長くなりましたが、考え方についての基本なので、慣れてくれば途中を省いたり応用が可能です。
また、最後まで確認するためには工数が少しかさみます。
しかし正確な情報を掴むためにも、自身の環境で確かめられる所までは、
頑張って確認してみてください。

なお、A+B=C A'+B=C A+B'=C という考え方は、デバッグやプログラムの組み方にも応用が可能です。
確認された現象が、どんなイベントコマンドが要因になっているのか特定が早ければ、
効率の良いデバッグを行うことが可能です。

イベント(C)がどんな要素(A・B)を含んで成立しているか細分化できるようになれば、
ウディタで複雑なイベントを組む際に大きな手助けになるはずです。

ぜひ、お役立てください。
スポンサーサイト

コメントの投稿

非公開コメント

リンク
twitter
http://twitter.com/vanzgraphica
このページのトップへ
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。