SRPG Studioでのゲーム制作を始めてから、少しずつではあるが、できることが増えてきた。

①②では、マップやイベントの基本的な制作方法から、敵ユニットの行動や武器の使用条件など、ゲームの土台となる機能について学んできた。今回はさらに踏み込み、キャラクターの成長管理やクラスチェンジの細かな設定、能力値の調整、複数のユニットに対するイベント処理など、ゲーム全体の完成度に関わる部分について記録しておきたい。

1. クラスチェンジの条件と仕組みを細かく設定する

最近、特に理解が深まったのがクラスチェンジ周りの仕組みだ。

最初は、クラスチェンジアイテムを使えば対象キャラクターが別のクラスに変わる、という程度の認識だった。しかし、実際に設定してみると、クラスグループや変更可能なクラスの指定、レベル条件など、複数の設定が関係していることが分かった。

 

例えば、主人公はイベントによってのみクラスチェンジできるようにし、村人など一部のキャラクターは専用アイテムを使用した場合だけクラスチェンジできるようにする、といった区別も可能になった。

 

また、クラスチェンジ後に以前の武器が残ってしまう問題にも直面した。そこで、変更後のクラスを判定するイベントを用意し、不要な武器を取り除いて新しいクラスに合った武器を持たせる方法を試した。こうした設定を通じて、単にクラスを変更するだけでなく、キャラクターごとに異なる成長ルートや転職条件を設計できることが分かってきた。

2. クラスごとの能力補正とキャラクターの能力値を管理する

能力値の調整についても、制作を進める中で新たな発見があった。

例えば、クラスにパラメータボーナスを設定すると、そのクラスに属する味方だけでなく敵にも影響する。味方だけを強化したつもりが、同じクラスの敵まで強くなってしまうことがあった。

 

この問題をきっかけに、クラス全体に適用する能力補正と、特定のキャラクターだけに適用する能力変更は分けて考える必要があることを学んだ。また、コンフィグで設定するパラメータ上限と、クラス側で設定するパラメータ上限など、能力値に関係する設定にも複数の仕組みがある。

 

こうした部分は、設定画面を見ただけでは分かりにくい。実際にレベルアップさせたり、能力値を変更したりして、どの設定がどこまで反映されるのかを確認する必要がある。キャラクターの成長はSRPGの面白さに直結する部分なので、味方と敵の強さを意図したとおりに管理できるよう、引き続き理解を深めていきたい。

3. 戦闘時のモーションやクラスの表現を調整する

ゲームの見た目についても、細かな部分が気になり始めた。

例えば、村人のようなクラスに弓を持たせても、戦闘時の攻撃モーションが弓兵のものにならず、石を投げるような動作になってしまうことがあった。調べていくと、武器だけでなくクラス側の戦闘モーションも関係していることが分かった。

実際に弓兵のモーションを設定して確認すると、弓を使った攻撃動作に変わった。

 

キャラクターのグラフィックや装備品だけでなく、戦闘時にどのような動きをするのかもクラスの設定に左右される。こうした細かな違いが、ゲーム全体の印象を大きく左右するのだと思う。今後、独自のクラスや装備を増やしていく場合にも、能力だけでなく見た目や動作まで含めて考える必要がありそうだ。

4. 複数のユニットを対象にしたイベント処理

イベントについても、以前より複雑な仕掛けを考えるようになった。

例えば、マップ上の特定の場所を調べると、敵全体が弱体化したり、場合によっては消滅したりするような仕掛けだ。

これを実現するために調べていたところ、複数のユニットを対象にまとめて処理する方法があることを知った。

今まではイベントで特定のキャラクターを指定して処理することが中心だったが、対象を敵軍全体にすることで、個々の敵を一体ずつ指定しなくても同じ処理を実行できる。

 

こうした機能を使えば、特定の装置を調べると敵全体に状態異常を付与する、能力を低下させる、あるいは何らかの特殊効果を発生させるといった演出も考えられる。まだ実現方法を検証している部分もあるが、イベントの組み合わせ次第で、通常の戦闘とは違った攻略方法を用意できそうだ。

5. テストプレイを通じてゲームバランスを調整する

現在は全体のうち、マップ制作を7割あたりまで進めている。

マップの大まかな構成や敵の配置ができてくると、次に重要になるのが実際の戦闘バランスだ。

最初から細かな能力値を決め込むのではなく、まずは仮の数値を設定してテストプレイを行い、敵の強さや戦闘にかかるターン数、味方の成長具合などを確認している。

 

実際にプレイしてみると、想定より敵が弱かったり、逆に特定の敵だけが強すぎたりすることもある。数字だけを見ていても分からない部分が、プレイすることで見えてくる。また、マップの広さや地形によっても難易度は変わる。敵の能力が同じでも、地形や配置が違えば戦闘の印象は大きく変わるため、単純に敵の能力値だけで難易度を調整するわけにはいかない。

 

最近はマップごとに特徴を持たせることも意識している。とあるマップでは防衛マップを想定し、20×20という比較的大きなマップに、海上を移動できる敵を配置した。通常の平地マップとは異なる攻略が必要になるように工夫している。

完成したマップを実際に遊び、想定した難易度や攻略の面白さになっているかを確認する。こうした作業を繰り返すことが、ゲームとしての完成度を高めるために欠かせないのだと思う。

6. SRPG Studioでゲームを作る楽しさと難しさ

ここまで制作を進めてきて、改めて感じるのは、ゲームを作ることは想像以上に楽しく、そして難しいということだ。

