35MMゲームの作成。 ロシアのポスト黙示録

すべての良い一日、私の名前はセルゲイノスコフです。 今日は、2016年にSteamでリリースされた35MMと呼ばれる最初の本格的なインディープロジェクトの作成についてお話ししたいと思います。 物語はもちろん長く、それ以来、プロジェクトのトピックに関するいくつかの記事とインタビューが公開されていますが、開発プロセスの詳細な説明はありませんでした。 また、実装の技術的な側面はほとんど触れられていません。 実際に、これについて話します。



少し背景から始めましょう。 35MMは、ロシアのポスト黙示録の設定で一人称視点での冒険です。 人々-ウォーキングシミュレーター。 このゲームは、文明によって残された無人の地を2人の放浪者が旅する物語を語っています。 人口の大部分はひどい病気の後に死亡し、今や自然は人類からそのポイントを取り戻しています。 残念ながら、私はこのプロジェクトのアイデアがどのように生まれたのか正確には覚えていませんが、当時はストーカー、メトロゲーム、一般的にそのような雰囲気のあるテーマの熱烈なファンだったことを間違いなく覚えています。 放棄された都市、工業地帯、村の風景はいつも私の不安と喜びを呼び起こしました。 私はそれがどんな病気なのか、そのような愛をどのように説明するのかわかりませんが、私たちの多くがいます。 一般的に、このトピックに対するそのような情熱は、あなた自身の小さなゲーム世界を作り始めるのに十分でした。









既に2つの小さなプロジェクト（LightとTrain）があり、Unityエンジンの経験があるため、新しいゲームの開発を開始しました。 間違っていなければ、その時点でエンジンの5番目のバージョンはすでに利用可能でしたが、ある程度私は保守的である（私の最高の専門的特性ではない）ので、バージョン4.7にとどまることにしました。 一般的な理解のために、エンジンのバージョン4と5の間には、特にレンダリング、照明、およびマテリアルに関して、多くの重要な違いがあります。 Unity 5は、光を正しく反射して反射を表示できる物理的に正確なシェーダーを導入しました。 簡単に言えば、このようなシェーダーを使用したマテリアルのグレアと反射は、より自然で魅力的に見えます。 バージョン4では、基本的なシェーダーははるかにシンプルでしたが、独自のシェーダーを作成すると、画像の品質が大幅に向上します。 これについては少し後で説明します。 ゲーム自体の開発に加えて、ゲームの開発には多くの側面が含まれることは明らかです。 エンジンが何かを詰め込むには、モデル、テクスチャ、サウンド、スクリプトなどのコンテンツが必要です。 最終的にはすべてモニター上で確認でき、列で確認できます。 そしてもちろん、各タイプのコンテンツには独自のソフトウェアが必要です。 3Dモデルを作成するために、3D maxを使用して、2Dグラフィックスを操作し、テクスチャを作成しました-Photoshop、サウンドを操作しました-Adobe Audition、Unityに付属のMonodevelopプログラムでコードを書きました。 特に目を閉じるか、次の章にスキップすることをお勧めします。ゲームはJavascriptで書かれています。 ただ、誰にも言わないでください。 一部の人にとってはこれが悪い味であり、誰もJavascriptについて書いていないことを知っています。 一般に、メインツールが選択され、ワー​​クフローは徐々に遠ざかりつつあります。

それがすべて始まった方法

いくつかのインタビューで、私は通常、明確な開発計画を持っているのではなく、全体像だけを持っていると述べました。 したがって、多くの場合、場所の作成は自発的に行われ、デザインは外出先で検討されます。 もちろん、これはプラスよりもマイナスですが、プラスの面もあります。非常に面白く、次に何が起こるかを正確に知ることはできません。 ゲームは、初期段階ですでにある程度の生活を送っています。 35MMの開発は、放棄されたフォレストハウスと、畑と針葉樹林のある広々とした区画の最初の場所の作成から始まりました。







