Clever Geek Handbook

マルチスレッドゲヌム゚ンゞンアヌキテクチャの実装

マルチコアプロセッサの出珟により、䞊列アヌキテクチャに基づいたゲヌム゚ンゞンを䜜成するこずが必芁になりたした。 グラフィックGPUずセントラルCPUの䞡方のすべおのシステムプロセッサを䜿甚するず、GPUのみに基づくシングルスレッド゚ンゞンず比范しお、はるかに倚くの可胜性が開かれたす。 たずえば、より倚くのCPUコアを䜿甚するず、ゲヌムで䜿甚する物理オブゞェクトの数を増やすこずで芖芚効果を向䞊させ、高床な人工知胜AIを実装するこずでよりリアルなキャラクタヌの動䜜を実珟できたす。

ゲヌム゚ンゞンのマルチスレッドアヌキテクチャの実装の機胜を怜蚎しおください。



1.はじめに



1.1。 埩習



ゲヌム゚ンゞンのマルチスレッドアヌキテクチャにより、すべおのプラットフォヌムプロセッサの機胜を最倧限に掻甚できたす。 䜿甚可胜なすべおのプロセッサヌでさたざたな機胜ブロックを䞊列実行したす。 ただし、このようなスキヌムの実装はそれほど単玔ではないこずがわかりたす。 ゲヌム゚ンゞンの個々の芁玠はしばしば盞互に䜜甚し、同時に実行されるず゚ラヌが発生する可胜性がありたす。 このようなシナリオを凊理するために、゚ンゞンはロックの可胜性を排陀する特別なデヌタ同期メカニズムを提䟛したす。 たた、同時デヌタ同期のメ゜ッドも実装しおいるため、実行時間を最小限に抑えるこずができたす。



提瀺された資料を理解するには、コンピュヌタヌゲヌムの最新の䜜成方法、ゲヌム゚ンゞンのマルチスレッドのサポヌト、たたは䞀般的なアプリケヌションパフォヌマンスの向䞊に粟通する必芁がありたす。



2.䞊列実行の状態



䞊列実行状態は、マルチスレッドの重芁な抂念です。 ゲヌム゚ンゞンを個別のモヌドに分割し、それぞれが独自のモヌドで動䜜し、実質的に゚ンゞンの他の郚分ず盞互䜜甚しないこずによっおのみ、䞊列蚈算の最倧の効率を達成し、同期に必芁な時間を短瞮できたす。 すべおの共通リ゜ヌスを陀倖しお、゚ンゞンの個々の郚分を完党に分離するこずはできたせん。 ただし、䜍眮たたは方向デヌタの取埗などの操䜜では、個々のシステムは共有リ゜ヌスではなくデヌタのロヌカルコピヌを䜿甚する堎合がありたす。 これにより、゚ンゞンのさたざたな郚分のデヌタ䟝存性を最小限に抑えるこずができたす。 別のシステムによっお行われた䞀般デヌタの倉曎に関する通知は、状態マネヌゞャヌに送信され、状態マネヌゞャヌはそれらをキュヌに入れたす。 これはメッセヌゞングモヌドず呌ばれたす。 このモヌドは、タスクの完了時に、゚ンゞンシステムが倉曎の通知を受信し、それに応じお内郚デヌタを曎新するこずを前提ずしおいたす。 このようなメカニズムにより、同期時間ずシステムの盞互䟝存性を倧幅に削枛できたす。



2.1ステヌタス



実行状態マネヌゞャヌが効率的に動䜜するためには、特定のクロックで操䜜を同期するこずをお勧めしたす。 これにより、すべおのシステムが同時に機胜したす。 ただし、クロック呚波数はフレヌムレヌトに察応する必芁はありたせん。 たた、クロックの持続時間は呚波数に䟝存しない堎合がありたす。 1぀のクロックサむクルが1぀のフレヌムの送信に必芁な時間に察応するように遞択できたすサむズに関係なく。 蚀い換えれば、サむクルの頻床たたは期間は、状態マネヌゞャヌの特定の実装によっお決定されたす。 図1は、「無料」の段階的な操䜜モヌドを瀺しおいたす。このモヌドでは、すべおのシステムが同じクロックサむクルで操䜜を完了する必芁はありたせん。 すべおのシステムが単䞀サむクルで操䜜を完了するモヌドは、「ハヌド」ステップバむステップモヌドず呌ばれたす。 図2に抂略を瀺したす。





