Component Based Game Development

[Mischa_NL]

Na veel werken aan mijn huidige engine loop ik een beetje vast op de onduidelijke structurering, en verschrikkelijk veel koppelingen tussen classes enzovoort enzovoort.

Daarom ben ik eens gaan kijken naar andere methodes met betrekking tot game design.
Ik vind het component based ontwerpen een interessante aanpak maar loop een beetje vast op de implementatie.

Allereerst een uitleg over componenten:

Alle objecten in je engine zijn zogenaamde entities. Entity is een class maar bevat eigenlijk barweinig functies.
Het enige dat deze class eigenlijk verzorgt is het bijhouden welke componenten aan de entity gekoppeld zijn.

De componenten zijn classes zoals bijvoorbeeld: spatial, rendering, physics enzovoort. Deze bevatten de parameters en wat basale functies om het component te beheren.

Dit is eigenlijk het basic design.
Nu zijn er twee opties: Componenten verzorgen de logic, of subsystemen verzorgen de logic. Rendert een render component zichzelf? of registreert een rendering component/entity zich bij een subsysteem?

Zo kun je dus een subsysteem zoals rendering hebben. Deze rendert en sorteert bijvoorbeeld de componenten en stampt ze naar de daadwerkelijke renderer.
Nu is hier de eerste lastigheid: Hoe stop ik componenten in een subsysteem? Stop ik er uberhaubt wel componenten in? Waarom geen entities? Mag een subsysteem afweten van het bestaan van componenten en/of entities?

Het lijkt mij zelf zeer onhandig om deze logic in een component te stoppen. Deze worden hierdoor zeer complex en groot. Mij lijkt het veel handiger een component meer een container van data/simpele functies te zijn, die gevoerd wordt aan een subsystem. Is dit handig, of eigenlijk compleet onlogisch?

Daarnaast communicatie tussen componenten. Componenten zoals rendering hebben info nodig van spatial om te kunnen renderen. Hoe deze communicatie verzorgen? Een pointer? Een message system?
Een pointer staat mij zeer tegen omdat deze dan weer gekoppeld zijn zoals bij een niet-component systeem. Messaging dan, maar hoe?

Met subsystemen zou dit probleem verholpen kunnen worden. Subsystemen hebben componenten geregistreerd en deze benaderen de componenten, en niet de componenten onderling! Op deze manier is communicatie tussen de componenten (bijna) compleet overbodig geworden. Ze hoeven slechts nog op de hoogte gesteld te worden van events.
Bv: health component broadcast -> health = 0. Rendering component pakt dit op en zet doodgaan-animatie in gang.


Zelf denk ik sterk aan het volgende:
- Entity
slechts container van components

- Component
container van parameters met wat basis functies.

- Subsystems
Hier gaan ENTITIES in en deze worden gemanaged door het subsysteem.


+ Entity Sphere
- Position Component
- Bounding Component
- Rendering Component
- Physcis Component

+ Subsystem Rendering
- List met entities die een rendering component bevatten.
- bevat logic om te sorteren, en te renderen.


Toch kan ik nergens een dergelijk systeem terugvinden op internet. Daarom lijkt het alsof dit verre van ideaal is. Ik kan echter geen reden bedenken waarom dit zo zou zijn.

Heeft iemand ervaring met component based game design? Wie kan me een schopje de goede richting ingeven?!

[MLM]

Subsystemen, omdat die dan ook vervangbaar zijn.

Je kan bijvoorbeeld je rendering subsysteem switchen tussen DirectX (voor windows), OpenGL (voor Linux) etc, terwijl je component dan niet hoeft te veranderen (het is immers nog steeds een sphere met een rood materiaal etc.).

Hoef je minder te veranderen als je gaat porten Daarnaast, je kan ook splitsen tussen je subsystemem (alle logica) en de componenten (alle data). Beter onderhoudbaar

Maar goed, het KAN op beide manieren.

[kaesve]

In deze paper draaien er subsystemen rondom een centraal entitysysteem, welke opgedeelt worden in systemen die de entities manipuleren en systemen die alleen maar hoeven uit te lezen. Hoewel het idee van een centraal/globaal systeem misschien tegenintuitief is, vind ik het een goed alternatief naast de twee genoemde opties. Op deze manier hoeft een entity of component in ieder geval niet gekoppelt te worden aan een subsysteem.
Maar goed, ga vooral niet op mijn woord af Ik ben maar een onervaren student, die toevallig ook net (voor mijzelf) bezig is met deze stof.. Hoop dan ook dat er meer mensen hier ervaringen en ideeen willen delen

[Mischa_NL]

kaesve schreef op woensdag 23 februari 2011 @ 23:51:
In deze paper draaien er subsystemen rondom een centraal entitysysteem, welke opgedeelt worden in systemen die de entities manipuleren en systemen die alleen maar hoeven uit te lezen. Hoewel het idee van een centraal/globaal systeem misschien tegenintuitief is, vind ik het een goed alternatief naast de twee genoemde opties. Op deze manier hoeft een entity of component in ieder geval niet gekoppelt te worden aan een subsysteem.
Maar goed, ga vooral niet op mijn woord af Ik ben maar een onervaren student, die toevallig ook net (voor mijzelf) bezig is met deze stof.. Hoop dan ook dat er meer mensen hier ervaringen en ideeen willen delen

Ik heb ook zitten denken aan een EXTRA systeem wat de communicatie verzorgt tussen componenten en subsystemen. Noem het een interface.
Deze beheert de componenten die nodig zijn voor een subsysteem en kan gemanipuleert worden door het subsysteem. De componenten weten dan alleen af van de interface en de subsystemen ook.
Echter brengt dit redelijk wat extra complexiteit met zich mee. Toch klinkt het in theorie erg logisch:

Component <--> Subsysteem

tegenover:
Component ---> Interface <---- Subsysteem

De complexiteit lijkt mij van de ene kant echter totaal overbodig. Van de andere kant zorgt het wel voor een stuk duidelijkere engine structuur.