地球の表面を構築するために、草と土の5-6のテクスチャーを持つテレーンを使用しました。 標準のテレーンシェーダーは、エンジン自体にブラシを使用して作成したRGBAマスクを使用して、さまざまなテクスチャで表面をペイントします。結果はしばしば非常にぼやけて見え、テクスチャ間の遷移は滑らかすぎて自然に見えません。 この点を改善するために、テレーンシェーダーが変更され、オフセットマスクが追加されました。 白黒のテクスチャは、地形に描かれたマスクを「シフト」し、破れた鋭いエッジを作成し、視覚的に表面の外観をわずかに複雑にしました。











私たちの土地の表面は、ランダムに散らばったプレインの形でいくつかのタイプの草で補われました。 ユニットにはビルボードモードもあります（グラスプレーンが常にプレイヤーを見る場合）が、一人称視点でのプレイにはあまり適していません。 この喜びは多くのドローコールを投げ、パフォーマンスに影響を与えるため、常に芝生に注意して合理的な範囲内で追加する必要があります。 ドローコールが多いほど、コンピューターシステムの負荷が高くなります。 しかし、チャレンジだけでなく負荷も増加することを忘れないでください。 ゲーム内のパフォーマンスを殺す方法はたくさんあります。 地面の草に加えて、変更のために、枝と石のメッシュが散らばり、汚れと車の車輪の痕跡が付いた一連のデカールが散らばっていました。







サーフェスを作成したら、植生、木々、茂みに行きます。 私は、テレーン自体のツールを使用して、つまりブラシで森林の主要部分（針葉樹）を植えることを好みました。 この方法の利点は、迅速かつ簡単に、しかも遠く離れた場所で行われることです。このようなフォレストはメッシュからビルボードに変換され、最適化に非常によく影響します。 しかし、負荷の近くでは大幅に増加します。なぜなら、私が理解しているように、そのような木は転がらないからです。 たぶん私は間違っている、誰かが私を修正します。 バッチ処理は最適化のための非常に重要なツールです。 大まかに言うと、これは1つの共通メッシュ内の1つのマテリアルとメッシュの組み合わせであり、それぞれドローコールの数を大幅に削減し、負荷を軽減します。 地形上の座席のもう1つのマイナス点は、木の同じ位置です。つまり、それらはすべて同じ角度で作成され、この同一性が顕著です。 この点で、私はいくつかの松、トウヒ、および落葉樹をさまざまな角度で、さまざまなサイズで手動で設置しました。これにより、風景に多様性が追加されました。 茂みは同じように配置されました。











完全を期すために、空に対処することが残っています。 このタスクでは、6つのテクスチャを持つ通常のスカイボックスマテリアルが使用されました。 空がダイナミックに見えるようにシェーダーを変更する試みがありましたが、結果はそれ自体を正当化せず、この考えは捨てられました。 別の方法は、雲のテクスチャとモーショントゥイーンのある水平ビルボードを備えたパーティクルシステムの使用でした。 私が覚えている限りでは、Stalkerゲームでも同様のオプションが使用されていましたが、実際には他にも多くのオプションがあります。

照明

Unityエンジンの4番目のバージョンでは、ライトマップをベイクするための非常に便利なモード、デュアルライトマッピングがありました。 現在のバージョンにも同様のオプションがありますが、まだ詳しく調べていません。 デュアルモードでは、近距離でリアルタイムにシャドウとグレアを描画できましたが、カメラから離れると、この全体がスムーズにベイクされたライトマップになり、ハードウェアのタスクが大幅に容易になりました。 一般に、ゲームのすべての場所でこの方法を使用しました。 その結果、それぞれの中間の位置について、近いプランの約5〜10個のライトマップのセットがベイクされ、遠いプランの同様の量がライトされました（近くのプランのライトマップもアンビエントベイクされたアンビエントのみ）。