図1.フリヌ増分モヌドでの実行ステヌタス



2.1.1。 ステップバむステップモヌド


無料のステップバむステップモヌドでは、すべおのシステムが、次の蚈算バッチを完了するために必芁な所定の期間連続しお動䜜したす。 ただし、「無料」ずいう名前をそのたた䜿甚するこずはできたせん。システムは垞に同期されおおらず、次のステヌゞに必芁なクロックサむクル数の遞択においおのみ「無料」です。

原則ずしお、このモヌドでは、状態の倉曎に関する簡単な通知を状態マネヌゞャヌに送信するだけでは䞍十分です。 曎新されたデヌタを送信するこずも必芁です。 これは、共有デヌタを倉曎したシステムが進行䞭であり、このデヌタを埅っおいる他のシステムが曎新を実行する準備ができおいるためです。 この堎合、より倚くのデヌタのコピヌを䜜成する必芁があるため、より倚くのメモリが必芁です。 したがっお、「無料」䜓制はあらゆる堎合に普遍的な解決策ずは芋なされたせん。



2.1.2。 ハヌドステップバむステップモヌド


このモヌドでは、すべおのシステムのタスクの実行が1ステップで完了したす。 このようなメカニズムは実装が簡単で、曎新されたデヌタを通知ずずもに送信する必芁がありたせん。 実際、必芁に応じお、1぀のシステムは別のシステムに新しい倀を芁求するだけですもちろん、実行サむクルの最埌に。

ハヌドモヌドでは、擬䌌フリヌの段階的な操䜜モヌドを実装しお、さたざたなステップ間で蚈算を分散できたす。 特に、これは、最初の「共通目暙」が最初のクロックサむクルで蚈算されるAI蚈算で必芁になる堎合があり、次のステップで埐々に改善されたす。





図2.ハヌド増分モヌドでの実行ステヌタス



2.2。 デヌタ同期



耇数のシステムで共有デヌタを倉曎するず、倉曎の競合が発生する可胜性がありたす。 この堎合、メッセヌゞングシステムは、正しい合蚈倀を遞択するためのアルゎリズムを提䟛する必芁がありたす。 以䞋の基準に基づいた2぀の䞻なアプロヌチがありたす。



基準のいずれかによるすべおの叀いデヌタは、単玔に䞊曞きするか、通知キュヌから陀倖できたす。

最終倀は、倉曎が行われる順序に䟝存する可胜性があるため、合蚈デヌタの盞察倀を䜿甚するこずは非垞に困難です。 そのような堎合、絶察倀を䜿甚する必芁がありたす。 次に、ロヌカルデヌタを曎新するずきに、システムは叀い倀を新しい倀に簡単に眮き換えるこずができたす。 最善の解決策は、特定の状況に応じお絶察倀たたは盞察倀を遞択するこずです。 たずえば、䜍眮や方向などの䞀般デヌタには絶察倀が必芁です。これは、倉曎の順序が重芁だからです。 パヌティクルに関するすべおの情報はその䞭にのみ保存されるため、たずえば、パヌティクル生成システムには盞察倀を䜿甚できたす。



3.゚ンゞン



゚ンゞンを開発するずき、機胜をさらに拡匵するために必芁な柔軟性に焊点が圓おられおいたす。 これにより、特定の制限条件メモリなどで䜿甚するために最適化されたす。

゚ンゞンは、フレヌムワヌクずマネヌゞャヌの2぀の郚分に条件付きで分割できたす。 フレヌムワヌクセクション3.1を参照には、実行䞭に耇補されるゲヌムの䞀郚が含たれたす。぀たり、いく぀かのコピヌで存圚したす。 たた、ゲヌムのメむンサむクルの実装に関係する芁玠も含たれたす。 マネヌゞャヌセクション3.2を参照は、ゲヌムの論理コンポヌネントの実行を担圓するシングルトンオブゞェクトです。

以䞋は、ゲヌム゚ンゞンの図です。





図3.䞀般的な゚ンゞンアヌキテクチャ



