ステラリス 開発者日記 第253回 三位一体 3.4 ‘Cepheus’パッチノートとその他！

スポンサーリンク
更新情報
2022.05.05

2022/5/6 日本語の公式実装について一番下に追記

2022/5/12 フォーラム内のやりとりを追記

パラドックス社の公式フォーラムにステラリスの開発者日記 第253回が掲載されています。

https://forum.paradoxplaza.com/forum/developer-diary/stellaris-dev-diary-253-three-in-one-3-4-cepheus-patch-notes-and-more.1523352/
forum.paradoxplaza.com

今回はStellaris Ver3.4 ‘Cepheus’パッチに関するお話です。

さらに普通の開発日記もありますが、Modの仕様が変わるようで、今後は日本語化について色々と変更が出てきそうな雰囲気です…😥

以下パラドックスフォーラムの内容を意訳したものとなります。
※画像等はフォーラムより引用。
スポンサーリンク

ステラリス 開発者日記 第253回 三位一体 3.4 ‘Cepheus’パッチノートとその他！

Stellaris Ver 3.4のリリースについて

この箇所の担当はステラリスのプロデューサーObidobiさんです。

皆さんこんにちは！

来週には次の拡張DLC「Overlord」を手に入れられるということで、皆さんもわくわくしていることと思います。
家臣/君主というダイナミックな組み合わせの拡張は多くの皆さん(そして社内的にも)が長い間望んでいたことなので、それがついに実現したのは本当に素晴らしいことです。

Overlordのリリースまでお待ちいただけるよう、変更履歴を含む通常の開発者日記をお届けします。

しかしその前にコミュニティのイベントをいくつか紹介しましょう。

本日17:00 CEST(UTC+2)においてStellaris 公式 DiscordチャンネルにてOverlordに関する開発者Q&Aをお届けします。
今日のパッチノートについて何か質問はありますか？ぜひ立ち寄って聞いてください！

また、5月7日と8日の14:00 CESTから、Content Creator Multiplayer Showcaseに参加してください。
週末はTwitchとYouTubeでOverlordのストリーミング配信を行い、コミュニティコンテンツのクリエイターを何人か紹介する予定です。

管理人注 以下スポイラーでVer 3.4.0 Cepheusのパッチノートがありますが紹介は割愛します。
全容を読みたい方は元サイトにてご確認ください。

Overlordを今日ウィッシュリストに登録してください！

Stellaris Ver3.4 ‘Cepheus’ におけるMod可用性の変更箇所

ここからはステラリス開発チームのテクニカル・スクリプター、Caligula Caesarさんによる紹介です。
以下はModによる改造に関する技術的なお話となります。
管理人は専門的な事は分かりませんので訳は参考程度でお読みくださいm(_ _)m

今回は私の基準でかなり手短にお話しします。
最近のアップデートではMod製作者に多くのものを与えてきましたが、Ver3.4でも同じです。
数週間前にシチュエーションシステムについて説明しましたが、これは間違いなくMod製作者に大いに利用されることでしょうから、ここでは他のスクリプト言語の変更に焦点を当てます。
最も大きな改善点は修飾子の分野です。
トリガーされた修飾子で「mult」値を定義できるようになりました。
これによりトリガーされた修飾子に修飾子またはスクリプト値を適用できます。

triggered_pop_modifier = {
    potential = {
        NOT = { is_same_species = owner }
}
    modifier = { pop_citizen_happiness = 1 }
    mult = modifier:non_main_species_happiness_mult
}

ご覧のようにゲームにはない修飾子を定義しました。これはスクリプト内で独自のアドホック修飾子を定義できるようになったためです。

non_main_species_happiness_mult = {
    icon = mod_planet_happiness_mult
    percentage = yes
    good = yes
    category = pop
}

この修飾子はもちろんどこかに適用されている限りは何かをすることになりますが、現在ではそれが可能な場所がたくさんあります(スクリプト値が有効な場所ならどこでもです)。
例えばこのシステムを利用するため、私たちは種の特性のアメニティをリファクタリングし、ジョブからのアウトプットを交換しました。
これにより種の数を調整するために必要な労力が削減されました(そしてこの点に関するいくつかのバグを追跡することができました)。

地味ではありますがとても良い改善点として、特定のコンテキストで特定の修飾子が機能しないロードオーダーエラーが発生しなくなりました(例：traitのethos修飾子)。

