ワールドフロンティア創世記~街の自動生成~
じゃん!

そのいち。普通の町。

そのに。村のイメージ。

そのさん。街道の整備された都市風味。
できるかどうか不安だったけど、やってみれば案外できました。
ということで、ついに街の(半)自動生成に成功。
(半)というのは宿屋とかお店とかのオブジェクトが用意したものを切り貼りしているだけなため。こいつらまでプログラムだけで生成できればすごいだろうけど、生成に分単位の時間がかかりそうだし気力もないので妥協しました。
オブジェクト配置はどうしようか非常に悩んだものの、結局マップを10×10に空間分割して、事前に用意しておいた10×10の範囲内で収まるオブジェクトを並べて配置するだけにしてしまった。なので、巨大な屋敷とか町全体がひとつの建物になってるとか、そういうのは無理げ。必然的にオブジェクトの配置パターンが違うだけの街が量産されるようになってしまい、個性が薄くなってしまった。残念。
結局のところプログラムを組んで本当にランダム生成しているのは地面と木や石なんかの小物オブジェクトだけ。
それでもまぁ、それっぽく見えるからいいかということで。

そのいち。普通の町。

そのに。村のイメージ。

そのさん。街道の整備された都市風味。
できるかどうか不安だったけど、やってみれば案外できました。
ということで、ついに街の(半)自動生成に成功。
(半)というのは宿屋とかお店とかのオブジェクトが用意したものを切り貼りしているだけなため。こいつらまでプログラムだけで生成できればすごいだろうけど、生成に分単位の時間がかかりそうだし気力もないので妥協しました。
オブジェクト配置はどうしようか非常に悩んだものの、結局マップを10×10に空間分割して、事前に用意しておいた10×10の範囲内で収まるオブジェクトを並べて配置するだけにしてしまった。なので、巨大な屋敷とか町全体がひとつの建物になってるとか、そういうのは無理げ。必然的にオブジェクトの配置パターンが違うだけの街が量産されるようになってしまい、個性が薄くなってしまった。残念。
結局のところプログラムを組んで本当にランダム生成しているのは地面と木や石なんかの小物オブジェクトだけ。
それでもまぁ、それっぽく見えるからいいかということで。
ウディタの処理軽減についてのあれこれ
ワールドフロンティアの処理軽減をあちこちで行ってみました。
ということで、とりあえず調べたことのまとめです。
・メモリロードを活用する
知っている人も多いでしょうが、ピクチャを表示したり音を鳴らしたりするときは、一度HDDからその情報をメモリにコピーしたうえで、ゲーム上で表現しています。HDDからメモリにロードするには結構時間がかかるので、ゲームが一瞬停止したりする事態を防ぐために、普通の商業ゲームなんかでは最初に必要なデータをメモリに全部コピーしてしまって、ゲームプレイ中はメモリロードを行いません(ローディング画面ってのは要するにこれですね)。
ウディタでもこれと同じで、ゲームプレイ中にSEとかをいちいち読み込んでいると(ほとんど体感できないレベルですが)、ゲームプレイが一瞬止まります。
なので、必要なサウンドデータは「メモリロード」のコマンドを使ってゲーム開始前にメモリに入れてあげるのがよさそうです。
ちなみに、メモリに読み込んだデータはほとんど瞬間的に再現できます。ロード画面なんかで体験したことのある人は多そうですが、ロード画面は初回表示には体感できるレベルで時間がかかる割に、二回目以降はかなりスムーズにいきます。これはセーブデータの情報をメモリに書き込んでいるからですね。
ここまでがサウンド関連。次にピクチャについて。
聞いたところによると、ウディタのピクチャ消去は単純にピクチャを消すだけじゃなくて、その後「メモリからピクチャ情報を消去」してしまうらしいです。で、メモリから消去してしまったので、再表示するにはまたHDDからデータを取ってこなくちゃいけなくて、これにまた時間がかかります。
ところが、このピクチャ消去には裏があって、メモリからピクチャ情報を消去するのは「同じピクチャが一枚も表示されていないとき」だけだそうです。ということはつまり、頻繁に使う画像なんかはどこかに表示(不透明度0で)しておけば、メモリ操作されない=処理が軽くなるとゆーことですね。
ということで、ピクチャについても必要な分はローディング画面を設けて適当に表示しておくのがよさそうです。特にスピードが求められる戦闘なんかのために、戦闘エフェクトはどっかに表示しておいた方がいいのかな?
・セーブ&ロードをなるべく使わない
セーブ&ロード処理を自作したことのある人なら、この二つの処理がかなり重いのはご存じだと思います。
で、聞いたところによると普通のセーブ&ロードなんかと、セーブデータ内の変数を読み書きする処理は同じ重さだそうですね。短編ならセーブデータもちっちゃいので問題ないですが、長編ともなるとセーブデータが肥大化し、読み書きにいちいち遅延が発生します。
基本システムではセーブデータ共通の情報(最終セーブ位置とか)はSystem.savという専用のセーブデータを作って保管してますが、セーブデータが大きくなってきたら、これをとっぱらって、CSVとかtextとかに保存する方が処理速度的にはおそらく速いです(ということにSystem.savを使うセーブロード処理を全部作り終えてから気づきましたorz)。
・ピクチャ以外停止を使う
イベント制御のところにあるこのコマンド。あまり使ったことがない人も多いのでは。
これはピクチャ以外の画像更新を停止するコマンドです。戦闘とかその他シミュレーション系でピクチャですべてを行っている画面では、マップの情報は必要ないのでこのコマンドを使って処理軽減に努めましょう。
全部やってみて、個人的にはピクチャのメモリロード>サウンドのメモリロード>それ以外って感じで処理軽減につながった気がします。
ということで、とりあえず調べたことのまとめです。
・メモリロードを活用する
知っている人も多いでしょうが、ピクチャを表示したり音を鳴らしたりするときは、一度HDDからその情報をメモリにコピーしたうえで、ゲーム上で表現しています。HDDからメモリにロードするには結構時間がかかるので、ゲームが一瞬停止したりする事態を防ぐために、普通の商業ゲームなんかでは最初に必要なデータをメモリに全部コピーしてしまって、ゲームプレイ中はメモリロードを行いません(ローディング画面ってのは要するにこれですね)。
ウディタでもこれと同じで、ゲームプレイ中にSEとかをいちいち読み込んでいると(ほとんど体感できないレベルですが)、ゲームプレイが一瞬止まります。
なので、必要なサウンドデータは「メモリロード」のコマンドを使ってゲーム開始前にメモリに入れてあげるのがよさそうです。
ちなみに、メモリに読み込んだデータはほとんど瞬間的に再現できます。ロード画面なんかで体験したことのある人は多そうですが、ロード画面は初回表示には体感できるレベルで時間がかかる割に、二回目以降はかなりスムーズにいきます。これはセーブデータの情報をメモリに書き込んでいるからですね。
ここまでがサウンド関連。次にピクチャについて。
聞いたところによると、ウディタのピクチャ消去は単純にピクチャを消すだけじゃなくて、その後「メモリからピクチャ情報を消去」してしまうらしいです。で、メモリから消去してしまったので、再表示するにはまたHDDからデータを取ってこなくちゃいけなくて、これにまた時間がかかります。
ところが、このピクチャ消去には裏があって、メモリからピクチャ情報を消去するのは「同じピクチャが一枚も表示されていないとき」だけだそうです。ということはつまり、頻繁に使う画像なんかはどこかに表示(不透明度0で)しておけば、メモリ操作されない=処理が軽くなるとゆーことですね。
ということで、ピクチャについても必要な分はローディング画面を設けて適当に表示しておくのがよさそうです。特にスピードが求められる戦闘なんかのために、戦闘エフェクトはどっかに表示しておいた方がいいのかな?
・セーブ&ロードをなるべく使わない
セーブ&ロード処理を自作したことのある人なら、この二つの処理がかなり重いのはご存じだと思います。
で、聞いたところによると普通のセーブ&ロードなんかと、セーブデータ内の変数を読み書きする処理は同じ重さだそうですね。短編ならセーブデータもちっちゃいので問題ないですが、長編ともなるとセーブデータが肥大化し、読み書きにいちいち遅延が発生します。
基本システムではセーブデータ共通の情報(最終セーブ位置とか)はSystem.savという専用のセーブデータを作って保管してますが、セーブデータが大きくなってきたら、これをとっぱらって、CSVとかtextとかに保存する方が処理速度的にはおそらく速いです(ということにSystem.savを使うセーブロード処理を全部作り終えてから気づきましたorz)。
・ピクチャ以外停止を使う
イベント制御のところにあるこのコマンド。あまり使ったことがない人も多いのでは。
これはピクチャ以外の画像更新を停止するコマンドです。戦闘とかその他シミュレーション系でピクチャですべてを行っている画面では、マップの情報は必要ないのでこのコマンドを使って処理軽減に努めましょう。
全部やってみて、個人的にはピクチャのメモリロード>サウンドのメモリロード>それ以外って感じで処理軽減につながった気がします。
タイトルが決まった~!
エフェクトづくりにハマるの巻
変数をうまく使おう
ということで、みなさん変数をうまく使ってますか~?という話です。
別に自分が特別上手に使っているというわけでもないけど。
このところウディタ公式のコモンからいくつかお借りして使ってみているんですが、改変するのに中を見てみると結構不便な処理を書いているなぁと思うことがありました。
たとえば万能ウィンドウにしても、
■可変DB書込:DB[万能ウィンドウDB:0:項目名] = CSelf5
■可変DB書込:DB[万能ウィンドウDB:0:コード] = 0
■可変DB書込:DB[万能ウィンドウDB:0:選択可能状態(1=可)] = 1
▼
■可変DB書込:DB[万能ウィンドウDB:1:項目名] = CSelf5
■可変DB書込:DB[万能ウィンドウDB:1:コード] = 1
■可変DB書込:DB[万能ウィンドウDB:1:選択可能状態(1=可)] = 1
…
というふうに一項目ずつ記述するよりは
■変数操作: CSelf0 = -1 + 0
■回数付きループ [ 10 ]回
|■変数操作: CSelf0 += 1 + 0
|■可変DB書込:DB[万能ウィンドウDB:CSelf0:項目名] = CSelf5
|■可変DB書込:DB[万能ウィンドウDB:CSelf0:コード] = CSelf0
|■可変DB書込:DB[万能ウィンドウDB:CSelf0:選択可能状態(1=可)] = 1
|■
◇ループここまで◇◇
と変数とループを使って記述した方が分かりやすいし短いしきれいですよね。
そして何より、変数を使った記述は訂正がすごく簡単になります。
最初の例だと、諸事情でコマンドを書き直すときにはすべてのコマンドをさらわないといけませんが、下のようにループを使うと訂正箇所が少なくて済みますね。
短編ならともかく、つくっているうちに調整の問題でいろいろな部分をいじる必要がある長編なんかでは、こういうふうに変数を使って抽象的に記述しておかないと、あとの修正がものすごく大変になってしまいます(もっとも、長編をつくれる人はこのくらいの初歩技術は当然マスターしている気もするが)。
特にピクチャ関連では、こういう変数を使った記述がとても大切になります。ピクチャID、表示XY、サイズXYあたりはすべて変数を使って記述して、コマンドの中に定数が入り込まないようにしておくといいと思います。
別に自分が特別上手に使っているというわけでもないけど。
このところウディタ公式のコモンからいくつかお借りして使ってみているんですが、改変するのに中を見てみると結構不便な処理を書いているなぁと思うことがありました。
たとえば万能ウィンドウにしても、
■可変DB書込:DB[万能ウィンドウDB:0:項目名] = CSelf5
■可変DB書込:DB[万能ウィンドウDB:0:コード] = 0
■可変DB書込:DB[万能ウィンドウDB:0:選択可能状態(1=可)] = 1
▼
■可変DB書込:DB[万能ウィンドウDB:1:項目名] = CSelf5
■可変DB書込:DB[万能ウィンドウDB:1:コード] = 1
■可変DB書込:DB[万能ウィンドウDB:1:選択可能状態(1=可)] = 1
…
というふうに一項目ずつ記述するよりは
■変数操作: CSelf0 = -1 + 0
■回数付きループ [ 10 ]回
|■変数操作: CSelf0 += 1 + 0
|■可変DB書込:DB[万能ウィンドウDB:CSelf0:項目名] = CSelf5
|■可変DB書込:DB[万能ウィンドウDB:CSelf0:コード] = CSelf0
|■可変DB書込:DB[万能ウィンドウDB:CSelf0:選択可能状態(1=可)] = 1
|■
◇ループここまで◇◇
と変数とループを使って記述した方が分かりやすいし短いしきれいですよね。
そして何より、変数を使った記述は訂正がすごく簡単になります。
最初の例だと、諸事情でコマンドを書き直すときにはすべてのコマンドをさらわないといけませんが、下のようにループを使うと訂正箇所が少なくて済みますね。
短編ならともかく、つくっているうちに調整の問題でいろいろな部分をいじる必要がある長編なんかでは、こういうふうに変数を使って抽象的に記述しておかないと、あとの修正がものすごく大変になってしまいます(もっとも、長編をつくれる人はこのくらいの初歩技術は当然マスターしている気もするが)。
特にピクチャ関連では、こういう変数を使った記述がとても大切になります。ピクチャID、表示XY、サイズXYあたりはすべて変数を使って記述して、コマンドの中に定数が入り込まないようにしておくといいと思います。
船の移動処理について

