Dziedziczenie i hierarchia

[Kartofelek]

Robię sobie gierkę o tytule The Bunkier ^^

1)

Wszystko idzie calkiem sprawnie, jednak natrafilem na pewien problem jak w tytule.

Przypuscmy ze mam obiekty parent:

obiekt_parent_solid

obiekt_parent_niesolid

obiekt_parent_cos

 

i mam inny obiekt, ktory powinien posiadac cechy np 2 powyzszych parentow. Ale nie potrafie sprawic by dziedziczenie bylo z dwóch obiektow. Czy wyjsciem jest tylko tworzenie dodatkowych parentow laczacych obie "klasy"?

 

2)

Jak dziedziczyc zmienne?

Przypuscmy ze mam obiekt parent ktory ma w [create]

 

zmienna = 'wartosc';

 

gdy ustawie taki obiekt jako parent innego obiektu, to ten inny obiekt nie dziedziczy tej zmiennej, czyli jezeli w [step] tego malego obiektu bede chcial

zmienic wartosc tej zmiennej to pisze mi ze nie ma takiej zmiennej.

 

HEH Wlasnie przeczytalem ze po prostu nadpisywalem zdarzenie CREATE i zmienne sie "psuly" trzeba uzyc jakiegos zdarzenia [Call Inherited Event].

[Marek.S]

ten obiekt, któremu ustawiasz parenta (rodzica) "dziedziczy" tylko te eventy, których sam nie używa.

 

a parenta zmieniasz poprzez:

GML

object_set_parent( ind , obj )

[Uzjel]

dziedziczenie zmiennych - event_inherited()

[Pental Stary]

Uch, dzięki za temat, wiecznie miałem ten problem i rodzice tracili sens :) .

[Kartofelek]

Pomyslalem ze najwyzej bede robil jakies "wrapery". Wczoraj pobawilem sie i robilem ogolnie tak:

class_opis_obiektow

parent_znaczniki

 

np obiekt parent_znaczniki byl dzieckiem obiektu [class_opis_obiektow]. Wywolywal on w create eventa ze swojego rodzica. Potem od razu ustawial odpowiednie zmienne tak by byc albo "solidnym" albo mozna bylo w niego strzelac itp. Potem np dzieci obiektu znaczniki indywidualnie tez dla siebie ustawialy sobie te zmienne-wlasciwosci. Dzieki temu mam zalationa sprawe z tworzeniem funkcjonalnosci dla wszystkich obiektow. Problem jednak zaczyna sie gdzie indziej...

 