それらだけではありません。オーバーロードDLCの開発は当然ながら古いシステムを再構築する機会を提供しました。
例えば「飛び地」に関するスクリプトでは、新しい「イベント継承」システムを使うことで何千行もの行数を節約することができました。
これによりbase=<some_event_id>を介して別のイベントからプロパティを継承するようにイベントを指定できます。
そしてdesc_clear、option_clear、picture_clear、show_sound_clearにより各種プロパティを上書きすることができます。
基本的にこれにより特定のイベントの動作を継承しながら、そのフレーバーを変更できます。

リストは続きます。新しいcommon/tradable_actionsフォルダーでは、他の帝国と取引可能なカスタムアクションを定義できるようになりました。
例えば臣下は他の利益と引き換えに君主への忠誠を誓うことができます。
またこのフォルダは広範囲に渡ってドキュメント化されています。

# trade_action_my_example_action = {
#   # If this is set to 'yes', then the action will be fired and then removed from the trade deal.
#   # If 'no', then the trade deal will be treated as a treaty that lasts for at least 10 years.
#   fire_and_forget = no
#
#   # Determines if the action will show up in the list in the trade deals view.
#   # SCOPE: Country "giving" the action
#   # FROM: Country "receiving" the action
#   potential = {
#       has_overlord = from
#       is_specialist_subject_type = { TYPE = bulwark }
#   }
#
#   # If this trigger returns 'no', then the trade deal will be cancelled. Checked on daily tick. Only relevant if fire_and_forget is 'no'.
#   # SCOPE: Country "giving" the action
#   # FROM: Country "receiving" the action
#   active = {
#       has_overlord = from
#       is_specialist_subject_type = { TYPE = bulwark }
#   }
#
#   # Effect that fires when the trade deal is accepted.
#   # SCOPE: Country "giving" the action
#   # FROM: Country "receiving" the action
#   on_traded_effect = {
#       from = {
#           set_galactic_custodian = yes
#       }
#   }
#
#   # Effect that fires when the trade deal ends. Only relevant if fire_and_forget is 'no'.
#   # SCOPE: Country "giving" the action
#   # FROM: Country "receiving" the action. Not guaranteed to be valid, since a trade deal is cancelled if one of the countries dies.
#   on_deal_ended_sender_effect = {
#   }
#
#   # Effect that fires when the trade deal ends. Only relevant if fire_and_forget is 'no'.
#   # SCOPE: Country "receiving" the action
#   # FROM: Country "giving" the action. Not guaranteed to be valid, since a trade deal is cancelled if one of the countries dies.
#   on_deal_ended_recipient_effect = {
#       set_galactic_custodian = no
#   }
#
#   # Used to determine how much the AI will value the action in a trade deal.
#   ai_weight = {
#       weight = 1
#
#       modifier = {
#           weight = 2
#           from = {
#               is_galactic_custodian = no
#           }
#       }
#   }
# }

AIと外交と言えば外交行動はスクリプトから少し制御できるようになりました。
それら(およびそれらを取り巻くAIロジック)は、今でもかなりの程度をコードで処理されますが、AIが提案を受け入れるか否かの追加の理由をai_acceptanceフィールドでスクリプト化できるようになりました。
一方、should_ai_proposalフィールドではAIによる提案をブロックできます。

最後にMod製作者の皆さんに知っておいていただきたいのはローカライズの同期に関する変更です。
というか完全に削除されました。
つまりローカライゼーションが使用されていたすべての場所で、代わりに通常のローカライゼーションシステムを使用するようになりました。
これには、いくつかの利点があります。

  • マルチプレイにおいて1人のプレイヤーが中国語でプレイし、1人のプレイヤーが英語でプレイしていても動作するようになりました(現在は動作しません) 。
  • 理論的には現在においてはすべての名称を他の言語に翻訳することが可能です。
    (しかし残念ながらこれが実現するとは約束できません。なぜならヨーロッパの言語はすべて複雑な文法規則を持っており、それに対処する合理的な方法をまだ開発していないからです。でもその可能性はクールなものです)。

残念なことにいくつかの複雑な問題もあります。
それは何か名前が付けられた時点のプロパティをそのまま保存する必要があり(つまり、プロパティは後で変わるかもしれませんが、それがローカライズの内容には影響しません)ます。
またどの言語で再生しているかに関係なく、プロパティが正しくローカライズされていることを確認する必要があります。

