Caesar III©（ゲームの仕組み）の分解を続けます

Caesar III©のテクスチャを取得し て都市を描画するアルゴリズムは分解され、最も「甘い」部分が残り、15年以上にわたって「古代ローマの建築家」、つまりゲームロジックが引き付けられました。 ゲームの分析に対するさまざまなアプローチを使用して、この小さな研究の結果を判断します。 長い記事を事前に謝罪しますが、彼らが言うように、あなたは歌から言葉を消しません。 結論として、元のゲームの実行可能ファイルから復元されたソースの運命についていくつかの言葉があります。









ちょっとした歴史

ゲームはCで記述されており、WindowsおよびMacで使用できます。 公式リリースは1998年10月に行われました。 Windowsの場合、おそらくゲームはVisual Studio 97でコンパイルされましたが、スタジオ6はまだ人気がありませんでした。 1999年に、ゲームはバージョン1.0.0.3に更新され、既に最も広く使用されているVisual Studio 6でコンパイルされました;パッチ1.1（c3 1.0.1.0）は後に英語版のゲーム用にリリースされました。



コンパイル日： 1999年9月3日金曜日、午前7時31分17秒

リンカーバージョン： 6.0

マシンタイプ： Intel 386以降のプロセッサーと互換性のあるプロセッサー

PEフォーマット： PE32

サブシステム： Windowsグラフィカルユーザーインターフェイス（GUI）サブシステム

最小OS： Windows 95

最小OSバージョン ：4.0

サブシステムバージョン： 4.0

ファイルバージョン： 0.0



また、ゲームのファンは、実行ファイルを修正して、 高解像度の画面で実行できるようにしました。





ゲームは2番目の部分のグラフィックエンジンを使用します。また、中間（デバッグ）バージョンのスクリーンショットもあり、古いグラフィックデザインの要素が表示されます。



シーザー2世





シーザーIII（アルファ）

道路、漁船、倉庫に注意してください。





シーザーIII（最終版）





そして今、より具体的に

そもそも、ゲームでは多くの変数が「マジックナンバー」の形式でコードにハードコーディングされており、指定されたコード例はc3_revディレクトリから取得され、ソースはコンパイルされてデバッグモードで実行され、ロジックを段階的に確認できます。 ニックネームから判断すると、ソースコードを動作状態に仕上げた同胞はメンテナンスに従事しています。

私たちの勇敢なローカライザーは、ゲームをロシア化すると、実行可能ファイルのバイナリコードを編集し、c3.engをc3.rusに置き換え、同時に後のパッチとの互換性を壊しました。







テキストリソース/ローカリゼーション

ゲームのテキストのほとんどは、ミッションのテキストデータを除き、ファイルC3.eng / C3_mm.engにあります

C3.engファイルには、建物、イベント、居住者などの説明が含まれています。 長さ28バイトのヘッダーと、長さ8000バイトのインデックステーブルで構成されます。 インデックステーブルには、選択したインデックスのテキストが配置されるオフセットが含まれます。 ローカリゼーションファイルからテキストを取得するためのアルゴリズムは、たとえば、インデックスTITLE_ADVISOR_EDUCATION（16）を持つ教育アドバイザーのウィンドウのタイトルのテキストを取得するようなものです。インデックスの配列から16番目の要素を選択し、取得したオフセットで最後の0まで文字を読み取る必要があります。







ユーザーインターフェース

ボタンを除くユーザーインターフェイス要素のサイズは、コードに記述されています。 したがって、情報ウィンドウまたはヘルプをドラッグすることはできません。 最初に、ウィンドウの背景が描画され、次にそれに付随する要素が描画されました。







ゲーム内のボタンの高さは固定されており、3つのテクスチャを使用して描画され、ボタンの本体を埋めるために中央のテクスチャが繰り返されます。 たとえば、ボタンは通常の状態です。

+ +



ウィンドウは、次のアルゴリズムに従って描画されます。ウィンドウの端は特別なテクスチャで描画され、中央はシームレスなテクスチャで塗りつぶされます

+ +

+ +

+ +



巨大なメカニズムの細部