Chodzi mi o to, ze korzystajac z pewnego przykladu zastosowalem dla przeciwnika ruch tworzony na podstawie grid (mp_...costam...). Tworze niepasujace komorki w tej siatce usuwajac miejsca gdzie sa obiekty ktore posiadaja klase opisowa (dziedzicza ja odpowiednio sobie ustawiajac). Niestety obiekt enemy i obiekt gracza tez posiada ta klase - w koncu sa "fizycznymi" obiektami ktore powinny byc opisane ^^. Droga wiec nie moze byc znaleziona :(. Nawet jak dam graczowi i enemy klase podrzedna (typu ludziki) ktora dziedziczy ta glowna (ustawiajac odpowiednie zmienne), to nie za bardzo dziala. Jezeli nie obejde tego problemu, to najwyzej zrezygnuje z tworzenia drogi za pomoca grida i napisze wlasny system (chociaz choroba nie mam na to zupelnie pomyslu) ^^

 

Rozwiazania ktore przychodza mi do glowy:

- napisanie wlasnego systemu znajdowania drogi (ale wolalbym by dzialal nie tylko na kontach 90 st. jak w pewnym przykladzie)

- robienie petli po wszystkich obiektach z klasa class_opis_obiektow (czyli wlasciwie wszystkich obiektach w grze ktore cos znacza ^^) i w zaleznosci od ustawionych zmiennych ustawianie branie ich pod uwage. - to bylo by latwe, ale czy wydajne? W sumie program i tak robi pewnie petle po wszystkich instancjach w grze, wiec czemu mialby dodatkowo nie zrobic jakiegos powornania ^^ (az tak na wydajnosci mi nie zalezy). Tylko czy to bedzie wygodne do pozniejszego stosowania...

- rozprawienie sie z podklasami tak by podklasy niby dziedziczyly a jednak grid widzial je jako "inne" (najbardziej chyba logiczne). Myslalem sobie by dane klasy mimo dziedziczenia byly jakby "odzielne". Np dziecko dziedziczy wlasciwosci class_opis_obiektow, ale juz gdybym mogl pobrac tylko obiekty spelniajace warunek (klasa obiektu == dziecko && klasa obietu != class_opis_obiektow) to bylo by dobrze ^^. Narazie tego nie próbowałem...

 

Na tworzeniu gier wlasciwie sie nie znam. To jest moja pierwsza przygoda. Moze ktos z was ma jakies lepsze pomysly na rozwiazanie tych problemow?

Ps. Zna moze ktos jakis fajny algorytm znajdowania drogi? ^^ Pierwsze co wymyslila moja muzgownica, to MOZE by wygladalo tak, ze jednak zastosowal bym algorytm znajdowania drogi z 90 stopniami, ale cala droge dzielilbym na kawalki i je bym tez "wynajdowal" ^^

 

 

EDIT:

 

Witam ponownie. Zrbilem jak wczesniej zakladalem. Czyli stworzylem glowna klase opisujaca obiekty. Obiekty ktore sa dziecmi tej klasy ustawiaja sobie odpowiednie zmienne typu "solidny", "ciezki" itp, i wtedy odpowiednio ustawia sie im akcje (robi to glowny obiekt-klasa).

 

Jednak natrafilem na kolejny blad. Konstrukcja wyglada teraz tak:

 

glowne_obiekty -> obiekty_solidne_itp -> inne_obiekty

 

klasa-obiekt glowne_obiekty opisuje wszystkie obiekty. Ma za zadanie wlasciwie rysowanie tylko sprita i jego cienia (czyli jak w ktoryms przykladzie na tej stronie).

klasa-obiekt obiekty_solidne_itp opisuje wszystkie akcje, obsluguje wlasciwosci takie jak solidny, ciezki, trafiany itp. Jest dzieckiem glowne_obiekty, ale nie dziedziczy wlasciwie nic szczegolnego (bo nie ma co ^^)

inne_obiekty - wlasciwie nie uzywane, bo dla praktycznie wszystkich ustawiam jako parenta obiekty_solidne_itp

 

Problem polega na tym, ze chcialbym by obiekt glowne_obiekty rysowal cien zalezny od zmiennej. Ustawiam wiec w jej [create] ową zmienną, ale [draw] tego obiektu nagminnie mi mówi ze takiej zmiennej nie ma! CO JEST?

Nawet jak dla dzieci tego obiektu ustawie ta zmienna, a nawet! jak przekazuje ten event za pomoca klocka inherit to tez jej nie widzi. Jakis pomysl? Zglupialem ^^

 

Jak ktos moze sprawdzic i w razie czego nakierowac/dac rady - to zapraszam do sciagniecia wersji roboczej. Tam sa 2 pliki GM - jeden to gra wlasciwa, drugi to wersja do testowania - szybciej sie kompiluje itp, bo nie ma menu itp.

Wszelkie sugestie bardzo mile widziane.

 

Z wersji wlasciwej usunalem demo w postaci gifa, bo to byl hardcore przy kompilacji i pamieci, wiec po menu glownym jest czarny ekran czekajacy na dowolny klawisz. Narazie nie mam programu do AVI zreszta nie probowalem jeszcze obslugiwac AVI ^^ (swoja droga dziwnie to wyglada jak GIF ma >5mb ^^)

 

 

https://gmclan.org/up4351_4_theBunkerDemo.html

 

Radze nie doublepostować. Tym razem bez Warna.

ΨΧΞ