けっこう前につくったやつなんですが、せっかくなのでネタとして書いておきます。
ネット上でウディタの船コモンを探すと、けっこうチップ処理とかタイルセット入れ替えとかで海チップを通行可能にしている人が多いみたいですね。
まぁそれでもいいっちゃいいんですが、私としてはチップ処理やタイルセット入れ替えを頻繁に行いたくない(設定が面倒だし、なんとなくスタイリッシュじゃない気がする)ので、船コモンは変数呼び出し値の移動を使ってます。
ウディタでは主人公の座標を取得する変数呼び出し値があって、それをいじることで主人公を移動させることができるという裏ワザチックなものがあります。
具体的な使い方はこんな感じ。
■変数操作: CSelf10[一時変数A] = 9180000 + 0
■変数操作: CSelf11[一時変数B] = 9180001 + 0
■変数操作: V[CSelf10[一時変数A]] = CSelf21[移動先X] + 0
■変数操作: V[CSelf11[一時変数B]] = CSelf22[移動先Y] + 0
9180000が主人公のX座標(標準)、9180001が主人公のY座標(標準)の呼び出しコードです。
これを適当な変数に「データを呼ばない」状態で入れてから「X番の変数呼び出し」を使って呼び出すと、主人公が変数に入力した座標までスィーって感じで移動します。面白いのでぜひやってみてください。
この変数呼び出し値には以下のような特徴があります。
・タイルの通行設定を無視して移動できる
・移動速度も反映される
・ただし方向転換は自動では反映されない
ということで、船コモンを変数呼び出し値を使ってつくる場合には、「移動時の方向キー入力を禁止」したうえで、キー入力を使ってコモンイベントで主人公の移動を自分で管理することになります。
つまり、並列実行イベントを使って、移動時の方向キー入力を禁止し、方向キーのキー入力を受け付け、入力された移動先に海チップがあるかどうか判定し、海チップがあるなら変数呼び出し値を使って主人公を移動させるわけですね。
なんだか七面倒くさそうな話ですが、自分で移動管理する分、細かいところまで設定できるので便利です。飛行系の乗り物まで作る人は少ないかもしれませんが、それもこのイベントをちょっと改造するだけで簡単に実現できそうですね。また、自分もローグの崖のときにはお世話になりましたが、一歩の挙動が命となるローグライクなんかでは必須の技術なんではないかと思います。
オマケ。主人公の方向もこんな感じで変えられます。
■変数操作: CSelf10[一時変数A] = 9180006 + 0
■変数操作: V[CSelf10[一時変数A]] = CSelf25[向き] + 0
オマケのオマケ。
変数呼び出し値にはいろいろ夢があって、裏技的なことがけっこうできるんですが、UDB操作なんかは実用性がある方なんではないかと。
■変数操作: CSelf10[一時変数A] = 1000000000 + 0
■変数操作: V[CSelf10[一時変数A]] = 1 + 0
分かりづらいですが、1000000000~がUDBの呼び出し値で、これに同様にして数値を入力してやることで、ゲーム中にUDBをいじることができたりします。もっとも、セーブ&ロードで初期化されてしまうので、一時的な使用しかできませんが。
ちなみに私は、スフィアンマスターズの他国マスター的なのをつくる際、このUDBの呼び出し値を使って敵データを自動生成したりしていました。
トランジションについて
なんかこう、横からスクロールするシンプルなトランジションがほしくて探したんですが、何故かオシャレすぎる素材ばかりでまったく見つからなかったので、自作というほどでもないですが自作しました。