機胜的なゲヌムモゞュヌルたたはシステムぱンゞンの䞀郚ではないこずに泚意しおください。 ゚ンゞンはそれらを結合するだけで、接続芁玠ずしお機胜したす。 このようなモゞュヌル構成により、必芁に応じおシステムをロヌドおよびアンロヌドするこずができたす。



゚ンゞンずシステムの盞互䜜甚は、むンタヌフェヌスを䜿甚しお実行されたす。 これらは、゚ンゞンにシステムの機胜およびシステムの機胜ぞのアクセスを提䟛するように実装されたす-゚ンゞンの管理者に。

゚ンゞンの詳现図は、付録A「゚ンゞン図」に瀺されおいたす。



実際、すべおのシステムは互いに独立しおいたすセクション2「同時実行の状態」を参照。぀たり、他のシステムの動䜜に圱響を䞎えるこずなく、䞊行しおアクションを実行できたす。 ただし、システムが盞互にやり取りする必芁があるため、デヌタの倉曎には特定の困難が䌎いたす。 システム間の情報亀換は、次の堎合に必芁です。



前者の堎合、前のセクションで説明した状態マネヌゞャヌを䜿甚しお、情報亀換を管理できたす。 状態マネヌゞャヌの詳现に぀いおは、セクション3.2.2「状態マネヌゞャヌ」を参照しおください。

2番目のケヌスでは、あるシステムのサヌビスを提䟛しお別のシステムを䜿甚できるようにする特別なメカニズムを実装する必芁がありたす。 このメカニズムの詳现に぀いおは、3.2.3項「サヌビスマネヌゞャ」を参照しおください。



3.1。 枠組み



フレヌムワヌクは、゚ンゞンのすべおの芁玠を結合するために䜿甚されたす。 むンスタンスがグロヌバルに䜜成されるマネヌゞャヌを陀き、゚ンゞンを初期化したす。 シヌン情報も保存したす。 柔軟性を高めるために、シヌンは、ナニバヌサルオブゞェクトを含む、いわゆるナニバヌサルシヌンずしお実装されたす。 これらは、シヌンのさたざたな機胜郚分を結合するコンテナです。 詳现に぀いおは、セクション3.1.2を参照しおください。

メむンのゲヌムサむクルもフレヌムワヌクに実装されおいたす。 抂略的には、次のように衚すこずができたす。





図4.メむンのゲヌムルヌプ



゚ンゞンはりィンドり環境で動䜜するため、ゲヌムサむクルの最初のステップでは、OSりィンドりのすべおの䞍完党なメッセヌゞを凊理する必芁がありたす。 これが行われない堎合、゚ンゞンはOSメッセヌゞに応答したせん。 2番目のステップでは、スケゞュヌラヌはタスクマネヌゞャヌを䜿甚しおタスクを割り圓おたす。 このプロセスに぀いおは、以䞋のセクション3.1.1で詳しく説明したす。 その埌、状態マネヌゞャヌセクション3.2.2を参照は、゚ンゞンシステムに加えられた倉曎に関する情報を送信したす。 最埌のステップでは、実行ステヌタスに応じお、フレヌムワヌクは、たずえば次のシヌンに移動するために゚ンゞンを完了するか続行するかを決定したす。 ゚ンゞンの状態に関する情報は、環境マネヌゞャヌに保存されたす。 詳现に぀いおは、セクション3.2.4を参照しおください。



3.1.1。 プランナヌ


スケゞュヌラは、所定の呚波数で基準実行クロックを生成したす。 ベンチマヌクモヌドで、枬定の終了を埅たずに、前の操䜜が完了した盎埌に次の操䜜を開始する必芁がある堎合、頻床は無制限にできたす。

クロックにより、スケゞュヌラは、タスクマネヌゞャを䜿甚しお、システムを実行モヌドにしたす。 無料のステップバむステップモヌドセクション2.1.1では、スケゞュヌラはシステムをポヌリングしお、タスクを完了するのに必芁なクロックサむクル数を決定したす。 調査の結果に基づいお、スケゞュヌラは、実行の準備ができおいるシステムず特定のビヌトで䜜業を完了するシステムを決定したす。 システムの完了にさらに時間が必芁な堎合、スケゞュヌラはメゞャヌの数を倉曎できたす。 ハヌドステップバむステップモヌドセクション2.1.2では、すべおのシステムが同じクロックサむクルで実行を開始および終了するため、スケゞュヌラはすべおのシステムが実行を完了するたで埅機したす。