ゲームは多数のサブシステム（水の利用可能性、建物の状態、教育、娯楽など）で構成され、それぞれを詳細に検討すると、非常にシンプルであり、その機能の説明はいくつかの段落に収まります。 これらの「ギア」の共同作業は、バランスのとれた刺激的なゲームプレイを提供します。 これらのサブシステムは実際には相互作用しないことに注意してください（劇場の場所は近隣の学校や市場に影響を与えず、医師は通り過ぎる俳優について何も知りません）。 影響の共通点は自宅であり、サブシステムの効果を蓄積します。サブシステムの数が増えると、そのサブシステムのレベルは高くなります。 絶対的な用語での家のレベルは、納税額と利用可能な労働者の数に帰着します。



ルート





異なるタイプの市民のルートは異なります。たとえば、ポイントA2が県の入り口エリアにある場合でも、長官（エンジニア）ルートはパスA1-A2-A1で構成され、その後、ベースに戻ります。 。 アテンダントは道路（橋、門、納屋、北部の貯蔵タイル、庭園、砦の敷地）に沿ってのみ移動します。 敵や野生動物は門を通過できません。 商人とメガポーターは道路に乗ることができますが、可能であれば、目的地までの道路を旅行することを好みます。 ポーターは庭や砦を歩くことができません。





建物には出口ポイントがあり、入口ポイントと一致しない場合があります。 発生の優先度は下にシフトされ、入力の優先度は高くなります。エントリポイントと出口ポイントの間には非常に長い距離があります。



以下では、都市の住民のルートの最大長を指定しましたが、異なる条件下で短いルートと長いルートの切り替えが発生しますが、まだすべてを理解していません。 たとえば、商人は、市場の近くに納屋がある場合、長いルートを含みます。

居住者タイプ	ルートの長さ/短い（タイル単位）
知事、エンジニア	52/43
俳優、剣闘士、調教師、税務署	43/35
司祭、医者、外科医、教師、商人、入浴、美容院	35/26

バイパスルートは、エリアに入る前に計算されます。 「最適な」ルートの選択を開始する前に、労働者の出口地点から道路のあらゆる方向への可能な経路の地図が作成されます。 さらに、得られた各経路はタイルで覆われ、労働者の作業エリアの建物は、彼のサービスの必要性について質問されます。 このインジケーターでは、ワーカーのサービスの需要が高いマーシュアウトが選択されます。



たとえば、知事は、火災の危険性が最も高い地域に行きます。 しかし、難易度は、たとえ最大レベルの火事があったとしても、彼は小さな家の群れには行かないが、火事の危険のレベルがまだ許容できる広いエリアに行くことです。 これは、大きなエリアの合計レベルが小さなエリアのこの数値を超えるためです。 同じことが他のサービスワーカーにも当てはまります。 パスの重要度を計算するアルゴリズムは、さまざまなタイプのサービスを使用するために統一されています。



例外は、ルートをプロットするときに、市場の商品を考慮するトレーダーの行動です。 次の画像は、トレーダーが通ることができる可能なパスを示しています。各交差点は、処理するルートの数を増やします。 最後に、市場から最大量の商品を販売するため、白い行進が選択されます。 トレーダーが選択したルートのエンドポイントに到達し、商品が残っていない場合、マーケットに最も近いルートを検索し、商品が残っている場合、同じルートに沿って戻ります。





家の進化

1つのタイルのサイズが島よりも低いレベルの家を隣人と組み合わせると、2x2タイルのサイズの同じレベルの家が得られます。 家を結合するための追加条件は、 ミニマップを生成するために使用されるバイトminimap_info配列[26244]からの擬似乱数の最初の3ビットの一致です。したがって、都市内のすべての小屋を結合できません。

->

さらに、あるレベルに達すると、次のレベルの家のサイズが現在の家のサイズよりも大きい場合、隣接する領域がキャプチャされます。



中島->大島（1×1-> 2×2）

->

中規模ヴィラ->大規模ヴィラ（2×2-> 3×3）

->

中宮殿->大宮殿（3×3-> 4×4）

->



次のタイルを拡張に使用できます（空の区画、庭、レベル以下の単一の家）。 家の拡張は4つの方向（北、西、南、東）で解決されます



都市人口