そのときの副産物ですが、欲しい方がいたら自由にお持ち帰りください。作成時間3分程度なので、著作権とかは一切放棄します。
あと、トランジションについてなんですが、自分自身最初のころは使い方がまったく分からなかったので、使い方をちらっとまとめておきます。
基本ですが、トランジションはコマンドの「イベント制御」にある「トランジション準備」「トランジションの指定」「トランジション実行」の3つのコマンドを使って行います。
まず「トランジション準備」とは、(画面停止)ってあるように画面の更新を停止するコマンドです。ウディタでは1秒間に何回も画面を描画しなおすことであたかもキャラが動いているかのように演出してますが、その画面更新を停止させるわけですね。ということで、トランジション準備を行うとそれ以降はキャラが動いたりしても画面に反映されなくなります。
トランジションの仕組みはこれを利用したもので、すなわち画面更新が停止されている間に別の画面(あるいはマップとか)を表示してしまって(もちろん更新されないので実際には表示されませんが)、あとからトランジション画像に合わせて別の画面を徐々に表示していく、みたいな感じです。訳が分かりませんね。
次に「トランジションの指定」です。これはそのまんまですが、ここでトランジションのタイプを指定します。システムDBに設定箇所があるので、適当にいじってください。フレーム数はトランジションを何フレームかけて実行するかってことですね。まぁ10~20フレームあたりが妥当だと思いますが。
最後に「トランジション実行」でトランジションを実行します。トランジション画像の黒い部分から徐々に見えるようになります。
実際のコマンドはこんな感じ。
トランジション準備
↓
トランジション指定
↓
画面なりマップなりをトランジション後のものに変える
↓
トランジション実行
が、しかし、これだけだとよくある「一度かっこよく暗転してから場面転換」みたいなことができません。
これをしたいときはトランジション実行を二回行うことになります。
トランジション準備
↓
トランジション指定
↓
暗転(基本システムなら全体エフェクト実行で0フレーム暗転)
↓
トランジション実行(ここまででトランジションしながら暗転するはず)
↓
トランジション準備
↓
トランジション指定
↓
画面を差し替えるなりマップ移動なり、トランジション後の画面をつくる
↓
全体エフェクト解除(0フレーム)
↓
トランジション実行
こんな感じですね。


