進捗報告

体験版を配布して感想をもらってからずっと、あーどうしようかなーと悩み続けてたんですが、ようやくアイデアが形になりつつあるので進捗として報告しようと思います。
最初に言うと、体験版とはほぼ別ゲーになりそうです。

・拠点とステージ制の導入
→ローグライクとRPGを同じライン上で並列して行うのはどう考えても無理だったので、結局拠点を導入しました。
不思議のダンジョンみたいな感じで、色々なダンジョン（世界）をクリアしていくステージクリア式のスタイルになります。これにより世界ごとに違った色を出せるので、単調さも多少は解消されるかなと思います。

・街マップ縮小
→街が広すぎるという意見をいただいたので、かなり縮小しました。さらにステージ制の導入にともなって、世界に街を配置する確率も引き下げたのでテンポ改善できそうです。ランダムマップやダンジョンも右に同じです。

・キャラシステムを大幅変更
→装備の概念をなくしてキャラ管理を単純化しました。さらに仲間の加入は敵を倒したときに人間に転生するという（やや苦しい）システムに変更。職業の数を60ほどまで増やし、さらにレアリティの概念も付け加えました。キャラによって能力値や能力の伸び方、持っているスキル・特技が異なるので、レア職業集めとかキャラ育成も楽しめる設計…になるといいなぁと思います。ここらへんはいわゆるスマホゲーを見習って（略）

以下は箇条書きで
・夜間の視界制限導入
・街でのクエスト・特技屋・鍛冶屋廃止
・名声を廃止、人間を殺した場合は悪評状態へ（複数フロア経過で回復）
・ダンジョン宝箱の開錠率を廃止

ということで、かさみ過ぎていたシステム類をばっさり切って、かなり機能的に変更しました。
全体的に考えることが減って遊びやすいバランスになるんじゃないかと思います。
もっとも、システム入れ替えしているせいでまだ完成のメドは立ちませんが…。

ウディタ雑記TOPページ

ウディタ雑記も数が増えてきたので記事をまとめておきます。
ほとんどそのとき思いついたことを書き散らした文章の塊ですが、何かのお役に立てればと思います。

・中級者シリーズ
その1～ビット積～
その2～疑似並列実行イベント～
その3～文字列の有効活用～
その4～ピクチャの慣性移動～
その5～タイトル画面でのキーコンフィグ～
その6～乱数のシード値を使う～
その7～ロード時のみ起動するイベント～
その8～デバッグ技術～

・その他
トランジションについて
船の移動処理について
変数をうまく使おう
ウディタの処理軽減について
ウディタ製ローグライクゲームの紹介
地形生成コモン（自作）の宣伝
ピクチャの表示形式について
ゲームファイル作成の際の注意
名前の自動生成
本気の戦闘AIづくりの話
マッピングの話

ウディタ中級者になるためのその8 ～デバッグ技術～

デバッグ技術について書いてなかったので、さらっと書いておこうと思います。
といっても、バグを発見する方法じゃなくて手早くバグの原因を特定する方法についてですけども。
自分のゲームはだいたいいつもバグだらけなので、バグを発見する方法があったら逆に教えてほしいです（たくさんテストプレイするしかないんだろな～）

とりあえず基本のところ。
F7…表示中の全ピクチャの情報を閲覧できます。ピクチャを最後に動かしたイベントとかも確認できるので便利。
F8…メモリに読み込んだピクチャやサウンドの情報、表示中のピクチャＩＤや実行中のイベントを確認できます。
F9…通常変数およびシステム変数を全表示できます。自分はあまり通常変数使わないので恩恵にあずかれないんですが。

以上のように、デフォでピクチャや通常変数あたりは閲覧できるようになっているので、そのあたりは問題なし。
ただゲームが複雑になると絶対可変データベースの中身を見たい！という状況に陥ると思うので、そんなときはウディタ公式にアップされているデバッグコモンを導入することをおすすめします。
（ちなみに自分はsuさんの製作された「Check it」というコモンを使ってます。並列実行のイベントを組んで、キーひとつでデバッグコモンを呼び出せるようにしておくと便利ではないかと思います）

で、これらの手段を駆使してもまだ原因不明なときがあります。
コモンが大量になってくると、コモンの構造も複雑になって「どこでバグが出ているのか分からない」という状況に陥ります。
こういうときは絡んだ糸をほぐすように、コモンの流れをたどって、イベントコマンドにデバッグコモンを挿んで逐一数値をチェックするようにしましょう。
「ここまではOK」「ここもOK」「ここで数値がおかしくなってる！」という部分が必ずあるはずです。

さらに、ピクチャ関連のバグがある場合について。
ピクチャの情報はデバッグコモンではなくF7、F8あたりを使って確認することになります。しかし、これらのコマンドはコモンイベントの中に挿むことができず、思ったような位置でピクチャ情報を確認することができません。
ということで、特定の場所でイベントの実行を一時停止させたいときはループを使いましょう。
コマンドはこんな感じ↓ですね。

| |■ループ開始
| | |■ウェイト：1 フレーム
| | |■
| |◇ループここまで◇◇

このコマンドを挟むだけで、イベントの処理がそこで一時停止されてF7やF8を操作することができます。もちろんウェイトを挿んでいるので50万エラーが出ることもありません。

というように、上記のような技術（というほどでもないけど）を駆使することによりほとんどのバグは潰すことができると思います。
ただ、自分が思うにデバッグで一番大事なのは、いかにバグを見つけて潰すかではなくて、いかにバグを出さないかです。
もちろん人間なのでバグを出さないのは不可能なんですが、プログラムを組む時点でバグが出にくいように組んでおくのはとても大切なことです。デバッグ作業にかける労力が段違いです。