市の人口は、0〜99歳の年齢で分けられます。 各家には、この家に住む住民の数と年齢を示すcharの人々[100]の配列が含まれています（配列のインデックスは住民の年齢に対応し、要素の値は特定の年齢の住民の数に対応します）。 毎年の初めに、配列の要素が1つの要素だけシフトされるため、長い肝臓が削除され、新生児用のセルが追加されます。 家の中の子供の出現の可能性と、老年期からの家の人口の自然な減少を計算する関数が呼び出されます。







サービスとリソースの消費

家は資源（食物、料理、油、家具、ワイン）とサービス（宗教、医療、教育など）を消費します。 食物の消費は家の住民あたり0.5単位の食物の割合で月に1回発生し、他の資源の消費は住民の数を除いて家ごとの1単位で月に2回発生します。 サービスの消費は毎日1ユニット発生します。 サービスは、あらゆるレベルの家が各サービスを100ユニットしか保存しないため、常に更新する必要があります。 それどころか、食料と資源の貯蔵は家のレベルに依存します。家が大きくなればなるほど、貯蔵できるさまざまな種類の再利用が多くなり、ゲームでは家は次の6ヶ月間商人から商品を購入します。



宗教



ゲームには5つの神（Ceres、Neptune、Mars、Mercury、Venus）がいます。 気分計算アルゴリズムは誰でも同じです。 都市のカバレッジは、地域ではなく人口によって考慮されます。 すべての寺院は、これが影響しない神の態度に好きなように立つことができます。 これらの寺院の司祭が仕える家の雰囲気は、寺院の場所に依存します。 カバレッジの割合は、次の式を使用して計算されます



Base_value = 100 *（500 *オラクルの数+ 750 * working_small寺院+ 1500 * working_larger）/ number_people。

「働く」という概念の下で、これらの寺院は少なくとも一人の労働者がいるところに落ちます。



神の態度に影響を与える追加の要因。

Festival_Factor = 12-最大（40、months_from_Last_Fest_For_this_Godhood）

神殿の要素=50。彼は、都市にある神殿の数が最大である神を受け取ります。複数ある場合、この要素はすべての人に対してリセットされます。

非尊重ファクター= -25。 彼は街で最も少ない寺院を持つ神を受け取ります。 そのような神々が複数ある場合、この要素はすべての人に対してリセットされます。



金星はボーナスの分配には参加しません。 おそらくバグ。



Final_setting = Base_value + Festival_factor + Templeファクター+非尊重ファクター。



都市の人口に応じた最小ムード値の制限。

人口	最小限の気分
0〜99	50
100〜199	40
200〜299	40
300〜399	30
400-499	20
400-499	10
> 500	0

神々の気分

各ゲーム日（25ティック）に、各神の気分がカウントされます。 神格には現在の気分があり、更新されるたびに、現在の気分は1単位ずつ真に近づきます。 例として、私たちは火星に何かを不快にさせ、それを修正しようとせず、火星の現在の気分を100に、真の気分を0にします。毎日、戦争の神の現在の気分は1単位減少します。 16日間のゲーム月に、6か月のプレイ時間の後、火星の街が（100/16）を処罰することが判明しました。おそらく、「神聖なランダム」が存在するためです神は抵抗することができます）。





ネタバレの下で、私は怒りのポイントの計算について説明しました（これらは、カエサルを演じた宗教顧問の窓に、神の気分の横に稲妻の形で表示されます）



各ゲーム月（16 * 25 = 900ティック）、怒りや神の祝福の出現を決定する追加のロジックが実行されます。





祭り/街の気分



ゲームには、小、中、大の3種類のフェスティバルがあります。 祭りは神の一人に捧げられ、祭りは都市への神の態度に影響を与えます。 祭りの費用を計算するための式は、表に示されています。

種類	費用	ワイン	準備時間
小さい	人口/ 20 + 10	-	2ヶ月
中	人口/ 10 + 20	-	3ヶ月
大きい	人口/ 5 + 40	人口/ 500 + 1	4ヶ月

祭りが開催された後、祭の神格の雰囲気を高めることに加えて、支配者に対する市民の態度も改善されます。 12か月間、ムードを高める2つのフェスティバルを開催できますが、次のフェスティバルは市内のムードを向上させません。 この表は、都市の雰囲気を高める値を示しています。

種類	最初に	第二
小さい	7	2
中	9	3
大きい	12	5

ファイナンス

