SimianVirus7

Ostatnio oglądałem na YT jakiś materiał o Doomie z 93 i pomyślałem, że spróbuję napisać jakiś raycast na miarę moich możliwości.

Generalnie sam już nie pamiętam co miałem wczoraj na myśli. Coś kojarzę, że w gm teraz nie ma tablic dwuwymiarowych tylko są zagnieżdżenia, a nie miałem z tym nigdy styczności. Dlatego chciałem zrobić tak jakby tablice jedno i dwuwymiarową pod jedną zmienną. Czyli jakbym chciał się odwołać do pierwszej tablicy to wpisywałbym grid[ i ], a jak do zagnieżdżonej drugiej tablicy (coś na styl dwuwymiarowej) to grid[ i ][ i ]. Generalnie błąd rozwiązałem tym, że mam grid[ 0 ] [ i ] - jakby do 1D grid[ i ] [ i ] - jakby do 2D ... właśnie pisząc to zauważyłem, że mogę zrobić grid[ 0 ][ i ] grid[ 1 ][ i ] i traktować to jak dawne tablice dwuwymiarowe

Witam, Natknąłem się na taki błąd i nie mam pojęcia czego on wynika. Ktoś ma jakiś pomysł? Create: for(var i=0; i < 64; i++) //64 - tyle jest promieni { grid[i] = -1; //ray type grid[i][i] = -1; //ray length } Draw: for(var i=0; i < 64; i++) //64 - tyle jest promieni { draw_text(400, 5 + (i*10), grid[5]); } wynik: [0,0,0,0,0,-1] <-- zależnie co wpiszę w index tablicy, tyle jest zer np. grid[3] = [0,0,0,-1] grid[6] = [0,0,0,0,0,0,-1] jak wpiszę grid[ i ][ i ] to jest ok. ale przy jednym grid[ i ] to już nie :/ Przy zmianie zmiennej grid, jest to samo. Uruchomienie ponownie kompa, to samo.

No kumpel powiedział, że tej w tej grze nie da się przegrać, zawsze wygrywa, więc zwiększyłem trochę poziom mi udało się podbić wszystkie w około 92 dni, z czego dwa razy kupiłem młodość u wiedźmy. Cóż, z pixelartem mam styczność dopiero od dwóch tygodni, czyli właśnie wtedy kiedy zaczynałem pisać tę grę Jeszcze nie ogarniam jak to robić, dlatego rysuje 16x16 co w powiększeniu na 720p faktycznie są wielkie.

Tytuł: KingKing Gatunek: Strategia turowa Opis: Jesteś królem któremu zostało 100 dni do końca życia. Spróbuj podbić wszystkie okoliczne państwa. Między wojnami udzielaj audiencji z poddanymi. Każda rozmowa składa się z potrzeb i skutków. Od Ciebie zależy którą z dwóch odpowiedzi wybierzesz, choć w sumie jesteś królem, więc jeśli nie chcesz, to nie rozmawiaj z plebsem ale to też ma swoje skutki. Gra powstała na 4 dniowym jamie ale postanowiłem troszkę ją rozwinąć, bo pomysł brzmiał fajnie. Zawsze chciałem zrobić strategie pokroju Anno 1503, ale z naciskiem tylko na ekonomię (czyli trochę taki Banished). Mam nadzieję, że KingKing to taki protoplasta tej strategi. Download: KingKing Autorzy: Programowanie: SimianVirus7 (Narkoleptyk) - Ja Grafika: SimianVirus7 (Narkoleptyk) - Ja Muzyka: ZapSplat.com Screeny:

"Ja Jadę a Ty bronisz orzełka" <3 Bardzo fajne demo, ogólnie gameplay jak najbardziej na plus. Grafika poprawna, a cząsteczki rozpadającego się murku dają satysfakcję z jego rozwalania. Jeśli mogę się do czegoś przyczepić to tak: - jeżdżenie po skosie jest trochę dziwne, znaczy, czołg po puszczeniu np. A + W czy D + W, mógłby od razu wracać do pionowego/poziomego sprite'a, a nie jechać krzywo jeszcze przez parę sekund - przeciwnicy mogliby być bardziej agresywni w stosunku do orzełka (pewnie i tak będziesz to poprawiał nie raz, tak tylko mówię ._.) - bardziej widoczne pociski, trochę szybko lecą i trudno je wychwycić - New Game wywala z gry xD - może bardziej statyczne menu, chociaż to pewnie przeszkadza mi dlatego, że łeb mnie dzisiaj boli :/ Gdyby dać więcej contentu i zaimplementować drugiego gracza (tak jak masz w planach) to myślę, że jak najbardziej nadaje się na Steam. Edit: a no i super szkice. Bardzo lubię kiedy deweloper dzieli się szkicami, to mnie zwykle nakręca.

