VSCodeによるデバッグをもっと軽く行いたい

アバター
みなわ
記事: 14
登録日時: 2019年1月21日(月) 22:19
連絡を取る:

VSCodeによるデバッグをもっと軽く行いたい

投稿記事by みなわ » 2020年5月22日(金) 11:27

お世話になっております。

ツクールMVでゲーム制作を行う上で、console.logデバッグを多用していましたが、
いい加減、ブレークポイント&ステップインによる真っ当な手法を身につけようと思い、
以下のURL記事を参考に、VSCodeによるデバッグ環境(後者)を構築しました。

>「Visual Studio Code」+「Chrome」で「ツクールMV」のローカルでデバッグなテクニックの紹介
https://qiita.com/Sanshiro/items/084fb0971942e03db9a4

>Visual Studio CodeでツクールMVをデバッグ~NW.js(ローカル環境)編~
https://qiita.com/Mihiraghi/items/a68440e597373aabba02

それでプレーンなプロジェクトにおいては問題なくデバッグできるようになったのですが、
改めて制作中のゲームで行おうとすると、ゲームそのものの実装が悪いらしく、
FPS値 1桁台という太極拳状態でのデバッグを余儀なくされてしまっている状況です。
(ツクールのエディタから通常起動した場合は、プレイに堪え得るFPS値を維持)
(ただしF8デベロッパーツールを起動すると、VSCodeデバッグと同様のFPS値となります)

処理負荷が掛かっていそうな箇所(各種並列処理等)を削除or纏めたり、
ループに適宜ウェイトを入れるなどによって多少の緩和は見られましたが、
あくまで多少であり、おまけに実装済みの箇所に影響が出たりと頭を抱えています。
(一応、可能な限りマップリフレッシュを抑えるべく、
なるたけ$gameVariables._data[??]式、$gameSwitches._data[??]式を利用したり、
セルフスイッチの変更によるリフレッシュ範囲も当該イベントのみにしたり的な処理は済)


そこで、VSCodeによるデバッグをもっとストレスなく行う方法について、
みなさまの知見をお借りできたらと質問させていただいた次第です。

このプラグインをツクールMVに導入するとデバッグ時のFPS負荷減るよみたいな情報や、
VSCode側に何らかのツールを導入することで軽くなるよみたいな情報、
あるいは一時的にデバッグ負荷OFF状態でVSCodeから起動⇒必要なタイミングでONにする方法など、
何らかの対応手段に心当たりのある方、いらっしゃいましたらご教示ください。。。

(あるいは、デバッグという行為自体がそういう重さを堪えてやるものだよという場合はその旨も)
(何分、手探りなもので、どのあたりに心持ちを置けばいいかも測りかねている状況でして……)

なお、以下が当方がゲーム制作・デバッグに使用しているPCのスペックです。
どうもスペックそのものが足りてない気もするので、そのへんわかる方も是非。
=============================
OS :Windows10 Home 64bit
CPU :Intel Celeron 3865U
メモリ:8GB
グラボ:なし
=============================

以上、何卒お力添えのほど、よろしくお願いいたします。。。

アバター
Plasma Dark
記事: 669
登録日時: 2020年2月08日(土) 02:29
連絡を取る:

Re: VSCodeによるデバッグをもっと軽く行いたい

投稿記事by Plasma Dark » 2020年5月22日(金) 12:45

それでプレーンなプロジェクトにおいては問題なくデバッグできるようになったのですが、
改めて制作中のゲームで行おうとすると、ゲームそのものの実装が悪いらしく、
FPS値 1桁台という太極拳状態でのデバッグを余儀なくされてしまっている状況です。


これはどこが重いか次第で、重い場所が限定されているのであればそこの実装を見直すことを推奨します。
例えば、タイトル画面は問題なく動くが、特定のマップに入ったタイミングだけ重い、とか、特定のプラグインが無茶な実装をしているとか。
NW.jsのバージョンがデフォルトと違う場合、その差異が何かしら出ている可能性もあります。

何にせよ、重くなっている原因を特定しないことには始まらないので、以下を確認してみてください。

- どの画面、場面で重くなっているか(タイトルやメニュー、セーブ・ロード画面は平気だがマップに入ると重い、等)
- 重い場面に関連したプラグインをOFFにすることで症状が改善しないか

あるいは、デバッグという行為自体がそういう重さを堪えてやるものだよという場合は


そんなことはありません。デバッグこそ快適に行うべきなので、なんとか解決したいですね。
奏ねこま
記事: 702
登録日時: 2016年1月20日(水) 20:04