これは基本的に名前を設定する際にブラケットコマンドを使用したい場合、名前を設定する場所にそれを登録しなければならないことを意味します。
例えば:

set_name = {
                    key = "NAME_Absorbed_Species"
                    variable_string = "[Root.GetSpeciesNamePlural]"
                }
NAME_Absorbed_Species:0 "Absorbed [Root.GetSpeciesNamePlural]"

random_namesディレクトリにある Empire names(帝国の名前)は、この目的のために新たに “lookups”行が追加されています。

# Imperial Spiritualist 2
empire_name_format = {
    random_weight = {
        factor = 0
        modifier = {
            add = 1
            has_government = "gov_theocratic_monarchy"
            is_pirate = no
            is_primitive = no
            NOT = { is_country_type = fallen_empire }
            NOT = { is_country_type = awakened_fallen_empire }
        }
    }
    lookups = " [This.Capital.GetName]"
    format = format.imp_spi.2 #  of [This.Capital.GetName]
    noun = format.homeworld # [This.Capital.GetName]
    prefix_format = format_prefix.imp_spi.2 # [This.Capital.GetName] 
    # Empire of Earth
}

Modではよくあることですがスクリプト内で名前がインラインで定義されている場合は、以前と同じように動作し続ける可能性があります(角括弧コマンドが使用されない限り)。
というのも中国語(そして現時点において韓国語や日本語)の翻訳を壊してしまうからです(中国語は常に名前を翻訳しているので)。
また設定する名前がローカライズされたキーで、それを参照するつもりがない場合にも問題が生じる可能性があります(注：現在では名前リストもローカライズキーを使用しています)。

注意点として使用可能にする角括弧コマンドはそれぞれC++のコードで動作するように定義する必要があります。
私たちは利用したいと思うすべてのケースをカバーするように最善を尽くしましたが、見逃しているケースもあるかもしれません(この場合、無効なプロパティGetXPersistentに関するエラー・ログが表示されます)。
もし私たちが見逃している特にひどいケースがあればバグレポートを提出してください。

Origin等の紹介

ここからはステラリスゲームディレクターのEladrinさんによる紹介です。

@Eladrinからまだ続きがあります。
今週Nivariasから発表されたオリジン(起源)はProgenitor Hiveでした！

最初は前駆体によるものだった。

あなたの母星での生活は過酷で競争的だったがそれでも強大な前駆体はその領土を拡大していった。
しかしそのような広大な領域に対する運営はすぐに限界に達したため、前駆体は最初の子孫を作った。
やがて子孫は単独では管理できないことが明らかになった。
その結果、子孫はドローンを生み出しこの星を手なずけようとした。

あなたが星を渡る最初の一歩を踏み出すと前駆体は特別な巣に閉じこもった。
より高度で合理化されたコントロールを与えられたあなたは、今や銀河のすべての星に前駆体の影響を広げる準備ができているー前駆体は、過去、現在そしてこれからも存在し続けるのだ。

Progenitor Hiveの起源(オリジン)はOverlord DLCにやってくる新しいハイブマインドの起源であり、そのためにはUtopia(DLC)もプレイ可能である必要があります。
このハイブは強力な子孫の存在に大きく依存しています。近くにいる間、ハイブは非常に効率よく成長し機能します。

この子孫の船はあなたの船団に含めることができ、あなたの船の固有のペナルティを相殺するオーラを提供し、プラスの小さなボーナスを提供します。
タイタンの制限と同様にあなたの帝国がサポートできる子孫の船の数は、あなたの艦隊の総能力に基づいて制限されています。
子孫船はプールを共有しており、大型船がプールの大部分を占めています。

また帝国領域を守るためのスターベース建物もあり、船よりも大きなメリットがあります。

Offspring Nestは通常のハイブのSpawning Poolsに代わるもので、追加のボーナスを提供します。
あなたの惑星のそれぞれにこれを一つずつ欲しいことでしょう。

子孫ドローンの仕事(ジョブ)をする人がいないと、コロニーにいる方向音痴の下働きドローン達が大変なことになりますから必ず誰かを雇ってください。