あなたがまだ何かを建てることができる都市の最大負債は、 -5000デナリです。 この状態は、すべての財務アクションで確認されます。





労働顧問の画面で設定した労働者の年salは、デナリで指定された値の1/10です。 数値30は、従業員への年間3デナリの支払いを意味します。これは、ゲームでは、財務計算が整数で実行されるためです。





労働者には毎月、簡単な公式に従って給与が支払われます。

Zp_v_ denarii =（月末の従業員数）*（zp_worker）/ 10/12

この金額は、市の宝庫から、たとえばトロピコでは居住者の財布に送金されたどこにも持ち込まれませんが、これはまったく別の話です。



都市が借金を抱えている場合、つまり 上のメニューに表示される金額が0未満の場合、市はローンの一種であるローマに利息を支払い始めます。

ローンの利率は10％で、毎月市の財務省から差し引かれます。



ペイアウト=（-money_of_trend）* 10/100/12



ローマが初めて5,000借金に達すると、ローマは融資を行います（ミッションによって異なりますが、通常10,000日）。2回目も金額を取得できますが、すでに融資として考慮されています。



税金



毎月、都市の家は税金を生み出します。これは家のレベルとそこに住む人々の数に依存します。 家からの税金は、徴収人が新しい年の初めに通り過ぎるときに徴収され、徴収されなかった場合は前年の金額が燃え尽きます。 税のレベルは、構成ファイルc3_model.txtで設定されます。都市の複雑さのレベルは、複雑さのレベルによっても影響を受けます。

難易度	係数
とても簡単	300％
かんたん	200％
わかった	150％
難しい	100％
とても難しい	75％

自宅から税金を計算するための最終的な式は次のようになります。

総税（Dn）=（tax_base / 2）*（percentage_city_state_city）/（12 * 100（



ファイル帝国

年末に、市は収入の一部をローマに送ります。支払いは、市の住民の数と利益に依存します。 ゲームでは、利益は収入と支出の差です。 市が借金を抱えている場合、税率は25％で、税は支払われませんが、天皇の好意は減ります。

収益コンポーネント	原価構成要素
寄付	建設業
商品の輸出	商品の輸入
	ローン金利
	定規の給料
	残り
	給与

また、税の最小値は、都市の人口によって決まります。

人口	利益なし/利益あり
0〜500	0/50
501-1000	0/150
1001-2000	100/225
2001-3000	200/300
3001-5000	200/400
5000+	200/500

天皇の好意



任務の成功に重要な役割を果たしているのは、支配者と都市の評価に対する天皇の態度です。 皇帝の気分に最も大きな影響を与えるのは、「都市の収益性」や、皇帝の要求の履行/無視などのパラメーターです。



贈り物は、あなたに対する天皇の意見を大いに増加させますが、頻繁に贈り物をすることで、彼らの影響は著しく減少します。 有利な変化を計算するとき、過去12か月間に行われたすべてのギフトが考慮され、それらは表にリストされます。

ギフト番号	控えめな	親愛なる	素晴らしい
1	3	5	10
2	1	3	5
3	0	1	3
4	0	0	1
5+	0	0	0

皇帝によって設定された時間に、要求が満たされると、一定の増加が得られます。 リクエストがCaesarによって設定された時間より後に完了した場合、報酬の半分しか受け取れません。それを無視すると、8ユニットだけ完全に敬意を失います。締め切り。



ストーリーのリクエストとギフトに加えて、慈善の価値の更新は毎年の初めに実行され、次の要因に依存します。

ベース変更 = -2

納税の成功 = 納税が成功した場合は +1、1年、2年、または2年以上納税しなかった場合はそれぞれ-3、-5、-8。

給与 =給与が現在のルーラーレベルの給与よりも低い場合は+1、レベルを上回る各ランクについては-1

イベント =ミッションに依存します。たとえば、人口1000人に達すると+5



文化の評価



ゲーム内の文化の評価は、都市の魅力を判断できる総合的な評価です。 それは、劇場、寺院、学校、アカデミー、図書館での都市の報道のレベルで構成されています。 間接的に、教育的要素の存在（文化のレベルは30以上）によって、都市には裕福な市民がいることがわかります。



文化_評価=劇場_評価+寺院_評価+ライブラリ_評価+学校_評価+アカデミー_評価





