ニコニコ自作ゲームフェス
まずはコメントにも書きましたが、「乗り物擬似３Ｄ化 視界拡張」をバージョン1.0.1に更新しています。
内容は、コンパス表示と併用した時に発生するエラーの対処です。
併用のチェックしてないのモロバレですね・・・
乗り物擬似３Ｄ化はあと一つオプション公開する予定です。
内容は計量化。・・・とは言っても、中身は視界拡張から視界拡張を取り除いたものです。
・・・え？ それ何が残るのかって？
タイルをビットマップに変換する面倒な設定だけが残ります。
効果の程は、タスクマネージャのCPU使用率を視た限り通常の２／３といったところでしょうか。
中身がほぼ同じな視界拡張との併用は出来ない予定。
重くなければ使う必要ありません。
ちょっとオマケな機能もついてますが、遊びでつけた機能なので安定性は求めないでください。
ニコニコ自作ゲームフェスで各賞が発表されたみたいですね。
公式っぽいページが全く更新されませんが、どうなってるんでしょうね？
私が投稿した作品では、「アクイ ト アイ」がツクール賞、「ぼくらの大革命！」が敢闘賞いただきました。
選考していただいた方、プレイしてくれた方、本当に有難うございます。
あんなつたない動画を見てくれた方、それだけでも十分嬉しいです。
・・・それにしてもこの賞、どういった基準で選ばれているんでしょうね。
「アクイ ト アイ」は素直にやったー！と思いましたが、「ぼくらの大革命！」は欠点多すぎて（作った本人が言うのもなんですが）本当にプレイしてくれたのかなとちょっと疑ってたり。
アイデアは良かったというのが認められたんでしょうか？ そう思っておきましょう。
ちなみに私もいくつかプレイしましたが、どれもツクール賞や敢闘賞でした。
さて、今まで私はほとんど作った作品には触れて来なかったわけですが、結果が出たということでちょっと触れて行きましょう。
一応伏せてますが、ネタバレあります。
クリアしてないかたは注意！
内容は、コンパス表示と併用した時に発生するエラーの対処です。
併用のチェックしてないのモロバレですね・・・
乗り物擬似３Ｄ化はあと一つオプション公開する予定です。
内容は計量化。・・・とは言っても、中身は視界拡張から視界拡張を取り除いたものです。
・・・え？ それ何が残るのかって？
タイルをビットマップに変換する面倒な設定だけが残ります。
効果の程は、タスクマネージャのCPU使用率を視た限り通常の２／３といったところでしょうか。
中身がほぼ同じな視界拡張との併用は出来ない予定。
重くなければ使う必要ありません。
ちょっとオマケな機能もついてますが、遊びでつけた機能なので安定性は求めないでください。
ニコニコ自作ゲームフェスで各賞が発表されたみたいですね。
公式っぽいページが全く更新されませんが、どうなってるんでしょうね？
私が投稿した作品では、「アクイ ト アイ」がツクール賞、「ぼくらの大革命！」が敢闘賞いただきました。
選考していただいた方、プレイしてくれた方、本当に有難うございます。
あんなつたない動画を見てくれた方、それだけでも十分嬉しいです。
・・・それにしてもこの賞、どういった基準で選ばれているんでしょうね。
「アクイ ト アイ」は素直にやったー！と思いましたが、「ぼくらの大革命！」は欠点多すぎて（作った本人が言うのもなんですが）本当にプレイしてくれたのかなとちょっと疑ってたり。
アイデアは良かったというのが認められたんでしょうか？ そう思っておきましょう。
ちなみに私もいくつかプレイしましたが、どれもツクール賞や敢闘賞でした。
さて、今まで私はほとんど作った作品には触れて来なかったわけですが、結果が出たということでちょっと触れて行きましょう。
一応伏せてますが、ネタバレあります。
クリアしてないかたは注意！
スポンサーサイト
スクリプトの更新と視界拡張
下記のスクリプトを更新しました。
乗り物擬似３Ｄ化
乗り物擬似３Ｄ化 コンパス表示
乗り物擬似３Ｄ化はデータベース・ゲームデータともに更新してあります。
更新する際は、必ず両方してください。
主な変更点は
・今後のことを考えて、拡張しやすいように所々変更。
・イベントを調べることの出来る機能の追加。
├ デフォルトでも可能な機能なので追加しました。
└ 空飛ぶ乗り物ではイベントを調べることができません。
・接触によって起動するイベントのうち、同位置によるイベント起動は乗り物が停止しないように変更。
└ プライオリティが「通常キャラと同じ」になっている衝突起動のイベントは、今までどおりその場で停止します。
・不具合を幾つか修正。
その他、細かい機能の追加は各ページを見てください。
【乗り物擬似３Ｄ化 視界拡張】
乗り物擬似３Ｄ化の視界距離を伸ばします。
少し面倒なスクリプトなので、「どうしても視界距離を伸ばしたい！」という場合でない限り、使わないほうが無難かもしれません。
また何か不具合があったり、使い方がわからないということがあったらコメントください。
乗り物擬似３Ｄ化
乗り物擬似３Ｄ化 コンパス表示
乗り物擬似３Ｄ化はデータベース・ゲームデータともに更新してあります。
更新する際は、必ず両方してください。
主な変更点は
・今後のことを考えて、拡張しやすいように所々変更。
・イベントを調べることの出来る機能の追加。
├ デフォルトでも可能な機能なので追加しました。
└ 空飛ぶ乗り物ではイベントを調べることができません。
・接触によって起動するイベントのうち、同位置によるイベント起動は乗り物が停止しないように変更。
└ プライオリティが「通常キャラと同じ」になっている衝突起動のイベントは、今までどおりその場で停止します。
・不具合を幾つか修正。
その他、細かい機能の追加は各ページを見てください。
【乗り物擬似３Ｄ化 視界拡張】
乗り物擬似３Ｄ化の視界距離を伸ばします。
少し面倒なスクリプトなので、「どうしても視界距離を伸ばしたい！」という場合でない限り、使わないほうが無難かもしれません。
また何か不具合があったり、使い方がわからないということがあったらコメントください。
スクリプトの更新
下記のスクリプトを更新しました。
乗り物擬似３Ｄ化
・シーン変更に関する不具合をいくつかの修正
今度こそ、本当の完成です。・・・たぶん
>哲 さん
ありがとうございます。
喜んで頂けたようで嬉しい限りです。
そして私も似たようなことは考えましたｗ
加速度設定できたりイベントでの操作なんかできるようにとか考えましたが、ただの乗り物スクリプトだと自分に言い聞かせて、必要な物だけにしておきました。
不具合の報告もありがとうございます。
実を言うと私の方ではその不具合確認できず、なんでだろうと思っていたのですが、どうやら先日の追記と同じ部分が原因のようでした。（修正済みだったので発生しないだけでした。
これで修正できているはずです。
本当に、なんであの一行削除してあったんだろう・・・
追記：
なんだか飛空艇の位置が低くなってますが、前のほうがいいという方は以下の部分のスクリプトを検索して書きなおしてください。
乗り物擬似３Ｄ化
・シーン変更に関する不具合をいくつかの修正
今度こそ、本当の完成です。・・・たぶん
>哲 さん
ありがとうございます。
喜んで頂けたようで嬉しい限りです。
そして私も似たようなことは考えましたｗ
加速度設定できたりイベントでの操作なんかできるようにとか考えましたが、ただの乗り物スクリプトだと自分に言い聞かせて、必要な物だけにしておきました。
不具合の報告もありがとうございます。
実を言うと私の方ではその不具合確認できず、なんでだろうと思っていたのですが、どうやら先日の追記と同じ部分が原因のようでした。（修正済みだったので発生しないだけでした。
これで修正できているはずです。
本当に、なんであの一行削除してあったんだろう・・・
追記：
なんだか飛空艇の位置が低くなってますが、前のほうがいいという方は以下の部分のスクリプトを検索して書きなおしてください。
def vscreen_y
Graphics.height - 48 - (flight? ? @altitude * 2 : 0)
end
ゲームデータの706行目くらい？
Graphics.height - 48 - (flight? ? @altitude * 2 : 0)
end
乗り物擬似３Ｄ化
【乗り物擬似３Ｄ化】
乗り物搭乗時の画面を、後方から視た擬似３Ｄで表示します。
完成したとか言いながら、不具合がいくつも見つかり修正してました。
まだ全て修正できた自信はありませんが、目立ったものはないはずなので公開します。
もし何らかの不具合が見つかりましたら、コメントでもメールでも報告していただけると助かります。
そして大半の人には関係ありませんが、そのうちスクリプトの中身も大きく書き換える予定です。
（中身は変わりません）
ちょっとデフォルトと大きく変えてしまったところがあるので、出来る限りデフォルトに近づけたいという自己満足に近い内容です。
でも、デフォルトに近いほど、他の素材と競合しにくいはずです。
こんだけ改造していればあまり関係ありませんが・・・
追記：現在見つかっている不具合
・乗り物搭乗中にセーブした後、そのファイルをロードするとデフォルトの乗り物画面になる
・乗り物搭乗中にコモンイベントが発生するアイテム・スキルを使用すると、デフォルトの乗り物画面になる
・乗り物搭乗中にイベントコマンドでシーン制御系を実行すると、たまにその次のイベントコマンドも実行されてしまう
今後についてですが、「箱庭の勇者たち」作る合間に上記の修正やら不具合修正やらオプションやら作っていこうと思います。
とりあえず作ろうと思っているオプションは、方角表示と視界拡張です。
マップ表示はちょっと大変なので予定にはありません。
でも、方角くらいは表示できるようにしたいと思います。
視界拡張（元タイプＢ）ですが、そこそこ視界も広くなったので急ぐ必要ないかなといった感じです。
一応どんな感じになるかなあと、前回視界を広げた技術をテスト段階のものに入れてみました。
すると・・・
・・・(゜o゜;
さすがにこんなにも必要ないね！
乗り物搭乗時の画面を、後方から視た擬似３Ｄで表示します。
完成したとか言いながら、不具合がいくつも見つかり修正してました。
まだ全て修正できた自信はありませんが、目立ったものはないはずなので公開します。
もし何らかの不具合が見つかりましたら、コメントでもメールでも報告していただけると助かります。
そして大半の人には関係ありませんが、そのうちスクリプトの中身も大きく書き換える予定です。
（中身は変わりません）
ちょっとデフォルトと大きく変えてしまったところがあるので、出来る限りデフォルトに近づけたいという自己満足に近い内容です。
でも、デフォルトに近いほど、他の素材と競合しにくいはずです。
こんだけ改造していればあまり関係ありませんが・・・
追記：現在見つかっている不具合
・乗り物搭乗中にセーブした後、そのファイルをロードするとデフォルトの乗り物画面になる
・乗り物搭乗中にコモンイベントが発生するアイテム・スキルを使用すると、デフォルトの乗り物画面になる
・乗り物搭乗中にイベントコマンドでシーン制御系を実行すると、たまにその次のイベントコマンドも実行されてしまう
今後についてですが、「箱庭の勇者たち」作る合間に上記の修正やら不具合修正やらオプションやら作っていこうと思います。
とりあえず作ろうと思っているオプションは、方角表示と視界拡張です。
マップ表示はちょっと大変なので予定にはありません。
でも、方角くらいは表示できるようにしたいと思います。
視界拡張（元タイプＢ）ですが、そこそこ視界も広くなったので急ぐ必要ないかなといった感じです。
一応どんな感じになるかなあと、前回視界を広げた技術をテスト段階のものに入れてみました。
すると・・・
・・・(゜o゜;
さすがにこんなにも必要ないね！
乗り物擬似３Ｄ化スクリプトについての変更点いろいろ
とりあえずは完成したので近いうちに上げます。
細かな仕様の説明ページ作ったり、本当に大丈夫か色々と確認作業したりとか細かいこと終わったらで。
一応、プロトタイプから変わったことや仕様についていくつか書いておきます。
まずはタイプＡやＢといった分類については無くすことにしました。
今回上げるのがもともとタイプＡと呼ばれていたものですが、タイプＢについては視界拡張機能と言った感じで、オプションとして後から追加するものにしようと思います。
というのも、思った以上にタイプＡとＢに違いがなかったので、ちょっとスクリプト付け足すだけで何とかなりそうです。
フレーム数について。
乗り物擬似３Ｄ化中はFPSを30に下げているというのはいつか書いたと思いますが、これについてはそのままで行きます。
一度60フレームまで上げて動作させてみましたが、フレーム数はなんとか58前後で動作したものの、CPUの使用率は通常時の３倍近くになっていたので、どのパソコンでも安定して動作させられるよう30固定ということにしました。
ただし、イベント処理やウィンドウの更新等は１フレームに２回行うようになっているので、特に問題なく動作すると思います。
操作方法については、プロトタイプとは若干変更してあります。
色々と悩んだ結果、オリジナルの操作方法にできるだけ近くなるようにしました。
最後、ここからが本番、視界ついて。
実はプロトタイプの↓の部分をこのようにコメントアウトすると、このスクリプトが裏でどんな処理をしてるかちょっとだけ視ることができます。
ちゃんと動作してるか確認するときは、よくこれをしてたりします。
で、これを眺めててふと気づいたわけです。
これってもうちょっと視界広げられるんじゃないか？ と
細かい説明はとても書ききれないので簡略化すると・・・
ウィンドウの縦のサイズが416なので、半分の208を二乗して２倍して平方根すると294。
今までの視界距離が256だったので、差の38は理論上伸ばせるということ！
おそらく今まで円を描くような回転していたのを、四角をなぞるように回転させればできるはず！
とはいっても、どういう計算式書けばいいのかさっぱりです。
こういうスクリプトって、動きがイメージできることも大切ですし、それを計算式に変えるのが一番頭が痛くなるところだったりします。
計算式が思い浮かばないなら、条件分岐を使って条件ごとに違う計算式を用意します。
X軸とY軸からアークタンジェントつかってラジアン導いて、それつかってをX軸にサイン、Y軸にコサイン掛ければいいことくらいはわかるので、あとはうまく動くまで適当に計算式を書いて動かしてみます。
そしてすぐに動いたものの丸から四角に変わったため、今度は動きが不自然です。
丸と四角の差分を求めて、その値分補正を加えてとかいろいろとやって、結局別のところから持ってきた数値でなんとか動かすことが出来ました。
今まで遊びで色々とスクリプトいじっては削除してきたけれども、今回のその集大成だったと思います。
なんと！ 視界はあれが限界と言っていましたが、1.5タイル分視界を広げることに成功しました！
・・・まあ、たったの1.5タイルです。48ドットです。
最初からその程度だとは思ってました。
でも、このスクリプトの限界に到達したという達成感があるので、とても満足です。
それにたった1.5タイルとはいえ、視界が広くなったのは感じることができます。
もしかしたら、視界拡張それほど必要ないんじゃないかなーと思ったり。
まあ、視界拡張もその分距離が伸びるんだけどね。
ちなみに画像はないです。
あとは、公開されてからのお楽しみ！
コメントお返事
>哲 さん
こちらこそ意見を貰えて助かってます。
わずらわせるなんてとんでもないです。こういうのをなんとかするのが楽しいんですｗ
それから書かれていたサイトさん見に行きました。
色んなスクリプトがあってすごいですね。
これはいろいろと勉強になりそうですｗ
細かな仕様の説明ページ作ったり、本当に大丈夫か色々と確認作業したりとか細かいこと終わったらで。
一応、プロトタイプから変わったことや仕様についていくつか書いておきます。
まずはタイプＡやＢといった分類については無くすことにしました。
今回上げるのがもともとタイプＡと呼ばれていたものですが、タイプＢについては視界拡張機能と言った感じで、オプションとして後から追加するものにしようと思います。
というのも、思った以上にタイプＡとＢに違いがなかったので、ちょっとスクリプト付け足すだけで何とかなりそうです。
フレーム数について。
乗り物擬似３Ｄ化中はFPSを30に下げているというのはいつか書いたと思いますが、これについてはそのままで行きます。
一度60フレームまで上げて動作させてみましたが、フレーム数はなんとか58前後で動作したものの、CPUの使用率は通常時の３倍近くになっていたので、どのパソコンでも安定して動作させられるよう30固定ということにしました。
ただし、イベント処理やウィンドウの更新等は１フレームに２回行うようになっているので、特に問題なく動作すると思います。
操作方法については、プロトタイプとは若干変更してあります。
色々と悩んだ結果、オリジナルの操作方法にできるだけ近くなるようにしました。
最後、ここからが本番、視界ついて。
実はプロトタイプの↓の部分をこのようにコメントアウトすると、このスクリプトが裏でどんな処理をしてるかちょっとだけ視ることができます。
ちゃんと動作してるか確認するときは、よくこれをしてたりします。
で、これを眺めててふと気づいたわけです。
これってもうちょっと視界広げられるんじゃないか？ と
細かい説明はとても書ききれないので簡略化すると・・・
ウィンドウの縦のサイズが416なので、半分の208を二乗して２倍して平方根すると294。
今までの視界距離が256だったので、差の38は理論上伸ばせるということ！
おそらく今まで円を描くような回転していたのを、四角をなぞるように回転させればできるはず！
とはいっても、どういう計算式書けばいいのかさっぱりです。
こういうスクリプトって、動きがイメージできることも大切ですし、それを計算式に変えるのが一番頭が痛くなるところだったりします。
計算式が思い浮かばないなら、条件分岐を使って条件ごとに違う計算式を用意します。
X軸とY軸からアークタンジェントつかってラジアン導いて、それつかってをX軸にサイン、Y軸にコサイン掛ければいいことくらいはわかるので、あとはうまく動くまで適当に計算式を書いて動かしてみます。
そしてすぐに動いたものの丸から四角に変わったため、今度は動きが不自然です。
丸と四角の差分を求めて、その値分補正を加えてとかいろいろとやって、結局別のところから持ってきた数値でなんとか動かすことが出来ました。
今まで遊びで色々とスクリプトいじっては削除してきたけれども、今回のその集大成だったと思います。
なんと！ 視界はあれが限界と言っていましたが、1.5タイル分視界を広げることに成功しました！
・・・まあ、たったの1.5タイルです。48ドットです。
最初からその程度だとは思ってました。
でも、このスクリプトの限界に到達したという達成感があるので、とても満足です。
それにたった1.5タイルとはいえ、視界が広くなったのは感じることができます。
もしかしたら、視界拡張それほど必要ないんじゃないかなーと思ったり。
まあ、視界拡張もその分距離が伸びるんだけどね。
ちなみに画像はないです。
あとは、公開されてからのお楽しみ！
コメントお返事
>哲 さん
こちらこそ意見を貰えて助かってます。
わずらわせるなんてとんでもないです。こういうのをなんとかするのが楽しいんですｗ
それから書かれていたサイトさん見に行きました。
色んなスクリプトがあってすごいですね。
これはいろいろと勉強になりそうですｗ
気になったことと、続き
先日お返事として書いた
>「遠景」画像を画面のスクロールにフィットさせてマップとして使っている
に対応させようとしたのですが、どうも遠景とキャラクターの位置が同期しない。
試しに新規プロジェクトで試しても同期しなかったので原因を調べた所、ツクール側のスクリプトミスが見つかりました。
具体的に書くと、Game_Mapクラスの165行目
@parallax_x * 16 * w1 / w2
となってますが
@parallax_x * 32 * w1 / w2
が正しい計算式です。
同様に177行目も
@parallax_y * 16 * h1 / h2
ではなく
@parallax_y * 32 * h1 / h2
が正しい計算式です。
これでキャラクターと背景の同期がとれるはず。
この不具合は乗り物擬似３Ｄスクリプトとは別物なので、この中に修正スクリプトは入れません。
修正が必要な方は、各自でお願いします。
昨日の続き。
なんか長ったらしくうんちく書いてしまいましたが、このブログではそういうのも書いてくという趣旨もあるので、興味ない方は適当にスルーしてください。
昨日書いたことで重要なのは、タイルマップを毎フレーム撮影（キャプチャー）しているということです。
実はこれが視界を広げられない原因だったりします。
画面をキャプチャーするので、必然的にそこに写っている範囲までしか視ることが出来ないのです。
２回キャプチャーして視界を広げるというのも試しましたが、急にfpsが一桁まで下がったのでやはりこれが限界です。
そこでタイプＢではタイルマップを使わずに、先にマップを画像に変換して、その画像を縮小・回転させて視界を広げるという手法をとっています。
そうなった場合のデメリットですが、
・マップ画像作成に時間がかかる
・リアルタイムでのマップ更新ができない
・縮小しているため、画像が荒くなる
というのが主なところです。
まず「マップ画像作成に時間がかかる」について
プロトタイプに入っている140×140タイルのマップで約1.5秒かかります。
とは言っても、パソコンのスペックによって変わると思うので、大目に見て２秒といったところでしょうか。
しかもこれは、水辺などのアニメーションをなしにした場合の数値です。
アニメーションを付けるなら、３倍の５～６秒かかります。
とはいっても画像はキャッシュできるので、一度作成すれば二度目からは作成しないということはできます。
場合によっては、ゲーム起動時に画像作ってしまえば、初回の読み込みも発生しません。
しかし、このキャッシュにも欠点があり、ストーリー進行によってマップが変化する場合は使用出来ません。
町が壊れたりとか、ちょっとこだわっただけでも再度画像を作成する必要があります。
さらに欠点として、メモリをたくさん使うというのもあります。
140×140タイルの画像で120MB超、アニメーション付けるなら500MBほど必要になります。
今のパソコンならこれくらい大丈夫でしょうけど、ここからさらに複数のマップがあったりすると、場合によってはプレイできない人も出てくると思います。
画像をキャッシュに入れておくなら、この辺りも考慮しないといけません。
マップ画像が変化しないなら、タイプＢがいいと思います。
ストーリー進行で変化するなら、アニメーション抜きで毎回作成というのもありでしょう。
マップを小さくするのも有効です。
次に「リアルタイムでのマップ更新ができない」について
水辺などのアニメーションくらいならどうにかなりますが、マップ上を移動するものをリアルタイムで表示することが出来なくなります。
最初に画像を作るので、その画像を変化させることができません。
もしかしたら、マップ上にキャラクターも表示できなくなるかもしれません。
表示したい場合は、乗り物乗るたびに画像作成が必要になると思います。
最後の「縮小しているため、画像が荒くなる」について
これは以前も触れてましたが、視界を広くするほど画像が粗くなります。
等倍ならタイプＡと変わらないか、ちょっと広くなると思います。
飛ばない乗り物で視界を広くすると、ちょっと荒いのが分かるかもしれません。
タイプＡとＢの大きな違いはこんな所です。
タイプＢの方が決して優れているわけではありません。
ゲームの内容に合わせて、適切な方を選び調整する必要があります。
視界が広くて、画像が鮮明で、リアルタイムで表示できるものとかは無理です。
このあたりは予めご了承ください。
>「遠景」画像を画面のスクロールにフィットさせてマップとして使っている
に対応させようとしたのですが、どうも遠景とキャラクターの位置が同期しない。
試しに新規プロジェクトで試しても同期しなかったので原因を調べた所、ツクール側のスクリプトミスが見つかりました。
具体的に書くと、Game_Mapクラスの165行目
@parallax_x * 16 * w1 / w2
となってますが
@parallax_x * 32 * w1 / w2
が正しい計算式です。
同様に177行目も
@parallax_y * 16 * h1 / h2
ではなく
@parallax_y * 32 * h1 / h2
が正しい計算式です。
これでキャラクターと背景の同期がとれるはず。
この不具合は乗り物擬似３Ｄスクリプトとは別物なので、この中に修正スクリプトは入れません。
修正が必要な方は、各自でお願いします。
昨日の続き。
なんか長ったらしくうんちく書いてしまいましたが、このブログではそういうのも書いてくという趣旨もあるので、興味ない方は適当にスルーしてください。
昨日書いたことで重要なのは、タイルマップを毎フレーム撮影（キャプチャー）しているということです。
実はこれが視界を広げられない原因だったりします。
画面をキャプチャーするので、必然的にそこに写っている範囲までしか視ることが出来ないのです。
２回キャプチャーして視界を広げるというのも試しましたが、急にfpsが一桁まで下がったのでやはりこれが限界です。
そこでタイプＢではタイルマップを使わずに、先にマップを画像に変換して、その画像を縮小・回転させて視界を広げるという手法をとっています。
そうなった場合のデメリットですが、
・マップ画像作成に時間がかかる
・リアルタイムでのマップ更新ができない
・縮小しているため、画像が荒くなる
というのが主なところです。
まず「マップ画像作成に時間がかかる」について
プロトタイプに入っている140×140タイルのマップで約1.5秒かかります。
とは言っても、パソコンのスペックによって変わると思うので、大目に見て２秒といったところでしょうか。
しかもこれは、水辺などのアニメーションをなしにした場合の数値です。
アニメーションを付けるなら、３倍の５～６秒かかります。
とはいっても画像はキャッシュできるので、一度作成すれば二度目からは作成しないということはできます。
場合によっては、ゲーム起動時に画像作ってしまえば、初回の読み込みも発生しません。
しかし、このキャッシュにも欠点があり、ストーリー進行によってマップが変化する場合は使用出来ません。
町が壊れたりとか、ちょっとこだわっただけでも再度画像を作成する必要があります。
さらに欠点として、メモリをたくさん使うというのもあります。
140×140タイルの画像で120MB超、アニメーション付けるなら500MBほど必要になります。
今のパソコンならこれくらい大丈夫でしょうけど、ここからさらに複数のマップがあったりすると、場合によってはプレイできない人も出てくると思います。
画像をキャッシュに入れておくなら、この辺りも考慮しないといけません。
マップ画像が変化しないなら、タイプＢがいいと思います。
ストーリー進行で変化するなら、アニメーション抜きで毎回作成というのもありでしょう。
マップを小さくするのも有効です。
次に「リアルタイムでのマップ更新ができない」について
水辺などのアニメーションくらいならどうにかなりますが、マップ上を移動するものをリアルタイムで表示することが出来なくなります。
最初に画像を作るので、その画像を変化させることができません。
もしかしたら、マップ上にキャラクターも表示できなくなるかもしれません。
表示したい場合は、乗り物乗るたびに画像作成が必要になると思います。
最後の「縮小しているため、画像が荒くなる」について
これは以前も触れてましたが、視界を広くするほど画像が粗くなります。
等倍ならタイプＡと変わらないか、ちょっと広くなると思います。
飛ばない乗り物で視界を広くすると、ちょっと荒いのが分かるかもしれません。
タイプＡとＢの大きな違いはこんな所です。
タイプＢの方が決して優れているわけではありません。
ゲームの内容に合わせて、適切な方を選び調整する必要があります。
視界が広くて、画像が鮮明で、リアルタイムで表示できるものとかは無理です。
このあたりは予めご了承ください。
ゲーム更新とスクリプト
「アクイ ト アイ」を更新しました。バージョン 1.1 となります。
このゲームの何が悪いかを色々と考えてました。
ストーリーはどうしようもないし変更する気もないので置いとくとして、あのシステムのめんどくささの原因はなんだろう・・・
思いついたのが、スキル変化技を探す楽しみがないこと。
そんでもって、それがボス戦になって急に必要になってくること。
ついでに、変化するかどうか使ってみないとわからないところ。
雑魚戦は特に戦術考えずに攻撃すればよくって、ボス戦になったらスキル変化技を駆使して考えて戦う必要がある。
・・・ってのが理想だったけど、ボス戦に戸惑わないように雑魚戦でも少しスキル変化技に慣れてもらおうと、ちょっと面倒な敵配置したのが悪かった。
結局、雑魚戦もボス戦も面倒になってしまった感じ。
今更スキル変化技を探す楽しみを追加するなんて無理だし、どうしようか・・・と悩んだ結果。
もうスキル変化技公開したほうがいいんじゃないか？ となったわけです。
探す楽しみはもう諦めて、どの技使って戦うかを前もって考える楽しみを優先することにしました。
というわけで、簡単な公式サイトを作り、ほとんどのスキル変化技を表記しました。
弱体は面倒だったので入れてません。
あと、一部のスキルはどの技から発生するかだけシークレットになってます。
さらに、戦闘中はスキル変化後の技が表示されるようになってます。
これで撃たなくてもどの技に変化するかが予めわかります。
一度クリアした方、途中で諦めてしまった方、スキル変化一覧を見てもう一度プレイしてみてはどうでしょうか？
公式サイトは→のバナーからどうぞ。
乗り物擬似３Ｄスクリプトについて
動画作ったり、↑を作ってたりで全く進んでなかったりします。
それだけでは何なので、そろそろタイプＡとＢの違いについて触れようかなと思ったのですが、その前にこのスクリプトがどういう処理を行ってるか簡単に説明から入らないといけなかったり。
でもちょっとアクイトアイの更新で行数使いすぎたので、分割して書こうと思います。
スクリプトさっぱりわからない人にはどうでもいい話です。
あと、ゲームプレイしたいだけでスクリプト素材すら全く興味ない方、もしいたら寄り道ばかりで本当に申し訳ないです。
さて、まずは擬似３Ｄに原理について。
RGSSでは画像を表示するスプライトというのがあるのですが、これは画像を回転させて表示させたり、拡大縮小したりということができます。
ですが、下側だけを横に引き伸ばしたりはできません。
まずはこれを擬似的に再現する必要があります。
これは簡単で、横長のスプライトを縦に並べて、下にあるスプライトほど横に引き伸ばせばいいのです。
こんな感じに。
ただ、これだけでは立体感が出なかったりします。
この状態で擬似３Ｄをやっても、上から下に背景が流れながら横に引き伸ばされていくだけでしかありません。
奥から手間に景色が流れていくというのが、このスクリプトで最も苦労した点だったりします。
今作ってる段階でも、水平移動を行うと地面が歪んで見えてしまいます。
私の頭ではこの計算式が精一杯です。
そしてこういうスクリプトは、探せばいくつか見つかると思います。
「箱庭の勇者たち」の戦闘画面でも地面の描写に使われています。
で、一番の問題が360度見渡せるようにすることです。
スプライトは回転させられるのに何が問題かというと、擬似３Ｄを再現した状態でスプライトを回転させるとこんな風になってしまうからです。
横長の画像が傾いてしまうだけです。
で、これを解消するために私はどうやったかというと、
回転させた画像をGraphics.snap_to_bitmapというゲーム画面撮影機能によって、回転した画像が写っている回転していない画像を作ったのです。
・・・何言ってるか分かりにくいですね。
なんとなくで理解してください。
あとはこの画像を擬似３Ｄで表示するだけです。
そしてこのスクリプトは他にも、タイルマップを擬似３Ｄ化させるために
タイルマップを撮影 → スプライトで回転 → 回転した画像をさらに撮影 → 擬似３Ｄ化
と、かなり暴挙なことやってます。
プロトタイプで気づいた方もいるかもしれませんが、擬似３Ｄを行なっている間はfpsを30まで落として実行しています。
60で試したことはありませんが、おそらくとてつもなく重くなるでしょう。
フレーム数を落としたことで、乗り物を乗っている間はイベント処理にも影響が出ます。
これらは対処に時間がかかるので、処理内容の方を変更して頂く必要があります。
そのへんはご了承ください。
とりあえず、今日はここまで。
次はタイプＡとＢについて書きたいと思います。
最後になりますが、応援コメント本当に有難うございます。
中でもちょっと気になったものがあるので、それについてちょっと書いておこうと思います。
>哲 さん
>「遠景」画像を画面のスクロールにフィットさせてマップとして使っている
そ、それは全く想定していませんでした・・・(゜o゜;
対応していたのは偶然ですｗ
そういえば、サンプルゲームにもそうやってるものがありましたね。
そして、今作ってるタイプＡはちょっと変えたため対応してなかったり・・・
でも数行書き換えるだけなので、対応はできると思います。
この意見がなかったら、プロトタイプでは出来たことが完成品では出来ないなんてことになってました。
本当に助かりました。
このゲームの何が悪いかを色々と考えてました。
ストーリーはどうしようもないし変更する気もないので置いとくとして、あのシステムのめんどくささの原因はなんだろう・・・
思いついたのが、スキル変化技を探す楽しみがないこと。
そんでもって、それがボス戦になって急に必要になってくること。
ついでに、変化するかどうか使ってみないとわからないところ。
雑魚戦は特に戦術考えずに攻撃すればよくって、ボス戦になったらスキル変化技を駆使して考えて戦う必要がある。
・・・ってのが理想だったけど、ボス戦に戸惑わないように雑魚戦でも少しスキル変化技に慣れてもらおうと、ちょっと面倒な敵配置したのが悪かった。
結局、雑魚戦もボス戦も面倒になってしまった感じ。
今更スキル変化技を探す楽しみを追加するなんて無理だし、どうしようか・・・と悩んだ結果。
もうスキル変化技公開したほうがいいんじゃないか？ となったわけです。
探す楽しみはもう諦めて、どの技使って戦うかを前もって考える楽しみを優先することにしました。
というわけで、簡単な公式サイトを作り、ほとんどのスキル変化技を表記しました。
弱体は面倒だったので入れてません。
あと、一部のスキルはどの技から発生するかだけシークレットになってます。
さらに、戦闘中はスキル変化後の技が表示されるようになってます。
これで撃たなくてもどの技に変化するかが予めわかります。
一度クリアした方、途中で諦めてしまった方、スキル変化一覧を見てもう一度プレイしてみてはどうでしょうか？
公式サイトは→のバナーからどうぞ。
乗り物擬似３Ｄスクリプトについて
動画作ったり、↑を作ってたりで全く進んでなかったりします。
それだけでは何なので、そろそろタイプＡとＢの違いについて触れようかなと思ったのですが、その前にこのスクリプトがどういう処理を行ってるか簡単に説明から入らないといけなかったり。
でもちょっとアクイトアイの更新で行数使いすぎたので、分割して書こうと思います。
スクリプトさっぱりわからない人にはどうでもいい話です。
あと、ゲームプレイしたいだけでスクリプト素材すら全く興味ない方、もしいたら寄り道ばかりで本当に申し訳ないです。
さて、まずは擬似３Ｄに原理について。
RGSSでは画像を表示するスプライトというのがあるのですが、これは画像を回転させて表示させたり、拡大縮小したりということができます。
ですが、下側だけを横に引き伸ばしたりはできません。
まずはこれを擬似的に再現する必要があります。
これは簡単で、横長のスプライトを縦に並べて、下にあるスプライトほど横に引き伸ばせばいいのです。
こんな感じに。
ただ、これだけでは立体感が出なかったりします。
この状態で擬似３Ｄをやっても、上から下に背景が流れながら横に引き伸ばされていくだけでしかありません。
奥から手間に景色が流れていくというのが、このスクリプトで最も苦労した点だったりします。
今作ってる段階でも、水平移動を行うと地面が歪んで見えてしまいます。
私の頭ではこの計算式が精一杯です。
そしてこういうスクリプトは、探せばいくつか見つかると思います。
「箱庭の勇者たち」の戦闘画面でも地面の描写に使われています。
で、一番の問題が360度見渡せるようにすることです。
スプライトは回転させられるのに何が問題かというと、擬似３Ｄを再現した状態でスプライトを回転させるとこんな風になってしまうからです。
横長の画像が傾いてしまうだけです。
で、これを解消するために私はどうやったかというと、
回転させた画像をGraphics.snap_to_bitmapというゲーム画面撮影機能によって、回転した画像が写っている回転していない画像を作ったのです。
・・・何言ってるか分かりにくいですね。
なんとなくで理解してください。
あとはこの画像を擬似３Ｄで表示するだけです。
そしてこのスクリプトは他にも、タイルマップを擬似３Ｄ化させるために
タイルマップを撮影 → スプライトで回転 → 回転した画像をさらに撮影 → 擬似３Ｄ化
と、かなり暴挙なことやってます。
プロトタイプで気づいた方もいるかもしれませんが、擬似３Ｄを行なっている間はfpsを30まで落として実行しています。
60で試したことはありませんが、おそらくとてつもなく重くなるでしょう。
フレーム数を落としたことで、乗り物を乗っている間はイベント処理にも影響が出ます。
これらは対処に時間がかかるので、処理内容の方を変更して頂く必要があります。
そのへんはご了承ください。
とりあえず、今日はここまで。
次はタイプＡとＢについて書きたいと思います。
最後になりますが、応援コメント本当に有難うございます。
中でもちょっと気になったものがあるので、それについてちょっと書いておこうと思います。
>哲 さん
>「遠景」画像を画面のスクロールにフィットさせてマップとして使っている
そ、それは全く想定していませんでした・・・(゜o゜;
対応していたのは偶然ですｗ
そういえば、サンプルゲームにもそうやってるものがありましたね。
そして、今作ってるタイプＡはちょっと変えたため対応してなかったり・・・
でも数行書き換えるだけなので、対応はできると思います。
この意見がなかったら、プロトタイプでは出来たことが完成品では出来ないなんてことになってました。
本当に助かりました。
更新と中途報告
こっそりと「ぼくらの大革命！」更新しました。
主に不具合修正とやり直し機能の追加です。
更新履歴にはセーブやロードの高速化とありますが、ほぼ体感出来ません。
消し忘れただけです。
１歩後退機能については実装が難しいのもありますが、これ実装したら全部これでいいようになってしまうので実装しないことにしました。
まだまだ中途半端なゲームですが、遊んでいただけたら嬉しいです。
●乗り物擬似３Ｄ化スクリプトについて
まずはブログコメントや拍手コメント、本当に有難うございます。
コメントいただけると本当に励みになります。
もうやる気が溢れ出ています( ´ー｀)
スクリプト名ですが、上記の通り「乗り物擬似３Ｄ化」とすることにしました。
おそらくこの方がわかりやすいでしょう。
これまで多くのスクリプトを自作して来ましたが、このスクリプトを作るのが一番楽しいです。
このスクリプトで、初めてFF6で飛空挺を手に入れた時の感動を思い出しました。
もう、空を飛んでるだけで楽しいｗ
プラットフォームがプレステに移ってからは、３Ｄが当たり前になってきたのでこういうのはあまり無くなってしまいましたね。
FF7の飛空艇は、移動が楽になった程度の思いしかなかった気がします。
むしろ、初めてフィールドに出た時、世界がフルポリゴンで作られていたことの感動の方が大きかったです。
おそらくこれはスーファミ世代のツクラーなら、一度は探し求めたスクリプトでしょう。
そしてスクリプト組める人の多くが一度は挑戦して、そしてスプライトの仕様を見て不可能だと判断したことでしょう。
私もその一人です。
FF5の飛空艇みたいなスクリプトならすでにあると思います。
ああいうのは私もXPの頃に一度作り、そしてネットで検索したらもっとすごいの作ってる人がいて愕然とした覚えがあります。
ですが、これは私が初めてのはず！
こんな変なスクリプト、考えつく人はそうはいないでしょう。
たぶん、ゲーム１本作るのと同じくらいの宣伝効果あるんじゃないかな？ と勝手に妄想しておりますｗ
さて、進捗状況ですが、
とりあえず、衝突判定と降りる時の判定は実装できたところです。
乗り物に乗った時と降りた時に、一度画面が暗転するようにしました。
テイルズみないなシームレスはとりあえず諦めます。
あと、背景の動きが逆になってる不具合も修正してありますｗ
問題の視界の広さですが、色々試した結果、色々と妥協しないと広げられないという結論に至りました。
ちょっと広げただけでfpsが一桁とかなったりしたので・・・
なので、汎用性の高いタイプＡと、色々と妥協するけど視界の広いタイプＢと、２種類用意しようと思います。
色々と妥協するといっても、ワールドマップならほぼ問題ないような内容なので、おそらくタイプＢの方がいいかもしれません。
ですが、素材としてはまずは汎用性の高いものから作ったほうがいいので、まずはタイプＡを完成させてそのうち公開しようと思います。
ただ、視界の狭さを埋めるためにワールドマップとか表示できないと、自分の場所がわからなくなってしまうかもしれません。
当然ですが、他のサイトのワールドマップ表示スクリプトはまず使えないです。
またそれは作ってから考えるしかないですね・・・
あとさらに、カスタム性も高く作ってあります。
移動速度から移動できる地形、操作方法なんかも変更できます。
陸地と浅瀬を移動できる乗り物だって作れます。
３つ以上の乗り物も作れます。
もちろん、何もいじらなくても導入するだけで操作できるようにしますよ！
あとついでに色々と妥協したタイプＢ（テスト段階）の画像です。
視界の距離は２倍、面積にして４倍まで可能です。
こっちは乗り物毎に視界の距離も変えられます。
ただ、よーく見るとわかりますが、視界を広げると地面の画像が粗くなります。
他にも色々と妥協してます。
最後にもう一度プロトタイプのプロジェクト貼っておきます。
ダウンロードはこちらから！
内容は先日と同じです。
主に不具合修正とやり直し機能の追加です。
更新履歴にはセーブやロードの高速化とありますが、ほぼ体感出来ません。
消し忘れただけです。
１歩後退機能については実装が難しいのもありますが、これ実装したら全部これでいいようになってしまうので実装しないことにしました。
まだまだ中途半端なゲームですが、遊んでいただけたら嬉しいです。
●乗り物擬似３Ｄ化スクリプトについて
まずはブログコメントや拍手コメント、本当に有難うございます。
コメントいただけると本当に励みになります。
もうやる気が溢れ出ています( ´ー｀)
スクリプト名ですが、上記の通り「乗り物擬似３Ｄ化」とすることにしました。
おそらくこの方がわかりやすいでしょう。
これまで多くのスクリプトを自作して来ましたが、このスクリプトを作るのが一番楽しいです。
このスクリプトで、初めてFF6で飛空挺を手に入れた時の感動を思い出しました。
もう、空を飛んでるだけで楽しいｗ
プラットフォームがプレステに移ってからは、３Ｄが当たり前になってきたのでこういうのはあまり無くなってしまいましたね。
FF7の飛空艇は、移動が楽になった程度の思いしかなかった気がします。
むしろ、初めてフィールドに出た時、世界がフルポリゴンで作られていたことの感動の方が大きかったです。
おそらくこれはスーファミ世代のツクラーなら、一度は探し求めたスクリプトでしょう。
そしてスクリプト組める人の多くが一度は挑戦して、そしてスプライトの仕様を見て不可能だと判断したことでしょう。
私もその一人です。
FF5の飛空艇みたいなスクリプトならすでにあると思います。
ああいうのは私もXPの頃に一度作り、そしてネットで検索したらもっとすごいの作ってる人がいて愕然とした覚えがあります。
ですが、これは私が初めてのはず！
こんな変なスクリプト、考えつく人はそうはいないでしょう。
たぶん、ゲーム１本作るのと同じくらいの宣伝効果あるんじゃないかな？ と勝手に妄想しておりますｗ
さて、進捗状況ですが、
とりあえず、衝突判定と降りる時の判定は実装できたところです。
乗り物に乗った時と降りた時に、一度画面が暗転するようにしました。
テイルズみないなシームレスはとりあえず諦めます。
あと、背景の動きが逆になってる不具合も修正してありますｗ
問題の視界の広さですが、色々試した結果、色々と妥協しないと広げられないという結論に至りました。
ちょっと広げただけでfpsが一桁とかなったりしたので・・・
なので、汎用性の高いタイプＡと、色々と妥協するけど視界の広いタイプＢと、２種類用意しようと思います。
色々と妥協するといっても、ワールドマップならほぼ問題ないような内容なので、おそらくタイプＢの方がいいかもしれません。
ですが、素材としてはまずは汎用性の高いものから作ったほうがいいので、まずはタイプＡを完成させてそのうち公開しようと思います。
ただ、視界の狭さを埋めるためにワールドマップとか表示できないと、自分の場所がわからなくなってしまうかもしれません。
当然ですが、他のサイトのワールドマップ表示スクリプトはまず使えないです。
またそれは作ってから考えるしかないですね・・・
あとさらに、カスタム性も高く作ってあります。
移動速度から移動できる地形、操作方法なんかも変更できます。
陸地と浅瀬を移動できる乗り物だって作れます。
３つ以上の乗り物も作れます。
もちろん、何もいじらなくても導入するだけで操作できるようにしますよ！
あとついでに色々と妥協したタイプＢ（テスト段階）の画像です。
視界の距離は２倍、面積にして４倍まで可能です。
こっちは乗り物毎に視界の距離も変えられます。
ただ、よーく見るとわかりますが、視界を広げると地面の画像が粗くなります。
他にも色々と妥協してます。
最後にもう一度プロトタイプのプロジェクト貼っておきます。
ダウンロードはこちらから！
内容は先日と同じです。
プロトタイプ
なんというか・・・
私は飽きっぽいところがあるようですね。
というか、他にやってみたいことがあると、やらなければならないことそっちのけでやってしまうというか。
箱庭は膨大なスクリプトに飽きてきて、
大革命も単純作業に飽きてきて、
実を言うとここ数日、ふと思いついたスクリプト作って遊んでました。
き、気分転換にと思ってね！
ええ、言い訳です・・・
でもその甲斐あってかプロトタイプは出来ました。
とりあえず満足。
というか、ちょっと行き詰まったので、またいい手が思い浮かんだら続き作ります。
で、そのスクリプトが何かというと・・・
私は飽きっぽいところがあるようですね。
というか、他にやってみたいことがあると、やらなければならないことそっちのけでやってしまうというか。
箱庭は膨大なスクリプトに飽きてきて、
大革命も単純作業に飽きてきて、
実を言うとここ数日、ふと思いついたスクリプト作って遊んでました。
き、気分転換にと思ってね！
ええ、言い訳です・・・
でもその甲斐あってかプロトタイプは出来ました。
とりあえず満足。
というか、ちょっと行き詰まったので、またいい手が思い浮かんだら続き作ります。
で、そのスクリプトが何かというと・・・
移動ルート設定の処理改善
イベントの実行内容と移動ルートの設定とでは、処理の仕方が若干違ったりします。
イベント処理では１フレーム内に実行できるものは、全て１フレーム内で行います。
スイッチや変数の操作、アイテムやお金の増減など、ウェイトが必要ないものは全て一瞬で処理します。
ウェイトや文章表示などが実行されると、処理が一旦中断されます。
移動ルートの設定はというと、１フレームで１行処理します。
向きの変更や各種フラグのON/OFFなど、同時に出来るような処理でも１フレームに１つずつです。
つまり、移動ルートの設定は１行毎にウェイト１が入っているような状態です。
とはいっても、１フレーム処理が遅れて困るなんてことはそうはないでしょう。
ある処理を除いては・・・
その処理とは、グラフィックの変更です。
正確には、グラフィックの変更を使ったキャラクターのアニメーションです。
「アクイ ト アイ」ではキャラクターがちょこちょこ動作を見せます。
こういうふうにキャラクターに動きを付ける場合、グラフィックの変更と向きの変更を使って行います。
場合によってはスクリプトでパターンも変化させます。
しかし、先にもあげたように、移動ルートの処理は１フレーム１つです。
グラフィックの変更と向きの変更を同時に行なってはくれません。
そうなるとどうなるかというと、一瞬だけおかしなグラフィックが表示されてしまいます。
グラフィックの変更→向きの変更とやると、一瞬グラフィックの変更後のキャラクターが写り、
向きの変更→グラフィックの変更とやると、一瞬向きを変えたキャラが表示されてしまいます。
たかだか１フレーム。
しかし見えてしまう以上、プレイしてる人に違和感を与えてしまいます。
せっかくゲームにのめり込んでいる時に、あれ？っと別のことに意識が行ってしまうのは、あってほしくないことです。
なので、１フレーム内で処理できるものは処理してしまうスクリプトを作りました。
class Game_Character
#--------------------------------------------------------------------------
# ◯ ルートに沿った移動の更新
#--------------------------------------------------------------------------
alias _wooden_ex_update_routine_move update_routine_move
def update_routine_move
if @wait_count > 0
@wait_count -= 1
else
_wooden_ex_update_routine_move
if @move_route_forcing && @move_succeed && stopping? &&
@wait_count == 0 && @move_route_index >= 0
update_routine_move
end
end
end
end
alias使ってますが、再定義でもいいような内容です。
ループ使っても良かったんですが、再帰呼び出しというのを使ってみたかったのでこんな感じです。
再帰呼び出しというのは知っていましたが、使ったのはこれが初めてだったりします。
またひとつかしこくなった！
話は変わって
「ぼくらの大革命！」の不具合修正とともにちょっと機能追加中です。
「アクイ ト アイ」を作った時に、リトライ機能をつけるのに作ったクイックセーブスクリプトが使えるんじゃないかと思って、付け足してます。
ワールドマップから町やダンジョンに入った時に自動で保存され、いつでもその状態までやり直しが出来るようにしたいなあと思ってます。
あと、１歩後退機能が付けたい所。
ただ、あの隊列スクリプトがちょっと特殊なので、１歩下げるというのがなかなか難しかったりします。
これは諦めるかもしれません。
あとはキャラクターの挙動を調整したいところなのですが、何百個もあるイベントを一つ一つ修正というのは非常につらいものがある・・・
まあ、あまり力を入れても仕方ないので、適当にきりがついたら更新しようと思います。
イベント処理では１フレーム内に実行できるものは、全て１フレーム内で行います。
スイッチや変数の操作、アイテムやお金の増減など、ウェイトが必要ないものは全て一瞬で処理します。
ウェイトや文章表示などが実行されると、処理が一旦中断されます。
移動ルートの設定はというと、１フレームで１行処理します。
向きの変更や各種フラグのON/OFFなど、同時に出来るような処理でも１フレームに１つずつです。
つまり、移動ルートの設定は１行毎にウェイト１が入っているような状態です。
とはいっても、１フレーム処理が遅れて困るなんてことはそうはないでしょう。
ある処理を除いては・・・
その処理とは、グラフィックの変更です。
正確には、グラフィックの変更を使ったキャラクターのアニメーションです。
「アクイ ト アイ」ではキャラクターがちょこちょこ動作を見せます。
こういうふうにキャラクターに動きを付ける場合、グラフィックの変更と向きの変更を使って行います。
場合によってはスクリプトでパターンも変化させます。
しかし、先にもあげたように、移動ルートの処理は１フレーム１つです。
グラフィックの変更と向きの変更を同時に行なってはくれません。
そうなるとどうなるかというと、一瞬だけおかしなグラフィックが表示されてしまいます。
グラフィックの変更→向きの変更とやると、一瞬グラフィックの変更後のキャラクターが写り、
向きの変更→グラフィックの変更とやると、一瞬向きを変えたキャラが表示されてしまいます。
たかだか１フレーム。
しかし見えてしまう以上、プレイしてる人に違和感を与えてしまいます。
せっかくゲームにのめり込んでいる時に、あれ？っと別のことに意識が行ってしまうのは、あってほしくないことです。
なので、１フレーム内で処理できるものは処理してしまうスクリプトを作りました。
class Game_Character
#--------------------------------------------------------------------------
# ◯ ルートに沿った移動の更新
#--------------------------------------------------------------------------
alias _wooden_ex_update_routine_move update_routine_move
def update_routine_move
if @wait_count > 0
@wait_count -= 1
else
_wooden_ex_update_routine_move
if @move_route_forcing && @move_succeed && stopping? &&
@wait_count == 0 && @move_route_index >= 0
update_routine_move
end
end
end
end
alias使ってますが、再定義でもいいような内容です。
ループ使っても良かったんですが、再帰呼び出しというのを使ってみたかったのでこんな感じです。
再帰呼び出しというのは知っていましたが、使ったのはこれが初めてだったりします。
またひとつかしこくなった！
話は変わって
「ぼくらの大革命！」の不具合修正とともにちょっと機能追加中です。
「アクイ ト アイ」を作った時に、リトライ機能をつけるのに作ったクイックセーブスクリプトが使えるんじゃないかと思って、付け足してます。
ワールドマップから町やダンジョンに入った時に自動で保存され、いつでもその状態までやり直しが出来るようにしたいなあと思ってます。
あと、１歩後退機能が付けたい所。
ただ、あの隊列スクリプトがちょっと特殊なので、１歩下げるというのがなかなか難しかったりします。
これは諦めるかもしれません。
あとはキャラクターの挙動を調整したいところなのですが、何百個もあるイベントを一つ一つ修正というのは非常につらいものがある・・・
まあ、あまり力を入れても仕方ないので、適当にきりがついたら更新しようと思います。
ただの日記
そういえば昨日はエイプリルフールでしたが、ツクールばかりやってた私には当然ながらウソ記事なんて作ってる余裕はありませんでした。
なので、今までどおりいろんなサイトさんのエイプリルフールネタを見て楽しみました。
で、
とりあえず一段落ついたということで、今まで作ったゲームや今後についてちょっと記しておこうと思います。
◯「箱庭の勇者たち」について
当然、次はこれですね。
今はまだスクリプトを全部見なおしているところです。
他のゲームでぜんぜん違うシステム作ったおかげか、見にくかったり効率悪い所がちょくちょく見つかり修正してます。
あと、見なおすことで一連の動作を頭のなかに入れなおす意味もあります。
それにしても、スクリプトの量が半端無い・・・
ですが、急ぐつもりもありません。
他のゲーム制作で学んだことは、焦って作るともう少しプレイしなおしていれば見つかるようなミスを残してしまうということです。
特に私は期限とかあると、昔からそれがよく出ます。
◯「アクイ ト アイ」について
もうちょっとゆっくり作ったほうが良かったかなあと、プレイしなおして思います。
作りなおす気はないですけどね。
これはこれで完結です。
結局アクイくんとアイちゃんの関係って最期まで書かれてませんが、ちょっと考えればわかると思います。
ひとひねりはしてありますが、複雑な関係ではありません。
アクイくんのセリフはなかなかきついものがありますが、これは作者の考えというより、作者が自分の嫌いなところを彼に言わせた感じです。
なので彼のセリフで一番ダメージ受けてるのは私です(-_-;
◯「ぼくらの大革命！」について
勢いで作ったせいか、プレイし直すとちょっと遊びにくい印象。
もうちょっとミニゲームっぽくしようかなあと思ったんですけど、こういうミニゲームってありますよね。名前知らないけど。
とにかく人が増えたらダッシュ移動いないようにしましょう！
それでも通れると思ったら通れなくて、全員解散しなくちゃいけなくなるとがっかりです。
動画の最後にもありますね。
職種ごとにもっと個性を付けたかったし、一部の仲間になりにくい人達も何とかしたかった。
やっぱり、ミニゲームっぽくするのが良かったかなあ・・・
作りなおさないけどね！
それからいくつか不具合も見つかってます。
・通行判定がおかしい部分が数ヶ所。
・同じアクターが設定されてるイベントが１０個ほど。
・そして設定し忘れたアクターが３０名ほど。
そのうち修正します。
あとはまたちょくちょくスクリプト素材や遊びでやったことなんか書いていこうと思います。
更新頻度はどうなるかわかりません。
まだ忙しくないけど、これから忙しくなるはず。忙しくなってくれないと困ります。
こんなところかな。
なので、今までどおりいろんなサイトさんのエイプリルフールネタを見て楽しみました。
で、
とりあえず一段落ついたということで、今まで作ったゲームや今後についてちょっと記しておこうと思います。
◯「箱庭の勇者たち」について
当然、次はこれですね。
今はまだスクリプトを全部見なおしているところです。
他のゲームでぜんぜん違うシステム作ったおかげか、見にくかったり効率悪い所がちょくちょく見つかり修正してます。
あと、見なおすことで一連の動作を頭のなかに入れなおす意味もあります。
それにしても、スクリプトの量が半端無い・・・
ですが、急ぐつもりもありません。
他のゲーム制作で学んだことは、焦って作るともう少しプレイしなおしていれば見つかるようなミスを残してしまうということです。
特に私は期限とかあると、昔からそれがよく出ます。
◯「アクイ ト アイ」について
もうちょっとゆっくり作ったほうが良かったかなあと、プレイしなおして思います。
作りなおす気はないですけどね。
これはこれで完結です。
結局アクイくんとアイちゃんの関係って最期まで書かれてませんが、ちょっと考えればわかると思います。
ひとひねりはしてありますが、複雑な関係ではありません。
アクイくんのセリフはなかなかきついものがありますが、これは作者の考えというより、作者が自分の嫌いなところを彼に言わせた感じです。
なので彼のセリフで一番ダメージ受けてるのは私です(-_-;
◯「ぼくらの大革命！」について
勢いで作ったせいか、プレイし直すとちょっと遊びにくい印象。
もうちょっとミニゲームっぽくしようかなあと思ったんですけど、こういうミニゲームってありますよね。名前知らないけど。
とにかく人が増えたらダッシュ移動いないようにしましょう！
それでも通れると思ったら通れなくて、全員解散しなくちゃいけなくなるとがっかりです。
動画の最後にもありますね。
職種ごとにもっと個性を付けたかったし、一部の仲間になりにくい人達も何とかしたかった。
やっぱり、ミニゲームっぽくするのが良かったかなあ・・・
作りなおさないけどね！
それからいくつか不具合も見つかってます。
・通行判定がおかしい部分が数ヶ所。
・同じアクターが設定されてるイベントが１０個ほど。
・そして設定し忘れたアクターが３０名ほど。
そのうち修正します。
あとはまたちょくちょくスクリプト素材や遊びでやったことなんか書いていこうと思います。
更新頻度はどうなるかわかりません。
まだ忙しくないけど、これから忙しくなるはず。忙しくなってくれないと困ります。
こんなところかな。
