Temporal

Tytuł: W the Gejm Gatunek: Boss rush Opis: W the Gejm to gra z gatunku boss rush osadzona w fikcyjnym świecie "Łykopu". Walcz z 5 potężnymi bossami, naucz się ich ataków i spróbuj wyjść z tych potyczek żywy. Uważaj by nie wpadła Ci rurka do silnika, rozglądaj się w lewo i prawo by upewnić się, że nie przejedzie Cię Pan rajdowiec, strzeż się platyny i stalkerów. PS Postacie występujące w grze są fikcyjne, podobieństwo do zdarzeń, miejsc i postaci jest przypadkowe. Download: https://temporal666.itch.io/w-the-gejm (wersja Windows) https://temporal666.itch.io/w-the-gejm-html-version (wersja HTML) Rozmiar pliku: 136 MB Autorzy: Programowanie: Temporal Fabuła: Temporal Grafika: Temporal Muzyka: Darmowe źródła z internetu Screeny: Trailer:

Super graficzki.

Można zaprogramować, by dźwięki nie odpalały się, gdy już jeden jest odgrywany, grać je w pewnych odstępach czasowych, nagrać kilka wariacji dźwięku itp.

Myślałem, że to w pełni przeróbka, a teraz wychodzi, że w oryginalne jest to też takie poryte

Ale to jest dobre. Szkoda, że na YT bardziej opłaca się robić jakieś kompilacje śmiesznych filmików i inne takie .

Jedynym plusem tej gry to lektor, reszta rzeczy nie gra. Denne sterowanie, beznadziejna mechanika walki, totalnie skopane AI wrogów i gui wyświetla się nie tam gdzie trzeba. Dałbym screena, ale jakbym nie kombinował, to dostaję biały ekran, więc nici z przechwytu. Jak zostanę zaatakowany, to mogę się wbić w ścianę, a później z niej już nigdy nie wyjść. Nie chcę być okrutny, ale gra jest całkowicie niegrywalna.

Ogólnie super, ale nie byłbym sobą, gdybym nie zaczął szukać dziury w całym, więc: ten shading na wilkach jakiś dziwny, jakby nie było żadnego shadingu i każdy polygon jest cieniowany "płasko".

Problem rozwiązałem już parę dni temu. Jeden z użytkowników GMclanu podpowiedział mi alternatywne podejście do tematu. Co prawda problem tworzenia grup nie odpadł całkowicie i bardziej się rozwiązał problem z tym konkretnym przypadkiem. Co do kodu powyżej, to podoba mi się pomysł, sprawdzaniem konkretnej zmiennej u danej istancji, ale niektórych rzeczy nie rozumiem. Możliwe, że się nie zrozumieliśmy dokładnie i stąd pewne nieścisłości. Ten kod sprawdza wszystkie instancje, które kolidują z linią i jeśli choć jedna z nich będzie danego typu, to zmienia się state machine obiektu, który ma ten kod. Jak widać w moim poprzednim kodzie, używałem sortowania listy, by zobaczyć czy dany obiekt jest widoczny, czy nie (jeśli obiekt gracza był pierwszy na liście, to oznaczało, że nie jest on za żadną osłoną). Mój wcześniejszy kod działał idealnie, ale wtedy byłem zmuszony do używania jakiegoś parenta, a chciałem znaleźć jakieś alternatywny sposób do tworzenie grup. Z parentami czasami dochodzi do sytuacji, gdzie chcemy mieć jeden obiekt w kilku grupach, a system parentowania to wyklucza. Znalazłem własny sposób by tworzyć własne skrypty przechowując grupę w tablicy. Później odpalałem pętlę razy ilość obiektów/pozycji tablicy. Ktoś mi doradził, że to głupie i zaproponował banalniejszy rozwiązanie. Twoje rozwiązanie jest nawet w pewnym sensie podobne do mojego, ale bawienie się w takie pętle zostało mi odradzone. Tak, czy siak dzięki za odzew, jestem wdzięczny za każdą radę od GMclanowiczów.

Nie do końca rozumiem jak to ma działać. Mam sobie stworzone trzy obiekty: obj_player, obj_enemy, obj_pietruszka. Wstawiam sobie je do room editora. W create event dla każdego z nich odpalam mój (twój) skrypt scr_unit_create(grupa). Nie wiem jaki cel jest pozostałych skryptów i po co miałbym je wywoływać? Teraz wszystkie moje trzy obiekty mają zmiennę "team" która równa się grupa? Hmmm, czyli scr_unit_create("grupa"), dobra teraz mam zmienną team ze stringiem "grupa". Co to mi daje? Chcę gdzieś w kodzie odpalić jakąś funkcję i zamiast odwołać się do danego obiektu odwołuję się do grupy np. par_spotted zamieniłem na "grupa", ale to bez sensu, to odwołam się zmiennej team Ok, to nadal bez sensu. Konrad-GM, nadal nie rozumiem co te twoje skrypty robią i jak mają rozwiązać mój problem? W funkcjach zamiast odnosić się do jednego obiektu chcę do pewnej grupy obiektów. Co bym nie kombinował z twoimi skryptami i co nie ładował do pierwszego argumentu jak nazwa obiektu, czy co, to co ja zrobię z tą zmienną? Mogę zapisać kilka id do jednej zmiennej? Jeśli możesz to podaj jakiś przykładowy kod z zastosowaniem tego twojego sposobu.