Re: VSCodeによるデバッグをもっと軽く行いたい

投稿記事by 奏ねこま » 2020年5月22日(金) 13:03

アバター
みなわ
記事: 14
登録日時: 2019年1月21日(月) 22:19
連絡を取る:

Re: VSCodeによるデバッグをもっと軽く行いたい

投稿記事by みなわ » 2020年5月22日(金) 17:05

さっそくの返信、ありがとうございます!


=====================================================
>Plasma Darkさま
=====================================================
制作中のゲームのざっくりした仕様をお伝えし忘れておりました。
拙作、一般的なツクール系RPGと比べてかなり特殊な実装をしています。

いわゆるSFC風来のシレンなどに代表されるローグライク系RPGで、
マップシーンが自作システムによるターン制動作となっております。

(プレイヤーの入力を並列処理で常時監視しているようなイメージで、
一歩動く度、マップ上の全他イベントの行動終了までループ待機させたり、
動いた先で何かイベントが発生しないか(罠踏んだ等)チェックするなど)


そのため、以下が確認結果となります。


>重くなる箇所
自作のターン制御システムを起動させた状態全般。つまりマップシーン全般。
システムを起動させてるだけでもVSCode起動でFPS 1桁台ですが、
特にプレイヤーの動作直後が重くなる模様。
さらにマップ内のイベント総数(並列処理による制御対象)によって負荷も増えるらしく、
正直、エディタ起動で通常プレイする分にはFPSが許容範囲に収まるのが自分でも謎。。。

なお、ゲーム開始直後のオープニング(システムOFF状態での自動イベント)に関しては、
VSCode起動でもほぼFPS50以上をキープしています。


>重い場面に関連したプラグインをOFFにすることで症状改善しないか
システムをOFFにすれば確かに改善(並列監視がなくなるため)するのですが、
それすなわちターン制御が機能しなくなってしまうことを意味します。
そして調べた限りでは、システム内の特定の処理で負荷がかかっているというよりは、
成立させるための処理それぞれで負荷が積み重なった結果、太極拳と化している模様です。

対処療法としては、システムそれぞれの箇所の実装見直し、負荷軽減用のウェイト挿入など。
(いまも行っていますが、さらにあちこち工夫できる限りはしていく所存です)

根本療法としては、システムの仕組みそのものを作り直す感じで、最終手段です。
(コアスクリプトもロクに読めない頃に無理やり実装したものが下地になっているため、
正直、これを選択するのが正道とも思うのですが、ひとまず本作は対処療法で進めたく……。
いまならプレイヤーやイベント移動の記述個所をプラグイン化して、ゲージ的なモノを加える感じかなあ)



NW.jsのバージョン違いによる差異、盲点でした。
確認してみたところ、確かにNW.jsのバージョンが違っていました。
後ほど、NW.jsバージョンを合わせて挙動を確かめてみます。
(記事は0.29.4、うちは0.29.0でした。
 当方の環境が1.6.1 ⇒ アツマール版コアスクリプト(community-1.3b)なためか……)


>デバッグこそ快適に行うべき
ありがとうございます。やはりそうあるべきですよね!
せっかくVSCodeでコアスクリプト内の動きを追えるようになったので、
何とかデバッグ環境を整備して、もっとツクールMVと親しみたいものです。。。



=====================================================
>奏ねこま さま
=====================================================
お教えいただきました参考URL記事をもとに設定を行ったところ、
F8デベロッパーツール実行時のFPS値が見違えたように改善しました!
(並列処理でガシガシスクリプト実行していたので、そのものズバリだった模様)

VSCodeに関しても、これと同じような設定をできないものか色々調べております。
ありがとうございます!
アバター
みなわ
記事: 14
登録日時: 2019年1月21日(月) 22:19
連絡を取る:

Re: VSCodeによるデバッグをもっと軽く行いたい

投稿記事by みなわ » 2020年5月25日(月) 01:06

調査内容 書き置き


奏ねこま さま の参考情報より、
F8デベロッパーツール実行時の負荷は「非同期スタックトレース」の禁止設定で緩和。
おそらくVSCodeにもその手の設定オプションついてるはずと当たりをつけて調べ始めるも、

まずVSCodeそのものに設定箇所があるのか(※1)、
それともデバッグの際に用意するlaunch.json側に記載するのか(※2)が不明。
どちらにせよ、ざっくり調べた限りではわからず、見つからず。。。

