Zaczynam więc wprowadzać atak na naszą przestrzeń 2D RTS (jest to Unity, więc jest sterowane komponentowo). Początkowo było tak proste, jak „wróg w zasięgu, zadane obrażenia”. Będzie jednak wiele „rodzajów” broni / ataków związanych z ich konkretnym statkiem lub strukturą. Jak również inne czynniki związane z przeszłymi obrażeniami, takie jak rodzaj obrażeń i ewentualnie bezwładność w przyszłości.
Czy mielibyście każdy typ jednostki i struktury, który ma swój własny typ ataku? Oznacza to, że tworzysz skrypt dla każdej jednostki / struktury, która określa jego typ ataku, obrażenia, efekty, zasięg, cząstki, duszki ... itd. I dołączasz jako element?
Lub stwórz skrypt, który definiuje typ ataku, skrypt dla typu pocisku powiązanego z tym ... itd. A następnie rozszerz je i zmodyfikuj dla każdej jednostki, dołączając każdy skrypt do jednostki / struktury.
Mam nadzieję, że mam jakiś sens, tak długo się nad tym zastanawiam. Nie jestem pewien, czy rozwiązuję problem, czy po prostu wymyślam własne problemy i wkopuję się w dziurę.
Jeśli masz grę, która może mieć wiele rodzajów ataków, które mogą, ale nie muszą ograniczać się do konkretnej jednostki / struktury, w jaki sposób projektujesz strukturę, która łączy ją z konkretnymi jednostkami / strukturami w środowisku projektowania opartym na komponentach ?
Jeśli nie jest to wystarczająco jasne, daj mi znać.
Edycja: Świetne odpowiedzi, dziękuję.
Rozszerzone pytanie:
Wydaje się, że odpowiedzi różnią się od „każdy obiekt może mieć własny skrypt atakujący” do „Mają typy ataków jako własne skrypty i przypisują je do każdego obiektu, aby uzyskać rozwiązanie wielokrotnego użytku”. Powiedzmy, że mam atak „blasterowy”, strzela on z pewnym czerwonym pociskiem z określoną prędkością. Obrażenia, szybkostrzelność i rozmiar pocisku zależą od tego, czy jednostka go wystrzeli. Czy lepiej jest po prostu wykonać skrypt ataku dla tej jednostki, czy spróbować zmodyfikować „atak blasterowy”, tak aby pasował do celu każdej jednostki, która chce z niej skorzystać?
źródło
Odpowiedzi:
Cóż, szczerze mówiąc, nie jestem ekspertem w tej dziedzinie, ale ... Myślę, że to zależy od tego, jak skomplikowane i różnorodne są ataki. Ponieważ jest to RTS, zgaduję, że będziesz mieć około 10-50 różnych jednostek lub struktur z własnymi typami ataku.
Opcja 1: Jeśli istnieje stosunkowo niewielka liczba jednostek, które będą miały nieco podobne ataki, po prostu umieściłbym wszystko w jednym dużym skrypcie i zdefiniował parametry używane w inspektorze.
Opcja 2: Jeśli z drugiej strony wyobrażasz sobie dużą liczbę typów ataków o odmiennym zachowaniu, możesz wszystko rozbić, aby każda jednostka i budynek otrzymały własny unikalny skrypt ataku. Myślę, że jeśli to zrobisz, możesz utworzyć skrypt pomocnika, który definiuje często używane fragmenty kodu, z których wiele indywidualnych skryptów może pobrać. W ten sposób nie będziesz musiał przepisywać wszystkiego i będziesz wiedział, gdzie to wszystko jest.
Opcja 3: To, czego prawdopodobnie nie powinieneś robić, to mieć pewne grupy skryptów współużytkujących jednostki, to prawdopodobnie wprowadzi cię w błąd i stanie się bałaganem, jeśli kod potrzebny do ataku jest w 10 różnych skryptach.
Tutaj narysowałem ci zdjęcie.
źródło
"Here, I drew you a picture."
przypomniał mi o tymNie wiem dużo o Unity i od jakiegoś czasu nie tworzyłem gier, więc dam ci ogólną odpowiedź programową na to pytanie. Swoją odpowiedź oparłem na wiedzy, którą posiadam na temat systemów encja-komponent, gdzie encja jest liczbą powiązaną z N wieloma komponentami, komponent zawiera tylko dane, a system działa na zestawach komponentów powiązanych z ten sam byt.
Twoja przestrzeń problemowa jest następująca:
Skonstruowałbym rozwiązanie w następujący sposób:
Ważne jest, aby punkt kontaktu między atakami a bytami był jak najcieńszy - dzięki temu Twój kod będzie nadawał się do ponownego użycia i nie będziesz musiał wymyślać zduplikowanego kodu dla każdego innego rodzaju jednostki, która używa tego samego rodzaju ataku . Innymi słowy, oto pseudo-kod JavaScript, który da ci pomysł.
Niestety ta odpowiedź jest nieco „wodnista”. Mam tylko pół godziny przerwy na lunch i ciężko jest coś wymyślić, nie wiedząc w pełni o Unity :(
źródło
Kiedy jednostka / struktura / broń atakuje, prawdopodobnie stworzyłbym Atak (podzielony na wszystkie twoje zabawne szczegóły), który zabierze atakującego i obrońcę (lub obrońców). Atak może następnie wchodzić w interakcje z celem / obrońcą (spowolnienie, trucizna, obrażenia, zmiana stanu), sam się narysować (promień, promień, kula) i pozbyć się po zakończeniu. Mogę przewidzieć pewne problemy, takie jak wielokrotne ataki trucizną, więc być może twoje cele zaimplementują interfejs do uszkodzenia, z którym atak wchodzi w interakcję, ale myślę, że jest to praktyczne, modularne i elastyczne podejście do zmiany.
Rozszerzony Answer
To jak będę zbliżać się do ataku blaster z tym podejściem . Pozwolę innym odpowiedzieć za siebie.
Chciałbym, aby moje jednostki zaimplementowały interfejs lub klasę IAttacker z podstawowymi statystykami / metodami ataku. Kiedy IAttacker atakuje IDamageable, tworzy swój konkretny Atak, przekazując siebie i swój cel (IAttacker i IDamageable, lub może kolekcję IDamageable). Atak pobiera potrzebne statystyki od IAttackera (aby uniknąć zmian podczas aktualizacji lub czegoś podobnego - nie chcemy, aby atak zmieniał statystyki po tym, jak już został uruchomiony), a jeśli potrzebuje specjalistycznych statystyk, rzuca IAttacker na jego potrzebny typ (np. IBlasterAttacker) i w ten sposób uzyskuje specjalistyczne statystyki.
Stosując to podejście, BlasterAttacker musi tylko utworzyć BlasterAttack, a BlasterAttack zajmie się resztą. Możesz podklasować BlasterAttack lub utworzyć osobny FastBlasterAttacker, MegaBlasterAttacker, SniperBlasterAttacker itp., A kod ataku dla każdego z nich jest taki sam (i być może odziedziczony po BlasterAttack): Utwórz BlasterAttack i przekaż mnie i mój cel (-y). BlasterAttack obsługuje szczegóły .
źródło