ぼくらの大革命！ver1.3
ぼくらの大革命！ バージョン1.3に更新しました。
ダウンロードは⇒のバナーからどうぞ。
不具合
・新しく追加した宝箱が取っても消えない
・毒沼に入ってもダメージを受けない
・新エリアで勇者PTが仲間から外されていないのに帰り際に仲間になる
・インベントリ内で戦闘記録の数値がおかしい
修正案
・仲間が0になったらインベントリ内のカウントをリセット
本当にこの調整でよかったのかと今でも自信がありません。
先日の調整について、たくさんの意見ありがとうございます。
皆さんの意見を見て、改めて自分のゲームに対する見方がまだまだずれていると気付かされました。
私にとってこのゲームはたくさん集めるのが目的であって、上限が決まっていないものでした。
ですが、もう全て集められることがわかっており、いかにテレポートを使用しないで集めるかというところまで来ているんですね。
（もちろん、まだまだそんなところまで来ていない人もいるでしょう）
私がこのゲームについてこれていないのが、調整に悩んだ一番の原因です。
この日記を書き終わり次第、ゼロから999人集める旅に出ようと思います。
更新内容については、お返事と合わせて書かせていただきます。
ダウンロードは⇒のバナーからどうぞ。
不具合
・新しく追加した宝箱が取っても消えない
・毒沼に入ってもダメージを受けない
・新エリアで勇者PTが仲間から外されていないのに帰り際に仲間になる
・インベントリ内で戦闘記録の数値がおかしい
修正案
・仲間が0になったらインベントリ内のカウントをリセット
本当にこの調整でよかったのかと今でも自信がありません。
先日の調整について、たくさんの意見ありがとうございます。
皆さんの意見を見て、改めて自分のゲームに対する見方がまだまだずれていると気付かされました。
私にとってこのゲームはたくさん集めるのが目的であって、上限が決まっていないものでした。
ですが、もう全て集められることがわかっており、いかにテレポートを使用しないで集めるかというところまで来ているんですね。
（もちろん、まだまだそんなところまで来ていない人もいるでしょう）
私がこのゲームについてこれていないのが、調整に悩んだ一番の原因です。
この日記を書き終わり次第、ゼロから999人集める旅に出ようと思います。
更新内容については、お返事と合わせて書かせていただきます。
スポンサーサイト
スクリプトの更新とぼくらの大革命！
下記のスクリプトを更新しました。
乗り物擬似３Ｄ化
乗り物擬似３Ｄ化 for VX
本当は土曜に書こうと思っていた記事です。
９割完成していたのですが、あれがあーなったので後回しとなりました。
ちょっとの気分転換で更新です。
特に機能は追加してませんが、他のスクリプトと併用しやすくなるような調整と、計量化しました。
併用についてはしやすくなっただけで、当然ですが出来る保証はありません。
逆に競合してしまうかもしれないので、前のバージョンは残しておくことをおすすめします。
素人さんの意見を見て、新しいスクリプトの前にちょっと競合しにくい構造に変えてみようかと思い立ったのが始まり。
で、スクリプトを眺めていたら競合しにくい構造を閃いたのですが、同時に別のことにも気付きました。
先日、自分で書いたスプライトについての日記。
あの中にあった「opasity=0では画面に描写されるけど、visible=falseなら描写されない」というもの。
これってスプライトだけでなく、ビューポートや画面撮影にも言えることなのでは？
つまりは画面撮影するとき、撮影する必要のないビューポートを非表示にすれば、撮影にかかる処理が軽くなるんじゃないかと。
試してみたところ、CPU使用率が１割ほど減りました。
なかなかの計量化。
まさか、書いたばかりの記事が自分のためになるとは思っても見ませんでした。
それから、素人さんの意見（のつもりで書いたわけではないのでしょうけどｗ）がなければ気づかなかったことでした。
書かれていた内容とは違う結果ではありますが、一応書かれていたスクリプトとの競合はしにくくなったと思います。
（ただし、視界拡張や計量化オプションの「予め作成するマップ」を使用するとダメかもしれません）
ひとまず、これでしのいでください。
まさに偶然の産物！
・・・まあ、それ以上の奇跡が起きてしまったわけですけどねｗ
ここからは「ぼくらの大革命！」について。
正直、なんかもうみなさんのやりこみ度が私の想像をはるかに超えてます。
実を言うと、私はこのゲーム、300人集めてくれる人がいれば上々だと思ってました。
私がテストプレイで集めたのが300人越えくらいだったからです。
やりこむ人がいたとしても、500人くらいが限界じゃないかなあと。
600人行く人、もしかしたらいるかなあ。
やりこんだ人ならわかると思いますが、エンディングの評価は500人以降変わりません。
（一応、999人で変わりますが、しょうもない一言だけです）
本当にその程度の認識でした。
テレポートも本当はただのオマケでつけただけです。
そこまでプレイしてくれた人に対する、ちょっとしたサービスのつもりでした。
先日、「魔王のあとに戦うことができる敵がいるのは想定している」とは書きましたが、あれはテレポート前提での人集めを想定しているという意味ではなく、ゲームを作ってる時に「あ、この敵って魔王の後でも戦えるな。まいいか」てな感じで、気づいたけど深く考えずに放置しただけです。
だというのに、もう990人も集めたというコメント、ちらほらいただきました。
え、990人・・・？
柵が壊せずに話しかけられないニワトリが２羽で、入れない家の中にいたのが７人だから・・・
( ﾟдﾟ)・・・
わたくし先日、「コンプリートするのが目的ではない」と書きました。
すみません、コンプリートするのが目的のゲームだったみたいです。
てか、どうやって集めたんでしょうね？
テレポートでどうにかなるレベルだったっけ？
家の中にいる人とか、宿屋どうしたんですか？
六芒星の部屋とか天使とか完全に罠じゃないですかｗ
適当に配置しすぎたので、全員集めるとか絶対無理だと思ってました。
こんなにもやり尽くしてもらえるだなんて、本当に幸せなゲームです。
ありがとうございます。
さて、次の更新についてなのですが、不具合修正のついでにちょっと付けたいと思っていたアイデア等をいくつか導入しようかと思っています。
ですが、300人ぽっちしか集めてない私では、本当に入れていいのかどうかちょっと迷ってたりします。
なので今回ここにいくつか書きますので、「そんなの入れたらヤバイことになる！」ということがあったら遠慮なく言ってください。
一応、更新は（余程のことがない限り）金曜には出そうと思っています。
ちょっと期間が短いですが、よろしくおねがいします。
１．見習い冒険者が仲間に加わる条件を、人数50人以上から40人以上に変更。
これは前から変えたかったものです。
ようやく一気に編集できるような作りに出来たので変えようかと思っているのですが、バランス的に本当にいいのかちょっと迷ってます。
そもそもこの人数にしたのは、この辺りが一つの壁だと思ったからです。
この辺りから本格的にダッシュ移動が制限されて来ると思います。
あと、これ以上の人数が必要な敵も出てきます。
50人だと少しだけ多い気がするんですよね。
40人は少なすぎたりしないでしょうかね？
２．プレイヤーのすぐ後ろの人を調べた際、その人だけを仲間から外して１歩後退する機能の追加。
入れようと思って一度挫折した機能です。
でも、思いついたらすぐ完成しました。
さすがに無制限はまずいと思うので以下の制限は入れています。
・アイテムを手に入れ、そのアイテムを消費することで行える。
・だいたい敵を倒したら２・３個手に入り、そこら辺の箱からも１～３個入手できる。
・仲間の数が１０人未満の場合は、使用せずにパーティ解散をする。
こんなバランスになってます。
新しく入った仲間は先頭に追加され、この機能は先頭のキャラから外していくという仕様上、「狭い部屋にいる人を仲間に入れた後、この機能を使って部屋から出る」といった人集め方法は出来ないはずです。
バランス調整で困ってるのは以上の２点です。
どちらも、ゲームを始めたばかりの人や途中の人を救済するシステムのつもりで作りました。
見落としがあったらまずいので、意見お待ちしてます。
だいぶ長い文になってしまいましたが、以下お返事です。
乗り物擬似３Ｄ化
乗り物擬似３Ｄ化 for VX
本当は土曜に書こうと思っていた記事です。
９割完成していたのですが、あれがあーなったので後回しとなりました。
ちょっとの気分転換で更新です。
特に機能は追加してませんが、他のスクリプトと併用しやすくなるような調整と、計量化しました。
併用についてはしやすくなっただけで、当然ですが出来る保証はありません。
逆に競合してしまうかもしれないので、前のバージョンは残しておくことをおすすめします。
素人さんの意見を見て、新しいスクリプトの前にちょっと競合しにくい構造に変えてみようかと思い立ったのが始まり。
で、スクリプトを眺めていたら競合しにくい構造を閃いたのですが、同時に別のことにも気付きました。
先日、自分で書いたスプライトについての日記。
あの中にあった「opasity=0では画面に描写されるけど、visible=falseなら描写されない」というもの。
これってスプライトだけでなく、ビューポートや画面撮影にも言えることなのでは？
つまりは画面撮影するとき、撮影する必要のないビューポートを非表示にすれば、撮影にかかる処理が軽くなるんじゃないかと。
試してみたところ、CPU使用率が１割ほど減りました。
なかなかの計量化。
まさか、書いたばかりの記事が自分のためになるとは思っても見ませんでした。
それから、素人さんの意見（のつもりで書いたわけではないのでしょうけどｗ）がなければ気づかなかったことでした。
書かれていた内容とは違う結果ではありますが、一応書かれていたスクリプトとの競合はしにくくなったと思います。
（ただし、視界拡張や計量化オプションの「予め作成するマップ」を使用するとダメかもしれません）
ひとまず、これでしのいでください。
まさに偶然の産物！
・・・まあ、それ以上の奇跡が起きてしまったわけですけどねｗ
ここからは「ぼくらの大革命！」について。
正直、なんかもうみなさんのやりこみ度が私の想像をはるかに超えてます。
実を言うと、私はこのゲーム、300人集めてくれる人がいれば上々だと思ってました。
私がテストプレイで集めたのが300人越えくらいだったからです。
やりこむ人がいたとしても、500人くらいが限界じゃないかなあと。
600人行く人、もしかしたらいるかなあ。
やりこんだ人ならわかると思いますが、エンディングの評価は500人以降変わりません。
（一応、999人で変わりますが、しょうもない一言だけです）
本当にその程度の認識でした。
テレポートも本当はただのオマケでつけただけです。
そこまでプレイしてくれた人に対する、ちょっとしたサービスのつもりでした。
先日、「魔王のあとに戦うことができる敵がいるのは想定している」とは書きましたが、あれはテレポート前提での人集めを想定しているという意味ではなく、ゲームを作ってる時に「あ、この敵って魔王の後でも戦えるな。まいいか」てな感じで、気づいたけど深く考えずに放置しただけです。
だというのに、もう990人も集めたというコメント、ちらほらいただきました。
え、990人・・・？
柵が壊せずに話しかけられないニワトリが２羽で、入れない家の中にいたのが７人だから・・・
( ﾟдﾟ)・・・
わたくし先日、「コンプリートするのが目的ではない」と書きました。
すみません、コンプリートするのが目的のゲームだったみたいです。
てか、どうやって集めたんでしょうね？
テレポートでどうにかなるレベルだったっけ？
家の中にいる人とか、宿屋どうしたんですか？
六芒星の部屋とか天使とか完全に罠じゃないですかｗ
適当に配置しすぎたので、全員集めるとか絶対無理だと思ってました。
こんなにもやり尽くしてもらえるだなんて、本当に幸せなゲームです。
ありがとうございます。
さて、次の更新についてなのですが、不具合修正のついでにちょっと付けたいと思っていたアイデア等をいくつか導入しようかと思っています。
ですが、300人ぽっちしか集めてない私では、本当に入れていいのかどうかちょっと迷ってたりします。
なので今回ここにいくつか書きますので、「そんなの入れたらヤバイことになる！」ということがあったら遠慮なく言ってください。
一応、更新は（余程のことがない限り）金曜には出そうと思っています。
ちょっと期間が短いですが、よろしくおねがいします。
１．見習い冒険者が仲間に加わる条件を、人数50人以上から40人以上に変更。
これは前から変えたかったものです。
ようやく一気に編集できるような作りに出来たので変えようかと思っているのですが、バランス的に本当にいいのかちょっと迷ってます。
そもそもこの人数にしたのは、この辺りが一つの壁だと思ったからです。
この辺りから本格的にダッシュ移動が制限されて来ると思います。
あと、これ以上の人数が必要な敵も出てきます。
50人だと少しだけ多い気がするんですよね。
40人は少なすぎたりしないでしょうかね？
２．プレイヤーのすぐ後ろの人を調べた際、その人だけを仲間から外して１歩後退する機能の追加。
入れようと思って一度挫折した機能です。
でも、思いついたらすぐ完成しました。
さすがに無制限はまずいと思うので以下の制限は入れています。
・アイテムを手に入れ、そのアイテムを消費することで行える。
・だいたい敵を倒したら２・３個手に入り、そこら辺の箱からも１～３個入手できる。
・仲間の数が１０人未満の場合は、使用せずにパーティ解散をする。
こんなバランスになってます。
新しく入った仲間は先頭に追加され、この機能は先頭のキャラから外していくという仕様上、「狭い部屋にいる人を仲間に入れた後、この機能を使って部屋から出る」といった人集め方法は出来ないはずです。
バランス調整で困ってるのは以上の２点です。
どちらも、ゲームを始めたばかりの人や途中の人を救済するシステムのつもりで作りました。
見落としがあったらまずいので、意見お待ちしてます。
だいぶ長い文になってしまいましたが、以下お返事です。
感謝とお返事
いつもにも増してコメントが多いので、感謝とコメントお返事を書こうと思います。
まずは、ぼくらの大革命！実況動画の方を視聴させて頂きました。
もう、動画見る前は緊張で胃が痛くなるほどでした。
正直な所、私はこのゲーム、クソゲーと言われても仕方ないと思ってます。
とは言っても、決して嫌いなわけではありません。
短い製作期間の中で、家にいる間はかかりっきりになって作ったゲームです。
愛着はあります。
ですが、やはり完成してみると欠点が多く見られます。
誰が仲間になるのか分かりにくい、
どこ行けばいいのかわからない、
破壊できるものと出来ないものがわからない、
せっかく集めたのに行き止まりについてしまったばかりに全員解散しか無くなってしまう、等々
作った本人でさえ、これくらいのことはプレイしてみてわかりました。
何も知らない人はもっと不便と感じたところがあるでしょう。
そしてそれらの修正が後からできないのがさらに厄介・・・
そう考えると、もうクソゲーと呼ばれても否定が出来ないな・・・というのが私の正直な気持ちです。
ですが、もし続編を作ることがあれば、ステージごとに分けて行き先や倒すべき相手がわかりやすくなるようにするとか、タイムアタック的な要素があれば戦闘ももう少し面白みが増すんじゃないかとか、アイデアはあります。
なので、「このゲームにはまだまだ可能性がある！」という思いもあり、決して悲観的な気持ちだけではありません。
話を戻して動画について。
そんなこんなでクソゲー呼ばわりされるのも覚悟してました。
そういうコメントがあってもおかしくないだろうとも思っていました。
そして動画の時間は30分超・・・
そんなにも耐えなきゃいけないのかと・・・
だけど、見ないわけにはいかない・・・！
もう全て杞憂でしたね。
すぐに不安も吹っ飛び、視聴している間たいへん笑わせて頂きました。
いつも実況動画見てる時は、失礼ながらもゲームしながら喋るだけの動画とか思っちゃってましたが、今回の動画で実況者さんって本当にゲームの面白さを伝えるのが上手いんだなあと、考えを変えさせられました。
30分があっという間でしたね。
しかも、さらにもう１回視聴させて頂きました。
素晴らしい実況動画、有難うございました。
そして実況者さんだけでなく、ゲームをプレイしてくる皆さんにも本当に感謝しています。
実況者さんのおかげで多くの方にプレイしていただくことが出来、そして皆さんが「何人集められた」というように競い合える環境ができたおかげで、このゲームはクソゲーからバカゲーになれたんだと思います。
私も製作者として、皆さんの声には出来る限り応えたいと思います。
今後についてですが、不具合についてはいくつか確認させて頂きました。
動画内にあった建物に入れないのも罠ではなく不具合ですｗ（中には宝箱とかなかったのでまだよかったです）
あまり高い頻度で修正版出すのも悪いので、もっと報告を聞いたり確認作業をしっかりやってから出したいと思ってます。
とは言っても、プレイする人いなくなってから修正しても仕方ないので、木曜か金曜辺りには出したいところ。
以下お返事です。
まずは、ぼくらの大革命！実況動画の方を視聴させて頂きました。
もう、動画見る前は緊張で胃が痛くなるほどでした。
正直な所、私はこのゲーム、クソゲーと言われても仕方ないと思ってます。
とは言っても、決して嫌いなわけではありません。
短い製作期間の中で、家にいる間はかかりっきりになって作ったゲームです。
愛着はあります。
ですが、やはり完成してみると欠点が多く見られます。
誰が仲間になるのか分かりにくい、
どこ行けばいいのかわからない、
破壊できるものと出来ないものがわからない、
せっかく集めたのに行き止まりについてしまったばかりに全員解散しか無くなってしまう、等々
作った本人でさえ、これくらいのことはプレイしてみてわかりました。
何も知らない人はもっと不便と感じたところがあるでしょう。
そしてそれらの修正が後からできないのがさらに厄介・・・
そう考えると、もうクソゲーと呼ばれても否定が出来ないな・・・というのが私の正直な気持ちです。
ですが、もし続編を作ることがあれば、ステージごとに分けて行き先や倒すべき相手がわかりやすくなるようにするとか、タイムアタック的な要素があれば戦闘ももう少し面白みが増すんじゃないかとか、アイデアはあります。
なので、「このゲームにはまだまだ可能性がある！」という思いもあり、決して悲観的な気持ちだけではありません。
話を戻して動画について。
そんなこんなでクソゲー呼ばわりされるのも覚悟してました。
そういうコメントがあってもおかしくないだろうとも思っていました。
そして動画の時間は30分超・・・
そんなにも耐えなきゃいけないのかと・・・
だけど、見ないわけにはいかない・・・！
もう全て杞憂でしたね。
すぐに不安も吹っ飛び、視聴している間たいへん笑わせて頂きました。
いつも実況動画見てる時は、失礼ながらもゲームしながら喋るだけの動画とか思っちゃってましたが、今回の動画で実況者さんって本当にゲームの面白さを伝えるのが上手いんだなあと、考えを変えさせられました。
30分があっという間でしたね。
しかも、さらにもう１回視聴させて頂きました。
素晴らしい実況動画、有難うございました。
そして実況者さんだけでなく、ゲームをプレイしてくる皆さんにも本当に感謝しています。
実況者さんのおかげで多くの方にプレイしていただくことが出来、そして皆さんが「何人集められた」というように競い合える環境ができたおかげで、このゲームはクソゲーからバカゲーになれたんだと思います。
私も製作者として、皆さんの声には出来る限り応えたいと思います。
今後についてですが、不具合についてはいくつか確認させて頂きました。
動画内にあった建物に入れないのも罠ではなく不具合ですｗ（中には宝箱とかなかったのでまだよかったです）
あまり高い頻度で修正版出すのも悪いので、もっと報告を聞いたり確認作業をしっかりやってから出したいと思ってます。
とは言っても、プレイする人いなくなってから修正しても仕方ないので、木曜か金曜辺りには出したいところ。
以下お返事です。
おや、何やら動画の様子が・・・
家に帰ってみてみれば、何故かいつもにもまして大量のメールが・・・
ニコニコ動画・・・？ ぼくらの大革命・・・？
なぜ今更・・・？
ニコニコのランキングみてみると、上位に何か見覚えのあるゲーム画像。
・・・(゜o゜;
えええええええええぇぇぇぇぇぇぇっ！？
まさかの実況動画。
しかもこんなランキング上位に。
・・・実況者さんは私もよく視る方です。
感染性ナイトメアの実況は見させて頂きました。
さすがですね・・・
まずは動画を見るべきか？
いやいや、それよりやらなくてはならないことがある。
たくさん頂いたコメントに目を通さなくてはっ！
ここはまず製作者として行動せねばならないっ！
いや決して動画見るのが恐いとか恥ずかしいとかそういうわけじゃ・・・
そんなこんなで、昨日はたくさん頂いたコメント読ませて頂きました。
不具合報告多いですね・・・
しかも内容がほとんど同じということは、ほとんどの方に発生してしまったと考えてよいでしょう。
ほんと申し訳ないです。
（あと、コメントの内容からしてクソゲーとして晒し上げられたわけではないようなのでホッとしてたりｗ）
とりあえず、よく報告の上がっていた不具合は修正出来たと思います。
こちらからダウンロード出来ます。
セーブデータはコピペすれば使えるはずです。
ちょっと急ぎすぎて不安ですが、そんな大きな修正は加えてないから平気なはず・・・
主な修正内容は
・ロードした際、壁の後ろ（本来通り抜けられる場所）が通れなくなる不具合の修正。
・戦闘中、人数が３人以下でメンバーが入れ替わると発生するエラーの修正。
・やり直し用のデータを外部に保存する方式に変更。
といったところです。
あと、細かい所いろいろ。
確認できなかった不具合ですが
・ドリアードのいる森で、草を狩ったのに通れない不具合。
・何らかの条件でロードを行うとフリーズしてしまう不具合。
・後ろをついてくる仲間の表示位置がおかしいことがある。
以上は確認出来次第、修正したいと思います。
修正内容にあるやり直しについてですが、データを外部に保存する方式に変更したため、ロード後もやり直しが出来るようになっています。
今までロード後にやり直しが出来なかったのは、データを内部に保存しており、それをセーブデータに含めないようにしていたためです。
ただでさえ５００人くらいになるとセーブに時間かかるのに、やり直し用のデータ含めるとさらに倍の時間がかかってしまうから・・・というのが一番の理由であって、バランス調整とかではありません。
いろいろと完成を急ぎすぎてしまった作品ではありますが、たくさんの方にプレイして頂けてほんとうに感謝です。
拙い作品ですが楽しんでいただけたら幸いです。
改めて、たくさんのコメントありがとうございます。
お返事については、上記に含まれていない内容のものを書かせて頂きます。
・見覚えのあるマップうんぬん
マップの殆どはツクールAceに入っているサンプルマップを改変して使用しています。
他にも使っている作者さんは多いと思います。
あと、人一人しか通れない道が多いのもサンプルマップだからだったりします。
> アイビス さん
それはニコニコ自作ゲームフェスに投稿した作品ということでよろしいのでしょうか？
それであればもちろんＯＫです。
また何か不備があるようでしたら連絡ください。
・ドリアードの森の草を刈ることができません。
あれはドリアードが仲間にいるとき消せるはずです。草刈り鎌ではありません。
こういう「消せるかどうかわからない」「仲間に入ってくれるかどうか話しかけないとわからない」「仲間にいないと消せないオブジェクトが多い」というのは私も反省してます。
以前も書きましたが、本当に後の祭りでして、容易に修正できない作りにしてしまったのがこの作品最大の失敗です・・・
・森のステージの障害物が邪魔で攻略できません。
森というと奥に妖精が入るほうかな？
こちらはドリアードが仲間にいないと通れません。
そしてドリアードはミニドラゴンがいないと会えません。
自由に歩けるようで、結構攻略順が限られてたりします。
いろいろと後付が多いんです・・・
・どうやったダッシュできますか？
シフトキー押しながら方向キーでダッシュできるはずです。
ゲームパッドならボタン１です。
ツクールはF1を押すとその辺の変更が出来る仕様になっています。
が、このゲームはダッシュが命取りになるので注意してくださいｗ
ニコニコ動画・・・？ ぼくらの大革命・・・？
なぜ今更・・・？
ニコニコのランキングみてみると、上位に何か見覚えのあるゲーム画像。
・・・(゜o゜;
えええええええええぇぇぇぇぇぇぇっ！？
まさかの実況動画。
しかもこんなランキング上位に。
・・・実況者さんは私もよく視る方です。
感染性ナイトメアの実況は見させて頂きました。
さすがですね・・・
まずは動画を見るべきか？
いやいや、それよりやらなくてはならないことがある。
たくさん頂いたコメントに目を通さなくてはっ！
ここはまず製作者として行動せねばならないっ！
いや決して動画見るのが恐いとか恥ずかしいとかそういうわけじゃ・・・
そんなこんなで、昨日はたくさん頂いたコメント読ませて頂きました。
不具合報告多いですね・・・
しかも内容がほとんど同じということは、ほとんどの方に発生してしまったと考えてよいでしょう。
ほんと申し訳ないです。
（あと、コメントの内容からしてクソゲーとして晒し上げられたわけではないようなのでホッとしてたりｗ）
とりあえず、よく報告の上がっていた不具合は修正出来たと思います。
こちらからダウンロード出来ます。
セーブデータはコピペすれば使えるはずです。
ちょっと急ぎすぎて不安ですが、そんな大きな修正は加えてないから平気なはず・・・
主な修正内容は
・ロードした際、壁の後ろ（本来通り抜けられる場所）が通れなくなる不具合の修正。
・戦闘中、人数が３人以下でメンバーが入れ替わると発生するエラーの修正。
・やり直し用のデータを外部に保存する方式に変更。
といったところです。
あと、細かい所いろいろ。
確認できなかった不具合ですが
・ドリアードのいる森で、草を狩ったのに通れない不具合。
・何らかの条件でロードを行うとフリーズしてしまう不具合。
・後ろをついてくる仲間の表示位置がおかしいことがある。
以上は確認出来次第、修正したいと思います。
修正内容にあるやり直しについてですが、データを外部に保存する方式に変更したため、ロード後もやり直しが出来るようになっています。
今までロード後にやり直しが出来なかったのは、データを内部に保存しており、それをセーブデータに含めないようにしていたためです。
ただでさえ５００人くらいになるとセーブに時間かかるのに、やり直し用のデータ含めるとさらに倍の時間がかかってしまうから・・・というのが一番の理由であって、バランス調整とかではありません。
いろいろと完成を急ぎすぎてしまった作品ではありますが、たくさんの方にプレイして頂けてほんとうに感謝です。
拙い作品ですが楽しんでいただけたら幸いです。
改めて、たくさんのコメントありがとうございます。
お返事については、上記に含まれていない内容のものを書かせて頂きます。
・見覚えのあるマップうんぬん
マップの殆どはツクールAceに入っているサンプルマップを改変して使用しています。
他にも使っている作者さんは多いと思います。
あと、人一人しか通れない道が多いのもサンプルマップだからだったりします。
> アイビス さん
それはニコニコ自作ゲームフェスに投稿した作品ということでよろしいのでしょうか？
それであればもちろんＯＫです。
また何か不備があるようでしたら連絡ください。
・ドリアードの森の草を刈ることができません。
あれはドリアードが仲間にいるとき消せるはずです。草刈り鎌ではありません。
こういう「消せるかどうかわからない」「仲間に入ってくれるかどうか話しかけないとわからない」「仲間にいないと消せないオブジェクトが多い」というのは私も反省してます。
以前も書きましたが、本当に後の祭りでして、容易に修正できない作りにしてしまったのがこの作品最大の失敗です・・・
・森のステージの障害物が邪魔で攻略できません。
森というと奥に妖精が入るほうかな？
こちらはドリアードが仲間にいないと通れません。
そしてドリアードはミニドラゴンがいないと会えません。
自由に歩けるようで、結構攻略順が限られてたりします。
いろいろと後付が多いんです・・・
・どうやったダッシュできますか？
シフトキー押しながら方向キーでダッシュできるはずです。
ゲームパッドならボタン１です。
ツクールはF1を押すとその辺の変更が出来る仕様になっています。
が、このゲームはダッシュが命取りになるので注意してくださいｗ
スクリプトの更新とSpriteでいろいろ実験 その２
下記のスクリプトを更新しました。
乗り物擬似３Ｄ化 視界拡張
乗り物擬似３Ｄ化 計量化
ゲーム起動時にビットマップに変換するのがうまく動作してなかったので修正しました。
ついでに、ビットマップへの変換作業をゲーム起動時ではなく、ニューゲーム選択後やロード後の暗転時に行えるような機能を追加しました。
ゲーム起動までが長いとちょっとストレスになりそうだし、ちゃんと起動してるのか不安になるのに対して、ニューゲーム選択後やロード後に待たされるのって若干許される感じがするという理由でつけてみました。
ツクール製のゲームなのに読み込みあるって時点で違和感ありますけどね。
前回の続き。
実験その４・原点0,0での回転
大きめのピクチャを原点左上 座標 X:0 Y:0 で回転させた時の角度ごとのFPSを測ってみました。
結果はこんな感じ。
0～90度 : 20fps
90～360度 : 60fps
0～90度とはピクチャが少しでも画面に写っている状態です。
原点位置が0,0なので、90～360度の間は画面に表示されません。
結果から見て、スプライトを回転させても画面内に無ければ回転処理を一切行わないようです。
しっかりと計量化されてるんですね。
ちなみに原点位置をX:1,Y:1にして、90～360度でもわずかに画面に写るようにしてみたところ、常に20fpsまで下がってしまいました。
どうやら、わずかでも画面に写ると画像全体の回転処理が行われるようです。
実験その５・画面に写っていない部分をsrc_rectで削る
ひたすら横に長いスプライトで画面に写っていない部分をsrc_rectを使って削った場合のどうなるかという実験。
この実験では回転描写を使っていないので、とにかくでかいビットマップを用意して実験してみました。
Aは普通に表示。Bは画面に写っていない部分をsrc_rectで削った場合です。
A : 60fps
B : 60fps
と、ここで初めて差がでませんでした。
いくらビットマップを大きくしても、全体的な動作は不安定になりますが大きな差が出ることはありませんでした。
むしろ「src_rectで余計な部分を削る」という処理が行われる分、Bの方が若干重いかも？
今までの実験結果からして、「写ってなくても全体の描写がされるからsrc_rectでできる限り無駄な部分を削ったほうがよい」と思っていたのですが、それはどうやら回転描写に限ったことのようです。
なので、でかい画像だからって余計な部分を削る必要は無さそうです。
ここもしっかりと軽量化されてるんですね。
で、以上二つの結果から何が言えるかというと、「画面の外にあるスプライトを更新しない」系の計量化スクリプトは、実はそれほど効果がないということです。
ないことはないですが、「画面から離れてるイベントは自律移動させない計量化」に比べると効果が薄いです。
続きはあるようなないような。
乗り物擬似３Ｄ化 視界拡張
乗り物擬似３Ｄ化 計量化
ゲーム起動時にビットマップに変換するのがうまく動作してなかったので修正しました。
ついでに、ビットマップへの変換作業をゲーム起動時ではなく、ニューゲーム選択後やロード後の暗転時に行えるような機能を追加しました。
ゲーム起動までが長いとちょっとストレスになりそうだし、ちゃんと起動してるのか不安になるのに対して、ニューゲーム選択後やロード後に待たされるのって若干許される感じがするという理由でつけてみました。
ツクール製のゲームなのに読み込みあるって時点で違和感ありますけどね。
前回の続き。
実験その４・原点0,0での回転
大きめのピクチャを原点左上 座標 X:0 Y:0 で回転させた時の角度ごとのFPSを測ってみました。
結果はこんな感じ。
0～90度 : 20fps
90～360度 : 60fps
0～90度とはピクチャが少しでも画面に写っている状態です。
原点位置が0,0なので、90～360度の間は画面に表示されません。
結果から見て、スプライトを回転させても画面内に無ければ回転処理を一切行わないようです。
しっかりと計量化されてるんですね。
ちなみに原点位置をX:1,Y:1にして、90～360度でもわずかに画面に写るようにしてみたところ、常に20fpsまで下がってしまいました。
どうやら、わずかでも画面に写ると画像全体の回転処理が行われるようです。
実験その５・画面に写っていない部分をsrc_rectで削る
ひたすら横に長いスプライトで画面に写っていない部分をsrc_rectを使って削った場合のどうなるかという実験。
この実験では回転描写を使っていないので、とにかくでかいビットマップを用意して実験してみました。
Aは普通に表示。Bは画面に写っていない部分をsrc_rectで削った場合です。
A : 60fps
B : 60fps
と、ここで初めて差がでませんでした。
いくらビットマップを大きくしても、全体的な動作は不安定になりますが大きな差が出ることはありませんでした。
むしろ「src_rectで余計な部分を削る」という処理が行われる分、Bの方が若干重いかも？
今までの実験結果からして、「写ってなくても全体の描写がされるからsrc_rectでできる限り無駄な部分を削ったほうがよい」と思っていたのですが、それはどうやら回転描写に限ったことのようです。
なので、でかい画像だからって余計な部分を削る必要は無さそうです。
ここもしっかりと軽量化されてるんですね。
で、以上二つの結果から何が言えるかというと、「画面の外にあるスプライトを更新しない」系の計量化スクリプトは、実はそれほど効果がないということです。
ないことはないですが、「画面から離れてるイベントは自律移動させない計量化」に比べると効果が薄いです。
続きはあるようなないような。
Spriteでいろいろ実験 その１
久しぶりのRGSSについて。
スクリプトさっぱりの人には関係ないお話です。
むかーし、まだVXを使ってた頃、スプライトをどう使えば処理が軽くなるかいろいろと試したことがあります。
長くなりそうなので分割で。
最初に書いておきますが、この結果はVXでの実験結果なので、もしかしたらAceでは変わっているかもしれません。あしからず。
スプライトの表示で重い処理といえば、回転描写です。
もしかしたら色調変更も重いかもしれませんが、めったに使うもんでもないので無視します。
今後スプライトを使っていく上で、どのような状態で回転描写を行えば処理が軽くなるか、というのを試してみたことがあります。
主に「箱庭の勇者たち」を作るための下準備です。
実験に使ったパソコンは、VXですら20fpsくらいでしか動かないような古いのを使いました。
まずは基本的なことから。
実験その１・拡大したスプライトの回転
Aでは大きく拡大した状態で回転処理を行い、Bでは通常サイズのまま回転処理を行いました。
ビットマップは同じ物です。
結果は以下のとおり。
A : 約20fps
B : 約60fps
表示しているビットマップは同じでも、拡大した場合処理が重くなります。
処理の重さはビットマップの大きさではなく、実際に表示している大きさが関係しているようです。
ピクチャでも同じ事なので、拡大したピクチャを回転するのはやめたほうがいいです。
この結果を見て、じゃあ逆に縮小して回転させた場合は処理が軽いのか、と思うかもしれませんがどうやら違うようです。
というか、私もつい最近まで縮小して回転させれば処理が軽いと思ってました。
ですが、乗り物疑似３Ｄ化の視界拡張を作っているとき、どうも縮小したところで元の画像が大きいと負荷が高いということに気付きました。
なので、おそらく元の画像より小さくしても軽くなることはありません。
これを考慮して、「箱庭の勇者たち」の表示関係は体験版からちょっと変更加えてます。
実験その２・透明の画像の回転
Aの画像は、イラストは小さいですが余白の多いビットマップ。余白の部分は透明です。
Bの画像は、余白のないビットマップです。
画像の大きさは違いますが、実際の画面では全く同じ物が表示されます。
これらを回転させた結果は以下のとおり。
A : 約20fps
B : 約60fps
余白が多いものは処理が重いです。
つまり、余白の部分も回転処理を行なっているということです。
・・・当然ですよね。
さらに似たような実験で、Aの余白の多い画像をスプライトのsrc_rectを使ってBと同じくらいまで余白を削った場合、約60fpsまで上がりました。
回転処理はsrc_rectで画面に表示されている部分だけ行われているようです。
画像を回転させる場合、余白は極力削ったほうがよさそうです。
実験その３・opacity=0とvisible=falseの違い
opacityはスプライトの不透明度で、0にすると画面に表示されなくなります。
visibleは可視状態で、faiseにすると不可視になります。
一見同じように見えますが、これらを回転させると処理速度には違いが出ます。
opacity=0の場合 : 約20fps
visible=falseの場合 : 約60fps
どうもopacity=0では透明状態で描写を行なっているようです。
これは回転描写にかぎらず、opacityが0で表示されないスプライトは、不可視にしておいたほうがよさそうです。
今回は以上で。
ニコニコ自作ゲームフェス2やるんだってね。
ノートパソコンほしいなあとは思いますが、新作作る気もないしネタもないしどうせ入賞できないし・・・
そして何より、これから暑くなるからダレること間違いなし！
以下お返事
> 素人 さん
報告ありがとうございます。
乗り物擬似３Ｄ化の軽量化スクリプトを確認した所、しょうもないミスが見つかったので修正しました。
競合ではなく、単純な軽量化スクリプト側のミスです。
ほんとにこんなの見逃すなんて、我ながら情けない・・・(_ _;
スクリプトさっぱりの人には関係ないお話です。
むかーし、まだVXを使ってた頃、スプライトをどう使えば処理が軽くなるかいろいろと試したことがあります。
長くなりそうなので分割で。
最初に書いておきますが、この結果はVXでの実験結果なので、もしかしたらAceでは変わっているかもしれません。あしからず。
スプライトの表示で重い処理といえば、回転描写です。
もしかしたら色調変更も重いかもしれませんが、めったに使うもんでもないので無視します。
今後スプライトを使っていく上で、どのような状態で回転描写を行えば処理が軽くなるか、というのを試してみたことがあります。
主に「箱庭の勇者たち」を作るための下準備です。
実験に使ったパソコンは、VXですら20fpsくらいでしか動かないような古いのを使いました。
まずは基本的なことから。
実験その１・拡大したスプライトの回転
Aでは大きく拡大した状態で回転処理を行い、Bでは通常サイズのまま回転処理を行いました。
ビットマップは同じ物です。
結果は以下のとおり。
A : 約20fps
B : 約60fps
表示しているビットマップは同じでも、拡大した場合処理が重くなります。
処理の重さはビットマップの大きさではなく、実際に表示している大きさが関係しているようです。
ピクチャでも同じ事なので、拡大したピクチャを回転するのはやめたほうがいいです。
この結果を見て、じゃあ逆に縮小して回転させた場合は処理が軽いのか、と思うかもしれませんがどうやら違うようです。
というか、私もつい最近まで縮小して回転させれば処理が軽いと思ってました。
ですが、乗り物疑似３Ｄ化の視界拡張を作っているとき、どうも縮小したところで元の画像が大きいと負荷が高いということに気付きました。
なので、おそらく元の画像より小さくしても軽くなることはありません。
これを考慮して、「箱庭の勇者たち」の表示関係は体験版からちょっと変更加えてます。
実験その２・透明の画像の回転
Aの画像は、イラストは小さいですが余白の多いビットマップ。余白の部分は透明です。
Bの画像は、余白のないビットマップです。
画像の大きさは違いますが、実際の画面では全く同じ物が表示されます。
これらを回転させた結果は以下のとおり。
A : 約20fps
B : 約60fps
余白が多いものは処理が重いです。
つまり、余白の部分も回転処理を行なっているということです。
・・・当然ですよね。
さらに似たような実験で、Aの余白の多い画像をスプライトのsrc_rectを使ってBと同じくらいまで余白を削った場合、約60fpsまで上がりました。
回転処理はsrc_rectで画面に表示されている部分だけ行われているようです。
画像を回転させる場合、余白は極力削ったほうがよさそうです。
実験その３・opacity=0とvisible=falseの違い
opacityはスプライトの不透明度で、0にすると画面に表示されなくなります。
visibleは可視状態で、faiseにすると不可視になります。
一見同じように見えますが、これらを回転させると処理速度には違いが出ます。
opacity=0の場合 : 約20fps
visible=falseの場合 : 約60fps
どうもopacity=0では透明状態で描写を行なっているようです。
これは回転描写にかぎらず、opacityが0で表示されないスプライトは、不可視にしておいたほうがよさそうです。
今回は以上で。
ニコニコ自作ゲームフェス2やるんだってね。
ノートパソコンほしいなあとは思いますが、新作作る気もないしネタもないしどうせ入賞できないし・・・
そして何より、これから暑くなるからダレること間違いなし！
以下お返事
> 素人 さん
報告ありがとうございます。
乗り物擬似３Ｄ化の軽量化スクリプトを確認した所、しょうもないミスが見つかったので修正しました。
競合ではなく、単純な軽量化スクリプト側のミスです。
ほんとにこんなの見逃すなんて、我ながら情けない・・・(_ _;
乗り物疑似3Ｄ化 for VX
【乗り物擬似３Ｄ化 for VX】
乗り物擬似３ＤのツクールVXバージョンです。
おそらく最初で最後のRGSS2素材です。
申し訳ないですが、オプションの方は移植する予定はありません。
VXは起動が遅いので、何十回もテストプレイしながら動作確認するのが非常に辛かったりします。
VXAceからVXの移植は楽な方だとは思いますが、それでも細かい仕様が違うためいろいろと面倒くさいです。
以下お返事
乗り物擬似３ＤのツクールVXバージョンです。
おそらく最初で最後のRGSS2素材です。
申し訳ないですが、オプションの方は移植する予定はありません。
VXは起動が遅いので、何十回もテストプレイしながら動作確認するのが非常に辛かったりします。
VXAceからVXの移植は楽な方だとは思いますが、それでも細かい仕様が違うためいろいろと面倒くさいです。
以下お返事
