Czy tarcza powinna być własną jednostką, która śledzi lokalizację gracza? Może to utrudnić wdrożenie filtrowania uszkodzeń. Trochę też zaciera linie między dołączonymi komponentami i bytami.
Edycja: Myślę, że nie ma wystarczającej liczby „autonomicznych zachowań” dla wydzielonej istoty. W tym konkretnym przypadku tarcza podąża za celem, działa dla celu i nie przeżywa celu. Chociaż zwykle zgadzam się, że nie ma nic złego w koncepcji „obiektu tarczy”, w tym przypadku mamy do czynienia z zachowaniem, które dobrze pasuje do komponentu. Ale jestem także zwolennikiem czysto logicznych bytów (w przeciwieństwie do pełnowymiarowych systemów bytów, w których można znaleźć komponenty Transformacji i Renderingu).
Czy tarcza powinna być komponentem, który mieści inne komponenty? Nigdy czegoś takiego nie widziałem ani nie słyszałem, ale może jest to powszechne i po prostu nie jestem jeszcze wystarczająco głęboki.
Zobacz to z innej perspektywy; dodanie komponentu dodaje również inne komponenty, a po usunięciu również dodatkowe komponenty znikają.
Czy tarcza powinna być tylko zestawem elementów dodawanych do odtwarzacza? Prawdopodobnie z dodatkowym komponentem do zarządzania innymi, np. Aby można je wszystkie usunąć jako grupę. (niechcący zostawić komponent redukcji obrażeń, teraz byłoby fajnie).
Może to być rozwiązanie, promuje ponowne użycie, jednak jest również bardziej podatne na błędy (na przykład w przypadku wspomnianego problemu). To niekoniecznie jest złe. Możesz znaleźć nowe kombinacje zaklęć z próbą i błędem :)
Coś innego, co jest oczywiste dla kogoś z większym doświadczeniem w komponentach?
Zamierzam trochę rozwinąć.
Uważam, że zauważyłeś, że niektóre komponenty powinny mieć pierwszeństwo bez względu na to, kiedy zostały dodane do bytu (to również odpowiada na inne pytanie).
Zakładam również, że używamy komunikacji opartej na wiadomościach (dla celów dyskusji jest to w tej chwili tylko abstrakcja wywołania metody).
Za każdym razem, gdy komponent ekranowy jest „instalowany”, programy obsługi komunikatów komponentu ekranowego są łączone w określonej (wyższej) kolejności.
Handler Stage Handler Level Handler Priority
In Pre System High
Out Invariant High
Post AboveNormal
Normal
BelowNormal
Low
System Low
In - incoming messages
Out - outgoing messages
Index = ((int)Level | (int)Priority)
Komponent „stats” instaluje moduł obsługi komunikatów „uszkodzenia” w indeksie In / Invariant / Normal. Za każdym razem, gdy odbierany jest komunikat „obrażenia”, zmniejsz HP o jego „wartość”.
Dość standardowe zachowanie (wprowadzające pewną naturalną odporność na obrażenia i / lub cechy rasowe, cokolwiek).
Komponent tarczy instaluje moduł obsługi komunikatów „uszkodzenia” o indeksie In / Pre / High.
Every time a "damage" message is received, deplete the shield energy and substract
the shield energy from the damage value, so that the damage down the message
handler pipeline is reduced.
damage -> stats
stats
stats.hp -= damage.value
damage -> shield -> stats
shield
if(shield.energy) {
remove_me();
return;
}
damage.value -= shield.energyquantum
shield.energy -= shield.energyquantum;
stats
stats.hp -= damage.value
Widać, że jest to dość elastyczne, choć wymagałoby to starannego planowania podczas projektowania interakcji komponentów, ponieważ trzeba będzie określić, w której części obsługi zdarzeń komunikatów komponentu potoku obsługi komunikatów są zainstalowane.
Ma sens? Daj mi znać, czy mogę dodać więcej szczegółów.
Edycja: dotyczy instancji wielu komponentów (dwóch komponentów pancerza). Możesz albo śledzić całkowitą liczbę wystąpień tylko w jednym wystąpieniu encji (to jednak zabija stan poszczególnych składników) i po prostu dodawać procedury obsługi zdarzeń wiadomości lub upewnić się, że kontenery komponentów pozwalają na zduplikowanie typów komponentów z góry.