頭の中で考えていた仕組みが、実際にゲームの中で動いたときの達成感は大きい。キャラクターがクラスチェンジしたり、特殊なイベントが発生したり、敵の配置によって戦況が変わったりする。少しずつではあるが、自分が遊びたいと思えるゲームの形が見えてきた。

 

一方で、何か一つの設定を変更すると、思いもよらない部分に影響が出ることもある。味方を強くしたつもりが敵まで強くなっていたり、イベントの条件を一つ間違えただけで意図しない動作になったりする。

ゲーム制作は、単純に機能を覚えて設定すれば終わりというものではない。実際に動かし、問題を見つけ、修正し、また試す。その繰り返しだ。

 

それでも、最初は何も分からなかった状態から、少しずつ自分の考えた仕組みを実現できるようになってきたことは、大きな進歩だと思う。

 

何より、自分が昔から好きだったSRPGというジャンルのゲームを、今度は自分自身で作っているということが楽しい。まだ完成までは道のりがあるが、焦らず一つずつ形にしていきたい。

 

いつかすべてを遊び終えたとき、自分なりに納得できる一本のゲームになっていることを目指して、これからも制作を続けていこうと思う。

 

前回の記事では、SRPG Studioでゲームを制作しながら学んだイベント、クラスチェンジ、武器、ショップなどの基本的な機能についてまとめました。

今回はその続編として、前回の記事では取り上げられなかった機能や、実際に制作を進める中で悩んだ設定について振り返ってみたいと思います。

ゲームを作り始める前は、マップを作ってキャラクターを配置し、会話と戦闘を組み合わせればゲームになるのだろうと考えていました。しかし、実際に制作してみると、敵が思ったように動かない、武器の設定が戦闘に影響する、仲間を次のマップに引き継ぐにはどうするのかなど、細かい疑問が次々と出てきます。

そうした問題をAIに相談し、実際に設定を変更してテストプレイすることで、少しずつ仕組みを理解してきました。

1. 敵ユニットが移動しない原因を調べる

SRPG Studioで敵ユニットを配置した際、敵が思ったように移動してくれない問題に直面しました。

最初は移動範囲や行動パターンの設定を疑いましたが、調べていくと、武器の使用条件が関係していることが分かりました。

実際に、敵が装備している武器をそのキャラクターのクラスでは使用できない設定にしたところ、敵が移動しなくなりました。

この経験から、敵の行動は移動力やAIの設定だけで決まるのではなく、装備している武器を使用できるかどうかも確認する必要があると学びました。

敵ユニットの動きがおかしいときは、ひとつの設定だけを見るのではなく、クラス、武器、行動条件などを組み合わせて確認することが大切です。

2. 武器の使用条件を利用してクラスの個性を作る

前述の問題を調べる過程で、武器をキャラクター専用にする設定についても学びました。

例えば、剣士には剣、戦士には斧、騎士には槍を使わせたい場合、単にそれぞれのキャラクターに武器を持たせるだけではなく、クラス側で使用可能な武器を設定する方法があります。

これによって、クラスごとの役割を明確にできます。

ただし、武器を使用できない設定にした場合、敵の行動にも影響が出ることがありました。武器の使用制限は、装備品を制限するだけでなく、敵の行動設計にも関係する重要な設定だと感じました。

3. 敵ユニットの行動と戦闘バランス

敵ユニットを配置する際には、単純に強い敵を置けばよいわけではありません。

敵が移動して攻撃するのか、その場にとどまって遠距離攻撃をするのかによって、プレイヤーが考える戦術は大きく変わります。

最初のマップでは、スライムやバットのように接近してくる敵と、遠距離攻撃を行うスケルトンを組み合わせる構想を立てました。

このような敵の配置を考えるとき、攻撃力やHPだけでなく、移動する敵と動かない敵の役割を分けることが、戦闘に変化を生み出すうえで重要だと分かります。

敵の行動をテストしながら調整する作業は、プレイヤーがどのような戦術を取るかを考える作業でもあります。

4. 再攻撃の設定と戦闘バランス

SRPGでは、素早さなどの能力値によって、1回の戦闘で2回攻撃できる仕組みがあります。

SRPG Studioでも、再攻撃に関する設定を確認しました。

再攻撃が発生する条件や、攻撃速度の差に関する設定を調整することで、戦闘のバランスを変えられます。

例えば、素早い剣士は2回攻撃を狙いやすく、重い武器を扱う戦士は一撃の威力を重視する、といった個性を作ることができます。

ただし、再攻撃の条件を厳しくするか、緩くするかによって、キャラクター間の強さの差は大きく変わります。

今後、実際にゲームを遊びながら、敵味方の能力値や武器の重さなどを調整していきたいと思います。

5. 仲間の加入と所属変更

ゲーム制作では、新しい仲間が登場する場面も重要です。

例えば、物語の途中で出会った人物が主人公の仲間になる場合、敵やNPCとして登場していたユニットを味方側に変更する仕組みが必要になります。

このとき、キャラクターそのものを新しく作り直すのではなく、ユニットの所属を変更する方法が使えます。

イベントの中で所属を変更すれば、戦闘中に登場したキャラクターが仲間になる演出などを作ることができます。

また、マップ上にキャラクターを登場させることと、そのキャラクターを味方として加入させることは別の処理です。

この違いを理解することで、会話イベント、戦闘中の加入、章の終了後に仲間になる展開など、さまざまな演出を考えられるようになりました。

6. 仲間を次のマップに引き継ぐ

仲間を加入させた後は、次の章でもそのキャラクターを使用できるようにする必要があります。

SRPG Studioでは、マップ上のユニット配置と、ゲーム内で使用するユニットデータを区別して考えることが重要です。