暗転からの場面転換!
分かりづらいですが1枚目から2枚目に場面転換、左から右に向かって暗幕が流れる感じでトランジションしてます。
ノベルゲームとかアドベンチャーとか作りたい人は演出にぜひ。




そのときの副産物ですが、欲しい方がいたら自由にお持ち帰りください。作成時間3分程度なので、著作権とかは一切放棄します。
あと、トランジションについてなんですが、自分自身最初のころは使い方がまったく分からなかったので、使い方をちらっとまとめておきます。
基本ですが、トランジションはコマンドの「イベント制御」にある「トランジション準備」「トランジションの指定」「トランジション実行」の3つのコマンドを使って行います。
まず「トランジション準備」とは、(画面停止)ってあるように画面の更新を停止するコマンドです。ウディタでは1秒間に何回も画面を描画しなおすことであたかもキャラが動いているかのように演出してますが、その画面更新を停止させるわけですね。ということで、トランジション準備を行うとそれ以降はキャラが動いたりしても画面に反映されなくなります。
トランジションの仕組みはこれを利用したもので、すなわち画面更新が停止されている間に別の画面(あるいはマップとか)を表示してしまって(もちろん更新されないので実際には表示されませんが)、あとからトランジション画像に合わせて別の画面を徐々に表示していく、みたいな感じです。訳が分かりませんね。
次に「トランジションの指定」です。これはそのまんまですが、ここでトランジションのタイプを指定します。システムDBに設定箇所があるので、適当にいじってください。フレーム数はトランジションを何フレームかけて実行するかってことですね。まぁ10~20フレームあたりが妥当だと思いますが。
最後に「トランジション実行」でトランジションを実行します。トランジション画像の黒い部分から徐々に見えるようになります。
実際のコマンドはこんな感じ。
トランジション準備
↓
トランジション指定
↓
画面なりマップなりをトランジション後のものに変える
↓
トランジション実行
が、しかし、これだけだとよくある「一度かっこよく暗転してから場面転換」みたいなことができません。
これをしたいときはトランジション実行を二回行うことになります。
トランジション準備
↓
トランジション指定
↓
暗転(基本システムなら全体エフェクト実行で0フレーム暗転)
↓
トランジション実行(ここまででトランジションしながら暗転するはず)
↓
トランジション準備
↓
トランジション指定
↓
画面を差し替えるなりマップ移動なり、トランジション後の画面をつくる
↓
全体エフェクト解除(0フレーム)
↓
トランジション実行
こんな感じですね。


