ビルド・アンド・スクラップ

久しぶりの更新です。
作っていたものは、そこそこ完成間近でなんか飽きて放置してます。
RPGをやっていてラスボス直前で飽きる現象に似ていますね。

今回の記事では、こうして前作がエターナった原因分析と対策として考えたことを垂れ流しつつ、今後の展望について語ります。
斃れた冒険者は、倒れた時のレベルのまま、半額のゴールドと、拾ったままのアイテムを持って再びダンジョンに向かうのです。


さて、分析と対策です。

仕様

仕様の絞り込みの不十分さが一番大きい原因だったと思います。
そもそも一作目なのでスモールスタートにしようという頭はあったのですが、"試しに作ってみた1分で遊べるゲーム"的なものを見かけて、まだまだ大きすぎたと思いました。

特にその点が顕著なのが、モンスターのバリエーションやアイテムの種類、またマップの広さでした。
戦闘や成長のバランスなど、触っているうちに色々試してみたくなって手を出したのですが。やりすぎでした。

もっとコア部分だけに絞って削るべきでしょう。
コアとは何か。私のゲームの場合、それは他ならぬおしっこ我慢シミュレーターでしょう。
自分の作ったゲーム音楽を使いたくて東方を作ったZUN氏や、自分の作った人工言語を使いたくて指輪物語を書いたトールキンのように、私もおしっこ我慢シミュレーターを使いたくてゲームを作るのが良いのでしょう。

そう考えると、マップの広さは切り捨てることが出来ません。トイレまで行くのに時間がかかる。トイレに戻りたいのに、帰り道が分からないといった焦燥がゲームの楽しみの一つのコアだからです。
しかし改善すべき点が無いわけではありません。前作では、サクサク探索する楽しみを実現しようと、歩行速度をかなり速めに設定していました。そのため、いわば"マップの消費が速い"状況が生まれてしまいました。マップ内のコンテンツ量が多い必要はありませんが、マップ自体の量は多くならざるを得ません。コンテンツは開発者が創意工夫をしてゲームが面白くなるように作る必要がありますが、マップ自体は道順およびアートワークとして破綻しない範囲で単純作業で作ることができます。私はマップを操作するためのツールを作りましたが、あのような非合理な作業を強いられたのは、今から思い返せば仕様の甘さからの予定調和でした。
また、更に言えばマップを細かく分けずに、広大な一枚マップにしてしまったのも、マップの再利用性を下げる選択でした。あれはあれで面白いと今でも思っていますが、やはり初回では切り捨てるべき要素でした。

次回作

そこで次の作品は、以下のようにします

• アイテム　：　初期装備の他に装備品を1、2程度
• 敵　：　ダンジョン一つ分程度のバリエーション
• 歩行速度　：　通常程度
• マップ　：　比較的小さいマップを繋ぎ合わせる。適宜テンプレートとなるマップを作る

チュートリアルイベントのようなものだけが遊べるゲームとし、イベントによて最初からある程度おしっこが溜まっている状態から始めようと思います。

プラットフォーム

次に選んだツールの問題です。
ウディタはコードを描くことができず、基本的にプルダウンなどのGUIで処理を入力する必要があるため、ある程度複雑な処理を書こうとすると、生産性が良くありません。
RPG作りの概念を学ぶ入門としては良かったのですが、ゲームシステム面を重視する今作に適した選択ではありませんでした。
そういう意味では、スクラップ・アンド・ビルドはいずれ必要でした。

次回作

RPGツクールVX Aceを入れました。Rubyが書けます。個人的にはJavaの次に使い慣れていて、C#の次に好きな言語です。
とりあえずオブジェクト指向的に書きやすいので、大抵のことはどうにでもなるでしょう。

モジュール分割

これも慣れないプラットフォームで手探りで実装を進めたせいという点もあるのですが、それにしても今回の設計はあまりに場当たり的で酷いものでした。

次回作

おしっこ我慢シミュレーターは今後も何かにつけて書く可能性があるので、メモ書き程度の汎用的なドキュメントを作成すべきでしょう。後で上げます。



まあ、こんなとこです。
しばらく止まってたこのブログですが、また動きますよ。