Huri

Dzięki :) .. Spróbuje jutro to ogarnąć (lubię rozumieć to co przepisuje). Teraz walczę z czym innym. Jeszcze się za to nie zabrałem i możliwe, że mój pomysł polega na tym samym albo jest niewykonalny ale... A gdyby tak narysować room tak jak odbywa się to normalnie, narysować jego tło, wypalić cienie na nim i zapisać cały room do pliku i odczytać go i ustawić jako tło? Coś na wzór bake'owania textur w grafice 3D.

Przyznam szczerze, że nie potrafię zrozumieć. Póki co to chyba dla mnie zbyt zaawansowane. Nawet z narysowanym w sprite'cie cieniem jest ten problem (w sumie logiczne). Daruje sobie chyba Cienie dopóki nie nauczę się więcej.

Cześć to znowu ja. Otóż zaplątałem się w tych wszystkich klockach i postanowiłem, że jednak przerzucę się na GML. Zacząłem od samego początku i napisałem kod odpowiedzialny za rysowanie poziomu (dla przypomnienia top-down fake isometric). Mam sprite spr_wall i spr_w_template. Gdy w edytorze ROOM rysuje poziom gry uzywam obiektu z domyślnie przypisanym spr_w_template (dla ułatwienia rysowania). W kodzie obiektu obj_wall w EVENT CREATE wstawiłem wykonywanie skryptu room_draw(). Skrypt ten jest dosyć uniwersalny dzięki czemu mogę rysować różne sprite'y dla obiektu obj_wall. Moim głównym zamierzeniem było to żeby obj_wall w zależności czy i z której strony jest otoczony przez inne obiekty (solid) zmieniał sprite. Wszystko działa super i tak jak chciałem... Ale zapragnęło mi się dodać cienie pod obiektami sciany. Skorzystałem więc z GMLdraw_sprite_ext(sprite_index, image_index, x, y, image_xscale, image_yscale, image_angle, image_blend, image_alpha); No spoko... Cień rysuje się nawet pod obj_wall... ale tylko tym, z którego został wygenerowany. Chciałbym żeby cienie były rysowane pod wszystkimi obiektami obj_wall a nie tylko pod jednym, z którego został wygenerowany. Jakieś pomysły? Kombinowałem też z surface'ami ale coś pochrzaniłem (nie doszedłem jeszcze do tego etapu obcowania z GM) i zcrashowałem grę. Część kodu odpowiedzialnego za przydzielanie sprite'ów do obj_wall (reszta wygląda tak samo tylko sprawdza czy obiekt jest/nie jest otoczony z innych stron): GML // Rysowanie ściany orientacji NE (Północ-Wschód) if (!place_free(x-grid_s, y+0) && place_free(x+0,y-grid_s) && !place_free(x+0,y+grid_s) && place_free(x+grid_s, y+0)) { image_index=w_ne; //rysuj_cien(); <-- to nieaktualne już } W EVENT DRAW obj_wall wpisałem to: GML GMLdraw_sprite_ext(sprite_index, image_index, x-3, y-3, 1.3, 1.3, image_angle, c_black, 0.4); depth=-x-y; draw_self(); W grze wygląda to mniej więcej tak. Nie zwracajcie uwagi na tą niebieską gębę :P ... wziąłem najtańszego statystę z Avatara do testowania rozwiązań :P . W czerwonej ramce oczywiście nakładające się cienie. Jeszcze jeden obrazek. Może na tym będzie lepiej widać (Tu zaznaczone na zielono). Cień może nachodzić na gracza (ale tylko na niego). Będę wdzięczny za pomoc.

Ereg wysłałem Ci PM :) Teraz wszystko byłoby dobrze (tak myślę) gdyby przeciwnik poruszał się tylko góra-dół i lewo-prawo. Przeciwnik gubi się w takie sytuacji... Podejrzewam, że muszę coś poprawić w IF z CHECK GRID, ale jeszcze nie wiem co dokładnie. Obstawiam, że źle (zbyt często) zapisuje poprzednią pozycję gracza i przeciwnik zamiast iść na poprzednią pozycję gracza idzie na aktualną. Ale... jest już późno a ja mam wodę z mózgu :) . Zobaczymy jutro :) . Mam powoli dosyć :). Czuję, że nie obejdzie się bez przejścia na GML żeby uniknąć bólu głowy.

Za duże zagnieżdżenie IFów w końcu powoduje taki bałagan, że czasami ciężko rozgryźć o co chodziło. Czasami nawet komentarze nie pomagają. Myślę, że dlatego właśnie jeśli nie ma potrzeby lepiej unikać. Ja np. w moim projekcie jak się zaczął bardziej rozwijać łapałem się na tym, że w złym miejscu wsadzałem START i END BLOCK i przez to wynikały problemy. W kodzie jest podobnie z nawiasami :) No ale kim ja jestem żeby się wypowiadać :)