一般に、多くの分野で、太陽の光を除いて、完全に焼き付けられた光を使用しようとしました。 ポイントライトは、アクセントとより多くの光を強調するために場所に置かれました。 これは主に、外光がほとんど透過しない部屋で行われました。 もちろん、多くの場所で、影付きのライトタイムランプも使用されました。火からの光、テーブルランプ、天井または壁のランプです。 ちなみに、照明を扱うときは、ポイントランプとリアルタイムシャドウに関連する大きな問題に対処する必要がありました。 一部の地域では、カメラが影のある点光源を注視すると、不気味なフリーズとブレーキがかかりました。 負荷が非常に高い理由は完全には明らかではありませんが、その瞬間のプロファイラーは一瞬ドローコールの過剰な値を示しました。 状況を修正するために、互いに反対方向に向けられた2つのスポットフィクスチャの使用が役立ちました。 このオプションはそれほど重くありませんでした。

モデル

ゲームの3Dモデルのほとんどは独立して作成されました。 法線マップやその他の微妙な部分を焼いて、何かを非常に慎重に行い、時間を節約するために急いで何かを作成しました。 ほとんどのオブジェクトはグループで作成され、単一のアトラステクスチャを使用しました。 つまり、1つのテクスチャには、たとえば、コンクリートブロック、道路標識、レンガの破片、下水道のハッチなどのセクションがありました。 これにより、これらすべてのオブジェクトに1つのマテリアルを使用できるようになり、それに応じてオブジェクトがばらばらになりました。 私たちが思い出すように、これはかなり良いです。 一部のモデルは、無料のライブラリからインターネットから忠実にダウンロードされました。 基本的に、これらは部屋を埋めるための小さな道具ですが、類似性があまりはっきりしないように、これらすべてのモデルを少し修正しようとしました。 多くの場合、インディーズゲームの同一の資産に気づきました。これは、私の方法に最適な方法ではなく、ある程度影響を与えました。 作成に関して最も問題があったのは、トランスポートでした。 車輪付き車両のゼロからのモデリングは非常に時間がかかり、多くの時間がかかります。 そのため、私はAsset Storeで車のコピーをいくつか購入しました。















別の「歌」はキャラクターの作成でした。 これはまだ実験中です。 ゲーム内に何らかの形で存在できるキャラクターが世界に登場するのにどれだけの作業が必要かについての良い考えを持っていない人のために、私は説明します。 ハイポリモデルは、すべての詳細、袖のボタン、顔のしわなどで作成されます。 テクスチャスキャンを使用して同じキャラクターの低ポリゴンモデルが作成されます（私のゲームでは、キャラクターあたりのポリゴンの数は平均で約5〜8千でした）。 さらに、法線マップであるアンビエント（ソフトシェーディング）マップは、cな操作または複雑でない操作によって、低ポリモデルの高ポリモデルから削除されます。 通常はアンビエントから、Photoshopで拡散マップを作成します。 アルファチャネルの拡散反射光マップで、鏡面反射光マップを作成して輝きを作成します。











2019年にはもちろん、それはすでに原始的すぎますが、16年の間、インディーズプロジェクトにとっては非常に適していました。



さらに、ペルシャ人はジップアップする必要があります-骨を配置するために、彼は手足を動かしたり、顎を動かしたり、指を曲げたり曲げたりすることができます。 最後に、全体をアニメーション化する必要があります。 通常、キャラクターはさまざまな状態（歩く、走る、立つ、座る）でアニメーションのセットを作成します。 しかし、たとえば私の場合、私たちのヒーローであるペトロヴィッチのパートナーには、ドアを開ける、地図を調べる、盗賊との戦い、Borレベルで光爆弾を投げるなど、さまざまなアクションが必要でした。 これらはすべて手作業でアニメーション化する必要がありましたが、もちろんその不器用さは非常に印象的です。 一般に、人間の動きの手動アニメーションは非常に難しいタスクであり、もっともらしい結果を達成することは非常に困難です。 したがって、モーションキャップはこのタスクに最適なソリューションです。 私の知る限り、受信したデータを手動で処理して「クリーンアップ」する必要がありますが、このオプションはアニメーターの作業よりも安価で高速です。

シェーダー