Progenitor Hive内で雇用されたすべてのリーダーは安定したペースで受動的に経験を積み、他の帝国のリーダーよりもはるかに速いペースでスキルレベルを獲得します。
平均すると、もし経験値ブーストや他の経験値ソースがない場合において約(1.5×目指すレベル)年ごとに受動的にレベルを獲得することになります。
他のハイブとは異なり前駆体は家臣としてセクターを解放することができ、セクターの運命を子孫の支配下に置くことができます。
子孫は前駆体の地位に昇格し新しい帝国の支配者となります。
解放された前駆体の家臣は帝国から前駆体の起源を継承し、それに伴うすべてのボーナスとペナルティを伴います。

Progenitor Hive以外の家臣がいる場合は彼らの世界にOffspring Nest()を構築して、彼らの労働者に必要な監視を行うことができます。基本的には同じ事ですよね？

もう1つ(Progenitor Hiveとは関係ない)物を公開しましょう！

このRanger Lodge(レンジャーロッジ)は対象の惑星の消費材の使用量を削減しますが、同時に自然保護区のブロッカーを作成し、ロッジが存在する限り取り除くことができません。

レンジャー・ロッジはブロック可能な地区がある自然惑星にのみ建設でき、エキュメノポリス、ハイブ・ワールド、マシン・ワールド、レリック・ワールドには建設できません。

オーバーロードを今日ウィッシュリストに登録してください！

以上

フォーラム内のやり取り(Q&A)

フォーラム内のやり取りで気になったものを紹介(全てを紹介するものではありません)。

Q:スパイ活動については何もないのですか。

A:後日カストディアンチームのパッチでスパイ活動にさらなる変更が加えられる予定です。

Q:(日記内で出てきたオリジンの「子孫」とその艦隊のボーナスについて多数の質問があったのでそのまとめの回答)

A:ボーナスはスタック(重複)しません。
艦隊を監督する子孫がいない場合は-50%、子孫の船がある場合は+5%、スターベース建物がある場合は+15%です。

Q:

  1. ゲームのスタート時に種の好む気候がドライ/ウェット/フローズンのいずれでもガイアシーダーを構築できるのですか？
  2. 気候回復のテクノロジーを研究することで、ガイアシーダーを墓石の世界にも構築することができるのか？
  3. ガイアシーダーにより増加した維持コストは「より広い範囲の惑星タイプ」にのみ適用されますか、それとも維持は種族の好みに一致する世界においては現行のゲームバージョンのものから変更されないのか？
  4. Idyllic bloom(のどかな開花)の国是はSubterranean(地下)の起源と互換性があるのか？

A:

  • のどかな開花の国是(通常帝国とハイブマインドの両方)は、生命の播種と粉砕リングの起源と一緒に取ることができます。
  • Life-Seeded(生命の播種)またはShatteredRing(粉砕リング)の起源を持たない市民の帝国は、無料の建物スロットがある場合、これまでのテラフォーミングの試みを表すため、母星にフェーズ1のガイアシーダー建物がある状態からスタートします。
  • フェーズ1ガイアシーダーの建物は居住性や好みに関係なく、すべての惑星タイプで建築できます。
  • 母星と同じ惑星タイプの惑星にガイアシーダーを構築するための新しい要件はありません。
  • Gaia-Seedersのフェーズ2、3、および4のアップグレードでは、母星の気候と比較した惑星の気候に応じて、追加のテラフォーミングテクノロジーが必要になります。
    • 「通常」の居住性を持つ帝国の場合：
      • Terrestrial Sculptingを研究したら、母星と同じ気候タイプの惑星でフェーズ2、3、4のガイアシーダーにアップグレードできます(たとえば熱帯が好みであれば大陸と海の世界にガイアシーダーを構築できます)。
        • 住みやすさの好みと同じ気候を持つが、その惑星タイプではない世界でのガイア・シーダーは維持コストが1.25倍に増加します。
      • Ecological Adaptation(生態学的適応)を研究したら、母星以外の気候の惑星でフェーズ2、3、および4のガイアシーダーにアップグレードできます(たとえば熱帯が好みで、乾燥およびツンドラ世界でガイアシーダーを構築できます)。
        • 居住性の好みと異なる気候の世界のガイア・シーダーは維持コストが1.50倍に増加します。
      • Climate Restoration(気候復元)を研究したら、Tomb Worlds(墓石の世界)でフェーズ2、3、および4のガイアシーダーにアップグレードできます。
        • 墓石の世界のガイア・シーダーは維持コストが1.75倍に増加します。
    • 「特別な」居住性を持つ帝国(例：ガイアワールドまたは粉砕リング)
      • Ecological Adaptation(生態学的適応)を研究したら、湿潤、乾燥、または寒い気候の惑星でフェーズ2、3、および4のガイアシーダーにアップグレードできます。
        • 通常の気候の世界でのガイアシーダーは維持コストが1.50倍に増加します。
      • Climate Restoration(気候復元)を研究したら、墓石の世界にガイアシーダーを構築できます。
        • 墓石の世界のガイア・シーダーは維持コストが1.75倍に増加します。
  • 同じ制限がガイアシーダーのホールディングスにも適用されます。
  • 地下の起源が市民を妨げるとは思いません。