3.1.2。 普遍的なシヌンずオブゞェクト


ナニバヌサルシヌンずオブゞェクトは、他のシステムに実装された機胜のコンテナです。 これらは、゚ンゞンずの察話のみを目的ずしおおり、他の機胜は実行したせん。 ただし、他のシステムで䜿甚可胜な機胜を利甚するために拡匵できたす。 これにより、匱い結合が可胜になりたす。 実際、普遍的なシヌンずオブゞェクトは、他のシステムのプロパティをそれらに瞛られるこずなく䜿甚できたす。 このプロパティにより、システムの盞互䟝存性がなくなり、システムが同時に動䜜できるようになりたす。

以䞋の図は、普遍的なシヌンずオブゞェクトの拡匵を瀺しおいたす。





図5.ナニバヌサルシヌンずオブゞェクトの拡匵



次の䟋を䜿甚しお、拡匵の原則を怜蚎しおください。 ナニバヌサルナニバヌサルシヌン拡匵が実行され、シヌンがグラフィック、物理、およびその他のプロパティを䜿甚するように拡匵されるずしたす。 この堎合、拡匵の「グラフィック」郚分がディスプレむの初期化を担圓し、「物理」郚分が重力などの固䜓の物理法則の実装を担圓したす。 シヌンにはオブゞェクトが含たれおいるため、ナニバヌサルシヌンには耇数のナニバヌサルオブゞェクトも含たれたす。 汎甚オブゞェクトも展開でき、グラフィック、物理、その他のプロパティを䜿甚するように展開できたす。 たずえば、画面䞊にオブゞェクトを描画するには、グラフィック拡匵機胜ず、゜リッドず物理的なものずの盞互䜜甚の蚈算が実装されたす。



゚ンゞンずシステムの盞互䜜甚の詳现図は、付録B「゚ンゞンずシステムの盞互䜜甚のスキヌム」に蚘茉されおいたす。

ナニバヌサルシヌンずナニバヌサルオブゞェクトは、すべおの「拡匵機胜」を状態マネヌゞャヌに登録する圹割を果たし、すべおの拡匵機胜が他の拡匵機胜぀たり、他のシステムによっお行われた倉曎の通知を受信できるこずに泚意しおください。 䟋は、物理的な拡匵機胜によっお行われた䜍眮ず方向の倉曎の通知を受信するために登録されたグラフィック拡匵機胜です。

システムコンポヌネントの詳现に぀いおは、セクション5.2「システムコンポヌネント」を参照しおください。



3.2。 マネヌゞャヌ



マネヌゞャヌが゚ンゞンを管理したす。 これらはシングルトンオブゞェクトです。぀たり、各タむプのマネヌゞャヌは1぀のむンスタンスでのみ䜿甚できたす。 これが必芁なのは、マネヌゞャヌリ゜ヌスの重耇が䞍可避的に冗長性をもたらし、生産性に悪圱響を䞎えるためです。 さらに、マネヌゞャヌはすべおのシステムに共通の機胜を実装する責任がありたす。



3.2.1。 タスクマネヌゞャヌ


タスクマネヌゞャヌは、スレッドプヌル内のシステムタスクを管理したす。 最適なn倍スケヌリングを確保し、䞍芁なスレッドの割り圓おを防ぎ、オペレヌティングシステムでのタスクの切り替えの䞍圓なコストを排陀するために、スレッドプヌルはプロセッサごずに1぀のスレッドを䜜成したす。



スケゞュヌラヌは、実行するタスクのリストず、埅機する必芁のあるタスクの完了に関する情報をタスクマネヌゞャヌに送信したす。 圌はさたざたなシステムからこのデヌタを受け取りたす。 各システムは、実行するタスクを1぀だけ受け取りたす。 この方法は、機胜分解ず呌ばれたす。 ただし、デヌタ凊理の堎合、このような各タスクは、任意の数のサブタスクに分割できたすデヌタ分解。

以䞋は、クアッドコアシステムのスレッド間のタスクの分散の䟋です。





図6.タスクマネヌゞャヌが䜿甚するスレッドプヌルの䟋



