iOSのジャンル「シミュレータ」のゲームでのメカニクスとグラフィックの最適化

数年前のジャンルとしてのシミュレーションゲームの台頭は、ルーチン化がゲーミフィケーションに役立つことを示しました。 WWDC 2015の主要なプレゼンテーションで言及されたGoat Simulatorの周りの誇大広告は神格化されました。私たちは、Simulators Liveのパートナーが取り組んでいる地下鉄の仕事をシミュレートする一連のクロスプラットフォームアプリケーションのエンジンの開発に参加することで、この傾向を無視しませんでした。



Subway Simulator-一連の地下鉄シミュレーションゲーム。 2014年にリリースされた最初のバージョンのゲームは、非常に抽象的でしたが、同様のテーマの製品に対する需要を確認し、非常に高いものでした。 製品の後続の更新と新しいバージョンは、地下鉄シミュレーターをより現実的にすることを目的としていました。列車と駅のモデリングが新しいレベルに達し、ゲームの「ローカライズされた」バージョンがロンドン 、 上海 、 モスクワ 、その他の都市の地下鉄を表示しました。 現時点では、iOSでのゲームの最初のバージョンのインストールの総数は、ほぼ100万番目の値に達しました。 同時に、ゲームは他のプラットフォームでも利用可能になります。









十分に大きな寸法の空間での運動のシミュレーションに基づいてエンジンを開発する場合、デバイス上で適切に動作するためにメモリの制限を考慮する必要があります。 深刻なリソース消費を必要とするゲームでは、最適化がユーザーエクスペリエンスの決定要因になります。 その助けを借りて、リアルで魅力的な画像とスムーズなゲームプレイプロセスを提供できます。 この記事では、Subway Simulator 3Dシミュレーターでの作業と、品質を損なうことなくメモリ消費を最小限に抑えるために使用されたさまざまなタイプの最適化に焦点を当てます。



アプリケーション開発は、最も手頃なゲームエンジンUnityで実行されました。 アップデートのために新しいステーションのモデルをエンジンに定期的にアップロードすることを計画しているという事実を考慮して、私たちは最も単純だが唯一可能な解決策、つまりゲームのモジュラーコアに決めました。



実際、彼の仕事の原理は、古典的なランナーのそれと同じです。



プレイヤーのプレハブがあります（この場合、必要な構成モデルがロードされる列車の構成、およびその他のパラメーター-速度、摩耗、パワー、音など）。



オブジェクトのブロックまたはタイルがあり、それぞれにモデルを埋め込むためのオブジェクトがあります。また、モデルのゼロ座標とその反対側の端のピボットがあり、そこから次のブロックのスポーンの位置が自動的に計算されます。



ゲームには、いくつかのタイプのブロックが含まれています。



トンネル -線形または曲線-は関係ありません。

ステーション -ゲームの独自のイベントリストとカットシーンを持つブロック。 乗客のプレハブが含まれています。

カスタムイベントブロック -分岐のあるトンネルが含まれる場合があります。たとえば、列車は緊急停止、減速などが必要です。



エンジンの本質：







図からわかるように、私たちの主人公は電車です。 したがって、彼に関しては、道を構築しています。 列車は主にルートコントローラーと接続されており、ルートコントローラーは、列車が移動する動的なルートラインを構築します。 ライン自体は、各ブロックで準備されたTransform'amに従って構築され、各Transformはレールトラックのちょうど中央に配置されます。



ゲームプレイの動的コンポーネントは、最もリソースを消費します。 適切に最適化するために、いくつかのソリューションを適用する必要がありました。 以下を検討してください。

電車の動き

列車のエンジンを作成する際の主な問題は、移動プロセスをどの程度徹底的に再作成するかです。 ここでは、列車が物理的な物体であると十分に想像する必要があります。これはマルチトンオブジェクトであり、徐々に加速して停止する必要があり、その位置と傾きは軌道の回転の程度に応じて決まります。



物理学の法則に完全に準拠して列車の動きをシミュレートすることには問題があります。 少なくとも、WheelCollidersの摩擦を考慮する必要があります。これは、Unityで常に適切に動作するわけではありません。特に、単なる車よりも複雑で大型の車輪付き車両に関してはそうです。 これは多くの要因の1つにすぎません。 最も深刻な障害は、物理学のこのような詳細な誤計算がエンジンに過度の負担をかけることです。 これはパフォーマンスに悪影響を及ぼし、バグを追加します。



私たちの意見では、最善の方法は物理学の動きを特定のルートに沿った位置のオフセットとしてのみ実行することです。



シミュレーターでの列車の回転は、2つの角度（現在と以前）の差に基づいて計算されます。 差が大きければ大きいほど、列車は横に傾き、対応する横揺れが発生します。