Zapamiętam tą regułę z IFami :) . W sumie wydaje się logiczne :) Nie wiem być może źle robię ale ciągle trzymam się mojej metody. Poradziłem sobie z poniższym. Wpisywałem złą nazwę zmiennej. Czasami jednak przeciwnik nie chodzi po siatce tylko przemieszcza się na ukos a nieraz wogóle się nie zatrzymuje tylko leci dopoki nie walnie w ściane.Robi tak pewnie dlatego, że użyłem klocka CHECK GRID. W momencie kiedy przeciwnik wyłapie gracza radarem "na ukos" wtedy idzie do niego "na ukos" i wtedy warunek z klocka CHECK GRID nie jest spełniony więc przeciwnik leci ciągle aż do przeszkody (ściany) i tam się blokuje. :( . Przeciwnik powienie poruszać się np. w ten sposób: góra, prawo, góra, prawo. Skokowo a nie bezpośrednio skośnie. :S Gdy obiekt radar trafi w gracza zapisuje dwie zmienne z jego pozycją w momencie uderzenia. Nastepnie w sekcji gdzie są klocki odpowiedzialne za ruch przeciwnika wrzucam klocek MOVE TOWARDS i jako parametry podaje te dwie zmienne z obiektu radar. Jednak Gdy dojdzie do kolizji między obiektem gracz i obiektem radar wywala mi taki błąd. Nie bardzo orientuje się jak odczytywać te błędy. GMLGML___________________________________________ ################################################################################ ############ FATAL ERROR in action number 1 of Step Event0 for object obj_enemy: Push :: Execution Error - Variable Get 4.player_y(100004, -1) at gml_Object_obj_enemy_Step_0 (line 20) - action_move_point( obj_target.player_x, obj_target.player_y, 1 ); ################################################################################ ############

Ok problem rozwiązałem. Polegał na tym, że nie wstawiłem jednego klocka End Block w odpowiednim miejscu. Jeżeli chodzi o te podpowiedzi, które mi wysłałeś to zapisałem je sobie i zostawie na przyszłość :). Napewno się przydadzą chociaż będę musiał przypomnieć sobie trygonometrie coś czuję :P. Niestety zawsze byłem kiepski w matematyce (tak tak wiem, że to podstawa jeśli chodzi o tworzenie gier). Pojawił się kolejny mini-problem ale myślę, że na tą chwilę to oleje. Otóż przy sprawdzaniu odległości między graczem a przeciwnikiem zdarza się sytuacja, że jeśli dwóch przeciwników jest odpowiednio blisko gracza obaj się ruszają (bo znajdują się w odległości mniejszej niż wyznaczona 48px) obaj przeciwnicy się ruszają mimo że tylko jeden z nich "widzi" gracza. Ale mogę to wytłumaczyć tym, że przeciwnik, który zobaczył gracza mówi temu drugiemu przeciwnikowi, że gdzieś tam jest gracz i dlatego ten się rusza ;) Heh. Zabawne i jednocześnie smutne (dla mnie). Wiedziałem, że GML jest 200% lepszy od klocków i coraz częściej widzę dlaczego. Po pierwsze w klockach przy nieco bardziej skomplikowanych funkcjach łatwo się zgubić. Powoli zaczynam mieć problemy z ogarnięciem tego wszystkiego i dodawanie nowych funkcji staje się problematyczne :(... W kodzie ten problem jest o wiele mniejszy. Nie mniej jednak dokończę to co zacząłem na klockach :) Piszę też bloga z produkcji ze wszystkimi swoimi spostrzeżeniami odnośnie stworzenia gier. Może kiedyś skompiluje z tego co napisałem artykuł dla ludzi, którzy będą chcieli wziąć się za GM :)

Dzięki ale jak już napisałem w poprzednim poście... podstawy ZNAM i nie mam raczej problemów z przystosowaniem się do nowego języka (problem tkwi raczej w moim słomianym zapale :P i poprostu przestaje mnie interesować programowanie) . Programowałem w zamierzchłych czasach na Atari w Basicu, na Amidze w AMOSie (czyli w sumie też taki BASIC), na PC w QBASIC, TURBOPascal, C++, Delphi, JAVA i jeśli można to nazwać programowaniem to w LOGO (ComLOGO). Języków było sporo ale znam tylko takie naprawdę podstawy raczej (zmienne, tablice, pętle, warunki itp). Nie mniej jednak jeśli będę potrzebował pomocy w GML (jak się już nauczę operacji na klockach) to nie omieszkam napisać... więc czuj się ostrzeżony :P :) Miło, że spotkałem się tu z taką chęcią pomocy :) Od momentu kiedy tu zawitałem naprawiłem/zrobiłem lub dołożyłem nowe funkcje w mojej grze. Oczywiście dzięki Waszej pomocy :) . Jakaś wzmianka w CREDITSach by się przydała. Się zrobi :) Teraz mam problem z tym, że przeciwnik zdaje się ignorować zmienną obj_player.ruszyl_sie i i tak rusza się za każdym razem kiedy wystrzelony z niego (obj_przeciwnik) obiekt obj_radar trafia w gracza. Ale to prawdopodobnie przez to, że za bardzo gmerałem w instrukcjach warunkowych i źle zmieniam wartość zmiennej obj_player.ruszyl_sie . W domu to naprawie. W pracy ciężko przysiąść i się skupić na tym . Jakoś to rozwiążę :)