あるマップで仲間にしたキャラクターを次のマップでも登場させたい場合、次のマップでの配置や所属などを適切に設定しなければなりません。

この仕組みを理解していないと、仲間にしたはずのキャラクターが次の章に登場しなかったり、意図しない所属で登場したりする可能性があります。

ゲームを章ごとに構成する場合は、各マップで何を設定し、何を引き継ぐのかを整理しておくことが大切だと感じました。

7. 柵や障害物による通行制限

マップ制作では、地形や障害物の設定も重要です。

例えば、村の周囲に柵を設置したり、建物の壁を通行できないようにしたりすることで、マップの形状に意味を持たせられます。

SRPG Studioでは、マップチップの通行に関する設定を利用して、キャラクターが侵入できる場所とできない場所を制御できます。

これによって、敵の進行ルートを限定したり、プレイヤーが通るべき道を明確にしたりできます。

マップを見た目だけで作るのではなく、実際の移動ルールも含めて設計することが大切です。

特に、戦術シミュレーションRPGでは、1マス通れるかどうかが戦闘の結果を左右することもあります。地形は背景ではなく、ゲームシステムの一部なのだと実感しました。

8. 戦闘準備画面のコマンドを変更する

SRPG Studioでは、戦闘準備画面に表示されるコマンドについても設定を確認しました。

例えば、出撃前に情報を確認するためのコマンドがありますが、作品の世界観に合わせて表示名を変更したいと考えました。

私の制作中のゲームでは、情報収集の機能を利用して、章ごとの説明や物語に関する情報を伝えることも考えています。

そのため、単に標準のコマンドを使うだけでなく、プレイヤーにどのような名前で表示するか、どのタイミングで情報を見せるかも気になりました。

ただし、既存のコマンド名を変更することと、新しいコマンドを追加することは別の問題です。標準機能だけでどこまで変更できるかを確認し、必要であれば仕様を見直すことも考えています。

9. レベルアップと能力上昇の演出

キャラクターの能力値を変更するイベントを作る際、レベルアップ時のような演出も表示できないかと考えました。

例えば、クラスチェンジ後に力や守備を上昇させる場合、数値を変更するだけでなく、プレイヤーに能力が上がったことを分かりやすく伝えたいところです。

イベントの「パラメータ変更」を利用すれば、特定のキャラクターの能力値を増減できます。

しかし、能力値を変更する処理と、レベルアップ時の演出をそのまま再現することは別の問題です。

このような場面では、標準機能で可能なことと、演出として追加で工夫する必要があることを分けて考える必要があると学びました。

ゲームでは数値の変化だけでなく、それをプレイヤーにどう伝えるかも大切です。

10. イベントの順番と処理の組み立て

イベントを作る際には、ひとつひとつの処理だけでなく、実行する順番も重要になります。

例えば、キャラクターがクラスチェンジした後に武器を変更したい場合、クラスチェンジの処理が先に実行され、その後に装備の変更処理が実行される必要があります。

会話の後にアイテムを渡す場合も同じです。

このように、イベントはコマンドを並べるだけでなく、ゲーム内で何が起こり、その結果として次に何を実行するのかを考えて組み立てます。

複数の処理を組み合わせるほど、実行順序や条件の設定が重要になります。

イベントが思ったように動かないときには、設定内容だけでなく、処理の順番を確認することも大切だと感じています。

11. マップごとのイベントをどう管理するか

ゲームが長くなると、同じようなイベントを複数のマップに作る機会が増えてきます。

例えば、クラスチェンジ後に装備を変更する処理や、章の終了時に実行する処理などです。

同じ処理を各マップで作れば実現できる場合もありますが、後から変更するときには、すべてのイベントを修正しなければならない可能性があります。

そのため、イベントをどこまで共通化できるか、同じ処理を再利用できるかという点も気になりました。

まずは標準機能で確実に動作するものを作り、その後で管理しやすい構成に整理する。小さな作品であっても、後から修正することを考えて作るのが大切だと思います。

12. 背景や演出の変更

ゲームの印象を決めるのは、戦闘やシステムだけではありません。

イベント中に表示する背景や、場面転換の演出も、作品の雰囲気を作る重要な要素です。

制作中には、イベントの背景表示についても確認し、意図した画面になるように設定を調整しました。

特に、オープニングや会話イベントでは、背景が変わるだけでも場面の印象が大きく変わります。

物語を説明する文章だけでなく、背景やキャラクターの登場タイミングを組み合わせることで、プレイヤーに世界観を伝えやすくなると感じました。

13. 標準機能を優先して制作する

ここまでさまざまな機能を調べてきましたが、制作方針として意識していることがあります。

それは、できるだけSRPG Studioの標準機能を利用することです。

ゲーム制作に慣れていない段階から、複雑な追加機能や独自のプログラムに頼りすぎると、設定の管理や不具合への対応が難しくなる可能性があります。

そのため、まずは標準機能で実現できるかを調べ、必要に応じてイベントで代替する方法を考えています。

もちろん、標準機能だけでは難しいこともあります。その場合は、実現したいことを少し変更したり、別の方法を選んだりすることも大切です。

機能を増やすこと自体が目的ではなく、完成したゲームとして遊べるものを作ることが目標です。

14. AIとの相談で大切だと感じたこと

今回も、分からないことが出てくるたびにAIに相談してきました。

AIは設定方法の候補を整理したり、問題の原因を切り分けたりするうえで役立ちます。しかし、説明された方法が自分の環境で必ずそのまま動くとは限りません。