その時点でシェーダーの記述を非常に表面的に理解していたことをすぐに明確にします。 私のトレーニングは、主に既製の例とその改良の分析でした。 ネットワークからさまざまなオプションを取り、パラメーターを変更し、新しいパラメーターを追加するか、古いパラメーターを削除して、これが結果にどのように影響するかを確認しました。 これは非常に刺激的な活動であることが判明しました。 私にとって特に興味深いのは、マスクとしての異なるテクスチャチャンネルの操作です。 場合によっては、最大量の情報を1つのテクスチャに合わせて使用​​しようとしました。 記事の冒頭で、Unityの4番目とそれ以降のバージョンの違い、特に最新のものには物理的に正しいシェーディングが存在することについて言及しました。 私は自分でこの欠点を解消しようとしましたが、フレネル効果が鏡面反射光、キューブマップ、法線マップを使用して標準シェーダーに追加されました。 これは、反射マテリアルのこのような機能です。ビューに対して角度を付けたサーフェスは、環境（この場合はcubmap）をより強く反射し、通常はより明るくコントラストが強くなります。 これは光沢のあるボールで非常に顕著であり、そのエッジは中央よりも明るく見えます。 私はこの効果を繰り返すことができただけでなく、マテリアルにカブマップをペイントする機能を追加することができました。これは通常、反射するが粗い表面で見ることができます。 このシェーダーは私に完全に適しており、ゲーム内のほとんどのマテリアルに適用されました。











2番目の興味深い経験は、キャラクターのスキン用のシェーダーの作成でした。 基礎は、モデルに影響を与える照明の強度と色の原因となるグラデーションテクスチャを使用できるようにするインターネット上のコードです。 真ん中に赤みがかった同様のテクスチャーにより、人間の皮膚を模倣することが可能になりました。つまり、少し半透明、つまり、光がスムーズに散乱する独自の厚さを持っています。 効果は完全ではありませんが、標準的なプラスチックのバンプ付き鏡面反射鏡よりも見栄えがよくなります。







上記のシェーダーに加えて、作業中に個々の効果を持つ多くの二次オプションが作成されました。 たとえば、cubmapと拡散マップデフォメーションを備えた水たまりシェーダー。 水たまりに実際の反射を適用するのは費用がかかりすぎるため、テクスチャでレンダリングを使用したくありませんでした（これは、フレームをテクスチャに保存し、マテリアルで使用するとき、たとえば、暖かい空気の歪みを作成できるとき）水たまりに引き伸ばされました。 効果は非常に素晴らしく、鉄にまったく負担をかけませんでした。 ちなみに、テクスチャーにレンダリングするシェーダーは、灯油ランプとたき火の空気の歪みにのみ使用されていました。 デトネーター資産からの熱変形だったようです。 また、ボリュームの光線をシミュレートするために、ソフトパーティクルエフェクトとリムライトエフェクトを使用して頂点シェーダーが作成されました（角度でポリゴンを見ると、メッシュはアルファになります）。 これは、古典的な実装済みの方法です。 さて、新しいUnityには、ポストエフェクトに基づいて動作するクールなオプションがあり、シャドウを考慮に入れても実際の光線を描画できます。



別の注目に値するのは、濡れた表面をシミュレートするために作成されたシェーダーのセットです。 このゲームには、ある時点で豪雨が始まり、いくつかの素材が特徴的な光沢をスムーズに獲得するというエピソードがあります。 主な効果は地形に適用され、水たまりの場合のように、拡散テクスチャが歪み始めました。 水漏れは家の窓にも現れました。 さて、最も「濡れた」チップは、レンズに落ちる水滴でした。 実際、ヒーローには眼鏡もヘルメットも付いていなかったので、ここで私は疑いで苦しみました。 しかし、視覚的には効果が非常に気に入ったため、拒否することはできませんでした。







