1. まずはプロトタイプから
RPGツクール本来の動作から外れた開発を試みて断念した後、しばらくは他のジャンルのゲームを作ることを考えたり、制作ツールを変えることを考えたりしていました。
最終的に残ったアイデアは、「『ドラゴンボール 大魔王復活』(1980年代のファミコンのソフト)みたいにカードの数字で戦ったりマップを移動できるゲーム」というものでした。ただし、開発規模を抑えるために以下のように要素を絞り込みました。
- マップは1本道で20マスくらい
- カードは数字とスキルが書いてある(敵に2ダメージ、自分のHPを3回復、など)
- 手札は5枚、デッキは最大20枚(たとえ1歩ずつでも20マスに届くように)
そして一番重要な点として「開発はテキスト中心のプロトタイプから始める」ということを事前に決めていました。開発の初期段階から色々な要素を盛り込んで大変なことになったので、今回は小さく始めることを意識しました。
プロトタイプのUIはテキストボックスとリストボックスとボタンだけなので、統合開発環境としては起動が速いGodot Engineのエディターで実装しました。
2. さらに要素を絞り込む
プロトタイプのカードの効果を検討しているうちに、当初のアイデアのコア要素ともいえる「カードの数字で移動」をやめて、バトルに絞った方が良いのではないかと考えるようになりました。
カジュアルに遊べるように一本道のマップとしたのですが、ゴールまでの進み方にバリエーションが無いなら1枚のカードを移動とバトルで取り合うことにあまり意味を感じられず、結局は移動もマップも無くしてバトルに集中することにしました。
 |
| 最終的なプロトタイプ。 起動直後にバトルが始まる |
プロトタイプの時点ではハイスコア機能も入っていたのですが、カジュアルに遊べる代わりに運要素も大きいゲームには馴染まないので、外しました。
3. カードもナーフする
プロトタイプの主な目的は、ゲームの全体の流れをテキストで確認することでしたが、最も重要な目的の1つが、カードの効果の検証でした。カードを使ってHPを増やしたり減らしたりするのは、テキストベースのプログラムでも確認できるからです。本格的に画像や効果音を付ける前に、このままカードを実装しても問題ないか確認することが重要でした。
今回制作したゲームはドロー効果のカードが多いので、常に大量ドローが発生した場合のことを考える必要がありました。その結果として、例えば以下のようなナーフが発生しました。
- トラッシュからカードを1枚選んで手札に加える →トラッシュから「武器」1枚を選んで手札に加える。
- HPを40回復(レア：枚数制限なし)→HPを「20」回復(レジェンド：デッキに1枚まで)
 |
| ナーフされたカードの例 |
4. ついに正式なUIの開発を開始
プロトタイプを何度も遊んでみて、繰り返し遊んで面白いと感じたので、ようやくビジュアル面を含めた正式な開発を始めました。
GodotでUIを作成する基本的な手順は、過去に3マッチパズルを開発した時に経験済みなので、あとは問題に衝突する度に公式ドキュメントやフォーラムのやりとりを見て学んで、修正する日々の連続でした。(GodotのAPIやコンポーネントの話は、また別の機会に書きます)
 |
| 画面に配置するパーツを作成 |
5. カードUIをどう実現するか
カードが画面内を移動したりプレイヤーに操作させる機能は、さすがに自作するのは大変なので、Godotプラグインを使うことにしました。以下のプラグインが候補に挙がりました。
Card Framework
https://github.com/chun92/card-framework
APIとドキュメントが整備されているカードUIフレームワークです。サンプル実装のフリーセルがあります。カードの情報をJSONに記述するので、他のソフトでカード情報を編集しやすいです。
Simple Cards
https://github.com/twdoor/simple-cards-v-2
カードゲームにありそうな要素を抑えつつ最低限の機能が実装されているライブラリです。
サンプル実装のソリティアがあります。全体的にドキュメントがやや不足しています。
Simple CardPileUI
https://github.com/insideout-andrew/simple-card-pile-ui
手札/デッキ/捨て札などのカードパイルの基本的な機能を提供するライブラリです。JSONに記述されたカード情報を読み込みます。手札のカードで敵と戦うサンプルがあります。
今回制作するゲームに対し、Card Frameworkは明らかにオーバースペックで、Simple CardPileUIはカードパイル以外の機能が不足していたため、Simple Cardsを採用しました。
6. 画像と音声
ゲーム内の画像はゲームの雰囲気に合わせて、 opengameart.org で公開されているドット絵を置く予定でした。しかし、ゲームの内容のシンプルさを考えると線画の方が合っていると思うようになり、ベクター画像エディタのInkscapeで自作することにしました。
ここでInkscapeを選択したおかげで、異なる媒体ごとに異なるサイズの画像が必要になった時に、過去に作った画像素材をパーツとして組み込むのが前より楽になりました。
 |