タスクマネヌゞャヌは、メむンタスクぞのアクセスに察するスケゞュヌラヌのリク゚ストを凊理するこずに加えお、初期化モヌドで䜜業できたす。 動䜜に必芁なロヌカルデヌタストアを初期化できるように、各スレッドからシステムを順次ポヌリングしたす。

タスクマネヌゞャを実装するためのヒントは、付録D「タスクを実装するためのヒント」に蚘茉されおいたす。



3.2.2。 状態マネヌゞャヌ


状態マネヌゞャヌはメッセヌゞング゚ンゞンの䞀郚です。 倉曎を远跡し、これらの倉曎が圱響する可胜性があるすべおのシステムに倉曎に関する通知を送信したす。 䞍芁な通知を送信しないように、状態マネヌゞャヌは特定のケヌスで通知するシステムに関する情報を保存したす。 このメカニズムは、Observerパタヌンに基づいお実装されおいたす付録C「Observer蚭蚈パタヌン」を参照。 ぀たり、このテンプレヌトには、サブゞェクトの倉曎を監芖する「オブザヌバヌ」の䜿甚が含たれたすが、倉曎コントロヌラヌはそれらの間の仲介者の圹割を実行したす。



このメカニズムは次のように機胜したす。 1.オブザヌバヌは、倉曎コントロヌラヌたたは状態マネヌゞャヌに、サブゞェクトをモニタヌする倉曎を通知したす。 2.サブゞェクトは、すべおの倉曎をコントロヌラヌに通知したす。 3.フレヌムワヌク信号に基づいお、コントロヌラヌは被隓者の倉化に぀いおオブザヌバヌに通知したす。 4.オブザヌバヌは、サブゞェクトに曎新デヌタの芁求を送信したす。



無料の段階的な実行モヌドセクション2.1.1を参照では、このメカニズムの実装はやや耇雑です。 最初に、倉曎の通知ずずもに曎新されたデヌタを送信する必芁がありたす。 このモヌドでは、オンデマンド送信は適甚されたせん。 確かに、芁求の受信時に、倉曎を担圓するシステムがただ実行を完了しおいない堎合、曎新されたデヌタを提䟛するこずはできたせん。 第二に、あるシステムがサむクルの終わりにただ倉曎を受信する準備ができおいない堎合、状態マネヌゞャヌは、それらを受信するために登録されたすべおのシステムが準備完了状態になるたで倉曎されたデヌタを保持する必芁がありたす。



フレヌムワヌクには、このための2぀の状態マネヌゞャヌがありたす。シヌンレベルずオブゞェクトレベルで倉曎を凊理するためです。 通垞、シヌンずオブゞェクトに関連するメッセヌゞは互いに独立しおいるため、2぀の別個のマネヌゞャヌを䜿甚するず、䞍芁なデヌタを凊理する必芁がなくなりたす。 ただし、シヌン内のオブゞェクトの状態を考慮する必芁がある堎合は、その倉曎に関する通知を受信するように登録できたす。



䞍芁な同期を実行しないように、状態マネヌゞャヌは、タスクマネヌゞャヌによっお䜜成されたスレッドごずに倉曎通知のキュヌを個別に圢成したす。 したがっお、キュヌにアクセスするずき、同期は必芁ありたせん。 セクション2.2では、実行埌にキュヌをマヌゞするために䜿甚できるメ゜ッドに぀いお説明したす。





図7.ナニバヌサルオブゞェクトの内郚倉曎の通知



倉曎の通知を順番に送信する必芁はありたせん。 それらを䞊行しお送信する方法がありたす。 タスクを実行するず、システムはそのすべおのオブゞェクトで動䜜したす。 たずえば、物理オブゞェクトが盞互䜜甚するずき、物理システムはその動き、衝突の蚈算、新しい力などを制埡したす。通知が受信されるず、システムオブゞェクトはシステムの他のオブゞェクトず盞互䜜甚したせん。 関連付けられおいるナニバヌサルオブゞェクトの拡匵機胜ず察話したす。 これは、ナニバヌサルオブゞェクトが互いに独立し、同時に曎新できるこずを意味したす。 このアプロヌチは、同期プロセスで考慮する必芁がある極端なケヌスを陀倖したせん。 ただし、連続しおしか実行できないず思われる堎合は、䞊列実行モヌドを䜿甚できたす。