Tak jak w temacie, da się jakoś grupować obiekty w GM inaczej niż za pomocą "child-parent"? Ten system parentowania działa spoko, ale co w przypadku jak chcę mieć dwie grupy np: kwadraty(obj_player, obj_kwadrat) i postacie (obj_player, obj_enemy)? obj_player może mieć tylko jednego parenta, więc nie mogę go podpiąć pod jakiś jeden obiekt "kwadraty" i drugi "postacie". Chciałbym dość często wykonywać kod dla poszczególnej grupy obiektów, a obecny system parentowania nie pozwoli mi tworzyć takich grup. Wiem, że parent może mieć kolejnego parenta, ale to nie jest dobre jak chcesz mieć grupy, które mają jeden obiekt, a innego nie mają. Da się jakoś inaczej? Ja wpadłem na taki pomysł tworzenia własnych funkcji/skrpytu, który zwraca 1 wymiarowego arraya i później przepuszczam pętlę razy ilość tych rzeczy w tym array'u. Wcześniej miałem taki kod i używałem obiektu "par_entity", który był taką jedną grupą. Niestety ta grupa zawierała w sobie obiekt gracza "obj_player", który występował też w innej grupie i jak się łatwo domyślić, to ten sposób powodował, że nie mogłem w różnych miejsach w kodzie odnosić się do obiektów typu par_ Z czasem zmieniłem ten kod na coś takiego: Działa idealnie, choć nie wiem czy to nie odbija się jakoś znacząco na wydajności. Mój problem polega na tym, że nie wiem co wyczarować w kodzie, gdy chcę zrobić podobny myk w takim przypadku: Zamiast par_spotted chciałbym odnieść się jakoś inaczej do wyznaczonej grupy obiektów. Mógłbym pokombinować tak jak wcześniej z grupą w array'u i pętlami. W przypadku jednak użycia jakiejkolwiek funkcji typu collision_list potrzebuję utworzyć listę wszystkich id występujących kolizji i posortowania ich w jednym kroku. Jakbym nie kombinował to po zmianie ten kod nie działa tak jak trzeba i obiekt zmienia swój status na attack, nawet jeśli gracz jest za ścianą. W oryginalnej formie kod działa perfekcyjnie, ale wtedy jestem zmuszony do używania parentowania, a chciałbym bez tego, bo w przyszłości i tak nie poparentuje tak swoich "grup" bym miał w nich te obiekty, które chcę. Da się jakoś inaczej?

Dużo geometrii, która ostatecznie i tak nie wpływa na kształt bryły.

Fajna ta laseczka. W sumie to nie wiem, czy to taka cartoonowa stylizacja i tak ma być, ale może fajnie byłoby wypalić AO z tego high poly i zmiksować trochę to z aktualną color mapą. O ile ta jaszczuro baba mi się średnio podobała, to te twoje nowe wrzuty są bardzo super. Mam nadzieję, że gra odniesie sukces, tyle włożonej pracy, więc nie może być inaczej

Fajne, ale przez tą zieloną obwódkę, to czuję się jakbym potrzebował okularów 3d. Może warto poexperymentować i ten zielony zamienić na inny kolor? To tylko moja sugestia, nie musisz się do tego stosować.

Jak zawsze klasa.Genialne to jest.

Wojzax, to jakaś gra strategiczna, klon xcoma?

Taki tam projekcik i zabawa nad AI wrogów.

Ale to jest ładne Z assetami to jest tak, że jak się wymiesza z innymi to wygląda to nie za dobrze, a raczej nikt nie zrobi pakietu pod naszą gierkę, więc ja na pewno nie skorzystam, ale jak ktoś sobie coś tam dłubie, to do testów jak znalazł. Szkoda, że projekt anulowany, bo fajnie to wygląda na tych gifach.

To jest czaszka z padem? Nie ogarniam co się tam dzieje, ale bardzo śliczne to

Widać, że ktoś tu się dobrze zna na grach Z reguły jak przejdę jakąś grę single player, to do niej nie wracam, ale z pierwszym Falloutami mam tak, że raz na jakiś czas bierze mnie taka chcica, że muszę kolejny raz zatopić się w ten świat. Szkoda, że takich erpegów się nie robi. Prawdziwy brutalny świat bez elfów, magii i innych takich. RPG w którym naprawdę podejmujesz decyzję i masz wpływ na otoczenie. Większość erpgeów mydli oczy toną tekstu, marketingowym bełkotem, a jak przyjdzie co do czego, to gra jest strasznie liniowa i każdy quest wykonuje się na jeden przewidziany sposób. Ludzie do dzisiaj podniecają się Baldurami, a tam wszystko było iluzją, jakiej opcji dialogowej byś nie wybrał, to nie miało to zupełnie znaczenia. W Falloucie to każdy quest można wykonać na wiele sposobów, a i tak większość z nich jest opcjonalnych. Questy poboczne, to nie tylko fecz questy, ale normalne duże rozbudowane zadania, które można wykonać albo przejść grę o nich nawet nie wiedząc. F2 to już w ogóle, takie F1, tylko na sterydach.