実際に操作してみると、設定項目の名前が違ったり、標準機能ですでに実現できていたり、想定とは違う動作をしたりすることもありました。

そこで、AIに質問し、設定を変更し、テストプレイで確かめ、結果をもとにもう一度相談するという流れを繰り返しています。

この作業を通じて、単に操作方法を覚えるだけでなく、ゲームの仕組みを自分なりに理解することが大切だと感じるようになりました。

おわりに

SRPG Studioでの制作を始めてから、敵の行動、武器の使用条件、仲間の加入、マップの通行制限、再攻撃、イベントの管理など、さまざまな機能について学んできました。

ひとつの問題を解決すると、今度は別の問題が見えてきます。最初は難しく感じたことも、実際に操作して確認すると、少しずつ理解できるようになります。

そして、機能を覚えることと同じくらい、何を標準機能に任せ、どこをイベントで制御するかを考えることも重要だと分かってきました。

まだまだ学ぶことはありますが、こうしてひとつずつ知識を積み重ねることが、完成したゲームにつながっていくのだと思います。

これからも、AIと相談しながら、実際に動作を確認し、自分のペースで制作を進めていきたいと思います。

1つ前の日記で書かせて頂いたように、SRPG Studio(Demo版)を使って、

現在初めてのシミュレーションRPG制作に挑戦しています。

 

Steam:SRPG Studio

 

これまでファイアーエムブレムなどのシミュレーションRPGを遊ぶことは好きでしたが、実際に自分でゲームを作るとなると、戦闘やキャラクターの設定だけでなく、イベント、マップ、アイテム、クラスチェンジなど、覚えることがたくさんあります。

そこで、制作中に分からないことが出てくるたびに、AIに相談しながら調べ、実際に操作して動作を確認してきました。

今回は、これまでに学んだSRPG Studioの機能や、制作を通じて気づいたことを整理してみたいと思います。

1. イベントの作成と実行条件

ゲーム制作で最初に重要になるのが、イベントの仕組みです。

SRPG Studioでは、キャラクターの会話やアイテムの入手、戦闘後の処理などをイベントとして設定できます。

イベントには、ゲーム開始時などに自動で実行するものや、特定の場所に移動したときに実行するものなど、用途に応じた種類があります。

例えば、ゲーム開始時に主人公と師匠の会話を表示したり、マップ上の特定の場所を訪問したときにイベントを発生させたりできます。

最初はイベントと聞いても漠然としていましたが、実際に作ってみることで、ゲーム内で起こる出来事を順番に組み立てる仕組みなのだと理解できました。

2. スイッチを使ったイベントの制御

イベントを作っていると、一度だけ実行したい処理が出てきます。

例えば、民家を訪問すると住人からアイテムをもらえるものの、何度も訪問してアイテムを入手できてしまうのは困ります。

こうした場合に役立つのがスイッチです。

イベントの最後にスイッチをONにし、そのスイッチの状態によって次のイベントを実行するかどうかを判定する、という考え方です。

また、訪問イベントでは、一般的な村のイベントを利用する方法もあります。標準機能を活用できれば、わざわざ複雑な仕組みを自分で作らずに済みます。

今回の制作を通じて、イベントを作るだけでなく、イベントが何回実行されるのか、どの条件で実行されるのかまで考える必要があると学びました。

3. マップ上の場所イベントとアイテム入手

マップ上の家や村などを訪問すると、住人との会話やアイテム入手が発生する仕組みも作れます。

例えば、主人公が赤い屋根の家の入口に移動した際に、住人から話しかけられ、アイテムを受け取るイベントです。

イベントの中では、会話を表示した後にアイテム入手の処理を実行するなど、複数の処理を順番に組み合わせられます。

ここで大切なのは、会話とアイテム入手を別々の処理として考えることです。

また、住人が主人公の仲間ではない場合、メッセージの話者として指定できるキャラクターが限られることもあります。その場合は、NPCの設定やメッセージの表示方法を確認する必要があります。

このように、ひとつのイベントを完成させるためにも、複数の機能を組み合わせることが大切だと分かりました。

4. クラスと武器の設定

SRPG Studioでは、キャラクターのクラスと武器を設定することで、戦闘の基本的な仕組みを作れます。

例えば、剣士には剣、戦士には斧、騎士には槍を持たせるといった設定です。

ただし、武器を所持させるだけでは十分ではありません。クラスがその武器を使用できる設定になっているか、実際に攻撃可能な状態になっているかも確認する必要があります。

敵ユニットが武器を持っているのに攻撃してこない場合も、クラスの武器使用設定や武器の条件などを確認することで、原因を切り分けられます。

ゲームを作る際には、武器を持たせることと、その武器を実際に使用できることを分けて考える必要があるのだと学びました。

5. クラスごとの戦闘アニメーション

今回、特に興味深かったのが、クラスと戦闘アニメーションの関係です。

敵として配置したシビリアンに弓を持たせたところ、実際の戦闘では弓を射るのではなく、石を投げるようなアニメーションが表示されました。

クラスや武器の設定画面では弓攻撃が設定されていたため、最初は原因が分かりませんでした。

そこで、弓兵のモーションに一時的に変更してテストしたところ、弓による攻撃が正しく表示されました。

この経験から、武器の設定と、画面に表示される戦闘アニメーションは、必ずしも同じ設定だけで決まるわけではないと分かりました。

シビリアンのような既存クラスには、そのクラス固有のモーションが用意されている場合があります。武器を弓に変更しただけでは、アニメーションまで自動的に弓兵と同じになるとは限りません。