劇場の評価値は、場所に関係なく、劇場の収容人数と居住者数の比率に対応します。

Theater_ Rating = 500 * working_theaters / populationの数。 このカバレッジに従って、評価が選択されます。

カバレッジ	文化ポイント
0〜30％	0
31〜50％	3
51〜70％	8
71〜85％	12
86-99％	18
100 +％	25

劇場の評価は、場所に関係なく、寺院の収容人数と居住者数の比率に対応しています。

神殿の評価= 150 *小寺院の数+ 300 *大寺院の数+ 500 *神託の数。

劇場と同様に、評価値は表から選択されます。

カバレッジ	文化ポイント
0〜30％	0
31〜50％	3
51〜70％	9
71〜85％	14
86-99％	22
100 +％	30

教育



学校は最大15の文化ポイントを持ち込み、計算は学齢期の居住者に対して行われ、各学校は75人の生徒を収容します。

アカデミーは10文化ポイントを追加し、学生年齢の居住者に対して計算が行われ、アカデミーは100人の学生を訓練します。

図書館には、住民の総数で計算される20ポイントがあり、1つの図書館で最大800人の住民にサービスを提供できます。

都市のカバレッジレベルに対する文化ポイントの依存性を表に示します。

カバレッジ	学校	アカデミー	図書館
0〜30％	0	0	9
31〜50％	1	1	2
51〜70％	4	2	4
71〜85％	6	4	8
86-99％	10	7	14
100 +％	15	10	20

リソースと生産





ゲームの経済の基礎はリソースであり、一部のリソースは処理が必要です。そのため、たとえば鉄鉱山->武器など、最も単純な生産チェーンが現れます。ゲーム内のリソースは無制限です。ただし、魚の数が限られている釣りスポットは例外です。



小麦は、ゲームが紹介する最初のリソースです。中部地方では、小麦農場は他の農場よりも効果的ですが、北部および砂漠地域では機能しません。農場は肥沃な土壌に置かれ、地図上に黄色い芽として表示されます。収穫物は納屋または倉庫に運ばれます。農場、採掘ビル、およびワークショップは、1スキームに従って動作し、25ティックごと（ゲーム1日に1回）、次の式に従って生産の進捗が更新されます。



生産の最後に、商品のポーターが作成され、それが最寄りの保管場所に配送されます。商品を配達することが不可能な場合、彼は生産の近くに立ちます。ポーターがビジーで、新しい製品がすでに生産されている場合、ポーターがリリースされるまで生産は停止します。



リソースの保管と配布



リソースの保管と配布には2つのタイプの保管が関係します。納屋と倉庫、納屋は製品のみを保管し、市場トレーダーは納屋から商品を受け取り、倉庫はあらゆる種類の商品を保管し、商人に販売できます。従業員の数が半分未満の場合、ボールトは商品の受け取りを停止し、ボールトは商品の配達に参加しません。ただし、特別な「商品受け取り」モードは例外です。別に。



商品のリソース抽出、処理、およびマーケティングの組み合わせは、非常に発展したことが判明しました。少数の商品はプレイヤーにミクロ管理を課しません。また、保管場所や配送場所の選択など、ほとんどの日常的なアクションの自動化により、戦略的計画のための定規室が残されます。



この時点で、おそらく記事を終了します。都市間の貿易や軍事作戦などのトピックは船外に残り、それぞれが非常に大きく、まだ十分な資料がありません。ご清聴ありがとうございました、



ZY記事の最後で、元のゲームのソースコードを復元するときに、ゲームのファンが見つけられなかった点や注意を払わなかった点をさらに追加できることは間違いありません。オリジナルの作者が慎重に磨き上げたバランスを崩さないように、ゲームロジックに関する一般的なアイデアを得ることが重要でした。復元されたソースについては、通常の（コンパイルするだけの）外観にするのに十分な忍耐力はありませんでしたが、親切な人（AntonBaracuda、github.com / AntonBaracuda / opencaesar3 / c3_rev）がこの大変な作業を完了しました。指定されたアドレスに、ソースおよび部分的に構造化されたファイルといくつかの関数があります。これらはすべてコンパイルおよび起動され、デバッガーで最初の関数を実行できます。



参照資料





(, )

CaesarIA: (opensource, c++, SDL)(Window,Linux,Mac,Haiku,Android)