Pierwszy raz brałem udział w jamie (poza moją ulubioną Ligą24 na gmclan). Temat przewodni "władza", czas 4 dni. Na razie gierka oferuje: - krzywy angielski - brak balansu - brak udźwiękowienia ale jak ktoś jest ciekaw, to zapraszam https://narkoleptyk.itch.io/kingking Jeśli starczy mi sił, to ukończoną wersję wrzucę też na gmclan, bo nie wiem, czy tak mała gra zasługuje chociaż na post w dziale "demo"

Wygląda trochę jak te przerywniki z DmC (ninja theory), tyle, że na sterydach

Dokładnie tak jak powiedział @adam014, użyj image_xscale, zaoszczędzi Ci to czasu i miejsca związane z tworzeniem sprite'ów. Pamiętaj tylko, żeby każdy sprite patrzył domyślnie w prawo. Co do kodu, będzie to mniej więcej coś takiego: Jeśli naciśniesz strzałkę w lewo to: - ustaw sprite na bieganie - ustaw image_xscale = -1 - ustaw prędkość poruszania się (np. hspeed = -4); Jeśli naciśniesz strzałkę w prawo to: - ustaw sprite na bieganie - ustaw image_xscale = 1 - ustaw prędkość poruszania się (np. hspeed = 4); (tutaj różnica jest tylko taka, że wartości są dodatnie) Jeśli nie naciskasz ani strzałki w lewo ani w prawo to: - ustaw sprite na stanie w miejscu - ustaw prędkość poruszania się na zero (image_xscale nie zmieniasz, tak, aby została wartość ostatnio obrana, czyli w lewo albo w prawo) W kodzie będzie to wyglądać mniej więcej tak: if(keyboard_check(ord("A"))) //jeśli strzałka w lewo { sprite_index = sHero_run; //ustaw odpowiedni sprite image_xscale = -1; //ustaw obrót w którą stronę patrzeć hspeed = -4; //ustaw prędkość } if(keyboard_check(ord("D"))) //jeśli strzałka w prawo { sprite_index = sHero_run; //ustaw odpowiedni sprite image_xscale = 1; //ustaw obrót w którą stronę patrzeć hspeed = 4; //ustaw prędkość } if(!keyboard_check(ord("D")) and !keyboard_check(ord("A"))) { sprite_index = sHero_idle; //ustaw odpowiedni sprite hspeed = 0; //wyzeruj prędkość aby postać zatrzymała się } A wynik powinien wyjść mniej więcej taki: grafika: https://opengameart.org/content/forest-boy-platformer-animated-character-24x24 edit: Z tego co się orientuje maziasz gry w game maker 8.1 więc chyba trudno będzie o jakikolwiek przykład projektu :/

Chodzi tutaj o dodatkowe sprawdzanie każdego piksela, tak zwane "pixel perfect collision". Samo IF sprawdza, czy w odległości od równej prędkości poruszania jest ściana (oWall). Jeśli tak, oczywiście IF wykonuje się. Ale co jeśli prędkość jest większa niż powiedzmy 10px? Wtedy zostanie nam luka, bo IF sprawdził to tylko raz. Kod w WHILE wykonuje się BEZ PRZERWY dopóki warunek jest spełniony. Dlatego łatwo grę można zatrzymać w miejscu, ponieważ WHILE zapętla się i nie pozwala programowi wykonywać się dalej, kiedy źle określimy warunek. Czyli, wykonując swój kod, IF sprawdza, czy napotkano ścianę, jeśli tak, WHILE sprawdza pozycję gracza + jeden pixel! (sign oznacza jeden pixel) i jeśli nie wykryję ściany, przesuwa gracza o ten jeden pixel i tak w nieskończoność, dopóki pozycja gracza + jeden pixel == pozycja ściany. W praktyce wygląda to następująco, gdy prędkość poruszania się gracza to 20px

Z racji, że gms2 nadal nie obsługuje sql, a rozszerzenie z gamemakerserver.com działa tylko pod gms, postanowiłem coś ruszyć w tej sprawię i zacząłem coś pisać w pythonie. To moje pierwsze starcie z tym językiem i naprawdę mnie denerwuje, co po chwile mu coś nie pasuje. Ale po trzech dniach jest mały postęp. Python sczytuje dane z sql i wysyła do game makera.

?, z tego co ja wiem solid nie sprawia automatycznie, że obiekty kolidują na siebie nawzajem, tylko trzeba do tego dopisać stosowny kod. Generalnie ja nie korzystam z flagi solid więc mogę się mylić. Jaki błąd?

a jaki jest twój kod kolizji z platformą?

Nie wiem jak wygląda Twój kod ale jeśli używasz vspeed, to możesz sprawdzać kolizje tylko wtedy, jeśli postać opada albo stoi. Czyli: If (vspeed >= 0) then kolizja Bo vspeed < 0 czyli np vspeed = -3 to skakanie, bo postać porusza się w górę, czyli wtedy nie sprawdzaj kolizji tylko przenikaj przez platformę.

Dziękuje :> Hmm.. też się nad tym chwilę zastanawiałem, więc bardzo możliwe, że tak jest. Nooo, to prawda Kolega mówił, że po kilku sesjach jego oczy chcą wypaść z oczodołów (づ｡◕‿‿◕｡)づ