RPGツクールVXで搭載されるRGSS2。僕が実際に触って気になる部分をピックアップしましょう。
Graphics.update １０秒呼び出さなくてもハングアップしない
RGSS1の基本構造は、以下のループでした。これはRGSS2でも変わりません。
loop do
Graphics.update
Input.update
# 何かする
end
以下、ヘルプより引用。
RGSS1 では、このメソッドが 10 秒以上に渡って実行されなかった場合、スクリプトが暴走したとみなして強制終了されるようになっていましたが、この仕様は廃止されました。
このメソッドが長時間呼び出されていない状態でもWindows のメッセージは正常に処理されます
RGSS1のこの機能、結構ひやひやさせられた人も多いことでしょう。今回は、読み込みに時間がかかるファイルを読む場合などでも心配がなくなりました。
メニュー画面の背景表示がしやすくなった
ヘルプより：
画面のスナップショットを取る機能が追加されました。
- Graphics.snap_to_bitmap
- 現在のゲーム画面のイメージをビットマップ オブジェクトとして取得します。
ツクVXではこの機能を使って、メニュー画面の背景にマップ画面を表示しています。
蛇足：これはツクXPでも可能だった
ツクールXPでは、マップシーンのスプライトセットを背景に表示する方法が主流でしたが、VXの新機能の方がより簡単ですね。
しかし、ツクXPを使ってきた僕から言わせてもらうと、スプライトセットを表示した方が、何かと融通がきく（例：メニュー画面でも雨や雪をアニメーションさせ続けられる）ため、そちらも推したいです。
手軽にやりたい人は今回の新機能を、こだわりたい人は従来のやり方でやるといいと思います。
異様に力が入った画像処理機能が追加
RPGツクールVXの中で、特に気になる仕様が『戦闘背景がウネウネ動く』こと。皆さんも気になっている人は多いのではないでしょうか。
そして、ツクールVXはRGSS2で全ての処理がプログラムできます。ということは、あのうねうねも、プログラムを理解すれば、解析、変更が出来るのではないでしょうか。
そのとおりでした。
そのためのライブラリが準備されていました。
ぼかし処理
Bitmapクラスの説明に以下の記述があります。
- blurメソッド
- ビットマップにぼかし効果を適用します。この処理には時間がかかります。
- radial_blur(angle, division)メソッド
- ビットマップに放射状のぼかし効果を適用します。
前者はメニュー画面切り替えのスナップショットを撮影するときに、後者は戦闘背景を作るときに使われていました。
あまり多用されていないのは、時間がかかる処理だからでしょうか。間違っても毎フレーム呼び出したりするのはご法度ですね。
RPGツクールXPのころ、文字の描画処理（時間がかかる）をupdateメソッド(毎フレーム呼び出される)の中で行ってしまった経験のある人は特に注意。
うねうね機能を解析して分かった驚愕すべき事実
Spiteクラスの中にありました。
- wave_amp、wave_length、wave_speed、wave_phase
- 波形描画のための振幅、周期、速度、位相です。波形描画とは、スプライトを正弦波関数によりラインごとに横にずらして描画するもので、いわゆるラスタスクロールのような表現を行います。
これは戦闘背景のうねうねを表現するため（のみ）に使われている様子です。
(※復習：RGSSでは、キャラクターひとつひとつもスプライトですが、戦闘背景のような大きな単位もスプライトとして作成します）
驚くべきは、これがSpriteクラスで定義されていることです。
これがスプライトクラスで定義されていると言う事は、戦闘背景だけではなく、スプライト一つ一つに背景のような『うねうね』が設定可能なのです！（イベントコマンドでは設定できませんが、スクリプトをいじれば可能だと言う事です）
ひょっとすると、ツクールVXでは、この「うねうね機能」を使った作品が主流になるかもしれませんね。
大ニュース！画面サイズをスクリプトで変更可能！
RPGツクールVXの画面サイズは、544x416です。
これを見て「中途半端」と思った方、朗報です。
最大640x480まで、スクリプトで変更可能なのです！
画面サイズ変更機能が追加された
以下、Graphicsより抜粋：
- Graphics.width, Graphics.height
- ゲーム画面の幅および高さを取得します。 通常はそれぞれ 544、416 を返します。
- Graphics.resize_screen(width, height)
- ゲーム画面のサイズを変更します。 width と height に幅および高さを 640×480 までの範囲で指定します。
蛇足（読み流し推奨）：個人的に嬉しかったこと
これで256x256の画面サイズが可能になれば、ツクールモバイル＠ＲＰＧに連載された「ぼくのすむまち」も移植可能になりそうです。
「ぼくのすむまち」はツクールモバイル独自の機能をふんだんに使用した戦闘システムでした。「敵味方全体に使用」「持てるアイテムは１人８個まで」「敵のグループ指定」などなど。
これらはツクール2000では再現が面倒くさいが、XPでは画面が大きすぎる、そんな理由でリメイクを見送ってきましたが、VXで日の目をみるかも。
参考：全画面表示すると……
全画面表示をした時、画面を見てください。
図のように、画面の端が黒くなっています。詳しくは調べていませんが、恐らくディスプレー画面は640x480であり、外の部分が塗りつぶされているのだと思います。
果たして、320x240くらいにサイズを設定した場合、どうなるんだろう。
逆にサイズを640x480にしたら、黒い部分がなくなって幸せになるのかな。
画面サイズを書き換えるのにかかる手間はどのくらいか
と、このようにライブラリレベルで書き換えが可能だと分かりましたが、まだ喜んではいられません。
準備されたRGSSスクリプトは、あくまで544x416を意識して組んであるのです。これを、別の画面サイズになじませるのに一体どのくらいの手間がかかるのでしょう。
まだ実行していないのでなんともいえないのですが、スクリプトを見た範囲での予測を話をします。
まず、ウィンドウなど、『レイアウト関連』は、全て見直す必要があります。
例えば、
こんな感じで画面サイズをいちいち定義している部分が多いですが、ひとつひとつ書き換えていけばいいでしょう。
@viewport.rect.set(0, 0, 544, 416)
しかし、それ以外の構造に大幅にメスを入れる必要は少なくて済むかも……RGSS2には、そういう配慮がされていると感じました。
例えば、画面表示にかかわる変数を導入しています。例えば、RGSS2のこういう部分です。
Game_Map内：
@margin_x = (width - 17) * 256 / 2 # 画面非表示分の横幅 / 2
@margin_y = (height - 13) * 256 / 2 # 画面非表示分の縦幅 / 2
この17と13とは、画面内のタイルの数です。(32x17=544, 32x13=416)
ここを画面サイズに応じて書き換えるなどすれば、マップ移動関連は、かなり少ない変更で済みそうです。
もともと、ツクールXPは画面サイズを気にせずに済む部分が多かったです。
- イベントの実行を含むマップの処理は、基本的に画面の描画処理とは独立して行われていました。
- 『画面内かどうか』の判定処理はありませんでしたしそれに左右されるイベントコマンドもありません。
以上より、あくまで僕の推測ですが、若干手間はかかりますが、腕に自身のある人ならば、素材化が可能……かもしれません。
Tilemapの仕様変更は大きい
「ゲームライブラリに大きな変化がない」と書きましたが、大きく変わった部分があります。それはZ座標の考え方です。
以下、RGSS2の基本を抜粋します：
キャラクターの下に表示されるべきタイルの Z 座標は 0 です。
キャラクターの上に表示されるべきタイルの Z 座標は 200 です。
ツクールXPで皆さんはTileMapの仕様を吟味してスプライトのZ座標に細工をしたでしょうか。僕はしました。ムンホイで「屋根や金網の上に上る」など優先順位をいろいろと入れ替えていたからです。（ああ、ムンホイXP、早く完成させないと）
このあたりにこだわりたい人にとって、「Tilemapの仕様がXPの方が好きだから、こっちで作ろう」なんてこともあるかもしれませんね。
しかし、大抵の人には、今回の仕様の方が、分かりやすいし納得いくものと思われます。このあたりは、後日マップ作成をしながら仕様を読み解くときに改めて紹介したいと思います。