したがって、スムーズにポストエフェクトに進みます。 画面上のドロップといえば、すべてが簡単です。テクスチャからの数滴が乗算され、異なる速度で下に移動します。 並行して、波（グラデーションテクスチャ）が下に移動し、それぞれが独自のドロップグループで乗算されます。 次に、全体が要約され、「拡散」にわずかに表示されますが、いわば、主に座標をシフトするためのマスクとして使用されます。 その結果、私たちの写真は水滴の屈折によって歪められます。 カメラで常にまたはオプションであったポストエフェクトの主なセット（プレーヤーがオンまたはオフにした場合）は、アンチエイリアシング、SSAO、ブルーム、収差、ビネット、サンシャフトです。 これらはすべて標準のUnityエフェクトですが、SSAOが修正され、ある距離での影のレンダリングがゼロになるようになりました。霧の距離では影の暗いスポットが奇妙に見えたためです。 収差効果も変更されました（これは、レンズ使用時の画像の色の歪み、オブジェクトの端の色の輪郭のようなものです）。Unityの標準効果は、オブジェクトの赤紫色の端を塗りました（私の意見ではかなり奇妙な解決策）。 実際、ほとんどの場合、色は黄赤青に近いものでした。 別の永続的な効果は、自作の色補正でした。 標準的なUnity効果はリソースを集中的に使用しているように見えたため、独自の単純化された効果が実現しました。 基本的に、彼はトンマッピングの効果を作成し、カラースキームをより冷たいものにわずかに変更しました。 画像のカラーパレットを選択することは常に困難な作業であり、決定するのは困難です。 あなたは完全に反対のオプションを好むかもしれず、決定を下すことは非常に難しいことが起こります。 このプロジェクトでは、くすんだ色と冷たい色に決めました。 多くの人にとって、彼女は過度に色あせたように見えましたが、私には、彼女が私のゲームに反映しようとした気分、悲しみ、落胆、孤独の気分を非常に正確に伝えています。

コードはどうですか？

インタビューの中で繰り返し述べましたが、私は常にプログラミングのトピックからは遠く離れており、視覚的なコンポーネントに重点を置いています。 「Train」ゲームに取り組んでいる間に最初の本格的なコードを書き始めたので、35MMが開発される頃には、すでにいくつかのスキルがありました。 一般的に、クエストのジャンルは、私の初期レベルでプログラミングを理解するのに非常に適しているように思えました。 ゲーム内のアクションのほとんどはトリガーに基づいています。 オブジェクトがトリガー（コライダーを備えた立方体）に入り、何かが起こり始めます。たとえば、カットシーンが始まります。 スクリプトでは、演劇のスクリプトのように、いつ何が起こるかを行ごとに説明しています-プレイヤーのカメラがオフになり、カットシーンカメラがオンになり、キャラクターがフレームに表示され、会話アニメーションが開始されます。 このプロセス全体を簡単にするツールはあると思いますが（深く掘り下げなかったためだと思います）、このオプションは、あなた自身がすべてのイベントを制御するため、最も理解しやすいようです。



ゲーム内でのパートナーの動きは、トリガーを使用して実装されました。トリガーはルートのチェックポイントです。 トリガーを押すと、新しいアニメーションがオンになるか、キャラクターが何かを言うことができます。







このメソッドは、最後を除くすべてのレベルで使用されました。 市内の最後の場所で、パートナーと一緒に彼女に着いた場合、彼はもはや私たちをルートに沿って案内しませんでしたが、むしろ私たちを追いかけました。 NavMesh（オブジェクトがターゲットへのパスを検索してそこに移動することを可能にするシステム）に基づくコントローラーは、そこで使用されています。







