最近、メンテナンスが停止され、ソースコードが公開されている『Don\u2019t Starve Together』の全スキルModを見つけました。最初は、こういったプロジェクトの実装方法はどれも似たようなものだと思っていました。公式スキンリソースをModディレクトリにパッケージ化し、いくつかのテーブルを変更し、最後にゲーム内で「表示する」だけで完了する、と。
しかし実際には、それは単なるリソースパックではありません。より正確に言うと、それはランタイムスキン注入システムです。単に公式スキンを持ち込むのではなく、『Don\u2019t Starve Together』本来のスキンの動作方法を可能な限り再現し、そのシステム上にさらに custom_ 名前空間と一連のランタイム Hook を追加することで、ローカルスキンがあたかも公式スキンのように、名前検索、アイコン検索、所有権判定、エンティティ生成、スキン変更のフローに参加できるようにしています。
スキンシステムの掌握
このプロジェクトは公式スキンシステムを回避しているわけではありません。可能な限り公式の構造に沿い、必要な箇所にのみ、独自のランタイム書き換えレイヤーを挿入しています。
例えば modmain.lua では、Modはまず custom_ プレフィックスの判定と除去ロジックを定義し、安定したマッピング関係を構築しています。
- 公式スキン
wilson_formal - Modスキン
custom_wilson_formal
Modはランタイム時に custom_wilson_formal を自身のスキンとして認識しつつ、公式データを呼び出す必要がある場合には、それを wilson_formal に戻して名前、説明、アイコン、レアリティを検索できます。
公式クエリ機能の再利用
skinloader/skinloader.lua では、巨大なローカライズテキストテーブルを管理したり、公式のアイコン名やレアリティ文字列一式を複製したりせず、クエリ関数を直接インターセプトしています。
以下のようなグローバル関数を、一律でプロキシでラップします。
GetSkinDescriptionGetSkinNameGetSkinInvIconNameGetModifiedRarityStringForItemGetColorForItem
渡されたアイテムに custom_ プレフィックスが付いている場合は、まずプレフィックスを剥がしてから、リクエストを公式関数に戻します。
Modは大量の表示レイヤーデータを自分で管理する必要がありません。ゲームが custom_wilson_formal をクエリする際、最終的に取得されるのは、やはり公式の wilson_formal の名前、説明、アイコン、レアリティロジックです。
所有権の偽装
skinloader/skinloader.lua では、このModはインベントリ所有権に関連する複数のインターフェースを書き換えています。例えば以下の通りです。
InventoryProxy.CheckOwnershipInventoryProxy.CheckOwnershipGetLatestInventoryProxy.GetOwnedItemCountInventoryProxy.GetFullInventory
その核となる考え方は非常にシンプルです。あるスキンがMod自身の SKINS テーブルに登録されていれば、公式ロジックにそれを「所有済み」として扱わせる、というものです。
このステップは非常に重要です。なぜなら、DSTのスキンシステムは「リソースがローカルにあればすぐに装備できる」というものではなく、その間に所有権チェックのレイヤーが存在するからです。
生成とスキン変更フローの掌握
このプロジェクトはランタイム時に、いくつかのスキンフローを掌握しています。
CreatePrefabSkin(...)SpawnPrefab(...)Sim:ReskinEntity(...)AnimState:GetSkinBuild(...)
Modはリソースをディレクトリに置いて、エンジンが偶然発見するのを待つのではありません。エンティティ生成、スキン変更、アニメーションビルド名解決といった重要なポイントで、ゲームに対して「今使うべきはこの custom_ スキンだ」と明確に指示します。
