■ 論文ID:
11

■ タイトル:
CapStudio: プログラムの実行画面の録画映像を利用した統合開発環境

■ 著者:
深堀孔明(東大)，坂本大介(東大)，加藤淳(東大／JSPS)，五十嵐健夫(東大)


------------------------------------------------------------------
レビューサマリ
------------------------------------------------------------------
研究の有用性に疑問はあるものの，技術についてしっかりと書かれている部分を評価します．論文の完成度をより高めるコメントを参考にしてください．


------------------------------------------------------------------
reviewer 1
------------------------------------------------------------------
■ 総合点:
3

■ 確信度:
3

■ 査読コメント:
評点の根拠：
本論文は、ゲームプログラムの実行時に描画プリミティブの実行情報（ソースコード、描画パラメタ）を記録し、それを再生しながらソースコードを編集することで即座に再生に反映される開発環境を提案している。メニュー画面やゲームの見栄えなどの変更を即座に見ることができるため、GUI等のプログラミングにも有用であると考えられる。
しかし、記録されるのは描画プリミティブに関する履歴のみのため、著者も指摘しているように、リサイズなど衝突判定に影響するような、実行挙動に変化を及ぼす変更に関しては対処しきれないという限界がある。本論文はゲームプログラミングを対象として考えており、この限界は実用性に関して厳しいものであると考える。
また、Smalltalkのような実行時にオブジェクトを直接編集できるプログラミング環境が現在も実用的なものとして存在している。関連研究において、こうしたLive Programming言語は大規模なプログラミングに適さないと論じているが、この記述は不正確であると考える。また本論文の手法についても大量のオブジェクトを描画するようなゲームにおいては録画ログが非常に大きくなることが考えられ、どの程度大規模なプログラミングに対応できるかは不明確である。

論文改善のためのコメント：
スクリーンキャスト手法に関してより詳細な記述が必要であると考える。スクリーンキャストにおいて記録される関数呼び出し情報に、どのような属性が含まれるか現在の記述はややあいまいで、より精緻に記述された方が良いように思われる。


------------------------------------------------------------------
reviewer 2
------------------------------------------------------------------
■ 総合点:
3

■ 確信度:
3

■ 査読コメント:
一般的にはゲームプログラミングは分業されているので，ゲームのロジックを作る人と，画面のレイアウトを作る人がそれぞれ別のツールで別のファイルを編集する．この論文でこだわっている，一つのファイルにレイアウト情報がプログラムの形で記述され，ロジックと一緒に編集される，という状況は考えにくい．プログラミング教育という視点ならばあるかもしれない．

ProcessingのloadImage， imageなどに限定してログを取る方法はコンパクトでいい方法のように思えるが，プログラミング教育の視点で考えるなら，画像の位置だけでは不十分で，Processingの処理系そのものに手を入れて，一般の変数のログも取った方がよいかもしれない．

スクリーン上の操作からコードへの値を反映する部分は面白いが，これでできる処理に限界があるので，実際にどれほど有用か不明．たとえば，スタートさせてからt0秒後に動き出すときに，ある時刻の画像の位置から開始時刻t0を計算するとか．今の時刻がt0より小さければ速度は０で，t0より大きくなって速度がv になる．普通は力学で動くので加速度も必要．


------------------------------------------------------------------
reviewer 3
------------------------------------------------------------------
■ 総合点:
4

■ 確信度:
3

■ 査読コメント:
ゲームプログラムの作成における，ゲーム画面の確認と関連するプログラムの修正作業というサイクルをより効率化するために，ゲーム画面を再生した映像上での直接操作をプログラムの修正に反映させる方式を考案し実装しています．プログラムの構造とその出力結果が乖離していることは一般的に大きな問題であり，この研究は出力としてグラフィカルオブジェクトの移動などを含む変化に対応した部分問題への解と見做すことができます．

この提案と関連するのは論文でも引用されている Live Edit システムですが，古典的ではあるものの，より洗練された Self， eToys， LivelyKernel との比較がなされていません．これらのシステムでは，morphと呼ばれるグラフィカルオブジェクトの直接操作と実行時のその場での編集を許しており，論文が問題点としている関連研究の欠陥は解決されているように思えますので，さらに詳細な比較をしていただきたいです．

これらの関連研究との比較は十分とは言えませんが，スクリーンキャスト上での編集という着想は Live Edit とは異なり，また直接操作をプログラムに反映する方法，さらに変数の依存関係に着目した解析など独創的かつ興味深い点が多々認められ，新規性は十分と思われます．

1−2節の内容は説明が抽象的であり，一部，不正確な記述があり難解であります．採択時には改善していただければ幸いです．

以下は論文改訂の参考になさって下さい．

「強く構造化された独自フレームワークを利用することで実現されており，ゲーム画面の描画といったプリミティブな処理をプログラマが編集することができず」で指摘している内容が理解できないために，論文が解決をめざしている問題点が把握できません．「強く構造化された」とは何を意味しているのでしょうか．また「構造的なもの」がもたらす，不利益について具体的に説明して下さい．

3.2 では API が受け取った引数の値を保存しているように思えますが，そのような方式では明らかにコード・リソースの編集に大きな制約が課せられます．4.1 において，API の仮引数に与えられた式に含まれた変数の値が保存されることが記述され，ようやく納得できるのですが，この間，読者を大いに不安にさせます．3.2 での記述をより正確なものに修正して下さい．

[2， 6] よりも伝統的に Live Edit をサポートしてきた Self， eToys， LivelyKernel などの言語は，オブジェクト指向言語におけるオブジェクトとmorphと呼ばれるヴィジュアルオブジェクトの概念を統合してmorphに対する直接操作によってフィールドやメソッドを修正する機能を提供しています．[2， 6] について詳しくは読んでいないのですが，掲載された図と比較すると Self， ... の機能ははるかに高度かつ直感的に思われます．これらの Live Edit をサポートした言語との比較が望まれます．