※1)VSCode左側下の設定アイコン>機能>デバッグ 内にはそれらしいもの見当たらず
※2)"configurations"に設定する属性にそれらしいのがあるかインテリセンス(Ctrl+Space)眺めるも、
   それっぽいのは"showAsyncStacks"ぐらいで、それを false にしても状況変わらず



次にNW.jsのバージョンをエディタ側のバージョンと合わせてチェック。
VSCode上で、F1キー ⇒ NWjs install ⇒ 使いそうなバージョンをひととおりインストール。

0.46.0 win-x64
0.46.0 win-ia32 ……おそらく現行最新バージョン。
0.29.4 win-x64
0.29.4 win-ia32 ……参考記事で指定していたバージョン。MV1.6.2相当。
0.29.0 win-x64
0.29.0 win-ia32 ……みなわ環境におけるエディタ側バージョン。MV1.6.1相当。

x64とia32はおそらく64bit環境用か32bit環境用か違い(と思われる)
x64のほうで環境作ってないのは、プレイヤーが32bit環境だったときのため?

ともかくも、configurations内のnwjsVersion属性にそれぞれのバージョン設定しつつ検証。
負荷状況変わらず。バージョン違いで致命的なことになってる線は消えた模様。
(プロフィールエラーが発生 ~ バージョンが新しいNW.jsのプロフィールは使用できません問題出現も、
 これは確か、どこかのフォルダの中身消してユーザーパス切ってとかで直せたはず。ググれば出てる)



ひとまずこんなところで、何とかなりそうな気配は見えません。
あとはlaunch方式を止めて、エディタから通常起動したものをattachで当てる(できるか不明)ぐらいですが、
どのみち負荷がかかってるのを抑えることはできそうもないので、素直にVSCode諦めたほうがいいかなあ感。
(デバッグが負荷でできないような状況になる前に、実装の方針を見直しましょうの意)
奏ねこま
記事: 702
登録日時: 2016年1月20日(水) 20:04

Re: VSCodeによるデバッグをもっと軽く行いたい

投稿記事by 奏ねこま » 2020年5月25日(月) 12:59

VSCodeからデバッグ実行した状態で「ゲーム画面側」でF12を押して開発者ツール画面は出ますか?
もし出るなら、その画面からDisable async stack tracesを確認してOFFになってるならONにしてみてください。
(↑は思いつきで語っています。実際に確認したわけではなく見当違いかもしれません。ご了承下さい。)
アバター
みなわ
記事: 14
登録日時: 2019年1月21日(月) 22:19
連絡を取る:

Re: VSCodeによるデバッグをもっと軽く行いたい

投稿記事by みなわ » 2020年5月25日(月) 15:00

奏ねこま さま

ありがとうございます。以下、検証結果です。


1)VSCode起動・chromeデバッグ
file属性の"${workspaceRoot}/index.html"に?testを付与。
テストモード起動。この時点で太極拳状態。
ゲーム画面側でF12⇒F1で件の画面出力。
Disable async stack tracesをONにするも重さ変わらず。


2)VSCode起動・NW.jsデバッグ(0.29.0 win-ia32)
package.json を編集し、main属性のindex.htmlに?testを付与。
テストモード起動。この時点で太極拳状態。
ゲーム画面側でF12→F1で件の画面出力。
Disable async stack tracesをONにするも重さ変わらず。


3)ツクールMVエディタ起動
テストプレイ開始。この時点ですこぶる快適。
ゲーム画面でF12→F1で件の画面出力。
Disable async stack tracesをONにすると、DevTools開いてても動作軽い。



同じNW.js起動でバージョンも揃えた2と3で明らかに重さが変わっているので、
やはりVSCode側の設定をどうにかしないとダメそうな感じではあります。
(そしてその設定が見つからない。。。)


なお、VSCodeではなくWebStormというIDEだと、
非同期デバッグモードというのがデフォルトでオンになっている模様。
それを無効にするにはレジストリ弄ってねという話らしいので、
もしかするとVSCodeもそんな感じかなあと遠い目をしております。

>非同期デバッグモード記述参考
https://pleiades.io/help/webstorm/debug ... hrome.html
(なお、regedit打って検索するも引っ掛からず。。。検索の仕方間違えてるかも?)
(js.debugger.async.call.stack.depth を 0に設定、だそうです)


ただ、VSCodeでツクール弄られてる方もそれなりにいらっしゃるはずで、
こんな大変そうな設定が必要なら検索で情報引っ掛かってきそうなものなので。。。
当方のイベントの組み方やマシンパワーのあたりが状況に直結してそうな気がします。。。

“MV:質問” へ戻る