今回は弓兵のモーションを使うことで対応しましたが、シビリアン本来の外見を維持したまま弓を使わせるには、専用のモーション素材を用意する方法も検討する必要があります。

また、アニメーションが石投げになっていることだけでは、弓の攻撃力が計算に反映されているかどうかは判断できません。実際に装備している武器と攻撃予測を確認することも重要です。

6. クラスチェンジと分岐転職

SRPG Studioでは、クラスチェンジ用のアイテムを設定し、転職先のクラスグループを指定することで、複数のクラスから転職先を選べる仕組みを作れます。

最初に設定した際、クラスチェンジ先が表示されずに悩みましたが、原因はアイテムの使用効果にある「変更可能なクラスグループ」の設定が不足していたことでした。

ここを設定すると、想定していたクラスチェンジができるようになりました。

分岐クラスチェンジでは、プレイヤーがどの能力を伸ばしたいかを考えながら転職先を選べることが重要です。そこで、標準のクラスチェンジ画面で能力上昇を確認できる仕組みを活用したいと考えています。

一方で、クラスのパラメータボーナスを設定したところ、同じクラスの敵ユニットにも影響することが分かりました。

味方と敵で同じクラスを使いながら、クラスチェンジの能力上昇だけを味方に適用したい場合には、設計上の工夫が必要です。

現時点では、味方のクラスチェンジ用クラスと敵用クラスを分ける方法や、イベントのパラメータ変更を利用する方法を検討しています。

ここは、画面上の分かりやすさと、敵ユニットの能力値を個別に管理することの両立が課題になっています。

7. クラスチェンジ後の武器の変更

クラスチェンジを実装して気づいたのが、転職前に所持していた武器が、そのまま転職後にも残ることです。

例えば、弓を持った村人が剣士に転職しても、弓が自動的に消えるとは限りません。

そこで、クラスチェンジ後にクラスを判定し、必要に応じて武器を変更するイベントを作りました。

剣士には剣、戦士には斧、騎士には槍を持たせるといった処理です。

このように、クラスチェンジそのものと、転職後の装備を整える処理は分けて考える必要があります。

今後、転職先が増えた場合に備えて、同じイベントを何度も作らずに済む方法も検討しています。

8. パラメータ変更と能力値の調整

キャラクターの能力値を変更する方法として、イベントの「パラメータ変更」も学びました。

クラス全体の設定を変更すると、同じクラスの敵ユニットにも影響が及ぶ場合があります。

一方、イベントで特定のユニットを指定して能力値を変更すれば、対象となるキャラクターに絞った調整ができます。

例えば、クラスチェンジ後に主人公の力を1、守備を1上げるといった処理です。

ただし、イベントが複数回実行されると能力値が重複して上がる可能性があるため、実行条件やスイッチを組み合わせることも重要になります。

能力値の調整は、クラス全体に適用するのか、特定のユニットだけに適用するのかを意識して設計したいと思います。

9. 勝利条件とマップクリア

マップを作る際には、勝利条件を設定する必要があります。

代表的な条件には、敵の全滅、ボスの撃破、指定ターンの終了、主人公が特定の場所に到達することなどがあります。

ここで学んだのは、マップ情報に表示する勝利条件の文章と、実際にゲームをクリアさせる処理は区別して考える必要があるということです。

一方、敵全滅については、実際のテストプレイで、追加のATイベントを作らなくてもクリアできることを確認しました。

そのため、標準機能ですでに実現できている処理については、無理にイベントを追加する必要はありません。

独自の会話や演出を挟んでからクリアさせたい場合など、追加の制御が必要なときにイベントを利用する、という考え方が効率的だと感じています。

10. ショップの設置

ゲーム内でアイテムを購入できるショップには、戦闘準備画面に設置するものと、マップ上の村や町などに設置するものがあります。

マップ上のショップでは、場所イベントを設定し、販売する武器やアイテム、在庫数などを登録します。

一方、戦闘準備画面のショップは、出撃前に装備を整える用途に向いています。

この違いを理解しておくと、ゲームの進行に合わせて買い物の場所を使い分けられます。

例えば、出撃前に基本的な武器を購入できるようにし、町を訪問したときには少し珍しいアイテムを購入できるようにするといった設計が考えられます。

11. 情報収集コマンドとイベントの見せ方

戦闘準備画面やマップ上のコマンドについても、標準機能でどこまで変更できるのかを確認しました。

例えば、戦闘準備画面に表示される「情報収集」という項目を、作品の世界観に合った名前に変更できないかと考えました。

このような変更は、単にイベントを作るだけでは解決できず、画面レイアウトやコマンドの設定、場合によっては追加機能の検討が必要になることがあります。

ゲームの内容だけでなく、プレイヤーが操作する画面の見せ方も、作品の雰囲気を作る重要な要素なのだと感じました。

12. AIと相談しながら制作すること

今回の制作で、SRPG Studioの操作方法を学べたことはもちろんですが、AIとの付き合い方についても気づきがありました。

AIに質問すると、設定方法や実装の考え方を短時間で整理できます。しかし、説明された方法が自分の使っているバージョンや実際の設定画面と完全に一致するとは限りません。

今回も、実際にテストプレイして初めて分かったことがいくつもありました。

例えば、敵全滅によるクリアは、最初からイベントを作る必要があると思っていましたが、テストすると標準機能だけで実現できていました。また、シビリアンの石投げモーションも、設定画面の確認だけでは原因を特定できず、実際に弓兵のモーションへ変更して動作を比較することで、問題を切り分けられました。