| Inkscapeで全てのカードの画像を作って管理 |
音声は有名な素材サイトをいくつか調べて回り、BGMやサウンドを組み合わせて使っていました。しかし、動作テストで何度も聞いているうちに、素材サイトによって音声のボリュームの基準に微妙な違いがあることが気になってきました。
当初は音声エディタのocenaudioを使ってゲインを調整したこともあったのですが、全ての音声ファイルをこのやり方で対応していくのは現実的ではないと判断し、今回は OtoLogic の素材で統一しました。
7. ひたすら動作テストと修正
一番地味で長く大変な工程です。いろんな問題がありましたが、特に心が動かされたものを上げます。
・手札のカードにマウスカーソルを近付けると手前に表示されるが、その状態でカードの右半分の領域を操作すると、右隣のカードの方が反応してしまう。(z-indexで見かけ上の表示順だけを変更した場合に起こる問題。Godotのビジュアルツリー内の順序も調整して解決した)
・カードをグリッド状に並べた画面をスマホでスクロールしようとすると、たまたま指で触ったカードが選択状態になってしまう。(Godotのスマホ対応でよくある問題らしい。スクロールした場合は選択しないように座標をチェックすることで解決した)
・画面の外側が半透明に暗くなるタイプのダイアログがあり、スマホで暗い部分をタッチしてみたら貫通して操作できた。(入力デバイスを「押した」タイミングに反応する仕組みだったのが原因。マウスボタンを離したりスマホから指を離したタイミングで反応するように修正した)
・Godot Playerでゲームを表示すると画面右上に「ゲームを閉じるボタン」が表示されるが、ゲーム本体の「画面を閉じるボタン」と位置が近いことが判明した。(事前確認が足りていなかった。今回は画面を閉じるボタンを下に伸ばして対応した)
8. 初めての公開は1度きりなので、その前に
普段のミニゲームの制作であれば、ある程度作ったところで公開して、暇な時にSNSでも報告して、となるところですが、今回は趣味とはいえそれなりの経緯があるので、以下の対応を行いました。
・Godot Playerに掲載する紹介文をよく考えて書く(初見で読まれなくても、何かあった時に一番最初に読まれる文章なので)
・SNS向けの紹介文と紹介動画を作成する(投稿してすぐに誰かが見るというよりも、誰かに紹介する時に見せる短い紹介ページとして便利)
・Google Sitesにマニュアルを非公開モードで用意する(人間が読むというよりは、ゲーム内の名称や用語をゲーム外からテキスト検索できるようにするための対応)
9. ついに公開
公開先は以前に3マッチパズルを投稿した Godot Player と決めていました。
いつの間にか機能が増えて、新着リストに載る前の状態で下書きアップロードが可能になったので(実は前からあった？)、正式に公開する前に色々な動作テストができて助かりました。
最後にGodot Playerでゲームを公開して、マニュアルを公開し、SNSに紹介文と紹介動画を投稿して、改めて自分でもゲームを遊んでみて、ようやく完了です。
趣味のゲームの公開が上手くいくか心配になりすぎて胸が痛くなったのは、今回が初めてでした。無事に公開できてホッとしました。
0 件のコメント:
コメントを投稿