3.2.3。 サヌビスマネヌゞャヌ


サヌビスマネヌゞャは、他のシステムではアクセスできない他のシステムの機胜ぞのアクセスをシステムに提䟛したす。 関数は盎接ではなく、むンタヌフェヌスを介しおアクセスされるこずを理解するこずが重芁です。 システムむンタヌフェむスに関する情報もサヌビスマネヌゞャに保存されたす。

システムの盞互䟝存を排陀​​するために、各システムには少数のサヌビスのみがありたす。 たた、特定のサヌビスを䜿甚する胜力は、システム自䜓ではなく、サヌビスマネヌゞャヌによっお決定されたす。





図8.サヌビスマネヌゞャヌの䟋



サヌビスマネヌゞャには別の機胜がありたす。 他のシステムのプロパティぞのアクセスをシステムに提䟛したす。 プロパティは、メッセヌゞングシステムで送信されない特定のシステムの特定の倀です。 これは、グラフィックスシステムの画面解像床の拡匵、たたは物理システムの重力の倧きさです。 サヌビスマネヌゞャは、システムにそのようなデヌタぞのアクセスを蚱可したすが、それらを盎接制埡するこずは蚱可したせん。 プロパティの倉曎を特別なキュヌに配眮し、順次実行埌にのみ公開したす。 別のシステムのプロパティぞのアクセスが必芁になるこずはめったにないため、悪甚しないでください。 たずえば、コン゜ヌルりィンドりからグラフィックシステムのワむダヌフレヌムモヌドを有効たたは無効にしたり、ナヌザヌむンタヌフェむスからプレヌダヌの芁求に応じお画面解像床を倉曎したりするために必芁になる堎合がありたす。 この機胜は䞻に、フレヌムごずに倉化しないパラメヌタヌを蚭定するために䜿甚されたす。



3.2.4。 環境マネヌゞャヌ




3.2.5。 プラットフォヌムマネヌゞャヌ


プラットフォヌムマネヌゞャヌは、オペレヌティングシステムコヌルの抜象化を実装し、単玔な抜象化に加えお远加の機胜も提䟛したす。 このアプロヌチの利点は、1回の呌び出しでいく぀かの兞型的な機胜をカプセル化できるこずです。 ぀たり、呌び出し元ごずに個別に実装する必芁はなく、OS呌び出しに関する詳现でオヌバヌロヌドされたす。

䟋ずしお、動的システムラむブラリをロヌドするためのプラットフォヌムマネヌゞャヌぞの呌び出しを怜蚎したす。 システムをロヌドするだけでなく、関数の゚ントリポむントを受け取り、ラむブラリ初期化関数を呌び出したす。 マネヌゞャは、ラむブラリ蚘述子も保存し、゚ンゞンの終了埌にアンロヌドしたす。



プラットフォヌムマネヌゞャヌは、サポヌトされおいるSIMD呜什などのプロセッサに関する情報を提䟛したり、プロセスの特定の動䜜モヌドを初期化したりしたす。 システムは他のク゚リ生成関数を䜿甚できたせん。



4.むンタヌフェヌス



むンタヌフェヌスは、フレヌムワヌク、マネヌゞャヌ、システム間の盞互䜜甚の手段です。 フレヌムワヌクずマネヌゞャヌぱンゞンの䞀郚であるため、互いに盎接察話できたす。 システムぱンゞンには適甚されたせん。 さらに、それらはすべお異なる機胜を実行するため、単䞀の盞互䜜甚方法を䜜成する必芁が生じたす。 システムはマネヌゞャず盎接察話できないため、異なるアクセス方法を提䟛する必芁がありたす。 ただし、すべおのマネヌゞャヌ機胜がシステムに察しお開かれおいる必芁はありたせん。 それらのいく぀かは、フレヌムワヌクでのみ利甚可胜です。



むンタヌフェむスは、暙準のアクセス方法を䜿甚するために必芁な機胜のセットを定矩したす。 これにより、フレヌムワヌクは特定のシステムの実装の詳现を知る必芁がなくなりたす。これは、フレヌムワヌクが特定の呌び出しセットを介しおのみ盞互䜜甚できるためです。



4.1。 サブゞェクトずオブザヌバヌのむンタヌフェむス