暗転からの場面転換!
分かりづらいですが1枚目から2枚目に場面転換、左から右に向かって暗幕が流れる感じでトランジションしてます。
ノベルゲームとかアドベンチャーとか作りたい人は演出にぜひ。
ずっと野球のターン
RPGがどっかいった。

前とたいして変化ないけど、とりあえずメニュー画面をリニューアル。アイコンが入るとテキトーな画面でもある程度はきれいになりますね。

こちらはシーズンの本塁打記録画面。79本て。バランスはまだ調整中なものの、だいたいそれっぽい数字が出るようにはなった感じ。
パワプロとかその他野球シミュレーション系のゲームがどうしているかは知らないけど、自分は投球から打撃・守備までの流れをこまごまと作ってます。細かい要素は捨象しているけど、だいたいこんな感じ。
投球がボールになるかストライクになるか(投手の制球、打者のパワー&ミート依存)
↓
ストライクの場合、バットに当たるかどうか(投手能力、打者のミート依存)
↓
当たった場合、ゴロになるかフライになるか(投手の変化球、打者のパワー依存)
↓
[分岐1]ゴロになった場合、どの方向へ転がるか。さらに外野に抜けてヒットになるかどうか(転がったポジションの守備力依存)。さらに内野ゴロになった場合、内野安打になるかどうか(打者の走力依存)
[分岐2]フライになった場合、どの方向へ飛ぶか。さらにホームランになるかどうか(パワー依存)。さらに外野フライでアウトになるかどうか(外野の走力&守備力依存)。ヒットになった場合、長打になるかどうか(パワー&走力依存)
てな感じで判定します。ついでに言えば各所でエラーになるか判定したりもします。
やっかいなのが送球するベースで、たとえば「1アウトで二塁に転がってきたら、一塁ランナーがいれば一塁ランナーアウト、その後一塁に投げて併殺になるかどうか」とか「1アウトで二塁に転がってきて三塁ランナーがいればバックホーム」とか「2アウトで二塁に転がってきたら三塁ランナーがいても一塁で確実にアウトを取りに行く」とか、かなりごちゃごちゃ。
救いはコレが野球シミュレーションであるということで、ようするに細かいプレーは多少おかしくても全体として数字がそれっぽくまとまっていればいいということですね。
それはさておき、NPCチームのAIをつくるのがけっこう楽しいです。
具体的には、打順&ポジションの構築とか新人選手の獲得とか。
なんにせよ根本のプログラムを組んでしまえば、あとはプログラムが一人歩きして無限にいろんな局面を生み出してくれるので、可能性って意味ではシミュレーションゲームはとても面白いと思うのでした。
なんかもう、この野球シミュレーションだけで別ゲーとして公開できそうな勢いですが…。
いちおうRPGの寄り道要素です。いちおう。