AIの説明をそのまま採用するのではなく、実際に操作して確認し、うまくいかなければ原因を切り分けて再び相談する。この繰り返しが、制作を進めるうえで大切だと感じています。

おわりに

SRPG Studioでゲームを作り始めてから、イベント、クラス、武器、戦闘アニメーション、クラスチェンジ、ショップなど、さまざまな機能を少しずつ学んできました。

まだ分からないことは多いですが、ひとつずつ動作を確認していくことで、頭の中にあったゲームの仕組みが、実際に動く形になっていくのは楽しいものです。

最初からすべての機能を理解しようとするのではなく、作りたい場面をひとつ実現し、その過程で必要な機能を学ぶ。今はこの進め方が、自分には合っていると感じています。

これからも、まずは標準機能を活用しながら、少しずつゲームを完成に近づけていきたいと思います。

――まだ見ぬ世界へ旅立つ、その前夜に。

はじまりは、小さな憧れだった

いつか、自分だけの物語をゲームにしてみたい。

そう思ったことは、ずっと昔からあった。剣を手にした戦士が戦場を駆け、魔法使いが不思議な術を操り、仲間たちがそれぞれの力を持ち寄って強大な敵に立ち向かう。そんな世界に、私は幾度となく心を奪われてきた。

なかでも、戦場を一手ずつ進み、仲間の成長を見守りながら物語を紡いでいくシミュレーションRPGというジャンルは、特別な存在だった。

しかし、遊ぶことと、作ることの間には深い谷がある。物語を思い描くことはできても、それを実際に動くゲームにするには、何を学び、どこから手をつければよいのか。そんな思いを抱えたまま、私は長いこと、谷の向こう側を眺めていた。

やがて出会ったのが、SRPG Studioだった。

本格的なゲーム制作の経験が十分にあるわけではない。それでも、これなら自分にも一歩を踏み出せるかもしれない。そう考え、まずは体験版を手に取った。

壮大な冒険の始まりにしては、あまりにもささやかな一歩だった。けれど、どんな英雄の旅も、最初の一歩なしには始まらない。

地図を広げ、最初の一歩を踏み出す

最初に取り組んだのは、いきなり壮大な物語を完成させることではなかった。

まずは小さなマップを作り、ユニットを配置し、敵を動かしてみる。自分の思い描いた戦場が、画面の中で本当に動くのか。それを確かめるところから始めた。

初めて自分で組み立てたマップの上で、ユニットが動いたときの感覚は、今でも大切にしたいと思っている。これまで遊ぶ側として眺めていた世界の仕組みを、今度は自分の手で組み立てている。その実感が、次の作業へと背中を押してくれた。

もちろん、すべてが思いどおりに進んだわけではない。

設定を一つ変えただけで別の部分に影響が出たり、思い描いた動作を実現するために、メニューやイベントの項目を何度も見直したり。頭の中では簡単に成立していたことが、実際に作ってみると、いくつもの手順に分解しなければならないこともあった。

それでも、わからないことを一つずつ調べ、試し、動作を確かめていくうちに、少しずつ見えてくるものがあった。

ゲームは、ひらめきだけで完成するものではない。小さな仕組みを理解し、それらを一つずつ積み重ねていくことで、ようやく一つの世界になるのだ。

制作者の視点という、新しい魔法

SRPG Studioに触れてから、ゲームを見る目も少しずつ変わってきた。

以前なら何気なく遊んでいた戦闘マップも、今では違った角度から眺めている。なぜこの場所に障害物があるのか。なぜ敵はこのタイミングで動くのか。なぜこの能力値なのか。プレイヤーにどのような選択をさせ、どんな体験を味わってもらうために、この仕組みが用意されているのか。

完成された作品の裏側には、きっと無数の判断がある。

敵の配置一つにも意味があり、地形一つにも役割がある。強い敵を置けば面白くなるわけではないし、複雑な仕組みを増やせば魅力が増すわけでもない。

むしろ、プレイヤーが迷わず遊べること、選択に意味を感じられること、そして一つの戦いを終えたときに小さな達成感を得られること。そうした目に見えにくい工夫こそが、作品の手触りを形作っているのかもしれない。

作る側に回ったことで、これまで多くの作品から受け取ってきた楽しさが、どれほど細やかな積み重ねによって生み出されていたのかを考えるようになった。

それは、制作技術を学ぶこととは別の、大きな収穫だった。

小さな完成を積み重ねる

制作を進めるうえで、もう一つ大切だと感じたことがある。

それは、最初から何もかもを完成させようとしないことだ。

頭の中には、やってみたいことがいくつも浮かぶ。仕組みを工夫したい。演出を加えたい。マップをもっと魅力的にしたい。物語にも、登場人物にも、こだわりたいところは尽きない。

けれど、思いついたことをすべて盛り込もうとすれば、作業はいつまでも終わらない。

だからこそ、まずは基本の機能を使い、必要なものから形にしていく。難しいことに出会ったら、いったん立ち止まり、標準機能で実現できないかを考える。それでも難しければ、調べたり、別の方法を試したりする。

遠回りに見える作業も、振り返れば次の一歩を確かなものにしてくれる。

そして何より、実際に動くものが一つずつ増えていくことがうれしい。

頭の中だけにあった構想が、少しずつ目に見える形になっていく。その喜びは、ゲームを遊んでいるときとはまた違ったものだった。

完璧なものを一度に生み出すのではなく、未完成のものを少しずつ完成へ近づけていく。

今の私にとって、それがゲーム制作を続けるための、一番確かな方法なのだと思う。

まだ見ぬ仲間たちへ

この日記を、すでにSRPG Studioで作品を完成させ、世に送り出した方々が読んでくださるなら、ぜひ聞いてみたいことがある。