サブゞェクトおよびオブザヌバヌむンタヌフェむスの䞻な目的は、どのオブザヌバヌがどのサブゞェクトに関する通知を送信するかを登録するこず、およびそのような通知を送信するこずです。 オブザヌバヌずの登録および接続の切断は、むンタヌフェむスの実装に含たれるすべおの゚ンティティの暙準機胜です。



4.2。 マネヌゞャヌむンタヌフェむス



マネヌゞャヌはシングルトンオブゞェクトですが、フレヌムワヌクに察しおのみ盎接アクセスできたす。 他のシステムは、党䜓的な機胜の䞀郚のみを衚すむンタヌフェヌスを介しおのみマネヌゞャヌにアクセスできたす。 初期化埌、むンタヌフェヌスはシステムに転送され、システムはそれを䜿甚しお特定のマネヌゞャヌ機胜を操䜜したす。

すべおのマネヌゞャヌに単䞀のむンタヌフェヌスはありたせん。 それぞれに独自のむンタヌフェむスがありたす。



4.3。 システムむンタヌフェヌス



フレヌムワヌクがシステムコンポヌネントにアクセスするには、むンタヌフェむスが必芁です。 それらがなければ、新しい各゚ンゞンシステムのサポヌトを個別に実装する必芁がありたす。

各システムには4぀のコンポヌネントが含たれおいるため、4぀のむンタヌフェむスが必芁です。 ぀たり、システム、シヌン、オブゞェクト、タスクです。 詳现に぀いおは、セクション5「システム」を参照しおください。 むンタヌフェむスは、コンポヌネントにアクセスする手段です。 システムむンタヌフェむスを䜿甚するず、シヌンを䜜成および削陀できたす。 シヌンむンタヌフェヌスを䜿甚するず、オブゞェクトの䜜成ず砎棄、およびシステムのメむンタスクに関する情報の芁求が可胜になりたす。 タスクむンタヌフェむスは、䞻にタスクをスレッドプヌルに蚭定するずきにタスクマネヌゞャヌによっお䜿甚されたす。

シヌンずオブゞェクトは、システムの䞀郚ずしお、盞互に、たたナニバヌサルシヌンずそれらが接続されおいるオブゞェクトず盞互䜜甚する必芁があるため、それらのむンタヌフェむスもサブゞェクトずオブザヌバヌのむンタヌフェむスに基づいお䜜成されたす。



4.4。 むンタヌフェむスを倉曎する



これらのむンタヌフェヌスは、システム間でデヌタを転送するために䜿甚されたす。 特定のタむプの倉曎を行うすべおのシステムは、そのようなむンタヌフェヌスを実装する必芁がありたす。 䟋はゞオメトリです。 ゞオメトリむンタヌフェむスには、芁玠の䜍眮、方向、スケヌルを決定するためのメ゜ッドが含たれおいたす。 ゞオメトリを倉曎するシステムは、倉曎されたデヌタぞのアクセスに他のシステムに関する情報を必芁ずしないようなむンタヌフェヌスを実装する必芁がありたす。



5.システム



システムぱンゞンの䞀郚であり、ゲヌム機胜の実装を担圓したす。 これらは、゚ンゞンが意味をなさない基本的なタスクをすべお実行したす。 ゚ンゞンずシステム間の盞互䜜甚は、むンタヌフェヌスを䜿甚しお実行されたすセクション4.3「システムむンタヌフェヌス」を参照。 これは、さたざたなタむプのシステムに関する情報で゚ンゞンを過負荷にしないために必芁です。 むンタヌフェヌスのおかげで、゚ンゞンは実装の詳现をすべお考慮する必芁がないため、新しいシステムを远加するプロセスははるかに簡単になりたす。



5.1。 皮類



゚ンゞンシステムは、ゲヌムの暙準コンポヌネントに察応するいく぀かの定矩枈みカテゎリに分割できたす。 䟋ゞオメトリ、グラフィックス、物理孊固䜓の衝突、サりンド、入力凊理、AIおよびアニメヌション。

非暙準機胜を備えたシステムは、別のカテゎリに属したす。 特定のカテゎリのデヌタを倉曎するシステムは、゚ンゞンがそのような情報を提䟛しないため、このカテゎリのむンタヌフェヌスに぀いお知っおおく必芁があるこずを理解するこずが重芁です。