Czyli darować sobie tilesy i wrócić do starych sprawdzonych obiektów kolizyjnych? Plansze w grze mają być duże, nie jakaś metroidvania, ale trochę tam ma się scrollować zanim etap się skończy. Pomysł z dezaktywacją obiektów, które są daleko od aktualnej kamery nie jest taki głupi i myślę, że nawet z moją małą wiedzą o GM'ie jestem w stanie ogarnąć temat.

Super twarz wyszła, ręka niestety jakością trochę odstaje. Może domalować jakieś wytarcia na krawędziach? Materiał w tych miejscach się najbardziej rysuje i farba odchodzi.

Tworzę sobie taki projekcik, gdzie wykorzystuję kolizję opartą o tilesy, a nie obiekty. Mój skrypt, który jest taką alternatywą dla "place_meeting()", tylko działa na tilesach: Tak wygląda kod odnośnie kolizji: Nic odkrywczego, taki standard jeśli chodzi o precyzyjną kolizję, tutaj jednak odnosimy się do tilesów. Chcę w grze mieć wrogów, którzy mają zasięg widzenia i jeśli my jako gracz się w nim znajdziemy, to odpalają się pewne state'y. Problem jest taki, że ściany, platformy, to tilesy bez obiektów kolizyjnych, więc funkcja collision_line() odpada. Moje doświadczenie jest małe i coś tak kombinuję sobie, jak pierwszy lepszy pomysł do głowy trafi. Skoro mam własną funkcję do wykrywania kolizji między obiektami a tilesami, to pomyślałem, że może "wzrok" przeciwników, to będzie obiekt, ze spritem o wielkości 1 pixela, który będzie się skalował w osi x na maksymalny zasięg z zmiennej. Problem jest taki, że kolizja z tilesami jest oparta o punkty bounding boxa tilesa. Rózne rozmiary kolidujących spirtów mogę powodować różne błędy i niewykrycie kolizji. W moim przypadku mamy 8 punktów sprawdzania kolizji i większości przypadków daje radę. Jeśli biała linia przejdzie za bardzo przez tilesa, to kolizja nie zachodzi i zmienna seeing_wall = false; Na screenie widać o co mi chodzi. Chciałbym żeby linia wchodząc w tilesa scalowała się w dół. Tak by nadal kolidowała z tilesem a się skracała tak by nie wychodziła poza obszar tilesa. Pewnie nie jest to najlepsze rozwiązanie, ale likwidacja tego jednego problemu dałaby mi to czego potrzebuję. Próbowałem coś na googlach szukać odnośnie collision_line z tilesami i jedyne co znalazłem jakiś niezrozumiały dla mnie skrypt, który był raycastem opartym o ds_grid. Jak na moje potrzeby, to jednak za bardzo skomplikowane. Może zamiast skalowanego obiektu na wzór linii zrobić obiekt "punkt", który jest w odległości od przeciwnika i w razie kolizji jest dopychany w pętli idealnie do punktu bounding boxa? samą linię mógłbym na potrzeby debbuginu rysować w drawie w odległości x przeciwnika do x punktu. Jakieś rady? Jeśli ktoś znałbym jakiś nie za bardzo skomplikowany sposób na zrobienie tego bez dodatkowych obiektów tylko na podstawie jakieś "zaawansowanej" matematyki, to się nie obrażę

Płakać na grach, nie płaczę, ale są takie momenty gdzie się morda cieszy, człowiek wczuwa się w tą fikcyjną scenkę itd. Taki Fallout1 i scena wygnania ze schronu, albo alternatywne zakończenie, gdzie supermutanty wbijają się nam do schronu 13, coś pięknego Hollow Knight i pierwsze zakończenie.

trzymam kciuki za projekt, bo naprawdę fajnie się to zapowiada

Trochę ze mnie debil, bo całkowicie zapomniałem, że alarm to po prostu wbudowana zmienna i mogę się do niej dostać tak samo jak do zdefiniowanych przez siebie zmiennych. Pytanie tylko teraz jest takie: po co jest to całe alarm_get? Sugerowałem się tym co jest napisane w helpie, ale teraz wychodzi, że prościej sczytywać sobie wartość bezpośrednio jak blabla = alarm[0] czy tak jak dla tego przypadku obj_player.alarm[0] Nie za bardzo widzę zastosowanie dla tego alarm_get... chyba, że to jakieś pozostałości ze starych wersji GM, gdzie inaczej się nie dało dobrać do tych wartości.