Dzięki :) Doceniam starania :) i napewno będę próbował. Pokombinuje. Może zaraz wrzucę gdzieś przykład w GM na którym testuję rozwiązania (sama gra powstaje w osobnym projekcie). Zdecydowałem się najpierw na klocki żeby poznać podstawowe zasady działania GM. Na GML przejdę jak skończe grę. Znam podstawy programowania i z tego co widziałem w przykładach w internecie nie jest to jakoś specjalnie trudne w GML i raczej rozumiem wszystko. Teraz chce się nauczyć co, kiedy i gdzie jest wykonywane. PS. Wczoraj np. wprowadziłem do gry widok pseudo-izometryczny i gra prezentuje się teraz lepiej. :) EDIT Banalnie proste :) Dzięki Twoim poradom zrobiłem już poruszanie się tylko tego przeciwnika, który widzi gracza a reszta poza zasięgiem stoi nieruchomo :) Dodatkowo zrobiłem coś co miałem w dalekich planach (Ściany robią się przezroczyste gdy gracz jest za nimi ukryty). Pozostało jeszcze sprawdzenie z tym kierunkiem poruszania się przeciwnika :) . Bo test na kierunek gracza już stosuje od poczatku wlasciwie zeby wiedziec w którą stronę gracz strzela :)

Dzięki za ten link :) W sumie opis klocków jest też w Helpie. Jeżeli chodzi o kombinowanie z wykonaniem ruchu w kierunku gracza przez przeciwnika. Myślę sobie tak: 1. Obiekt przeciwnika strzela radarem w 4 kierunkach. 2. Jeżeli któryś z wystrzelonych (dowolny) trafia w gracza do zmiennej dir_target zapisywany jest kierunek tego obiektu, który walnął w gracza. (Obawiam się, że jako, że są 4 obiekty radar następuje jakiś konflikt). 3. Kierunek ze zmiennej dir_target jest przekazywany do obiektu przeciwnika i jeśli przeciwnik może wykonać ruch (zależne od tego czy gracz się ruszył) to nadawana jest mu prędkość (speed) np. 1 Na mój prosty nie matematyczno-logiczny umysł powinno to zadziałać. Jednak się nie sprawdza. Obiekty radaru są wystrzeliwane w 4 konkretnych kierunkach (0,90,180,270) więc odczytanie wartości kierunku w EVENT COLLISION z obiektem GRACZ powinno dać się zapisać do zmiennej. Sam nie wiem Wywala mi taki błąd GML___________________________________________ ################################################################################ ############ FATAL ERROR in action number 1 of Step Event0 for object obj_enemy: Push :: Execution Error - Variable Get 3.dir_tg(100003, -1) at gml_Object_obj_enemy_Step_0 (line 16) - direction = obj_target.dir_tg ################################################################################ ############

Ok. Jako, że dopiero się uczę pójdę na kompromis i zrezygnuję z tego że rusza się tylko ten przeciwnik, który wykrył gracza. Kombinowałem z ID instancji, która trafia w gracza i zapisuje pozycję do zmiennych ale jakoś mi to nie bardzo wychodzi albo nie do końca rozumiem instance_id :). Daruje też sobie poruszanie się w kierunku ostatnio wykrytej pozycji gracza (chociaż już jakaś myśl mi się pojawiła ). Zastanawiam się też czy takie coś zda egzamin ale to przetestuje już sam. Zamiast wystrzeliwać obiekty w 4 kierunkach stworze prostokąt lub koło i przyczepie na środek każdego przeciwnika. Jeśli zajdzie kolizja między graczem a tym przyczepionym obiektem wtedy przeciwnik zacznie się ruszać. Dzięki temu powinienem zaoszczędzić nieco zasobów systemowych. :)

Poniżej mój pierwotny post. Pojawiło się inne pytanie. Otóż poradziłem sobie z tym całym wystrzeliwaniem. Teraz nie wiem jak zrobić aby przeciwnik poruszał się w kierunku gracza o jedno pole (16x16 pikseli). I żeby ruszał się tylko ten przeciwnik, który widzi gracza (Ci przeciwnicy poza zasięgiem mają zostać nieruchomi) Którego klocka użyć? Cała reszta ma pozostać taka sama czyli przeciwnik rusza się tylko wtedy gdy gracz wykonał ruch (zmienna obj_gracz.ruszyl_sie=1). Nie wiem czy jasno to napisałem :S ... mam nadzieję, że tak. :)