最初の作品を作っていた頃、どんなことで悩み、どんな瞬間に喜びを感じただろうか。

思いどおりに動かないイベントに頭を抱えた日も、完成したマップを何度も眺めた夜も、きっとあったのではないだろうか。あるいは、完成した作品を初めて誰かに遊んでもらったとき、どんな気持ちになったのだろう。

今まさに制作を進めている方々には、同じ道を歩く仲間として、そっと声をかけたい。

進み具合は人それぞれだ。毎日制作できる人もいれば、仕事や生活の合間を縫って少しずつ進める人もいる。技術に自信がある人もいれば、調べながら一つずつ覚えている人もいる。

それでも、自分の手で何かを作ろうとしているという点では、きっと同じ場所に立っている。

そして、これからSRPG Studioを始めようと考えている方々へ。

最初からすべてを理解している必要はない。壮大な構想がなくてもいい。まずは小さなマップを一つ作り、ユニットを動かしてみるだけでも、そこから見える景色は変わってくるはずだ。

完成までの道のりは、始める前に想像していたものとは違うかもしれない。それでも、一つずつ覚え、試し、自分の世界を形にしていく時間には、作り手にしか味わえない喜びがある。

いつか、どこかの誰かが作った作品を遊び、そこから新しい制作の旅が始まる。そんなつながりが生まれたら、すてきなことだと思う。

本編購入前夜

そして今、私は一つの節目を迎えようとしている。

体験版で学べることを試し、基本的な仕組みに触れ、自分がどのような手順でゲームを作っていくのかを、少しずつ理解してきた。

まだ知らないことは多い。これから先、思いどおりに進まない場面もあるだろう。制作を続けるうちに、最初の構想を見直したくなることもあるかもしれない。

それでも、始める前に抱いていた漠然とした不安は、少しずつ具体的な課題へと変わってきた。何がわからないのか、何を試せばよいのか。その輪郭が見えてきただけでも、大きな前進だったと思う。

本編を購入するということは、単に新しいソフトを手に入れるということではない。

自分の思い描いた世界を、最後まで形にする。そのための時間を、これからも少しずつ積み重ねていくということだ。

世に出すからには、誰かに遊んでもらえる作品にしたい。けれど、最初から大作を目指す必要はない。まずは自分の力で一本を完成させ、遊べる形にして、誰かの手に届けること。それが今の私にとっての大切な目標だ。

いつか完成した作品を振り返ったとき、技術的に未熟だったところも、もっと工夫できたところも見つかるだろう。それでも、最初の一作を最後まで作り上げたという経験は、きっと次の挑戦につながっていく。

窓の外は静かだ。

まだゲームの世界には、動かすべきユニットが残っている。整えるべきマップがあり、確かめるべきイベントがあり、これから覚えていく仕組みがある。

けれど、今夜くらいは、ここまで歩いてきた道を振り返ってもいいだろう。

いつか作りたいと思っていた世界は、まだ完成していない。

それでも今は、ただの夢ではなくなった。

近い将来、私は新しい扉を開く。

その向こうに待っているのは、華やかな成功ばかりではないだろう。地道な作業も、思わぬ壁も、きっと待っている。それでも、自分で選んだ道なら、一歩ずつ進んでいきたい。

いつか、この旅の終わりに一本のゲームを完成させ、まだ見ぬ誰かに届けるために。

これは、ゲームを完成させた者の物語ではない。完成を目指す者が、その第一歩を踏み出す前夜の物語である。

さあ、本当の冒険を始めよう。

 

 

下記の画像は今制作中の作品の初期タイトル&マップ&登場キャラ案です。

起:久しぶりの週5日勤務、その先へ

新しい仕事を始めてから、約1か月半が経過した。

前回、仕事を始めて3週間ほどの時点で日記を書いたときは、久しぶりに週5日働く生活そのものに慣れることが大きな課題だった。毎朝決まった時間に起きて、職場へ行き、夕方まで仕事をして帰宅する。それだけでも、以前の生活とは大きく違っていた。

今も、仕事が終わると疲れを感じる日はある。ただ、毎日出勤するという生活の形そのものには、少しずつ慣れてきたように思う。

 

仕事が始まった当初は、初めて扱う業界の知識や業務の進め方を覚えることに加え、職場の人間関係や雰囲気を把握することにも気を使っていた。何をどこまで自分で判断してよいのか、誰に相談すればよいのか。そうしたことも、実際に働きながら学んでいく必要がある。

 

最近は、毎日の仕事に対して以前ほど強い緊張を感じない場面も増えてきた。少なくとも、日々の業務そのものが常に大きなストレスになっているわけではない。

 

一方で、仕事に慣れてきたからといって、すべてが楽になったわけではなかった。むしろ、仕事の全体像が少しずつ見えてきたことで、新たな難しさも感じるようになってきた。

承:覚えること、考えること、そして少しずつできること

現在の仕事で、特に時間を使っているのは、知識を覚え、理解し、必要なときに取り出せるようにすることだ。

決められた手順をそのまま覚えれば済む仕事ばかりではない。資料を調べ、過去の事例を確認し、複数の条件を照らし合わせながら判断する必要がある。しかも、規定や手順を読んだだけでは分からない運用上の取り決めが存在することもある。

自分では理解したつもりでも、実際の案件に当てはめると迷うことがある。反対に、最初は分からなかったことでも、調べ方や考え方が分かってくると、自力で答えにたどり着ける場合もある。

 