ゲームの2番目の場所にあるクマでは、事態はさらに困難でした。 リジッドボディ（物理ボディ）でのみ動作するコントローラーが使用されていたため、獣は愚かで、しばしば木や他のオブジェクトに衝突しました。 摩擦がゼロの物理的な材料により、深刻なジャムを回避することができ、その結果、クマは滑り落ちて私たちを追い続けました。 ここで、そして一般的にあなたが死ぬ可能性のある地域で、私は私にとって最も深刻な問題に遭遇しました-死の開始と再起動。 死亡時には、キャラクターの現在の状態をすべて考慮する必要がありました。懐中電灯が点灯しているか、カードが開いているか、ナイフが作動しているかなどです。 また、ヘルスとすべてのリソースの値を保存することも必要でした。その後、アクティブ化されたすべてのものを非アクティブ化し、カメラの落下アニメーションを開始する必要がありました。 画面を暗くした後、すべてを返して保存された値を読み取る必要がありました。 実際、適切なアプローチには大きな困難はありませんが、私の場合、バグがたくさん発生しました：クマが攻撃したときにナイフが私の目の前に残っていたので、カードは消えませんでした-そのようなすべて。 さらに、プレイヤーがこの瞬間にどのように自分を導くことができるか、彼がどこに走るのか、熊がどのような状況で導くことができるのかは決してわかりません。 一般に、すぐには予測できない多くのニュアンスがあります。



キャラクターとオブジェクトの相互作用は、レイキャストレイを使用して実現されました。 すべてのインタラクティブオブジェクトはSubjectタグでタグ付けされ、ビームがヒットするとバックライトがアクティブになり（メッシュはエッジが強調表示されます）、このオブジェクトで実行できるアクション（オブジェクトのピックアップ、読み取りなど）を既に担当するスクリプトが含まれていますメモまたはドアを開けます。



インタラクションについては、最初はオブジェクトに手を伸ばす本格的なハンドを作成する計画がありました。これにより、存在のより明白な効果が生まれます。しかし、このオプションは、実装の大きな難しさと将来のバグの「バンドル」の可能性を表していたため、すでに選択されたアイテムを運ぶ手しかありませんでした。カメラの前には小さなハンドルが付いたプレハブがあり、そこにはすべてのオブジェクト（カメラ、ナイフ、aなど）がすでに存在しています。ゲーム中にオブジェクトを選択すると、目的のオブジェクトがオンになり、不要なオブジェクトがオフになります。







興味深い点は、キャラクターが話しているアニメーションに関連していました。テクニックは原始的ですが、私はそれを自分で考え、誇りに思っています。最初は、キャラクターとコミュニケーションをとるとき、あごが開くアニメーションをフレーズごとにランダムな順序で開始する必要があると考えました。しかし、その後、スクリプトが再生時にサウンドトラックの音量レベルを読み取り、このレベルをフロート値に転送できることがわかりました。この値はすでにヒーローのあごの位置を担当しています。最終的には、音声ファイルのビートに合わせて単語を発音するときに顎が自動的に開きました。これはタスクを非常に単純化しましたが、あまりにも「マシン」に見えました。

最適化

最適化は開発の非常に重要な部分であり、さまざまなハードウェアでゲームがスムーズに機能するかどうかは依存しています。プロジェクトの視覚コンポーネントの最適化に触れます。これにはいくつかの便利な方法があります。lodのグループ、カリングがオクルードされる、オブジェクトを遠くにクリッピングする。 LODグループは、「重い」高ポリゴンオブジェクトの場合に使用する必要があります。これを行うには、異なる数のポリゴンで複数のメッシュを作成します。カメラが被写体から遠ければ遠いほど、モデルはフレームに描かれます。たとえば、35MMの場合、車、キャラクター、一部の木のモデルでlodが使用されました。通常、2〜3個のロードが作成されました。その後の各メッシュのポリゴンは、ほぼ2倍少なくなりました。明確にするために、元の車のモデルは15,000のポリゴンで構成され、最初のLODにはすでに約9トンがあります。（リブの数が減り、ヒンジ、内部部品などの小さな部品が削除されます）、2番目のLODは既に5トンに達します（ドアハンドル、キャビン内のミラーが削除され、ジオメトリがさらに簡単になります）。さらに同じ流れで。ところで、1つの興味深いトリックがlodに使用されました。 lodを使用してオブジェクトのライトマップをベイク処理する場合、両方のオブジェクトをベイク処理する必要があります。ベイク処理の時間を短縮し、システムメモリを節約するために、割り当てられたライトマップを親オブジェクト（LODがゼロ）から他のすべてのlodにすべての座標とともに自動的に転送するスクリプトを使用しました。1つの興味深いトリックが使用されました。 lodを使用してオブジェクトのライトマップをベイク処理する場合、両方のオブジェクトをベイク処理する必要があります。ベイク処理の時間を短縮し、システムメモリを節約するために、割り当てられたライトマップを親オブジェクト（LODがゼロ）から他のすべてのlodにすべての座標とともに自動的に転送するスクリプトを使用しました。1つの興味深いトリックが使用されました。 lodを使用してオブジェクトのライトマップをベイク処理する場合、両方のオブジェクトをベイク処理する必要があります。ベイク処理の時間を短縮し、システムメモリを節約するために、割り当てられたライトマップを親オブジェクト（LODがゼロ）から他のすべてのlodにすべての座標とともに自動的に転送するスクリプトを使用しました。



