【解決済み】RGSS3の組み込みクラスについて

[奈々（なな）]

早速ですが、質問をさせて頂きます。

RGSS3の組み込みクラス（WindowやSpriteなど）に関して
これらの中身が非公開であることに困っています。
これまでは、直下の_Base以降の改変や
ヘルプからメソッドやプロパティを参照してやってきました。

Rubyの方の組み込みクラスは、インターネットで検索できますし
そもそも基本的なものが多くツール的な用途なので問題なかったのですが
RGSS3は、大本のスーパークラスになっているため
各処理で何をやっているかが分からないのが不便に感じます。

そこで、主にスクリプト製作者様に質問なのですが
・上記のような仕様に不便を感じたことはないか
・その場合、解決策や、調べ方はどうしているのか

以上、ご経験を教えて頂ければ幸いです。
どうぞ宜しくお願いします。

[seea]

こんにちは。
Spriteは割と素直な作りで、不便を感じたことはないですが、
Windowの仕様を知ったときは思わず「うわぁ……」となりました。

ツクールの伝統なのかもしれませんが、
ウィンドウスキンという仕組みそのものがちょっと困りました。
最終的に、ウィンドウスキン画像の左半分は透明色にするしかありませんでした。

調べ方は
・エラーログファイルを出す（Thanks to エラーログ出力(by 半生氏) ）
・コンソールログをなるべく多く出す
・他の方のスクリプトを観察する
　（特にMoghunter氏のスクリプトは勉強になる。さらっと10000行超えたりしているので……）

SpriteとViewportの重なりは、既存、自作、他作も含めて全ての階層指定の
階層マップを作っています。
メソッドの競合対策はともかく、階層(Z座標)の競合はあまり意識されないことが多いのか、
サクッと重なっていたりします。重なっても問題はないことが多いものの、
大抵のスクリプトは組み込むときに階層の修正が入っていますね。

あとスクリプトからはあまり触らないのですが
ゲーム内の「スイッチ」と「変数」は、ON/OFFや値変更のタイミングでログを出すように
しています。シナリオで使っているスイッチがどうも勝手に書き換えられていると思ったら
他のスクリプトがさらっと書き換えていたりとか稀によくあるので、早期発見のために。

[奈々（なな）]

こんばんは、お返事ありがとうございます。

やっぱり非公開なのは仕方がないようですね。
pを打ちまくってコンソールで中身を調べるのは、我流の力技のつもりでしたが
他の人もやっていると分かって安心しました（笑）

ほーSpriteはそうなんですか。
私の場合、Windowに関してはサブクラスが多いので
メソッドの処理の参考や比較がしやすいのに対して
Spriteは数が少ないので、トップが非公開なのがより不安になった次第です。
（因みにWindowのスキンは、透明にして画像背景などでお茶を濁しています）

私もZ座標の競合は意識しない、というか事前対策の仕方が分からないですね・・・。
ある程度はViewportで管理できるでしょうが
メソッドの競合対策におけるaliasのような定番がないと思うので。

大変参考になりました。ありがとうございます。
どうしても独学・我流でやっていると
もしかして自分だけ物凄く非効率なやり方をしているのではと思うので。

タイトルに【解決済み】をつけておきますが
もし他にもご意見を頂けるのであれば、引き続きお願いします。