ではバグの出やすい構造とは何かという話ですが。

・常時並列実行は極力使わない
→他の記事でも書いてきましたが、並列実行イベントは発生するタイミングが難しく、特にこの中でいろいろな変数をやり取りしていたりすると、バグの特定が難しいうえに修正も難しいです。ウディタに慣れないうちは、常時並列実行イベントをいくつも組むのは控えた方が賢明だと思います。

・マップイベントを使わない
→これは個人の感覚かもしれませんが、マップイベントとコモンイベントが同時に動いて変数をやり取りしていたりすると、原因が特定しづらくなります。内容が複雑になるマップイベントは極力コモンイベントで処理した方がいい気がします。

・ディレイ系を使うときは慎重に
→ピクチャの表示・消去ディレイやサウンドのディレイ、自動キー入力あたりはバグの温床です。特にピクチャのディレイリセットを忘れたがために、本来表示されるはずのピクチャが表示されないみたいなバグはよくあります。
ディレイ系は原因が特定しづらいこともあるので、使うときは慎重になりましょう。

・コモンを細分化する
→いろんなコモンの中でよく使う処理は、専用のコモンを作ってコモンの役割を細分化しましょう。
イベントコマンドが長くなれば、その分だけバグも出やすくなるしデバッグも大変になります。また、コモンを細分化することによってプログラム全体の構造も分かりやすくなります。

ピクチャの表示形式による違い

ピクチャの表示形式には通常、加算、減算、乗算があります。ウディタ初めたての頃は何がなんだかよく分からなかったんですが、最近ようやく使いこなせるようになったので記事を書いてみました。

最初に文章で軽く説明。
・通常…下の色合いを無視して上に色を重ねる。
・加算…下の色合いにＲＧＢを加算する。ので、白っぽくなる。
・減算…下の色合いからＲＧＢを減算する。ので、黒っぽくなる。
・乗算…よくわからぬ（）

では、夜と視界の表現を例にしてみます。
まず「通常」

640×480サイズの「SQUARE」を表示形式「通常」で展開したうえに「ＣＩＲＣＬＥ」を加算表示して視界を表現しています。
が、全体的にかすんだような感じになってしまって見づらいですね。
ちなみに「SQUARE」のRGBは20、20、30、不透明度は150です。

次に「減算」

640×480サイズの「SQUARE」を表示形式「減算」で展開したうえに「ＣＩＲＣＬＥ」を加算表示して視界を表現しています。
けっこうそれっぽい感じですね。この色合い、「巡り廻る。」の夜の色合いと似てます。あれもウディタ作品なので、おそらく減算で夜を表現しているんじゃないかと思います。
今回視界を加算表示でつくることになった関係で、ワールドフロンティアの夜表現はこの減算表示を使うことになりました。

最後に「乗算」

640×480サイズの「SQUARE」を表示形式「乗算」で展開したうえに「ＣＩＲＣＬＥ」を加算表示して視界を表現しています。
減算よりも落ち着いた感じになってますね。ワールドフロンティア体験版での夜の表現はこの乗算を使っていました。
乗算は色調やフォグが場になじむので、比較的使いやすい表示形式じゃないかと思います。

まとめ。
・「通常」はフォグや色調表現には向かない。メニューやユーザインタフェースの表示に。
・「加算」は白くなる。減算表示したピクチャの上に加算表示を重ねるといい感じ。
・「減算」は暗くなる。やや癖のある色調かも。
・「乗算」は周りの色となじんで自然な色合いになる。フォグには乗算が最適。

番外編。

前作の視界表現では二枚のピクチャを組み合わせることはせず、中央が丸く透過されたこんな画像↓を使ってました。

てっとり早く視界を表現するならこういうのを使った方が簡単のような気もします。

※結局、ワールドフロンティアにも視界の概念を取り入れることになりました。処理速度的にはそれほど問題なさそうです。

名前の自動生成

前にどこかのブログの記事で読んだ記憶があるんですが、名前の自動生成にチャレンジしてみました。
とりあえず男の名前と女の名前、および地名です。

まず男性。


女性。


地名。


いまいちな感じもするけど、まぁこんなもんかな。

やり方は以下の通り。
実際の名前データを名前辞典から引っ張ってくる
↓
一文字ずつ、その文字がどの文字の後ろにあるかを解析してデータベース入力
↓
つながりが多かった文字の組み合わせのみを抽出（「ア→ル」、「ア→ー」など）
↓
一文字ずつ名前を組んでいく
さっき抽出した組み合わせの中からランダムに次の文字を決定

やり方はかなり雑でしたが、「ニコライ」「クリス」「ニューブリック」みたいな自然な文字の流れをある程度は組むことができそうです。
今回は二文字のつながりのみ考慮しましたが、本気でやるんだったら三文字の流れの考慮とか、確率とかを使うことになるんでしょうねぇ。めちゃくちゃ面倒くさそうだったので手は出しませんでしたが。

ちなみに解析したのは男性と女性の名前が英語、ドイツ語、フランス語の名前をそれぞれ2000ほど、地名は各国の都市の名前を500ほどでした。
生成された名前を眺めているとなんとなく名残が分かりますね。
「リヒ」のつながりはドイツ語だし「ーヌ」のつながりはフランス語だし。
もっと素材があれば「ギリシャっぽい名前」とかいろいろなことができそうです。

しかしカタカナの名前はどうつなげてもある程度は自然に聞こえるからいいですね。日本人の名前の自動生成は難易度がとても高そうです。