Nexus Modsニュース和訳：レコードにかける情熱 - ElminsterAUのインタビュー(2019/1/12)

2018/01/12のNexus Modsニュース For the records - ElminsterAU（レコードにかける情熱 - ElminsterAUのインタビュー）の和訳です。聞き手はPickysaurus。

レコードにかける情熱 - ElminsterAUのインタビュー
元記事：For the records - ElminsterAU
投稿者：Pickysaurus (コミュニティマネージャー）
投稿日：2018/01/12 (UTC)

目次

はじめに

今週取り上げるMOD制作者は、Creationエンジンを使うゲームのモッディングで欠かせないツール xEditで著名なElminsterAUだ。xEditアプリケーションはOblivionからFallout 76まで、モッダーやMOD制作者の使うツールキットの中心的存在となっている。

記者からの注記：ElminsterAUからの要請により、チームの項目にユーザーを追記した (2019/1/11 23:15 GMT)。

ElminsterAUという名の背後にいる人物を知りたい読者のために、少し自己紹介をお願いできますか？

'80年代から'90年代前半をドイツ中西部のライン渓谷で過ごした後、16年前にオーストラリアに移住した。今は妻と6歳の双子の子供と共にブリスベン北部、クイーンズランド州南東部に住んでいる。8歳の頃に最初のコンピューター（Atari 520ST）を手に入れ、すぐに夢中になった。ゲームをプレイするだけでなく、コンピューターに自分のやりたいことをさせる方法についても考えていた。Omikron-Basic(Atari ST用のBASIC言語ソフト)でサンプルを見ながらプログラミングを学んだ。そのことは今でも大切な思い出として残っている。

その一年後に「家族用のPC」（最初は286、少し後で386 ※1）を手に入れた。時折PCを使うこともあったが、数年はAtariをメインに使っていた。PC用のGW-BASIC (※2)を使って少し物足りなかったが、少し後にTurbo Pascal 4.0 (※3)が発売されたので、サンプルプログラムとポケットサイズの「Turbo Pascal 4.0 リファレンスブック」でPascalの勉強を始めた。それから他にもたくさんのプログラミング言語（アセンブラからSmalltalk、それに最近のJavaやC#などなど）を学んだものの、Pascal (Delphi) を選択して今まで使い続けている。

※1：286/386 - インテルの16ビットCPU 80x86のこと。MS-DOS時代にIBM/PCやPC-9800シリーズに搭載され一世を風靡した。
※2：GW-BASIC - もともとCompaqのためにMicrosoftがIBM BASICをベースに開発したBASIC言語ソフト。
※3：Turbo Pascal - ボーランド社が発売したPascal統合開発環境。その成果は後継製品のDelphiに結実した。
※余談：Pascal言語はマイコン登場～PCの台頭あたりまではALGOL系言語の最高峰であり、最もエレガントな言語と評されていた。Delphiの登場で日本でも広く普及したが、2000年代中盤から（個人的には）あまり聞かなくなったし、少なくともビジネスレベルで使われることが少なくなった。おそらくRAD環境(GUI/コードの一体開発環境)を持つ他言語の登場や、JavaやC#といった言語に押されてのことだと思われる。海外では今でもよく使われていて、Delphiを使って開発されている商用ソフトウェアが結構ある。

まだ学校の最終学年だった15歳のときに会社を興し（未成年だったので家庭裁判所から特別な許可を得る必要があった）、多くの顧客のためにカスタムPCの制作やカスタムソフトの開発を行ってきた。

それから10年後に学校を卒業して（ドイツではRealschule、secondary school=第2の学校と呼ぶ）、"Kommunikationselektroniker Fachrichtung Informationstechnik" (情報技術に特化したコミュニケーションエンジニア)業界の見習いになり、予定より1年早く最高成績で卒業した。

期間中もカスタム開発の仕事を続けていたが、主要顧客のひとつであるMicrotech社でのフルタイム勤務を開始して、すぐに「新人」から次世代ソフトウェア向けアプリケーションフレームワークの設計と開発を担当した。Microtech社での充実した4年間の後、FlashFiler（Microtechで利用していたデータベースエンジン）の完全な新しいデザインをFlashFiler開発元であるTurboPower社に提供するためにオーストラリアに渡り、僕の設計に基づいたFlashFilerの後継であるCOSMOSの開発支援を開始した。

オーストラリアに来て間もなく突然TurboPowerが買収され、Delphiコンポーネント市場から撤退することになり（開発者目当ての買収だった）、多くのFlashFilerのユーザーが離れていった（つなぎとめる現実的な方法はなかった）。だからその後8ヶ月間をCOSMOSの開発に取り組む代わりに、まったく新しいデータベースエンジンNexusDBをいちから開発し、以来16年間開発し続けている。

コンピューター以外では、幼少のころからテーブルトークRPGの大ファンで、ダンジョンマスター（ゲームマスター）をしてきた。DSA（ドイツのRPGDas Schwarze Auge, The Dark Eye）第2版から始まり、後にAD&D2とその続編に手を出した。AD&Dの影響でファンタジー小説も読むようになった。ドラゴンランス3部作を始めて英語原文で読もうと頑張ったのは懐かしい思い出だ。それがきっかけでファンタジー小説とSF小説の熱烈なファンの道を歩み始めた。

ゲームを始めたきっかけを覚えていますか？

最初に「ゲームをした」記憶といえば、学校の友達のところに行ってコモドール64のゲームをいっぱいプレイしたことだ。今でも覚えているのはグレートギアナシスターズだけだが、他にもいろいろプレイしたはずだ。

Atariを手に入れた当初は高精細モノクロモニターを持っていなかった。つまり、商用のゲームが全くプレイできなかった。週末に父に連れられて隣の大都市の店に行ったのを懐かしく思い出す。その店ではフリーウェアやシェアウェアのゲームが売られていて、安い値段でフロッピーディスクのコピーを購入できた。その頃に（当時8歳だった）お気に入りだったゲームはBallerburgだ。それとAirballでさんざん遊び倒したのも大切な思い出だ。

ようやくAtari用のカラーモニターを手に入れて最初にプレイしたのはダンジョンマスターで、これでRPGへの嗜好が確かなものになった。これまで覚えきれないほどのゲームをプレイしてきたし、数を数えるのを忘れてずいぶん経つ。あらゆるジャンルに手を出したが、一番楽しめるのはロールプレイング、タクティカル、ストラテジーゲームだ。ウルティマ7は世界が「生きている」と始めて感じられたコンピューターRPGで、今でも心に残っている作品だ。

今もゲームで遊ぶ時間はありますか？

時間を取ろうとはしているが、なかなか思うようには取れない。毎年かなりの数のゲームを試してはいるが、最後までクリアする時間はほとんどない。これはxEditの作業が楽しいせいもある。自分のゲーミングのルーツに近づけるんだ。

モッディングを始めたばかりの人に向けて、xEditが何なのか、なぜ必要なのかを説明していただけますか？

xEditの歴史についても説明するので、少し長くなるが許してほしい。

オブリビオンをプレイし始めたとき、あれほど幅広いモッディングシーンのあるゲームに出会ったは初めてだった。NexusModsの前身であるtessource.netからMODをたくさんダウンロードして、全部適当に導入してプレイしようとしたら… 色んなところに不具合が出てまともにプレイできなくなった。色々探してみたが、なぜこうなるのかを理解できるツールがまったくないことが分かった。

これまでカスタム作成のプログラムを使って解決できない問題に遭遇したことはなかったから、後に今のxEditとなるTES4Viewの開発に着手した。だが、そのルーツは「競合の検出」にある。ゲームと同じ方法でMODのセッティングをロードして、各モジュールがどのように競合し、どのように相互作用するかについての直接的かつ視覚的な情報を提供する。xEditがサポートするゲームでMODを利用するなら、xEditを使ってロードオーダーの競合を探し出し、情報に基づいてオードオーダーやパッチの必要性についてすべきだ。これに勝る方法はない方法はない。LOOTや作者のMODページの説明から一般的な情報を得られるものの、所詮MODの設定とはユーザー毎に特有のものであり、インストールされたMOD間の相互作用を理解して競合を正しく解決できるのはユーザーしかいない。他の近道はないんだ。MODとは「サードパーティー企業によるDLC」ではないからね。MOD動詞を一緒に動作させるには、それぞれの機能と相互作用を学ぶためにある程度の学習意欲と努力が必要になる。

最初のTES4Viewを作成した後、MOD間に「Identical to Master（マスターと同一）」（略称ITM）と呼ばれる競合が大量にあることに気付いた (※1)。その頃に流通していたすべてのMODには、MODの機能とは無関係な公式ゲームのマスタープラグインと全く同じレコードが無数に含まれていた。これら不要なレコードを削除することで、これまで互換性のなかった多くのMODを同時に利用することができる。Construction Set（Oblivion公式のエディタ、後にFO3/FNVでGECK、TES5/SSE/FO4でCreation Kitと呼ばれる）を使ってこうしたレコードを削除するのは事実上不可能であることが分かったので、TES4Viewにモジュールファイルを直接変更して問題を解決できる機能の追加してTES4Editに拡張する作業に着手した。

※1：ITM - MODのプラグインによる修正対象となるプラグインのことをマスタープラグインと呼ぶ。通常はSkyrim.esmやFallout4.esmといったゲーム本体のプラグインがこれに該当する。TES/FOのMODでは、マスタープラグインに対して「レコード単位」で情報を書き換えることで新たな要素を追加する。しかし、MODが修正するつもりのないレコードがMOD中に含まれる場合（これがITM、つまりバニラそのままの未修正のレコード）、ロード順によっては他のMODで修正されたレコードをバニラの状態に戻してしまうかもしれない。xEditでITMを削除することにより、こうした「バニラに戻してしまう」問題を回避して、競合を最小限に抑えることができる。ちなみに、CS/GECK/CKで修正するつもりのない項目を開き、結果を保存してしまった場合にITMが生成される。

この手順（ITMを削除する手順）を「クリーニング」と呼び、これによってxEditの主要な利用方法が2つになった。その目的とは、他のMODとの競合の可能性を減らすため、MODから不要なレコードを見つけて削除することだ。通常これはMOD制作者がMODのリリース前に行う手順となる。

残念ながら、すべてのMOD制作者がクリーニングを行うとは限らないし、最新バージョンののxEditでITMの検出が改善されている可能性がある。つまり、MOD制作者自身がMODを更新しなくなった場合、ユーザー自身のために不要な競合の原因となるITMを検出する手順が必要となるということだ。

これは全てのMODにおいて儀式的あるいは習慣的に行われるべき手順ではない。かつてのOblivionのモッディング初期とは異なり、現在ではそのためのツールが存在するし、MOD制作者自身もこの問題を知っている。だからアップロードするMODはどれもクリーニングされているはずだ。だからMODユーザーはITMによる競合が検出された時に限りクリーニングを行う必要がある。TES4Editは単にITMを削除するものから、モジュールに含まれる全データを編集できるだけでなく、新しいモジュールをいちから作成できるツールへと急激に成長した。

新しいモジュール作成機能の当初の目的は、複数のMODが一緒にうまく動くようにマージされた競合レコードだけを含むパッチを作成することで「教護を解決」することだった。これは今のMODユーザーにとっても基礎となっているxEditの機能だ。特定のMODを組み合わせるためのパッチが事前に用意されている場合もあるが、MODのセッティングはユーザーによってまちまちだから、事前に用意されたパッチだけではカバーできないMODの組み合わせがあり、競合が発生する可能性が高い。MODユーザーなら誰でも競合の検出結果に基づいて自分独自のパッチが作成できるスキルを習得しておくべきだ。そしてTES4Editでモジュールファイル中の全情報が確実に編集できるようになると、TES4Editだけを使って「新しいMODをいちから作成」したり、既存のMODに大幅な変更を加えることが可能になった。これらはパッチ作成のために開発された技術の上に成り立っている。今日では、NexusMods上にはxEditだけで作成されたMODが数多く存在する。TES4Editは後に開発したTES4LODGENの基礎となった。TES4LODGENは、Oblivionで各自のロードオーダーを元に木々/オブジェクトのLOD(遠景)情報を生成できる最初のツールだった。

このソフトウェアはこれまでずっとチームによって保守されてきました。主要な開発者とプロジェクトへの貢献内容について教えていただけますか？

今日xEditと呼ばれるソフトウェアは元々ソースを公開しておらず、Oblivion版、Fallout3版、Fallout New Vegas版の初期までは僕が一人で開発していた。記憶が正しければバージョン3.0.19までだ。

その後、仕事の責任と双子の誕生によってxEditを十分に保守する時間が取れないと分かったとき、プログラムをオープンソースにすることにしたんだ。

ありがたいことに、僕が不在の間、献身的なグループが仕事を引き継いでくれた。特に貢献してくれたのはHlp, Zilav, Sharlikranの3名だ。

• Sharlikran : 組織的作業の大半を引き継ぎ、レコード定義の解析に取り組んでいる。
• Zilav : Skyrimのサポートに不可欠なスクリプティングエンジンとローカライズ機能を追加した。
• Hlp : セーブデータの表示を実現するために多くの作業をした（今も作業中だ）。
• fireundubh : Fallout 4のレコード定義とハードコードされたレコード、その他様々な追加と修正に大きく貢献した。
• Jonathan Ostrus : Fallout 76のレコード定義に大きく貢献した。
• その他の貢献者についてはGitHubのページにある。

彼らは全員Skyrim、Fallout 4、Skyrim Special Editionのレコード定義の作成に役立ってくれた。

LOD生成の改善のためにShesonがプロジェクトに参加して、xLODGenの改善とDynDOLODの開発に取り組んでいる（DYNDOLODの一部はxEditのソースから派生したもので、追加機能を加えてある）。彼は64ビットでコンパイルできるようにxEditを修正するのにも役立ってくれた。

ここ数年は、問題に取り組んだり、xEditのコアに関する他のプロジェクトメンバー以上の深い知識が必要な機能に取り組むため、ごくごくまれに1～2週間ほどの時間を取ることがあった。

2018年の半ばからxEditに戻る時間が取れるようになったので（双子が学校に通い始めたおかげだ）、難しい問題の解決や新機能を進めるために数週間時間を費やす予定を立てていた。

だが、簡単に修正と新機能追加が終わるはずが、数ヶ月に渡るプロジェクトとなってしまい、去年12月半ばにリリースしたxEdit 4で行った膨大な改良と修正のおかげで通常の仕事を休むほどだった。

2018年の半ば以降、xEditに関する作業はすべて僕が行っているが、Sharlikranは引き続き貴重な組織的作業と、画面右上の「ヘルプ」ボタンからアクセスできるオンラインドキュメントの更新をしてくれている。ZilavとShesonは貴重なフィードバックを提供してくれている。

最近重要な節目となるxEdit v4.0をリリースされました。このアップデートの呼び物となる改善点は何ですか？

最も目に見えやすい改善点はUIテーマのサポートだろう。明るいテーマに暗いテーマ、それに認知しやすい競合色だ。xEditでは標準で暗いテーマが使われる。暗い背景色に明るいテキスト、各種競合状態は明るいフォントカラーで表示される。

最も重要な追加にESLの完全サポートがある。今ではxEditはゲームエンジンと全く同じ方法でモジュールをロードすることができ、ESLフラグの付いたモジュールはロードオーダー 0xFEFF空間にマッピングされる。この改善がなければ255個以上のモジュールを持つロードオーダーをロードすることができなかったが、今ではゲームでロードできるものはxEditでもロードできるようになった。ESLサポートの追加に合わせてxEditにおけるロードオーダー処理を完全に見直し、サポートされるすべてのゲームと同様に動作するようにした。

プログラムの開始時やxEdit中の様々な場面で利用されるモジュール選択画面を完全に作り直し、より情報豊富となり、プリセットの保存/読み込みやフィルタリングがサポートされた。

言語とコードページのサポートも完全に作り直した。以前は文字列の大半に対してシステムのANSIコードページを使用していた。今ではxEditにおいてどの文字列でどのコードページが使用されているかが非常に明確となり、これを設定する様々な方法が用意されている。

以前のxEditでは、起動するたびに"Referenced By (参照元)"タブに表示する情報を作成していたため、起動に時間がかかっていた。それにゲームマスターファイルの参照情報が自動的に更新されず、プログラム起動後に必要に応じて明示的に作成する必要があった。新しいxEditにアップデートすることで、毎回作成するのではなくディスク上の永続キャッシュから必要な情報を読み込むことによって、2回目以降の起動が早くなる。ディスク上のキャッシュはアップデート後の初回起動時に作成される。初回の起動は遅いものの、それでも以前のバージョンでマスターから参照情報を作成するよりは高速だ。これは作成プロセスにマルチスレッドアプローチが採用されたことによるものだ。

MODグループ(ModGroups)機能は完全に作り直された。これはxEditの中心となる重要な機能で、実は10年以上前からあったものだが、誰も気づいていなかった起動だ。この機能によってxEditが衝突を探す方法を完全に変えることができる。この機能によって、巨大なロードオーダーでも競合の検出と解決が容易になるんだ。MODグループの基本的な考え方は、xEditに「このモジュールのセットがこの順序でロードされていれば、それらの競合は解決済みなので、各レコードの最後の上書き(the winning override)だけを考慮すればよい」と伝えるものだ。以前のバージョンではxEditの外でテキストエディタを使って.modgroupsファイルを作成する必要があり、ほとんど使われていなかった。今回のMODグループサポートではすべてxEdit内に実装されていて、xEdit内の操作でMODグループの作成/編集/削除ができる上、いつでも異なるMODグループをリロードすることもできる。

整列可能配列の整列機能は追加されたことに気付きにくい機能だが、一度慣れるととても自然で正しいものに思えるので、絶対に手放せなくなるはずだ。順序が重要となる配列は多数あるが、重要なもののひとつに条件式(Conditions)がある。

これは簡単な例でうまく説明できる。
この機能がない場合、2つの上書き(Override)を含むレコードは次のようになる。

    A  B  B 
    B  C  A
    C

整列が有効な場合、次のように見えるはずだ（訳注：いわば「名寄せ」ですね）。

    A
    B  B  B
             A
    C  C

View(表示)タブでフィルタをかけたり、Viewタブのノードを折りたたんだりすることで、大規模レコードの作業が大幅に改善される。

お互いに密接に関連する2つの新機能がある。一つは差分パッチ（delta patch）の作成機能。あるモジュールの2つのバージョンがある場合、xEditを使って2つのモジュール間で異なるレコードだけを含むパッチモジュールを作成できるというものだ。もうひとつは任意のモジュールの内容をマスターにマージする機能。ここでいうモジュールとは差分パッチのようなものだが、CKを使って既にマスターに存在するレコードを編集して作成したプラグインのことだ。モジュールの元のバージョンと差分パッチがあれば、パッチをマージすることで2つ目のバージョンを再作成することができる。この機能はまた、バージョン管理を使う際に通常必要となるCKの機能 "merge into master (マスターにマージ)"機能の代わりにもなる。

以上の大きな改善のほか、あらゆるところに細かな改善とバグ修正が何百と施されている。.

ゲーム非依存の共通の機能のほかにも、FO76EditとしてFallout 76が完全サポートされた。

ベゼスダが新しいゲームをリリースした場合、xEditを新しいプラグインに適応させるにはどんな手順が必要ですか？

普段はxEditのコアに隠されているモジュールファイル構造解析支援機能の助けを借りた、かなり複雑で何段階にもわたる手順となる。基本的には、既存のゲームのレコード定義を流用することが可能だ。

最初の手順は、新しいゲームマスターの全体的な構造、ファイルに含まれるレコードの識別子およびグループの順序の分析だ。

これが判明して基本的なレコード定義を更新または作成したら、各レコードタイプ（最新のゲームでは何百もある）を解析して、それぞれのサブレコードに何が含まれているのか、サブレコードの構造はどうなっているかを理解する。サブレコードが配列は構造体になっていたり、ときには複数の深い階層までネストしていることもあるから、かなり複雑な作業になる。

次の手順は各サブレコードの内容の分析だ。値一つだけなのか？ 複雑な構造体か？ FormID、文字列、浮動小数点が格納された場所の大半は、適切な解析ツールを使って洗い出すことができる。とはいえ、これらの値が何に使われているのか、どんな名前なのかを知ることはできなず、どういった形式の値がどこに格納されているのかが識別できるだけだ。この手順では、FormIDを含みうる場所を見つけることが特に重要となる。FormIDの場所がすべて分からなければ、xEditがファイルのマスターを追加したり削除したり、あるいはソートしたりすることが不可能なんだ。

現時点では、CKのような公式のツールが利用可能かどうかは重要ではない。以上の手順に従ってFO76Editのためのレコード定義を作成するのに、のべ約150人時かかった（Fallout 4の定義のレコード定義をベースに、解析によって矛盾を修正/拡張するのに要した時間）。

これ以降の手順は、公式のエディタによってモジュールファイルが作成できるかどうかにかかっている。

Fallout 76のように公式ツールがない場合でも、追加/変更された未知の値に対応する名前が何なのか、試行錯誤によって推測することは可能だが、多くの推理が必要になる。

公式のエディタが利用できるなら、エディタ上の入力項目にユニークな値を設定したテスト用プラグインを作成してxEdit(または内部ツール)に読み込み、公式エディタに表示された名前と値を突き合わせていけばよい。これはとても複雑な繰り返し作業となるので、レコード定義をさらに洗練させるのに何百時間もかかることがある。

xEditでのゲームサポートにおける大きな欠落にThe Elder Scrolls III: Morrowindのサポートがあります。これには何か技術的な理由があるのでしょうか？

明白な技術上の理由がある。xEditはもともとTES4: Oblivion用に開発されたものだ。Oblivionはベゼスダが個々のレコード識別のためにFormIDを採用した最初のゲームで、xEditの基本設計は、各レコードを識別するためのFormIDが存在するという前提に基づいている。この前提はOblivionに続くすべてのゲームで満たされていた。

モロウウィンドではFormIDが使われておらず、以降のゲームと比較してモジュールファイルの構造がはるかに「汎用的な」ものとなっている。このことが、xEditが以降のゲームのために確率した既存のフレームワークでモロウウィンドをサポートするのを非常に難しくしている。

最近はxEditでモロウウィンドをサポートする方法の発見に取り組んでいる。まさに四角い杭を 丸い穴に通すようなものだが、ロード時にレコードに仮想的なFormIDを割り当てるというアプローチによって少し進展があった。

これを実現するにはもっと多くの作業と時間が必要になるが、TES3Editが達成可能な目標だと信じている。

まったく別のゲームエンジン用にこういったツールを作ろうと思ったことは？

モッディング可能なゲームのうち、xEditのようなツールが欲しいと思えるものがいくつかあって、データ形式を調べてみた。残念ながらどのゲームのデータ形式も、合理的な努力でxEditが適用そうなものではなかった。
僕はベゼスダに感謝すべきだね。なんといってもベゼスダのゲームのモジュール基本構造は、他のゲームで見たどれもよりもずっと複数のMODをセットアップするのに適している。

リソースが無限にあるとしたら、xEditにどんな機能を追加したいですか？

今取り組んでいるモロウウィンドサポートの先に、将来的に対応したいと思っている大きな機能がいくつかある。

まずはメインフォームのモジュール化。xEditを起動すると左側にナビゲーションツリービュー、右側にタブが表示される。これは過去10年間を通して成長してきた、巨大で強力で相互接続された一つのものだ。ここでの目標は、それらすべてを独立した別個のモジュール、つまりナビゲーションツリービュー、ビュータブ、スプレッドシートタブといった個別に実行できる別々の機能に分割することだ。これには大量の作業が伴うが、最初の時点ではユーザーの目から見て大きな変更はない。だが、将来の多くの作業に向けて本当に必要とされる基盤となるんだ。

メインフォームをモジュール化すれば、ナビゲーションツリービューやビューを複数表示して、それぞれ別のフィルタを適用したり、別のレコードを同時に表示する機能サポートがより簡単になる。

さらに、これによって任意のレコードをドロップして一時保管し、後で別のレコードにコピーできるスクラッチパッドといった操作性の向上が実現可能となる。

もう一つの大きな機能は、現在モジュールでサポートされているのと同じ水準でアセットをサポートすることだ。ナビゲーションツリービューに.bsa/.ba2ファイル、さらに対応するフォルダーのルーズファイルを一覧表示する。格納フォルダをブラウズしてファイルを開くことができる。ファイルを選択すると、ビュータブにはレコードみたいにファイルタイプに応じた様々な情報がファイルバージョン毎に表示される。ここにはテクスチャやモデルといった各種ファイルのプレビュー機能も含まれるはずだ。

その後はパスグリッド、ナビメッシュ、セルの内容全般のグラフィカルな視覚化を行うだろう。

これら大きな項目以外にも、可能な限り細かな改善をしたい。そこには各種の操作性改善やナビメッシュやその他複雑なレコードのエラーチェックの向上などが含まれる。

そしてもちろん、ベゼスダが現在のモジュール形式に基づく新ゲームをリリースした際は、そのゲームのサポートが最優先となる。

xEditを使ったことのある多くのモッダーが知りたがると思いますが、xEditの開発を支援する一番の方法は？

主要な支援の手段に、僕のPatreonでの支援(pledge)がある。これによって月々の収入が大まかに予測できるので、xEditに費やせる時間に関する長期的な計画を立てることができる。

他の手段としてPayPalによる直接の寄付がある。Nexus Modsの寄付機能を使ってもいいし（この機能についてNexus Mdosが関与することはなく、そのままの金額が僕のPayPalに寄付される）、直接僕のPayPalに寄付してもいい。どちらにもxEditのメインフォームの右上にあるボタンから簡単にアクセスできる。

最後の手段にKo-fiがあるが、これはPayPalに直接転送される一時的な寄付の手段でしかないため、PayPalに直接寄付をするのに比べて今のところは特にメリットがない。どの手段でxEditを使うにせよ、金額が少ないほど仲介業者による手数料の割合が大きくなる点に注意してほしい。これはごく少額の場合に特に顕著で、1ドル寄付した場合、僕の手元に届くのはその半額となる。

xEdit 4で達成された膨大な進歩は、何百時間もの開発時間を投資したおかげであり、これによって僕は通常の仕事による収入をかなり失った。もしこれまで通り余暇だけを使って取り組んでいたら、xEdit 4のリリースは2～3年後になっていたことだろう。

xEditの開発による経済的損失を継続的に維持することは不可能だから、今後のxEditの開発の進捗は、コミュニティから得られる支援のレベルに直接依存すると思ってほしい。

現時点でのPatreonでの支援とPapPalによる直接の寄付額を平均すると、毎月通常の仕事の1/8の時間をxEditに費やすことができる。

Nexus Modsコミュニティに向けて何か一言お願いします。

xEditの作業、そしてモッディングコミュニティとの交流を大いに楽しんできた。このインタビュー記事のコメントでの質問にはできる限り答えるつもりだ。普段はxEditのDiscordサーバーにいるからよろしく。DiscordサーバーにはxEditのメインフォーム右上のDiscordボタンからも行ける。

最後に

質問に答えてくれたElminsterAUに大いなる感謝を。

紹介してほしいMOD制作者やプロジェクトがあれば、BigBizkitまたはPickysaurusまで提案してほしい。

以上

→ その他のNexus Modsニュース和訳はこちら