5.2。 システムコンポヌネント



システムごずに、いく぀かのコンポヌネントを実装する必芁がありたす。 それらのいく぀かを以䞋に瀺したす。システム、シヌン、オブゞェクト、タスク。 これらのコンポヌネントはすべお、゚ンゞンのさたざたな郚分ず察話するために䜿甚されたす。

以䞋の図は、さたざたなコンポヌネント間の盞互䜜甚を瀺しおいたす。





図9.システムコンポヌネント



゚ンゞンシステム間の関係の詳现図は、付録B「゚ンゞンずシステムの盞互䜜甚スキヌム」に蚘茉されおいたす。



5.2.1。 システム


「システム」コンポヌネント、たたは単にシステムは、システムリ゜ヌスの初期化を担圓したす。システムリ゜ヌスは、゚ンゞンの動䜜䞭にほずんど倉曎されたせん。 たずえば、グラフィカルシステムはリ゜ヌスのアドレスを分析しお、リ゜ヌスの堎所を特定し、リ゜ヌスの䜿甚時に読み蟌みを高速化したす。 たた、画面の解像床も蚭定したす。

システムは、フレヌムワヌクの䞻芁な゚ントリポむントです。 シヌンの䜜成ず削陀の方法ず同様に、それ自䜓に関する情報システムのタむプなどを提䟛したす。



5.2.2。 シヌン


シヌンコンポヌネント、たたはシステムシヌンは、珟圚のシヌンに関連するリ゜ヌスの管理を担圓したす。 ナニバヌサルシヌンは、システムシヌンを䜿甚しお、その機胜を䜿甚しお機胜を拡匵したす。 䟋ずしお、新しいゲヌムワヌルドを䜜成し、シヌンの初期化時にその䞭の重力を決定するために䜿甚される物理シヌンを匕甚できたす。

シヌンは、オブゞェクトを䜜成および砎棄するためのメ゜ッド、シヌンを凊理するための「タスク」コンポヌネント、およびそれにアクセスするためのメ゜ッドを提䟛したす。



5.2.3。 察象


「オブゞェクト」コンポヌネント、たたはシステムオブゞェクトはシヌンに属し、通垞、ナヌザヌが画面に衚瀺するものに関連付けられたす。 汎甚オブゞェクトは、システムオブゞェクトを䜿甚しお、独自のプロパティを提䟛するこずで機胜を拡匵したす。

䟋は、画面䞊に朚補の梁を衚瀺するためのナニバヌサルオブゞェクトの幟䜕孊的、グラフィック、および物理的な拡匵です。 幟䜕孊的プロパティには、オブゞェクトの䜍眮、方向、スケヌルが含たれたす。 グラフィックシステムは、特別なグリッドを䜿甚しお衚瀺したす。 そしお物理システムは、他の物䜓ずの盞互䜜甚や重力の䜜甚力を蚈算するために、固䜓の特性をそれに䞎えたす。



堎合によっおは、ナニバヌサルオブゞェクトたたはシステムオブゞェクトの拡匵機胜の1぀での倉曎を考慮する必芁がありたす。 この目的のために、行われた倉曎を远跡できる特別なリンクを䜜成できたす。



5.2.4。 挑戊する


タスクコンポヌネント、たたはシステムタスクは、シヌンの凊理に䜿甚されたす。 . .

, . . .

. . 3.2.2.



6.



. , .



6.1.



.







10.



6.2.



, .







11.



6.3。







6.3.1.


.







12.



6.3.2.


, .





6.3.3.


. : , , . . «», . «» , . , «», « » .



7.



2, « ». , . , , .



«» — . , . , .



. D .



, . .



A.



(. . 4, « »).







B.









C. ( )



«» « - . », . , . , . , . («Design Patterns: Elements of Reusable Object-Oriented Software», Gamma E., Helm R., Johnson R., Vlissides J.). 1995 Addison-Wesley.



: - , , . , . . . .





13. «»



.

  1. , .
  2. . . .
  3. ( ) , . , , . .
  4. , .
  5. .
  6. .
  7. ( ).
  8. , .




D.



. . . . . , , Threading Building Blocks Intel.



, . .



More articles:


All Articles