Typeの意味と数え方
Dude Typeは固有名と能力を持つ識別単位です。Steamストアはベースゲームに42種類あると案内しています。Dudexは能力の説明に必要なEchoやSkeledudeも掲載するため、表示行を数えただけでは42と同じ集合になりません。
一覧を作る時は、通常の採用候補、支援用の存在、未確認を分けます。Dudexに掲載されていることは存在の根拠ですが、通常のFlyerから採用できる根拠とは限りません。CollectionやTrinketを調べる時もこの区分を保ちます。
一件を調べる順序
ゲーム内で見た正確な名前をDudexのDudeカテゴリで探し、詳細を開きます。最初にFamily、次に能力の条件と対象、最後に結果と時間を記録します。アイコンや名前の印象だけで役割を決めません。
次に現在の編成で有効な対象が何体いるか、発動が何回起きるかを確認します。理想の最大値と次の区間での現実値を分けると、将来への投資を現在の戦力と誤認しません。
役割を割り当てる
Typeを攻撃、耐久、経済、アクセス、継続性のいずれかへ仮に置きます。これは公式カテゴリではなく比較用のメモです。一体が二つを担う場合は、現在重要な方を先に書きます。
二つのTypeが同じ役割を果たすなら、Family、pool、対象の多さ、方針変更の費用で比べます。役割が異なるなら、次の遭遇で不足する方を優先します。
Familyとの関係
公式FamilyはAction、Employed、Fantasy、Sci-Fi、Undead、Warriorです。同じFamilyでも能力は異なり、別Familyでも同じ役割を別の手段で果たせます。Familyは条件として使い、仕事の説明には能力を使います。
新しいFamilyを入れるとRelic poolも変わり得ます。現在の役割を埋める価値と、Family候補を増やす価値を二列に分けます。Familyで集中と分散を比較できます。
二つの候補を比較する表
発動条件、対象数、次区間での回数、Family、poolへの影響、代替経路を並べます。数字が分からない欄は「未確認」とし、推測の百分率を入れません。空欄は悪いことではなく、調べるべき場所を示します。
比較後に一文で理由を書きます。「対象がすでに二体おり、耐久を補い、新Familyを追加しないため」のような理由なら、後で結果と照合できます。
支援用の行を扱う
EchoやSkeledudeを見つけたら、それを生成または参照する能力へ戻ります。自分で採用するTypeなのか、効果として生じる存在なのかを区別します。FamilyやTrinketとの関係も個別に確認し、通常Typeの規則を自動適用しません。
コミュニティ一覧の合計が異なる場合、誤りと決める前に対象範囲を見ます。42はストアが示すプレイ可能Typeの輪郭であり、Dudexは説明資料として別の目的を持ちます。
poolを通じた長期価値
開発者ガイドは七つの専用RelicとFamily候補の構造を説明します。Typeの採用は、能力の即時価値と将来候補の構成を同時に変えます。どちらか一方だけで判断しません。
狙うRelicが一つだけなら、別Familyの追加は候補を散らす場合があります。しかし、そのTypeが耐久の穴を埋めるなら、生存によって将来の選択機会そのものが増えます。時間軸を含めて評価します。
更新と検証
能力やFamilyが外部ガイドと違う時は、Dudexの現在文を優先し、日付を記録します。アップデートで変更の背景を探しますが、ニュースにない細かな調整を勝手に説明しません。
観察は一変数ずつ行います。複数のDudeとアイテムを同時に変えた結果は、単独Typeの証拠になりません。公式文、観察、仮説を別の欄にします。
Type別メモの作り方
一件につき、公式名、Family、発動条件、対象、主な役割、poolへの影響、確認日を記録します。能力文を丸ごと複製する必要はありません。判断に必要な部分を自分の言葉で要約し、Dudexへのリンクを残します。値が変わった時に元のページと比較できます。
同じTypeを別のモードで使った場合は、同じ行へ結果を上書きせず、モード別の観察を追加します。Classicで候補が徐々に来る場合と、DailyでFamilyが事前公開される場合では、アクセスの価値が違います。Typeそのものの能力と、入手状況による評価を分けてください。
失敗例も有用です。対象が不足した、開始が遅かった、別のDudeと資源を競合したなど、能力が弱いという一語ではなく止まった理由を書きます。次回に対象を増やして改善したなら、Typeの価値ではなく条件が変わったことが分かります。
Typeを入れ替える条件
採用時に、残す条件と外す条件を一つずつ決めます。主な対象が維持される限り残す、三つの候補を見ても第二の発動源が得られなければ外す、というように観察可能な条件にします。気分だけで頻繁に入れ替えるとpoolと連鎖の両方が不安定になります。
外す時は、そのTypeが担っていたすべての役割を確認します。攻撃だけに見えても、別能力の対象やFamily候補の入口だった可能性があります。代替が同じ仕事を引き継ぐか、編成全体の矢印を書き直します。
反対に、過去に資源を使ったことは残す理由になりません。現在の条件を満たさず、今後の候補にもつながらないなら、費用が沈んだ事実と次の最善手を分けて考えます。
次の判断へ
Typeを特定したら能力で文を因果関係へ変え、シナジーで連鎖へ組み込みます。Trinketとの対応はTrinketsで確認します。
本ページは2026年8月1日の正式リリース情報を対象にします。固定Tier listではなく、現在のTypeを正しく数え、役割とpoolを使って比較するための方法です。
Type表を役割で絞る
一覧が大きくなったら、まず現在不足する役割で絞ります。攻撃が足りない時に経済候補だけを順位付けしても、次の危険は解決しません。耐久、開始の速さ、対象生成、資源、第二経路のどれが必要かを決め、その役割を今の条件で実行できるTypeを比べます。
次に発動の費用を加えます。必要な回数、対象、別のDude、Family、Relicがすでに存在するかを確認し、追加条件の数を記録します。条件が多い候補には到達までの橋が必要です。橋として採用するType自身が何も働かないなら、待つ間の危険も費用になります。
同名・翻訳差の確認
コミュニティ表や別言語の画面で名前が異なる時は、能力の一部だけを見て同一Typeと決めません。Dudexの現在項目、Family、画像、能力文、AppIDと確認日を照合します。古いDemo名が残っている場合も、正式版の現在表示を基準に別名メモとして扱います。
数える目的と攻略目的も分けます。42 Typesという公式規模を確認する作業と、現在のRunで候補を比較する作業は同じではありません。総数へ入るか不明でも、画面に出た候補の役割は観察できます。反対に公式一覧に存在しても、現在のpoolから必ず出るとは限りません。
推薦を書く時の形式
「このTypeが強い」ではなく、「この対象がすでに二体あり、次の区間までに発動でき、攻撃不足を埋めるため候補Aを選ぶ」と書きます。選ばなかった候補の役割と費用も一行にすると、条件が変わった時に判断を反転できます。
結果は成功、失敗だけで終わらせず、いつ動き始め、何が残り、どの条件が不要だったかを記録します。余分だった条件が分かれば次回は編成を軽くでき、失敗した条件が分かれば別のTypeで補えます。
未確認のTypeを扱う
まだ出会っていないTypeは、外部画像だけで役割や順位を確定しません。Dudexで存在と現在文を確認し、実際に選べた時にモード、Family、対象、開始時間を記録します。未確認欄を残せば、42 Typesという公式規模と、自分が検証した範囲を混同せずに済みます。
この区別は一覧の更新にも役立ちます。名前を見つけたこと、能力を読んだこと、Build内で結果を確認したことを別の状態として管理してください。