Dear!くろうどぃあ!

このブログでは、私、くろうどの趣味に関する事を記述します。
当面は、「RPGツクールMV」をメインにします。

バグを減らすために考えておくこと

2017-12-06 11:50:01 | RPGツクールMV
  • はじめに

さて皆さん。
この記事は、「ツクール Advent Calendar 2017 ( https://adventar.org/calendars/2748 )」の12月6日の記事です。
創作関連アドベントカレンダーとの事らしいです。

この記事では、創作ツールとしてRPGツクールMVを取り上げて、その中でもテストについて書きます。

ちなみに、RPGツクールMVのアドベントカレンダーに関しては、( https://adventar.org/calendars/2288 )もありますので、見てください。



  • バグとは?

さて、バグとは何でしょうか?
ココでは、「作者の想定する動作と異なる動作をする事」としておきましょう。
つまり、理想と現実が異なるわけですから、「問題」なわけですね。
「問題」であれば「解決」しましょう。

「問題」とは、理想と現実のギャップの事です。
※ちなみに、某所ではバグの事を「故障」って呼んだりしますね。

それから、この記事では、RPGツクールMVに関しての内容になりますので、コンピュータゲームにおけるバグという事になります。

そして、バグを見つける作業を「テスト」と呼ぶ事にしておきます。

※当然ですが、「想定する動作(理想)」がどういう物なのか、つまり「仕様」は、把握または決めておいてください。

 

  • テスト手法

前述の通り、バグが発生するという事は、ゲームの故障であり問題であるわけですから、なるべく発見して解決しておきたいものです。

バグを発見するためには、多くの場合、ゲームのテストプレイをする事になるでしょう。

では、どのようにテストプレイすれば良いのでしょうか?

闇雲にテストプレイしても時間だけが過ぎて行き、バグが見つけられない可能性があります。
そこで、テスト項目(どのようにテストプレイするのか)という物を考えます。

テスト項目を考える上で押さえておきたいのが、「同値分割」「境界値分析」という考え方です。

例えば、「変数A > 0」かつ「変数A < 5」という条件があるとします。
同値分割だと、「0以下、1以上5未満、5以上」の3つに分かれ、それぞれのグループに含まれる値をテストするという考え方です。
境界値分析だと、条件の境界値である「0、1、4、5」の4つの値をテストするという考え方です。
これを組合せてテスト項目を作ります。


とは言え、これは一番細かい部分のテスト手法なので、ゲームのテストプレイでどこまでやるのか……というのはあります。
ですがまぁ、この記事では、このテスト手法を元に話をします。


  • バグを発見するためのテストプレイ

それでは、実際にゲームを見てみましょう。

村人5人に話しかけてから村長に話しかけたらクリアになるゲームです。

RPGツクールMVの初心者講座に「複数の人から情報を聞かないと先に進まないイベントを作る」というページがあるので、それを元に説明します。
https://tkool.jp/mv/guide/006_005e.html

 



テスト項目は以下です。

  1. ゲーム開始時(話しかけた村人の数→0人)
  2. 村人1人に話しかけた(1人)
  3. 同じ村人に5回話しかけた(増えない)
  4. 村人4人に話しかけた(4人)
  5. 村人5人に話しかけた(5人)
  6. 村人が6人以上いるなら6人に話しかけた(6人)

※上記のそれぞれで村長に話す(5人以上ならクリア)

この場合、村長に話しかけるテストプレイを6回する事になります。

※テスト項目の2番は省略してもいいかもしれません。


  • ゲーム作成段階でバグを減らす

さて、ゲーム作成やプログラミングに慣れてくると、どういう所にバグが潜んでいるかが分かるようになってきます。

前述の村人5人のゲームで考えてみましょう。

このゲームのイベントは、村長と、村人5人以上で作られます。
この時、村人はセリフこそ違えど、話しかけた数のカウント処理は同じです。
それぞれの処理を見てみましょう。

    • 村長

村長に必要なのは、変数(話しかけた村人の数)が 5 以上であるかどうかの条件分岐イベントです。



    • 村人

村人に必要なのは、変数(話しかけた村人の数)を 1 加算する処理です。
同じ村人に話しかけた時には加算しないようにする必要があります。



慣れてくると、これらのイベントを作る時に、前述の6個のテスト項目が頭に浮かびます。
例えば、「同じ村人に2回話しかけたらどうなるんだろうか?」という疑問が浮かぶわけです。
その疑問を元にして、イベントコマンドを見た時に、「同じ村人に2回以上話しかけた時には加算しないようにする」処理を加える事が出来れば、バグを事前に減らせた事になります。

 

  • おわりに

テストは地味で面倒くさい作業ですが、品質を向上させるために必要な作業です。
この記事で書いたように、テストにもやり方があります。
上手にテストをする事で、効率よくバグを発見し、やがては、作成時にバグを減らす事も出来ます。
テストを意識する、つまり、どのようにゲームを動かしたいのかをイメージして作成しましょう。

それでは~。

コメント
この記事をはてなブックマークに追加

【アドベントカレンダー2017】ラノゲツクールMV先行体験版を触って、RPGツクールMVとの違いなど……

2017-12-05 00:01:41 | RPGツクールMV
  • はじめに

さて皆さん。
この記事は、「RPGツクールMVアドベントカレンダー2017」の12月5日の記事です。

https://adventar.org/calendars/2288

この記事では、ラノゲツクールMV先行体験版を触って感じた事などを書き、どのようなツールなのか紹介できればと思います。

 

  • ラノゲツクールMV概要

さて、ラノゲツクールMVは2017年12月14日発売予定のツクールシリーズ最新作です。
RPGではなく、物語ゲームやノベル系のアドベンチャーゲーム(以下、ラノゲ)を作るためのツールです。

ですが、スクリプトを改造とまで行かずとも、ラノゲツクールMVの本来の機能だけでも、色んなジャンルのゲームが作れるようです。
サンプルとして、ブラックジャックがありました。


ちなみに、キャッチコピーは「あなたしか知らない物語は、やがてみんなの物語へ」のようです。

Twitterでも言ってる人を見かけましたが、良いコピーですよね~。

 

※以下の画像は、プロジェクトのシーン作成画面と、データベース画面。



  • RPGツクールMVとの違い

RPGツクールMVとの違いですが、RPGでは登場人物の他に武器や魔法、敵キャラクターといった「データ」に、「マップ」と発生する「イベント」を作成しますが、ラノゲでは「登場人物」を設定して「シーン」を書けば基本的には作れるので、シンプルと言えるかもしれません。

(RPGツクールMVのイベント作成だけが連続しているイメージ)

機能面では、「リスト(可変長配列)」が使える、ピクチャ番号に変数が使える、「ホットスポット」という機能で画像にクリックを受け付けられる……など、コマンドに関しては、RPGツクールMVよりも機能が豊富です。

ただし、プログラミングの知識がなければ、それらの機能が何なのか、分かりにくいかもしれません。

ヘルプだと機能名から機能の使い方を引きますが、作りたい物から機能を逆引き出来るといいかもしれません。
(そのためのフォーラムかしら?)

ツクールweb(https://tkool.jp/

 

  • ラノゲツクールMV入門

さて、ラノゲツクールMVを使って、普通にラノゲを作る場合、物語が一本道であれば必要なコマンドは、メッセージ表示、キャラクター表示、音楽再生、シーンの変更などの物語部分と演出だけでも作れるでしょう。

ここに選択肢による分岐をちょっと足しても、変数や(変数による)条件分岐、ループといったプログラミング的な要素を使わずに作れるでしょう。

これは、(ゲームを作成する難易度に関わる)ちょっとしたポイントかもしれません。


選択肢による分岐では、変数を使わなくても済むのです(ラベルやシーンに移動させる)。
つまり、プログラミングに興味がない方は、物語の流れや構成を工夫すれば、プログラミング的なコマンドを使わなくても済むのです。

※以下の画像は、選択肢の表示と、「いいえ」を選んだら選択肢をループさせている。「はい」を選ぶと次のシーンへ進む。

※上の画像で使っているコマンドに、演出系のコマンドを使うだけでも、ラノゲを作る事は出来そう。

 

  • 先行体験版で私がやった事

サンプルのブラックジャックを改造して、「クリベッジ」というトランプゲームを作っています(未完成)。

※「クリベッジ」というのは、配られたカードを相手と交互に出して役(ポーカーで言うとペアやストレートなど)を作るなどして得点を稼ぐゲームです。役として得点になる組合せが多く(カードの値を足して15になると得点になるというのが特徴的)、徐々に得点が増えていきつつ、時々高得点が得られたりして楽しいゲームです。得点のカウントにはクリベッジボードという物を使います。


ラノゲツクールMVのおかげで、画像処理はかなり楽だったと思います。

特に、「ホットスポット」という機能で、いわゆるピクチャのボタン化が出来るので、カードを選択する処理で、選択肢を表示するのではなく、カードをクリック出来るように作れました。
(画像周りは苦手意識があるのです)

※作成中の画面。

 

  • ちょっとしたアドバイス
    • インデント(字下げ)

条件やループの中身はインデントで表現するようです。
設定したコマンドで左右キーを押すと、コマンドがちょっと左右に移動するのが、それです。
慣れるまで、分かりにくいと思いますので、特にループに関しては、ラベルを使ってループさせた方が分かりやすいかもしれません。

    • リスト

リストは、RPGツクールMVには無かったコマンドです。
変数が連続した物で、RPGで言うとパーティメンバー4人全体を長さ4のリストとして、勇者ハロルドがリスト0番のデータ……という感じです。
(変数ABCDの4つをリストXの1つにまとめられると考えてください)

※リストを使う事で、スタックやキューといったデータ構造を利用する事が出来ます。

※「リストのシャッフル」というコマンドも用意されているので、カードゲームを作る時にシャッフル処理に悩む事もありません。

※以下の画像は、リストの概念を図にした物です。

 

 

  • おわりに

色々と書いてきましたが、ラノゲツクールMVは、作りたい物が明確にある人向けな気がします。

RPGツクールMVは、テキトーにデータをいじってるだけでも楽しめる部分はありますが、ラノゲツクールMVは文章を書かない事には成果物が何もないからです。

ここは、いきなりつまづく可能性があるので、気を付けましょう。
そこさえ乗り越えれば、あとは、永遠の大海原(大草原?)が待っているはずです。

それでは〜。

コメント
この記事をはてなブックマークに追加

すごろくシステムを作ってみた【3】実装編

2017-06-19 17:35:54 | RPGツクールMV

さてみなさん。
今回は、ここまで検討した内容をツクールMV上に実装していく工程になります。

(今回が最終回です)

 


▼実装(1)マップ

こんな感じで、設計時に検討した通りに、マップイベントで埋めています。
また、次に移動する方向に合わせて、リージョンを設定しています。

マップイベントの無い左上のマス(リージョン1を設定している所)が、スタート地点です。

商人風のお姉さんは、ショップイベントです。
マスに止まった時に、話しかける(任意)事で、買い物が出来ます。


↑マップイベントも設計通りに作成します。
ポイントは、サイコロを振る(移動する)かどうかの確認を行うコモンイベントを呼ぶ事と、プライオリティをプレイヤーと同じにして、トリガーを接触にする事です。

 


▼実装(2)変数

↑今回の「すごろくシステム」で使うために用意した変数です。
それぞれについて、以下に説明します。

■[Move Counter]
サイコロ1回分の移動する歩数を管理します。
ここに既に1以上の値が入っている場合、サイコロを振らずに、その値の分だけ移動します。

■[Next Way]
次の1歩の方向を示します。
リージョンIDと対応させる事として、1~5を使用します。

■[This X]
■[This Y]
プレイヤーが居るマスの座標を取得します。
そのマスのリージョンIDを取得するために使います。

■[This Map ID]
■[Map Move Counter]
プレイヤーが居るマップIDを設定し、そのマップ内での総歩数を管理します。
それぞれのマップで、止まったマスのイベントを起こすために使います。

■[Dice Counter]
サイコロを振る時の、サイコロの追加個数です。
通常はゼロでサイコロを1個振り、1だと+1個振ります(つまり2個振る)。

 

 


▼実装(3)コモンイベント

以下は作成したコモンイベント(一部省略)です。
設計通りに作ってあるはずなので、説明は省略します。

これで、「すごろくシステム」のテスト用の実装は終わりです。
あとは、動作確認をして、想定通りの動きをすればOKです。

それでは~。


「◆Move」
移動用コモンイベント
------------------------------------------------------------
◆注釈:Set [Move Counter] before this.
◆移動ルートの設定:プレイヤー (飛ばす, ウェイト)
:        :◇すり抜けON
:        :◇移動速度:5
◆ループ
◆変数の操作:#0043 [This X] = プレイヤーのマップX
◆変数の操作:#0044 [This Y] = プレイヤーのマップY
◆指定位置の情報取得:[Next Way], リージョンID, ({[This X]},{[This Y]})
◆条件分岐:[Next Way] = 1
◆移動ルートの設定:プレイヤー (飛ばす, ウェイト)
:        :◇下に移動

:分岐終了
◆条件分岐:[Next Way] = 2
◆移動ルートの設定:プレイヤー (飛ばす, ウェイト)
:        :◇左に移動

:分岐終了
◆条件分岐:[Next Way] = 3
◆移動ルートの設定:プレイヤー (飛ばす, ウェイト)
:        :◇右に移動

:分岐終了
◆条件分岐:[Next Way] = 4
◆移動ルートの設定:プレイヤー (飛ばす, ウェイト)
:        :◇上に移動

:分岐終了
◆条件分岐:[Next Way] ≥ 5
◆変数の操作:#0041 [Move Counter] = 0
◆ループの中断

:分岐終了
◆変数の操作:#0046 [Map Move Counter] += 1
◆変数の操作:#0041 [Move Counter] -= 1
◆条件分岐:[Move Counter] ≤ 0
◆ループの中断

:分岐終了

:以上繰り返し
◆移動ルートの設定:プレイヤー (飛ばす, ウェイト)
:        :◇すり抜けOFF
:        :◇移動速度:4
◆コモンイベント:◆Stop Event
------------------------------------------------------------


「◆Check Move」

移動確認コモンイベント(マップイベントで呼び出す)
------------------------------------------------------------
◆文章:なし, ウィンドウ, 上
:  :Would you move ?
◆選択肢の表示:Yes, (No) (ウィンドウ, 中, #2, #2)
:Yesのとき
◆条件分岐:[Move Counter] ≤ 0
◆変数の操作:#0041 [Move Counter] = 0
◆ループ
◆変数の操作:#0041 [Move Counter] += 乱数 1..6
◆条件分岐:[Dice Counter] ≤ 0
◆ループの中断

:分岐終了
◆変数の操作:#0047 [Dice Counter] -= 1

:以上繰り返し

:分岐終了
◆文章:なし, ウィンドウ, 上
:  :Move \V[41] step !!
◆コモンイベント:◆Move

:(No)のとき

:分岐終了
------------------------------------------------------------

「◆Stop Event」
止まったマスでイベントを起こすコモンイベント(1)
------------------------------------------------------------
◆変数の操作:#0045 [This Map ID] = マップID
◆条件分岐:[This Map ID] = 6
◆コモンイベント:◆Event 6 Test Map

:分岐終了
------------------------------------------------------------


「◆Event 6 Test Map」
止まったマスでイベントを起こすコモンイベント(2)
------------------------------------------------------------
◆条件分岐:[Map Move Counter] = 1
◆文章:なし, ウィンドウ, 上
:  :Get Gold 1000 !!
:  :And next dice plus 2 !!
◆所持金の増減:+ 1000
◆変数の操作:#0047 [Dice Counter] = 2

:分岐終了
◆条件分岐:[Map Move Counter] = 8
◆文章:なし, ウィンドウ, 上
:  :Next Step is 6 !!
◆変数の操作:#0041 [Move Counter] = 6

:分岐終了
◆条件分岐:[Map Move Counter] = 14
◆戦闘の処理:Sample
:勝ったとき

:逃げたとき

:負けたとき

:分岐終了

:分岐終了
◆条件分岐:[Map Move Counter] ≥ 22
◆文章:なし, ウィンドウ, 上
:  :Sugoroku goal !!
◆場所移動:STAR_LAND (8,9) (向き: 下)

:分岐終了
------------------------------------------------------------

 

コメント
この記事をはてなブックマークに追加

すごろくシステムを作ってみた【2】設計編

2017-06-19 10:13:03 | RPGツクールMV

さてみなさん。
この「すごろくシステムを作ってみた」ですが、なんか長くなりそうなので、今回は設計編です。
見切り発車で書いているので、何回で終わるかは分かりません。

ちなみに、「はじめに」→「要件定義」→「設計」→「実装」→「動作確認(試験)」という順番になると思いますが、実際には所々で前工程に戻っていたり、思い付いた事を先攻して動作確認したりします。

要するに、めっちゃトライ&エラーしてます……って事です。


▼設計

さて、設計では、まとめた要件を実際にツクールで、どのように実装するのかを検討する工程です。
紙に書いたり、いきなりツクール上で作り始めたり、やり方は色々あるでしょうし、私もその時々でまちまちです。

いわゆるウォーターフォール型の開発では、要件から仕様を作っていくので、それに倣って書いていきたいと思います。

●すごろくになるのは、ダンジョン部分とする。
→マップ作成時にそのように作る事とします。

●すごろくマップでは、プレイヤーは自由に動けない。
●プレイヤーが動くためにはサイコロを振る必要がある。
→なんらかの手段で、プレイヤーの移動を不可能にする必要があります。
→今回は、マップに、マップイベントを埋め尽くして、イベントの「プライオリティをプレイヤーと同じ」にする事で通行不可を作り出す……という案を思い付きました。
→また、プレイヤーが、そのイベントに「接触したらサイコロを振る」イベントを実行するという事にすれば、埋め尽くしたイベントを有効活用できそうです。

●サイコロを振ったら、その出目の分だけ移動する。
→ここはちょっと厄介です。
→進行方向が1方向だけであれば、「移動ルートの設定」の「1歩前に進む」を出目の分だけ繰り返せば済むのですが、(要件に書いてませんが)マップをダンジョンっぽくしたいので、向きの変更も出来るようにしたいです。
→今回は、リージョンを使う事で、プレイヤーが居るマスの「次に進む方向を示す」という案を思い付きました。
→移動は、イベントの「移動ルートの設定」で行う事とします。

※ちなみに、サイコロって言ってますが、サイコロを振るグラフィックを用意する予定はありません。
※内部で乱数を生成して、その結果を表示して移動させるだけです。
※見た目は地味ですが、今回はそういう仕様にする事にしてます(書いてませんが)。

●移動して止まったマスでイベントが起こる。
→これもちょっと厄介です。
→今回は、イベントの「移動ルートの設定」で移動させる事にしてますが、移動先のマスにイベントを設定していても動作しないようなのです。
→また、仮にイベントが動作するとしても、それをマップ上に設定するのは、管理が大変な気がします(イベントが起こるマスと起こらないマスが混在するため)。
→というわけで、今回は、「マス番号を設定して、移動後に、止まったマス番号に対応したイベントを起こす」という案を思い付きました。
→この案の場合、マップ内の何番目のマスで何が起こるのかをコモンイベントで一括管理できますが、例えばマップに宝箱グラフィックを置いても、番号とずれると挙動が合ってないという事象が発生する事には留意する必要があります。

●イベントが起こらないマスもある。
→前述の案の場合、単にイベントを設定しなければいいだけなので、仕様として何かをする事はないです。

●ゴールでは必ず止まる(今回は、余分な出目の分だけ戻ったりしない)。
→今回は、リージョンで進行方向を管理する事にしましたが、リージョンで必ず止まるマスも表現する事にします。
→つまり、リージョンとして、上下左右+停止の5個を使うという事です。

●ゴールに来たら、次のマップに移動する。
●止まったマスのイベントには、戦闘も含まれる。
●止まったマスのイベントには、宝箱などのアイテム入手も含まれる。
●基本的に、買い物も止まったマスでしか出来ない事にする。
→ここら辺のモノは、止まったマスのイベントとして、それぞれのイベントを起こすだけです。

●イベントによっては、次に移動する歩数が決まる。
→これは、ちょっと仕掛けをしておく必要があります。……と言っても、フラグとして、変数を用意するだけですが。
移動歩数変数を用意して、ゼロ以下であればサイコロを振る、1以上であれば、その歩数分だけ移動する……という事にします。

●歩数の決定は、アイテム使用でも可能とする。
→前述した移動歩数変数をアイテムを使用する事で変更するコモンイベントを用意すれば、実現できそうです。

●今回は、必ず止まるマスはゴールのみとする。
●ルート分岐する時は、マップを切り替える事とする。
→これは、実は後付けした、仕様を簡略化するための要件なので、実装時に、そのように作るだけです。

●今回は、戻る移動を使用しない事とする。
→これも後付け要件ですが、前述の移動歩数変数の仕組みから考えると、後でこれを追加実装するのは大変そうです。


というわけで、「設計」は、こんな事をしました。

文章ばかりな上に、ツクール上の作業に入っていないので、地味に見えるかもしれません。
頭で考えている内容をここまで書き出す事はないかもしれませんが、だいたい、こんな事を考えて作っていますよ……という一例として受け取ってもらえれば幸いです。

※なんか、当初の意図からずれて、IT業界の開発工程をツクールで説明する内容になってしまってますが、せっかくなので、開発工程っぽく続けたいと思います。

それでは~。

コメント
この記事をはてなブックマークに追加

すごろくシステムを作ってみた【1】要件定義編

2017-06-16 22:33:16 | RPGツクールMV

さてみなさん。

ご無沙汰しております。

今回は、作成中のうちのゲームで作った「すごろくシステム」をsample的に紹介してみます。
(すごろくシステムが出来た所でゲーム作成は停滞してますが……)

もっとスマートでエレガントな方法があるかもしれません。
あくまで、うちが作った物の紹介です。


▼はじめに

そもそも、「すごろく」にしようと思ったのは、神託を受けたから(夢で見たから)なんですが、ちょっと考えてみた所、……サイコロを振ってるだけで自動的にマルチシナリオっぽくなるのではないか?……という安直な事を考えたからです。

たぶん、シナリオの文章量は、うちがいつも普通に作ってるより増えるような気がしますが……。
(いつも、たいしてシナリオを書いてない)

 


▼要件定義

まず、「すごろくシステム」に必要な要件を考えました。

●すごろくになるのは、ダンジョン部分とする。
●すごろくマップでは、プレイヤーは自由に動けない。
●プレイヤーが動くためにはサイコロを振る必要がある。
●サイコロを振ったら、その出目の分だけ移動する。
●移動して止まったマスでイベントが起こる。
●イベントが起こらないマスもある。
●ゴールでは必ず止まる(今回は、余分な出目の分だけ戻ったりしない)。
●ゴールに来たら、次のマップに移動する。

こんな感じです。
割と、すごろくの仕様をそのまま書いただけですね。
それから、以下のような要件も追加していきました。

●止まったマスのイベントには、戦闘も含まれる。
●止まったマスのイベントには、宝箱などのアイテム入手も含まれる。
●基本的に、買い物も止まったマスでしか出来ない事にする。
●イベントによっては、次に移動する歩数が決まる。
●歩数の決定は、アイテム使用でも可能とする。
●今回は、必ず止まるマスはゴールのみとする。
●ルート分岐する時は、マップを切り替える事とする。
●今回は、戻る移動を使用しない事とする。


やり方は人それぞれあると思いますが、うちは、こんな感じで、箇条書きで要件を出しています。

あと、これも人それぞれあると思いますが、「はじめに」っていう項目を重要視しています。
「はじめに」には、主に目的や方針といった「なぜそれをやるのか」という事を書きます。
これがぶれると、後々、全部やり直しになったりします。
なので、きちんと書いておきましょう。

といった所で、案外長くなったので、今回はここまでです。
それでは~。

コメント
この記事をはてなブックマークに追加