Nexus Modsニュース和訳：新MODマネージャーの名称決定とTanninによるQ&A (2017/5/10)
2017/5/10のNexus Modsニュース We have a name! And a Q&A session with Tannin regarding the new mod manager.（新MODマネージャーの名称決定とTanninによるQ&A）の和訳です。
新MODマネージャーの名称決定とTanninによるQ&A
元記事：We have a name! And a Q&A session with Tannin regarding the new mod manager.
投稿者：Dark0ne (サイトオーナー)
投稿日：2017/5/11 0:52:51
新しいMODマネージャーへの取り組みについて話してからしばらく経過した。「最近あった」出来事について簡単にまとめると、Nexus Modsのためのまったく新しいMODマネージャーの仕事の指揮を取ってもらうため、2016年8月にMod Organizerの作者として著名なTanninを連れて来た(※)。それ以来、彼は元NMMプログラマーの2名と一緒に作業している。
※訳注：当時の記事はこちら→ (2016/10/13) Nexus Mod Managerの大きな変化とNMM開発の新しいリーダーTannin42の紹介について
Tanninの任務は一見単純だ。出来る限り多くのゲームのモッディングを扱うことができ、SkyrimやFalloutといったゲーム用のMODマネージャーに期待される高度な機能すべてを含みつつ、初心者にとっても簡単に使えるNexus ModsのためのMODマネージャーを作ることだ。表面上は簡単に見えるが、実際にやるとなると簡単じゃない！
方法や時期の決定はすべてTanninに一任した。Tanninはフルタイムの仕事の合間に偉大なソフトウェア(MO)を作ることができたし、やり方を理解している。だから僕が口出しする必要は全くないと思ったからだ。それに、彼がMODマネージャーのために下した決断に僕が口出しする資格はほとんどない。だからTanninがプロジェクトリーダーで、僕はUI関連の意見を言ってTanninと議論するだけだ。彼ならやり遂げてくれるはずだ！
新MODマネージャーの詳細について現時点で話せることは少ない（多くのことを話す準備が出来ていないので口をつぐんでいるだけだ。疑問に答えたり宣伝をするよりも作業を優先しているからね！）。クローズドアルファ版に向けて作業を進めている中で、今話せることについてちょっとだけ質疑応答しよう。
今話せることは、新MODマネージャーの名称について（今週！）合意が取れたということだ。時間がかかった理由の一つは、僕が名前について一定の基準を求めたことだ。興味を引き、今日的な意味を持ち、「ブランド化」可能な単語が欲しかった。変に思われるかもしれないが、僕はMODに特化した名前を望んでいなかった。このソフトウェアが2年後、5年後、それに10年後に何になるかなんて誰にも分らないからね。例えばだけど、僕はいつかNexus Modsのメンバーにゲームのセーブデータ用のクラウドストレージを提供して、簡単にセーブデータのバックアップと復元ができるようにしたいと思っている。もしこうなればMODマネージャーという名前は過去のものとなり無関係となってしまう。将来的に「再ブランド化」するよりも、今の時点で汎用的な名前をつけたかったんだ。
Nexus Client (最悪の場合の代案！）、Nexus Mod Manager2、Nexus Mod Organizerといった名前はどれも退屈だし面倒だから拒否した。その代わり、最近公開したNMMに関するニュース投稿に対するコミュニティメンバーからの提案を受け入れた。周りの人にちょっと聞いてみたけど、ほとんどの人が気に入ってくれたので… これにしたんだ！
それでは発表する。Nexus Modsの新MODマネージャーの名前はVortexだ。
すぐにロゴの制作に取り掛かる。
Tanninの紹介はさっき済ませたから、さっそく質疑応答に入ろうか…。
Robin: まず最初に、Vortexに対する君の目標と価値観は、Mod Organizerに対するそれとどう違うんだろう？
Tannin: Mod Organizerに取り掛かったとき、それを特別なものにするための仮想ファイルシステム(VFS)が既に出来上がっていた。VFSを作ったのは別の目的のためだけど、OblivionのMODをプレイしたときにその技術がこの種の問題に適用できると気付いたんだ。
最初の一年でこれほど大きな成功を収めるとは期待していなかった。僕は常に技術的な挑戦をしていて、その姿勢は「僕のものを好きになってもらえれば幸せだし、好きじゃなければ他のを選べばいい」なんだ。誰にとっても最高のMODマネージャーを作るというのは僕の目標ではなく、僕にとっての得意分野にいることが幸せだった。
もちろん、Vortexに取り組んでいる今は変わったよ。僕たちはNexus Mods公式のMODマネージャーを作っている。誰にとっても便利で問題のないものを作らなきゃならないからね。
Robin: Vortexでのファイル仮想化やファイルの扱い方、ハードディスクへの保存方法について周りから大きな関心を受けているのは知っているよね。Vortexでは仮想化を使うのかい？
Tannin: ああ、使うよ。
この件に関してはみんなが ―しばしば強固な― 意見を持っているのは分かっているけれど、コメントや愚痴を言う前に僕の説明をよく読んで欲しい。
Vortexの最初のリリースでは、NMM v0.6のようなリンク（シンボリックリンク/ハードリンク）を使って仮想化を実装する。他の可能性は残しておくので、様々なアプローチ（例えばMod Organizerのusvfsライブラリ）を実装することもできるけれど、現時点では「仮想化なし」という選択肢はないと考えている(※)。
※訳注：シンボリックリンク/ハードリンクはWindows OSの機能で、ファイルシステム上に実際にファイルへのリンク情報を作成する。エクスプローラーやコマンドプロンプトのdirコマンドで見てもそこにファイルがあるように見える。一方、MOの仮想化は実際にファイルを作成せず、実行中のアプリケーションのファイルアクセスをフックして「騙す」ことで、そこにファイルがあるように見せかける。MOを使うとSkyrim/Dataフォルダが常にクリーンに保たれる理由である。
Robin: 単純にゲームディレクトリにMODファイルを展開する古いやり方よりも、仮想化を使った方がVortexにとって良い理由について説明してくれるかい？
Tannin: なるべく簡単に説明しよう！
仮想化を使わずにMODを管理すると遅くなるし、ハードディスクの使用量も増えるし、エラーが発生しやすくなって目に見えない複雑さが増すうえ、実装により多くの作業が必要となり（プログラマーの苦しみを気にしない人にとっては「時間あたりの機能が少なくなる」ということ）、理解しにくくなるんだ。
例を挙げて説明するのが一番だね。想像してみよう。
- 君は "spider.dds" と "bear.dds" を含むMOD Xをインストールした
- 次に君は "spider.dds" と "dragon.dds" を含む MOD Yをインストールした
君はゲームディレクトリに"spider.dds"、"bear.dds"、"dragon.dds"があり、"spider.dds"はインストール順序に応じてMOD XかMOD Yのどちらかのものだと期待するはずだ。ここではMOD Yのものであると仮定しよう。
- 君は気に入らないMOD Yをアンインストールすることにした。
これで君はゲームディレクトリに"spider.dds"、"bear.dds" があり、"spider.dds"はMOD Xのものだと期待するはずだ。
仮想化を使わずにこれを実現するには、MODマネージャーがファイルの元の場所と上書きされたファイルのマニフェスト（目録）を保持する必要がある。こうすることで、MOD Xの中にある別の "spider.dds" を回復すべきだと知ることができる。
MOD Xの中に "spider.dds" があると知ったMODマネージャーは、インストールしたときのアーカイブを開いてファイルを再度展開する必要がある。マニフェストはデータベースやXMLファイルに隠されているだろうが、恐らく目に触れることはないし、君には読めないだろう。ほとんどのユーザーはそこにどんな情報が含まれているのか知らないし、使い方も分からないだろう。ゲームディレクトリと一緒にそれをバックアップすべきことに気づかないかもしれないが、マニフェストの内容は実際にインストールされたMODと同期する必要がある。
これが破損するまで気付かないだろうMODマネージャーの隠れた複雑さなんだ。
バックアップから古いマニフェストを復元してMOD本体を復元しない場合、またはその逆の場合、MODマネージャーはMODのロードオーダーを正常に無効化/削除/変更できなくなる。そしてこれは修復不可能な状態となる。
MODマネージャーがマニフェストを使って追跡するのは、手作業でゲームディレクトリにMODファイルをインストールしたりアンインストールするのと同じだ。実際にやってみれば、何が起こったのかをマニフェストによってマネージャーに推測させるのが間違ったことだと分かるはずだ。10回やって9回はうまく推測できるだろうが、他はエラーとなるだろう。
それにマニフェストの移行も必要となる。マニフェストの形式を変更するたびに、旧形式から新形式への移行パスを開発する必要がある。移行処理のコードにバグがあったり既にマニフェストが破損していて扱えない場合、何千人ものユーザーのMODインストールが破損する可能性がある。いつか移行に失敗するまで、マニフェストのエラーが延々と残ることになる。
それにインストールされたすべてのMODのアーカイブも保管する必要がある。どれか一つでも削除してしまえば復元できなくなる。
同様に、容量や帯域幅節約のために高圧縮されている場合には特に、アーカイブからの展開がとても遅くなる可能性がある。
さらに言えば、MOD Yをインストールすると、MOD Xから展開した"spider.dds"に対する変更内容は消えてしまう。うわああ！だよね。
一方、仮想化を使うVortexのようなMODマネージャーではそれぞれのファイルを追跡する必要がない。持っているMOD（ディスク上にある一連のディレクトリなので明白だ）と優先順位の付け方を知る必要があるだけなんだ。
ゲームディレクトリにファイルを「配置」するのも簡単で、その時点で有効化されたMODの一覧と優先順位を利用して、どのファイルがどこにあるべきかを判断する。過去に何があったのかを知る必要はない。MOD XとMOD Yをインストールすると、ゲームディレクトリに両方のファイルを配置し、MOD Xの"spider.dds"をMOD Yのファイルでオーバーロード（上書きされているように見せかける）する。すべては期待通りだ。
MOD Yを削除するとゲームディレクトリに配置したMOD Yのファイルもすべて削除され、新たなファイルが配置される（マニフェストがなくても検出できるのは、リンクそのものが各ファイルの場所を示しているからだ）。この場合はMOD Xの"spider.dds"が配置される。
マニフェストがないのにすべては期待通りだ。ファイルの再展開も不要だし、MOD Xに対する変更内容があっても消えずに残るというボーナス付きだ。
まとめると、仮想化はインストール後のMODアーカイブを必要としないため、実に単純で、高速かつ容量を節約できる（オプションでMODアーカイブを残すこともできる）。
Robin: それほど簡単じゃなかった。仮想化をユーザー選択可能なオプションにしない理由は？
Tannin: いつかそうするかもしれない。でも正直に言って、仮想化は客観的に見ても優れているし、「仮想化なし」のインストール方法を実装するには開発作業と保守作業の両方が大変になる（理由は上記のとおり）。他にも便利な機能を沢山作らなきゃいけないから、よほどの理由がなければそれに時間を費やしたくないんだ。
Robin: Vortexの仮想化システムはMod Organizer方式よりもNMM方式に近いと言ったね。知ってのとおり、MOユーザーのほとんどはインストールフォルダがクリーンに保たれる点に信頼を置いているからビックリするんじゃないかな。MO方式ではなくNMM方式を採用する背景について説明できるかい？
Tannin: 最初に言っておくけど、VortexでMod OrganizerのVFS（仮想ファイルシステム）を後からオプションとして提供する選択肢はまだ残されている。でもMOのVFSをデフォルトとするのが良くない理由がいくつかあるんだ。
一つ目は、VFSによる実装ではエラーが発生しやすくなる。特に、異なるアプリケーション間との非互換性問題に遭遇しやすくなる。この方式がMOで受け入れられたのは（僕はそう思ってる）、ほんの一握りのゲームしかサポートしていなかったし、ツールもあまりなかったからだ。それでもツールが動作しない/おかしなエラーを吐いて対策に数週間かかることもざらにあった。
Vortexでは出来る限り多くのゲームをサポートしたいと考えているから、多数のゲームとツールのためにVFSをメンテナンスするのはまさに悪夢となる。
二つ目は、VFS実装のために利用されている技術がマルウェアと同様であるため(※)、ウィルス検出ソフトのヒューリスティック検索によってMOがウィルス判定されることが頻繁にあった（もちろん間違っている）。これでも問題なかったのは、平均的ユーザーよりも技術面に精通した数千人のMOユーザのうちの数パーセントに影響を与えただけだったからだ。でもVortexはどんなユーザーでも簡単に利用できることを目指しているんだ。600万人のユーザーの5%からアンチウィルスに関するバグ報告なんて受けたくないからね…。
※訳注：VFSはアプリケーションからのシステムDLL呼び出しをフックしてウソの結果を返却することでファイル仮想化を実現している。ウィルスやマルウェアがアプリケーションの挙動を変える際の常套手段であるため、ウィルス判定されやすい。
三つ目は、MOの開発を始めたとき、VFSテクノロジー（32ビット版）は卒業論文の一部としてほぼ完成していたものを単に書き直したものだったことを指摘しておきたい。だから正直に言えば、僕はソリューション（解決策）を持っていて、解決すべき問題を探していたんだ。
MOは僕にとってこの技術が問題に適用できるかどうかを確認するための実験だった。MOの目標は最も使いやすいMODマネージャーを作ることじゃなかった。MO2にリンクベースのオプションを追加する時間があったなら…
今のところVortexでゲームフォルダ―をクリーンに保つことはできないが、Vortexによってインストールされたリンクを迅速かつ確実に全削除できる「パージ」機能がある。だからゲームディレクトリをクリーンに保つことは忘れて、ボタンをクリックするだけでいい。
Robin: 仮想化に伴う性能低下は？
Tannin: ハードリンクの場合はない。ゼロだよ。
シンボリックリンクの場合もほとんどない。みんなに測定できるとは思わないし、気になるほどのものじゃないと保証するよ。
Robin: 仮想化のおかげでMODのバックアップサイズが2倍になるとの苦情が一部のユーザーから来ている。これに対する解決策は？
Tannin: もっと良いバックアップソフトを手に入れることだね。真剣に言うけど、バックアップソリューションがリンクを適切に処理できないなんて言い訳にもならないよ。
でも別の方法がある。全MODの配置を取り消す「パージ」オプションだ。バックアップを取る前にパージして、後でVortexから再配置すればいい。これは安全な操作だし、多分1分もかからない。
Robin: 話を進めてVortexのリリース計画は？ アルファ版はある？ 時期はいつ頃？
Tannin: 具体的な日程を提示するのはいつも難しいものだよ。完成に向けて磨きをかける作業がどれだけ必要か、ほとんどの人はいつも過小評価しがちだからね。
僕の計画では、テストユーザーの限定グループの手元に早期アルファ版を届けるのが1ヶ月から6週間以内だ。
彼らからのフィードバックに応じてバグを修正するのに1～3ヶ月くらいかかり、その後に公開アルファ版をリリースすることになると考えている。
以上