前とたいして変化ないけど、とりあえずメニュー画面をリニューアル。アイコンが入るとテキトーな画面でもある程度はきれいになりますね。

こちらはシーズンの本塁打記録画面。79本て。バランスはまだ調整中なものの、だいたいそれっぽい数字が出るようにはなった感じ。
パワプロとかその他野球シミュレーション系のゲームがどうしているかは知らないけど、自分は投球から打撃・守備までの流れをこまごまと作ってます。細かい要素は捨象しているけど、だいたいこんな感じ。
投球がボールになるかストライクになるか(投手の制球、打者のパワー&ミート依存)
↓
ストライクの場合、バットに当たるかどうか(投手能力、打者のミート依存)
↓
当たった場合、ゴロになるかフライになるか(投手の変化球、打者のパワー依存)
↓
[分岐1]ゴロになった場合、どの方向へ転がるか。さらに外野に抜けてヒットになるかどうか(転がったポジションの守備力依存)。さらに内野ゴロになった場合、内野安打になるかどうか(打者の走力依存)
[分岐2]フライになった場合、どの方向へ飛ぶか。さらにホームランになるかどうか(パワー依存)。さらに外野フライでアウトになるかどうか(外野の走力&守備力依存)。ヒットになった場合、長打になるかどうか(パワー&走力依存)
てな感じで判定します。ついでに言えば各所でエラーになるか判定したりもします。
やっかいなのが送球するベースで、たとえば「1アウトで二塁に転がってきたら、一塁ランナーがいれば一塁ランナーアウト、その後一塁に投げて併殺になるかどうか」とか「1アウトで二塁に転がってきて三塁ランナーがいればバックホーム」とか「2アウトで二塁に転がってきたら三塁ランナーがいても一塁で確実にアウトを取りに行く」とか、かなりごちゃごちゃ。
救いはコレが野球シミュレーションであるということで、ようするに細かいプレーは多少おかしくても全体として数字がそれっぽくまとまっていればいいということですね。
それはさておき、NPCチームのAIをつくるのがけっこう楽しいです。
具体的には、打順&ポジションの構築とか新人選手の獲得とか。
なんにせよ根本のプログラムを組んでしまえば、あとはプログラムが一人歩きして無限にいろんな局面を生み出してくれるので、可能性って意味ではシミュレーションゲームはとても面白いと思うのでした。
なんかもう、この野球シミュレーションだけで別ゲーとして公開できそうな勢いですが…。
いちおうRPGの寄り道要素です。いちおう。
野球もできるRPG
まったくどうでもいい話なんですが自分は育成・経営シミュレーションゲームがけっこう好きです。パワプロのサクセスやペナントなんかも結構好きだし某CGIゲームも昔はまっていました。
というわけで(というわけでもないですが)、野球シミュレーションを作ってみました。好き嫌いが分かれると思うので、ほぼ完全に寄り道要素。
製作途中なのでまだテキトーですが、とりあえずスクリーンショット。