private void Change() { target.position = Vector3.Lerp(target.position, currentPoint.position, lerpSpeed * Time.deltaTime); //     -   if (Vector3.Distance (PivotTrain.position, target.position) < damper) { //    ,       float DeltaR = Roll - (currentPoint.rotation.z - previousPoint.rotation.z); //      if (!(DeltaR > 0.05f || DeltaR < -0.05f)) Roll = Mathf.Lerp(Roll, currentPoint.localRotation.z - previousPoint.localRotation.z, 10 * Time.deltaTime); //   NextCall (); } private void NextCall() { //   ,      ,         if(!CurrentPoints[0].GetComponent<itemWay>().Last) previousPoint = currentPoint; CurrentPoints [0].GetComponent<itemWay> ().EndBlock (); CurrentPoints.Remove (CurrentPoints [0]); currentPoint = CurrentPoints [0]; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

列車は、カメラのアニメーション（運転者が動きの速度によって決まるペースで頭を振る）と、ブレーキの速度または程度に応じた列車モデル自体の揺れのアニメーションにより揺れます。 カメラまたはオブジェクトのサイクリックアニメーションは、NGUIエンジンの標準コンポーネントである通常のTweenPositionまたはTweenTransformを簡単に作成できます。



主なものは、アニメーションをコンポジションの速度に依存させることです。 列車の速度係数を考慮した依存関係の例を以下に示します。

 void FixedUpdate() { speed = TrainEngine.Instance.speed; maxSpeed = TrainEngine.Instance.maxSpeed; tweenRot.dutation = (speed / maxSpeed) * 10; tweenRot.from.y = speed / (maxSpeed)/30; tweenRot.to.y = -tweenRot.from.y; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

物理学が整理されたら、次の問題に進みます。 ブロックに基づいてエンジンを作成する場合、現在のブロックのオブジェクトから列車までの距離を読み取る必要があることに留意してください。 理想的には、距離を最小に計算するために操作の数を減らす必要があります。



エンジンのロジックは、任意の瞬間に、列車とそれに最も近いブロックの間でのみ距離が計算されることを意味します。 残りのトンネルとステーションはプール（オブジェクトプーリング）にあり、メインコントローラーと対話しません。 列車がアクティブなブロックを通過するとすぐに、後者はアクティブなシートからパッシブなブロックにリダイレクトされます。



lenghtBegin-ブロックの長さ。その後、削除してパスをさらに構築できます

ItemType-ブロックタイプ

 private void DistanceCheck() { if ((Vector3.Distance(transform.position, player.transform.position) > lenghtBegin)) { //  ActiveBlock=false; Model.SetActive(false); //   ,      WayController.Instance.ReturnBlock(ItemType); //   WayController.Instance.GenerateWay(); } } WayController.cs //    public void GenerateWay() { //             if (CurrentLenght < LenghtTunnel) { RespawnTunnel (); } else { //   RespawnStation(); } } //  ,      .       public void RespawnTunnel() { countLinear++; if (countLinear > LenghtLinear) { countLinear = 0; if (turnTunnel!=null) LoadTurn (Random.Range (0, turnTunnel.Count)); else LoadLinear (Random.Range(0,frontTunnel.Count));  } else { LoadLinear (Random.Range(0,frontTunnel.Count)); } } //     public void LoadLinear(int num) { if (RespList) RespBlock.Add(frontTunnel [num]); //     CurrentBlock.Add (frontTunnel [num]); //         CurrentBlock [CurrentBlock.Count-1].ChangePosition (); CurrentBlock [CurrentBlock.Count - 1].transform.SetParent (RootTransform); frontTunnel.Remove (frontTunnel [num]); } //    -  ,  -         public void ChangePosition() { Model.SetActive (true); this.transform.position = new Vector3 (WayController.Instance.EndBuild.position.x, WayController.Instance.EndBuild.position.y, WayController.Instance.EndBuild.position.z); this.transform.rotation = Quaternion.Euler (WayController.Instance.EndBuild.eulerAngles.x,WayController.Instance.EndBuild.eulerAngles.y, WayController.Instance.EndBuild.transform.eulerAngles.z); rotationTile = EndPos.rotation.eulerAngles.y; WayController.Instance.BuildWay (EndPos.position,rotationTile); SetWayPoint (); } //             public void SetWayPoint() { for (int i = 0; i < WayPoints.Count; i++) RouteController.Instance.CurrentPoints.Add (WayPoints [i]); } t = target.position - transform.position; toRot = Quaternion.LookRotation(t); transform.rotation = rot;  pos = transform.position + transform.forward * speed * Time.deltaTime; //    RigidBody     rbTrain.MovePosition (pos);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、Route ControllerスクリプトはWay Controllerと直接連携する必要があります。 Route Controllerが処理し、移動の目的として列車に与えるオブジェクトのリストを定義するのはWay Controllerです。



使用するエンジンのバージョンの主な利便性は、ライン上の動きの性質を一度に変更するために必要な値を駆動するだけで十分であることです。 たとえば、現在の移動時間がユーザーに適していないことが統計で示されている場合、駅間の線を長くしたり短くしたりします。 新しいステーションモデルがある場合は、単純にそれらをエンジンモデルのリストに追加し、それぞれでピボットの開始と終了を設定できます。



アプリケーションで静的な場所が使用されている場合、フラッシュと更新は非常に面倒で時間のかかるプロセスになります。 このバージョンでは、最小限のアクションで、サーバーを使用せずに新しいステーションまたは追加のモデルでバージョンをダウンロードできます。 もちろん、大量の更新がある場合でも、サーバーが唯一の正しいソリューションです。

デバッグメトリック

移動に関連する別の問題は、Unityでの距離とメトリックの比率です。 列車のパスが常にブロック単位で連続的に生成される場合、遅かれ早かれ、オブジェクトは適切なフレームのレンダリングが不可能になるような座標になります。



複数のメッシュで構成される列車のキャビンは、座標が高すぎる値に達すると文字通り揺れ始めました。



これは、Unityには無限空間の概念がなく、座標値を簡単に計算できる条件付き境界のみがあるという事実によるものです。 これらの境界から離れるほど、シーンのレンダリングでエラーが発生します。



これに基づいて、ゲームエンジンにリスポーンを追加することを決定しました。言い換えると、駅に到着すると、列車はそれとトンネルの最も近い調整ブロックをゼロ座標点に戻すことを確認しました。 このソリューションは、プレイヤーが30分以上ロールした場合の動きの計算におけるエラーの可能性を減らします。

 public void RespawnStation() { StationResp [0].SetTriggers (false); StationResp [0].transform.localPosition = new Vector3 (0.0f, 0.0f, 0.0f); StationResp [0].transform.localRotation = Quaternion.identity; EndBuild.transform.position = new Vector3(StationResp [0].EndPos.position.x,StationResp [0].EndPos.position.y,StationResp [0].EndPos.position.z); EndBuild.transform.rotation = Quaternion.Euler (StationResp [0].EndPos.eulerAngles.x,StationResp [0].EndPos.eulerAngles.y, StationResp [0].EndPos.eulerAngles.z); Train.transform.localPosition = new Vector3 (RespPoint.localPosition.x, RespPoint.localPosition.y, RespPoint.localPosition.z); Train.transform.localRotation = RespPoint.localRotation; WayController.Instance.RebuildBlocks (); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エンジンで行われた作業によりメモリが大幅にアンロードされましたが、そこで停止しませんでした。 次のステップは、アプリケーションの視覚と音声を最適化することでした。

テクスチャ圧縮

Subway Simulatorの最初のバージョンには、事前設定された光源（リアルタイムを含む）を含む静的な場所が含まれていました。 このようなコンセプトは、ゲームがインターフェイスと場所、列車、人の両方にマルチポリゴンモデルと多数のテクスチャを使用するまで機能しないことがすぐに明らかになりました。 それ以外の場合は、中程度のメモリコストで高品質を提供する別のオプションを選択する必要があります。



まず、プリベイクドライトカード（LightMaps）を備えたシェーダーが作成されました-照明の計算を原則として放棄し、マテリアルの特別なシェーダーと電車のスポットライトに置き換えたいと考えました。



テクスチャリングの際、 ここで説明した方法が使用されました。 実装では、すべてが非常にシンプルでしたが、パフォーマンスへの影響が最も有益でした。



RGB Compressed PRVTC 4ビット圧縮を使用して、各ロケーションテクスチャを256x256に圧縮しました。 しかし、LightMap（照明マップ）は、別々のRGBチャンネルの1つの画像にペアで配置されました。



チャンネルミキシングシェーダーも追加され、3つのバリエーションの目的のマップがオブジェクトの近くの目的のマテリアルに表示されます。 わかりやすくするために、テクスチャにRGBを混合したシェーダーコードの一部のスクリーンショット：

 void surf (Input IN, inout SurfaceOutputStandard o) { fixed4 c = tex2D (_MainTex, IN.uv_MainTex) * _Color; fixed4 light = tex2D (_Light, IN.uv2_Light); fixed4 g = tex2D (_MainTex2, IN.uv_MainTex); fixed a = (c.r+c.g+cb)/3; fixed3 r; rr = ((g.r+(cr-a))*_R)+((g.g+(cr-a))*_G)+((g.b+(cr-a))*_B)+((g.a+(cr-a))*_A); rg = ((g.r+(cg-a))*_R)+((g.g+(cg-a))*_G)+((g.b+(cg-a))*_B)+((g.a+(cg-a))*_A); rb = ((g.r+(cb-a))*_R)+((g.g+(cb-a))*_G)+((g.b+(cb-a))*_B)+((g.a+(cb-a))*_A); o.Albedo = r.rgb; o.Metallic = _Metallic; o.Smoothness = _Glossiness; o.Emission = ((light.r*_N1)+(light.g*_N2)+(light.b*_N3)+(light.a*_N4))*r.rgb; o.Alpha = ca; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、画像自体の色は圧縮されますが、アルファチャネルマップ、照明、コントラストは許容可能なサイズのままであるため、モバイルデバイスの画面からは品質の劣化はほとんど目立ちません。







上記はテクスチャ分布の例です。 左の画像には色のみが含まれています。可能な限り圧縮します（中規模の場所のテクスチャの場合、制限は原則として正確に256ピクセルです）。 右の画像には、3つのRGBチャンネルのコントラストとLightMapが含まれています。



アプリケーションの各コンポジションには、512 x 512の解像度で4つの異なる色があるため、トレインでテクスチャをパックする同じ方法を使用しました。したがって、ロケーションとトレインの両方のメモリ消費を削減することができました。



また、小さな場所のオブジェクトに対して2ビット圧縮を実行することも非常に便利です。 大きなオブジェクトでは、このソリューションは機能しません-目に見えるアーティファクトが表示される場合があります。



以下のスクリーンショットは、このような圧縮の試みが失敗した例です。場所の上部にアーチファクトがはっきりと見えます。

音とモデルの圧縮

追加の最適化の一環として、すべてのサウンドを最大値1に絞りました。テストの経験から、モバイルデバイスからの音質の低下はほとんどないことがわかりました。 また、すべてのサウンドファイルのモノラルモードを設定すると、メモリ消費がほぼ半分に削減されました。



参考のために：Decompress On Loadを長いサウンドに適用し、Compressed In Memoryを短いサウンドに適用することをお勧めします。

プロトタイプモデリング

優れたシミュレーターのタスクは、ユーザーにゲームプロセスの詳細なメカニズムに興味を持たせるだけでなく、適切な画像を提供することでもあります。 実際のコピーから複数の列車と駅をシミュレートすることが決定されたものに基づきます。 パブリックドメインにあるスケッチとスキームのおかげで、現時点では、3つのモデルの列車と、モスクワと北京の地下鉄のいくつかの駅を実装することが非常に可能になりました。



ポリゴンステーションの平均指標は、25〜3万ポリゴンおよび列車の12〜2万ポリゴンです。 上記で述べたように、テクスチャ圧縮とオブジェクトごとのマテリアルの量に対する厳格な制限が追加で適用されました。 テクスチャとモデルの数が非常に多いので、テクスチャの事前に作成されたシャドウマップのみに焦点を当てて、照明の計算ミスを放棄しました。



シミュレーション結果は次のとおりです。













地下鉄駅「ノボスロボツカヤ」、写真





地下鉄駅「Novoslobodskaya」、スクリーンショット

おわりに

個々のロケーションブロックをロードしてゲームエンジンを静的カードから動的カードに変更すると、操作中のアプリケーションのメモリ消費を大幅に削減することができました。 これで、アプリケーションはより弱いデバイスで実行でき、同時に非常に許容可能な1秒あたりのフレーム数を生成できます。



テクスチャとアトラスをRGBチャンネルの個別のスペクトルにパックすると、アプリケーションの重量を減らすことができました。 これは、アトラスが存在しても保存できないほど多くのテクスチャがアプリケーションにある場合に特に重要です。 「シミュレータ」というジャンルのゲームを開発する場合、環境の信頼性には写真的に正確な要素の最大数が必要になるため、この問題は特に深刻です。 私たちの場合、この圧縮とパッキングの段階のおかげで、ゲームで最も必要なすべての詳細をまともな品質で維持することができました。



メカニックの実装に関しては、ここでは、場所の動的な読み込みにより、プレイヤーによるゲームプレイの受け渡しプロセスとセッションの長さを制御することが可能になりました。 あるレベルまたは別のレベルでプレイする平均的なユーザーのデータに基づいて、弱点と長所を特定し、それに応じてゲームプレイを拡張またはトリミングできます。 また、ダイナミックエンジンのおかげで、将来、アプリケーションを完全に再構築することなく、サーバーから直接新しいステーションをエンジンに追加することが可能になりました。



提案されたソリューションが読者の関心を引くことを願っています。 ご清聴ありがとうございました！