今は、知識の量だけでなく、どこを調べればよいのか、何を根拠に判断するのか、どこから先は人に確認すべきなのかを学んでいる段階なのだと思う。

 

これは、これまで経験してきた仕事とも少し違う。過去には、Web関連の仕事やディレクション、マネジメントなど、比較的長い経験を積んできた分野もあった。しかし、新しい業界や業務では、その経験だけで簡単に対応できるわけではない。

経験があるからこそ気づけることもある一方で、経験があるからこそ「もっとできるはずだ」と自分に期待してしまうこともある。以前の自分と現在の自分を比べて、思うように進まないことに焦りを感じる場面もある。

それでも、以前よりできるようになったことはある。分からないことを調べ、必要なときには質問し、自分なりの理解を組み立てる。仕事上の問題に気づいたときには、改善できないか考える。そうした行動は、少しずつ日常の一部になってきた。

仕事を始めたばかりの頃に比べれば、目の前の業務だけでなく、その周辺にある仕組みや課題にも目が向くようになっている。これは、今の自分にとって前向きな変化だと思う。

転:小さな失敗と、納得できない仕事の進め方

もちろん、良いことばかりではない。

最近、完了していると思っていた作業が、実際には未完了だったことに気づいた。気づいた時点で対応はしたものの、上司への報告が後になってしまった。翌朝、改めて事実を伝え、謝罪した。

上司からは「いいね」のメンションの反応があっただけで、強く責められたわけではない。これまでのやり取りを振り返っても、今回の反応を過度に悪く受け取る必要はなさそうだと感じている。

 

ただ、自分が完了したと思っていたことと、実際に完了していたことが違ったのは事実だ。記憶や感覚だけに頼らず、最後にきちんと確認する必要がある。経験を積んできたからといって、ミスをしなくなるわけではない。むしろ、慣れてきたときほど確認を怠らないようにしたい。

 

もう一つ、強いストレスを感じた出来事があった。

業務上のルールについて確認する場面で、明文化されたルールには記載されていないものの、実際の運用では守る必要があるという説明を受けた。ルールそのものが複雑なうえ、どこに書かれているのか、どのような条件で適用されるのかが、すぐには分からない。

 

その場では、説明された内容のうち理解できた部分を自分の言葉で説明した。大きな訂正もなく会議は終わったが、気持ちはすっきりしなかった。

腹が立ったのは、単に自分が理解できなかったからではない。規定に書かれていないルールを、すでに知っていることが前提であるかのように説明され、さらに理解できたかどうかを確認される。その状況に、理不尽さを感じたのだと思う。

正確に仕事をするためには、判断の根拠が必要だ。しかし、必要な情報が明確に整理されていない状態で、正しく理解することを求められても困ってしまう。

 

もちろん、すべての運用を規定に書ききることが難しい事情もあるだろう。長く仕事をしている人にとっては当たり前の知識でも、初めて担当する人には分からないことがある。それ自体は理解できる。

それでも、知らないことを知らないままにしておくわけにはいかない。かといって、すべてを自分の努力不足として引き受けるのも違う気がする。

 

今回の出来事を通して、業務知識を増やすことだけでなく、自分の責任範囲と、職場の仕組みとして整えてほしい部分を区別する必要があると感じた。

結:完璧に適応するのではなく、続けながら学ぶ

仕事を始めて1か月半。今の自分は、職場に完全に適応したわけでも、毎日余裕を持って働けるようになったわけでもない。

できることが増えている実感はある。一方で、知識不足を感じる場面もあれば、仕事の進め方に納得できず、気持ちが張り詰める日もある。小さなミスをして、自分の確認不足を反省することもある。

 

ただ、こうした出来事を一つひとつ経験することで、少しずつ自分なりの仕事の進め方ができてくるのかもしれない。

分からないことは調べる。必要なことは質問する。間違いに気づいたら、隠さずに報告して修正する。改善できそうなことがあっても、すぐに結論を出そうとせず、周囲の事情を知ってから提案する。

 

当たり前のことばかりだが、新しい環境では、その当たり前を一つずつ身につけていく必要がある。

今回、改めて感じたのは、仕事に慣れることと、仕事のすべてに納得することは別だということだ。職場のやり方に疑問を感じることがあっても、すぐに自分や相手のどちらかを否定する必要はない。まずは事実を整理し、自分にできる対応を考えればよい。

そして、仕事のことを考え続けてしまう日ほど、仕事から離れる時間も必要になる。仕事上の課題をすべて解決してから休むのではなく、未解決のことがあっても、その日の仕事を終えて休む。長く働き続けるためには、そうした切り替えも覚えていきたい。

以前の自分なら、もっと早く仕事を覚えなければ、もっと役に立たなければ、と焦っていたかもしれない。今もその気持ちがなくなったわけではない。ただ、最初から完璧にできることを目指すより、半年ほどの時間をかけて少しずつ適応していくと考えたほうが、現実的なのだろう。

 

仕事を始めた当初の不安は、完全には消えていない。それでも、1か月半前には分からなかったことが、今は少し分かるようになっている。

 

まずは、目の前の仕事を一つずつ覚えていこう。必要以上に自分を責めず、かといって問題から目をそらさず、できることを増やしていく。

 

数年後、この日記を読み返したとき、今の悩みが小さなことに思えるかもしれない。あるいは、当時はこんなことに悩みながら働いていたのか、と懐かしく感じるかもしれない。

そのときの自分がどうなっているかは分からない。

ただ、仕事を始めて1か月半の今、良いことも、嫌なことも、うまくできたことも、失敗したことも含めて、ここまで続けてきた。それを、今の自分の記録として残しておきたい。