これは試合中画面ですね。ご覧の通りモンスターを選手として育成する(という名目のただの野球シミュレーション)ゲームです。RPG内のゲームなのでRPGっぽく演出しようと思ったが、あまりうまくいかず。まぁ試合を飛ばすモードもあるし、いちいち試合をみる人もいないと思うので妥協。
いつものことながら画面表示に安っぽさ&イモっぽさがほとばしっていますが、そこは安定のこよるクオリティということで。

二枚目。こちらは試合消化画面。パワプロのペナントで数試合を一瞬で処理しているのをみてすげぇなぁと思った記憶がありますが、案外いけました。3試合で待ち時間は5~10フレーム程度。ローグの崖のときはあんなに処理の重さにてこずっていたのに、くそ。
あ、そういえば、片道勇者のスライドするメニューコマンドが格好いいと思ったので真似ようと思ったんですが、見事に失敗しました。
しかしここ数日RPGを作っている気がしないな…。
というわけで(というわけでもないですが)、野球シミュレーションを作ってみました。好き嫌いが分かれると思うので、ほぼ完全に寄り道要素。
製作途中なのでまだテキトーですが、とりあえずスクリーンショット。

これは試合中画面ですね。ご覧の通りモンスターを選手として育成する(という名目のただの野球シミュレーション)ゲームです。RPG内のゲームなのでRPGっぽく演出しようと思ったが、あまりうまくいかず。まぁ試合を飛ばすモードもあるし、いちいち試合をみる人もいないと思うので妥協。
いつものことながら画面表示に安っぽさ&イモっぽさがほとばしっていますが、そこは安定のこよるクオリティということで。

二枚目。こちらは試合消化画面。パワプロのペナントで数試合を一瞬で処理しているのをみてすげぇなぁと思った記憶がありますが、案外いけました。3試合で待ち時間は5~10フレーム程度。ローグの崖のときはあんなに処理の重さにてこずっていたのに、くそ。
あ、そういえば、片道勇者のスライドするメニューコマンドが格好いいと思ったので真似ようと思ったんですが、見事に失敗しました。
しかしここ数日RPGを作っている気がしないな…。