2番目の最適化方法は、オクルージョンカリングです。これは、カメラの視野にない、または別のオブジェクトによって閉じられているすべてのものが遮断されるメカニズムです。たとえば、壁の後ろの部屋に入ると、路上に多くのオブジェクトが表示されなくなります。そのため、レンダリングにリソースを費やす必要はありません。







レンダリングを簡素化する別の便利な方法は、オブジェクトを遠くにクリップすることです。これは、プロジェクト「Light」の時から出会った最初のオプションです。各レイヤーのレンダリング距離を調整するスクリプトがカメラに掛けられています。私の場合、3つのカテゴリのレイヤーが特別に作成され、小さなオブジェクト（家庭用品、ハンマー、レンガ、小さな破片）で、平均サイズと平均サイズよりわずかに高い（ティーポット、茂み、植木鉢、小さな街灯柱など）。 3つのカテゴリに距離が割り当てられました：40、80、120メートル。指定した距離を超えると、カメラは対応するオブジェクトのレンダリングを停止しました。このオプションは非常に便利で効果的です。小さな小道具が遠くから見えなくなるため、レンダリングする意味がありません。

音

ゲームのサウンドのほとんどは、インターネットの無料ライブラリから取得されました。通常、必要なオプションをダウンロードし、Adobe Auditionでそれらを組み合わせて混合しました。一般的に、この作業はこの作業についてはあまり説明しません。これは、かなり日常的で退屈なプロセスであり、私にとって特に魅力的ではないからです。ちなみに、サウンドの導入、カットシーンのスコアリング、適切なタイミングで目的のサウンドが再生されるようにサウンドファイルを調整する作業は、おそらくゲームの全体の作業時間の4分の1でした。唯一の楽しい瞬間は音楽の紹介でした。音楽の導入では、クールで非常に才能のある作曲家、ドミトリーニコラエフが働きました。概して、私が聞きたいことを正確に知らなかったので、私は彼がしたことに非常に満足しています。しかし、ドミトリーは気分がとてもよく感じました、プロジェクトで作成され、大気環境の形で実装されました。幻想的で神秘的でメロディックなものになりました。



もう1つの興味深いステップは、声優のキャラクターを扱うことでした。外部からの批判にもかかわらず、私はまだ結果に満足しており、俳優は彼らの仕事を非常にうまくやったと思います。ところで、主人公はVsevolod PetrykinとAlexander Bragiによって表明されました。



一般に、サウンドに重大な問題はありませんでしたが、リリース後、私はまだその性質を理解していなかったため、私はまだ克服できないというまれなバグが発見されました。音の一部が再生されなくなったり、何らかの強力なエコー効果で聞こえることがありました。ヒーローと話すと、声が突然消え、同じように突然回復する可能性があります。大きな負荷と多数のサウンドが同時に再生されることに関連する推測がありました。バグとリバーブゾーンの関係についても仮定がありましたが、これは正確ではありません。



おそらくそれだけです。開発から長い時間が経ち、いくつかのことは忘れられ、いくつかは完全に無関係になりましたが、この記事が誰かにとって有用であり、いくつかの質問に対する答えを提供してくれることを願っています。みなさん、ありがとうございました！