Q:

  • Hyper Relay(ハイパー・リレー)ネットワークを使用するのと同様に、Quantum Catapults(クアンタムカタパルト)を使用できますか。
  • AIは自分たちの宇宙空間を横断する適切なHyper Relayルートを計画できるほど洗練されているのか、それとも単純にすべてのシステムにスパムを送るだけなのか？
  • 防衛プラットフォームが具体的にどのくらいバフ(強化)されたかについて、数値はありますか。パッチノートのバランスセクションには正確な数字は記載されていません。それともアップデートが公開されるのを待たなければならないのでしょうか。

A:

  1. 私はこれを試したことがないので、よくわかりません。
  2. AIは通常、植民地と惑星をつなぐハイパーリレーの構築を優先するが、私は十分な時間をかけて彼らが帝国全体でそれを構築するのを見てきた。維持コストは十分に低い。
  3. 記憶では:
    • ヒットポイントが2倍
    • 建築時間が半分
    • 範囲が10％増加
    • 発射速度が20％増加
    • 追跡が10％増加

Q:これらのパッチ内容にはDLCが必要なのか？

A:いいえ。これらはVer3.4パッチの一部分です。

Q:家臣と子会社の違いはなにか？

A:家臣は企業の君主を持つことはできません。
子会社は企業の君主の家臣や支店に取って代わります。
それぞれには契約期間の制限もたくさんあります。

今回は以上としますm(_ _)m

感想・まとめ

以上、Stellaris 開発者日記 第253回の紹介でした。

まず一番気になったのは、翻訳に関する変更点です。
これ今ある日本語化Modは影響を受けないんでしょうか…😥

中国語はそもそもステラリスにデフォルト言語として含まれているので、それが影響を受けるとかそういう話では無いと思います。

私はModの仕組みの詳しいことまではわかりませんが、とにかくまずは今ある日本語化Modがそのまま機能することを願うばかりです。

さてOverlord DLCは来週リリースとなります。

いつものパターンだとDLCリリースの週は開発日記はお休みだと思うので来週は無しかもしれません。
※一応いつもの時間にチェックはしておきますので日記があったら紹介したいと思います。

追記:ついに日本語が公式に実装される

当記事記事公開後に、パッチノートを読んでいたら日本語がParadox社より公式に実装されるという一文が記載してありました。
(記事作成時には気が付かず…😥)

パッチノートに日本語実装について記載があります

Added Japanese and Korean language support.

公式日本語はStellaris Ver3.4から実装されるようなのでもう間もなくですね😊
ということで、今後はゲームの日本語対応をParadox自らがやってくれることになり、日本語化Modは必要なくなる流れのようです。

今後ゲーム内容が更新された場合に日本語が実装されるペースがどうなるのか、他の言語と同じタイミングで提供されるのか？(過去にParadoxのタイトルでは言語ごとに対応ペースが異なっていた場合があります。)等、不透明な部分はありますが、これで一番いい方向になったような気がします。

日本語化Modは役目を終えるのかもしれませんが、改めてこれまで日本語化作業に携わってきた方々に感謝したいです。いままで本当にありがとうございましたm(_ _)m

ゲーム本体やDLCはこれで大丈夫なんでしょうけど、
ただ、Modを日本語化する場合はまた別の問題が残ると思います。
それに関しては本文にあるように名称付け作業の影響が出ると思いますのでそちらは引き続きどうなるか注意したいところです😥

スポンサーリンク