Przyznaję, że popełniłem grzech nadużywania, a nawet nadużywania dziedzictwa. Pierwszy (tekstowy) projekt gry, który stworzyłem, gdy brałem kurs OOP, obejmował „Zamknięte drzwi” i „odblokowane drzwi” z „Drzwi” i „Pokój z jednymi drzwiami”, „Pokój z dwojgiem drzwi” oraz z „pokoju”.
W grze (graficznej), nad którą ostatnio pracowałem, pomyślałem, że nauczyłem się mojej lekcji i ograniczyłem korzystanie z dziedziczenia. Zauważyłem jednak, że problemy wkrótce zaczynają się pojawiać. Moja klasa root zaczęła coraz bardziej wzdychać, a moje klasy liści były pełne zduplikowanych kodów.
Myślałem, że nadal robię coś źle i po sprawdzeniu tego w Internecie odkryłem, że nie tylko ja miałem ten problem. W ten sposób odkryłem systemy Entity po dokładnych badaniach (czytaj: googlefu)
Kiedy zacząłem czytać o tym, mogłem zobaczyć, jak wyraźnie było w stanie rozwiązać problemy, które miałem z tradycyjną hierarchią OOP z komponentami. Były to jednak pierwsze czytania. Kiedy natknąłem się więcej ... „radykalne” ES podejść, takich jak ten, w T-maszyna .
Zacząłem nie zgadzać się z metodami, których używali. System czysto komponentowy wydawał się albo przesadny, albo raczej nieintuicyjny, co prawdopodobnie jest siłą OOP. Autor posunął się nawet do stwierdzenia, że system ES jest przeciwieństwem OOP i chociaż może on być użyteczny podczas OOP, tak naprawdę nie powinien. Nie twierdzę, że to źle, ale po prostu nie czułem się rozwiązaniem, które chciałbym wdrożyć.
Więc dla mnie i rozwiązanie problemów, które miałem na początku postu, bez naruszania moich intuicji, to nadal używać hierarchii, jednak nie będzie to monolityczna hierarchia, jak te, które stosowałem wcześniej, ale raczej polilityczny (nie mogłem znaleźć słowa przeciwnego do monolitycznego), który składa się z kilku mniejszych drzew.
Poniższy przykład pokazuje, co mam na myśli (zainspirowany przykładem, który znalazłem w Game Engine Architecture, rozdział 14).
Chciałbym mieć małe drzewo na pojazdy. Główna klasa pojazdu miałaby komponent renderujący, komponent kolizji, komponent pozycji itp.
Następnie czołg, podklasa pojazdu, odziedziczyłaby po nim te komponenty i otrzymałaby własny komponent „armaty”.
To samo dotyczy postaci. Postać miałaby własne komponenty, a następnie Klasa Gracza odziedziczyłaby ją i otrzymałaby kontroler Wejścia, podczas gdy inne klasy wroga odziedziczyłyby po klasie Postaci i otrzymałyby kontroler AI.
Tak naprawdę nie widzę żadnych problemów z tym projektem. Pomimo braku używania czystego systemu kontrolera encji, problem z efektem bulgotania, a duża klasa root jest rozwiązana za pomocą hierarchii wielu drzew, a problem ciężkich, powielających kod listków zniknął, ponieważ liście nie mieć na początku dowolny kod, tylko komponenty. Jeśli trzeba dokonać zmiany na poziomie liścia, jest to tak proste, jak zmiana pojedynczego komponentu, zamiast kopiowania wklejania kodu wszędzie.
Oczywiście będąc tak niedoświadczonym jak ja, nie widziałem żadnych problemów, kiedy po raz pierwszy zacząłem używać modelu z pojedynczą hierarchią i dziedziczenia, więc jeśli pojawią się problemy z modelem, który obecnie zamierzam wdrożyć, nie być w stanie to zobaczyć.
Twoje opinie?
PS: Korzystam z Javy, więc używanie wielokrotnego dziedziczenia do implementacji tego zamiast używania normalnych komponentów nie jest możliwe.
PPS: Komunikacja między komponentami będzie realizowana poprzez łączenie wzajemnie zależnych komponentów. Doprowadzi to do sprzężenia, ale myślę, że jest to dobra kompromis.