Temporal

tam w ostatniej linijce nie powinno być: draw_text(10,110, "alarm shooting" +string(a); zamiast var _a; with(obj_player){_a = alarm_get(0);} draw_text(10,110,"alarm shooting "+string(alarm_get(0))); ??

Mam w grze obiekt ctr_game, który robi za taki "globalny obiekt". Odpowiedzialny jest za kody, debbuger i inne takie. W moim debugerze chcę widzieć aktualną wartość alarmu konkretnego obiektu. Jest taka funkcja alarm_get i dzięki niej mogę sprawdzić wartość konkretnego alarmu dla obiektu w którym użyta jest ta funkcja. Problem jest taki, że chcę użyć tej funkcji w moim globalnym obiekcie. if (hide = true) && (instance_exists(obj_player)){ draw_text(10,30,"hspd "+string(obj_player.hspd)); draw_text(10,50,"vspd "+string(obj_player.vspd)); draw_text(10,70,"grounded "+string(obj_player.grounded)); draw_text(10,90,"shooting "+string(obj_player.shooting)); draw_text(10,110,"alarm shooting "+string(alarm_get(0))); } W ostatniej linijce widać co chcę zrobić. Oczywiście chcę się odnieść do obiektu obj_player, tylko nie wiem jak to ugryźć :/ Mam coś kombinować z with obj_player?

Technicznie zrobione bardzo fajnie, ale parę rzeczy mi się nie podoba. Mamy 3 kolorowe paski, brakuje jakiegoś opisy, nie wiadomo, co który robi. W pewnym momencie można się domyślić górnego paska, ale co robią pozostałe dwa dolne? To jest jakiś exp? Przydałaby się jakaś punktacja, skora gra nie ma żadnej fabuły, nowych leveli i innego elementu wskazującego na postęp gry. Po co mam zabijać przeciwników jak mogę unikać wszystkiego? Przeciwnicy mogą niezabici przelecieć przez dolną krawędź ekranu, coś tam się podświetla jakbym dostawał jakieś obrażenia, ale tak naprawdę to nic nie robi. Po paru zmianach mogłaby być to fajna gierka.

To jest clipping camery, czy ukryte polygony?

"FAILED: Run Program Complete" :/ EDIT: Dobra, działa, coś tam GMowi odbiło, ale po restarcie jest ok. Pamięć zżera totalnie :/ Ten bug we wcześniejszych wersjach też był, czy to bolączka GMS2?

Dziękuję za wszystkie odpowiedzi, doceniam to bardzo. Pierwszy mini projekcik mam już za sobą i sam jestem z tych, co uważają, że optymilizacja dla sztuki jest nie warta świeczki, ale warto jednak brać pod uwagę różne rzeczy podczas kodzenia, by nasza gra nie była zrobiona totalnie na odwal. Mam w planach trochę większy projekt i chciałbym się odpowiednio do niego przygotować. Na razie mam zamiar zrobić jeszcze dwie jakieś proste gierki w ramach nauki a później skupić się na tym swoim głównym projekcie. Mam zamiar stworzyć platformera z dużą ilośćią roomów i chcę być "gotowy". Wiele dzisiejszych indyków jest robiona w stylu retro i nawet jak same gry są napisane mało optymalnie, to obsługiwanie gierek o małych rozdzielczościach na dzisiejszych kompach nie powinna sprawiać problemów, ale ja chciałbym zrobić modernistyczną grę 2d, takie full hd, pełna paleta barw itd. Nie mam zamiaru robić jakieś metroidvani, ale chciałbym żeby każdy level się trochę "scrollował". Programista ze mnie żaden, a w GM siedzę jakieś z 1,5 miecha. Oglądam masę tutoriali i czytam różne ciekawe tematy na forum yoyo. O tej aktywacji i dezaktywacji obiektów poza widokiem też się trochę naczytałem. Cały czas mnie tylko zastanawiało, jak prosi robią gry, czy korzystają z podstawowych ficzerów GM'a, czy jednak robią wszystko okrężną, trudniejszą, lecz wydajniejszą drogą. Nie mam zamiaru robić żadnego wielkiego sieciowego mmo, ale chciałbym żeby moja gra chodziła sensownie na każdej konfiguracji i ładowała się szybko. Data structure w GM zawsze powodują memory leak, czy źle zrozumiałem ten wcześniejszy post? Z tego co czytałem, to jak będziemy usuwać w clean evencie nasze struktury, to powinno być wszystko ok.

Jak profesjonalnie powinno się podchodzić do tworzenia leveli w grze? Jeśli każdy poziom/ekran, to nowy room, to nie jest to rozwiązanie mało wydajne? Czy poziomy gry nie powinny być zapisywane oddzielnie jako pliki i ładowane w konkretnym momencie? Jak wygląda sprawa roomów w GM? Odpalam grę i wszystkie roomy ładowane są do pamięci, czy po prostu dany room ładowany jest gdzieś z pliku data podczas wczytywania danego rooma? Może mi ktoś przybliżyć tę kwestię? Tworząc przyszłe gry chciałbym na etapie planowania już sobie ogarnąć jak zabrać się za dany projekt, niż w trakcie uznać, że wszystko trzeba przepisać i zrobić inaczej by było wydajniej.

SLy, dobra robota

Dodatkowe serca można zbierać i z reguły częściej opłaca nam się stracić jedno serce niż wpaść do przepaści. Level nie został układany z ręki, tylko został wygenerowany losowo. Trochę powinienem popracować nad balansem poziomu trudności, bo są momenty gdzie jest ciężko po a jednym trudnym momencie nagle przez dłuży czas jest banalnie prosto. Im dłużej gramy, tym szybciej przewija się ekran, oraz zwiększa się częstotliwość pojawiana platform z kolcami. Kolejny projekt będzie trochę bardziej rozbudowany ale też bez jakiś przesadnych ambicji, żadnych rpg ani nic z tego. Po prostu chce przez takie projekty stopniowo uczyć się programu. Jak będę miał wystarczające umiejętności, to wtedy zacznę swój projekt życia :). Dzięki za komentarze, zawsze to jakaś motywacja, wiem, że sama gra po paru minutach się nudzi i nie wyróżnia się niczym na tle darmowych gier znajdowanych w sieci. Pierwszy krok wykonany, czekajcie na kolejne produkcje

Zapisałem uwagi i następnym razem postaram się by uniknąć tych niedogodności z listy. Dużo się nauczyłem robiąc tą mingierkę. Mam w planach zrobić jeszcze z jakieś 2 gierki, każda bardziej zaawansowana, a później zacznę już mój "oficjalny" projekt.

Taka prosta gierka w ramach nauki GMS'a. Sterujemy piłeczką, skaczemy i kombinujemy by nie wpaść do przepaści. Z czasem prędkość gry stopniowo się zwiększa, dochodzą platformy z kolcami, a gdzieniegdzie pojawiają się serduszka, które zwiększają naszą żywotność. Screen: Download: https://drive.google.com/file/d/1_-7sHkjdreetIb0RlcSsDCOxkaDDVUDt/view?usp=sharing

Pokombinowałem trochę i wymyśliłem coś takiego: dla obj_player: create dla obj_player: create /// @desc Variables spd = 2; jump_impulse = 4; grav = 0.1; hspd = 0; vspd = 0; lift = false; step /// @desc Main code // initialize input iLeft = (keyboard_check(vk_left)) || (keyboard_check(ord("A"))); iRight = (keyboard_check(vk_right)) || (keyboard_check(ord("D"))); iUp = (keyboard_check(vk_up)) || (keyboard_check(ord("W"))); iDown = (keyboard_check(vk_down)) || (keyboard_check(ord("S"))); iJump = (keyboard_check_pressed(vk_space)); // x direction dx = iRight - iLeft; dy = iDown - iUp; // horizontal speed hspd = dx*spd; // gravity if (grav<0.3){grav+=0.01}; vspd = vspd+grav; // horizontal collision and movment if (place_meeting(x+hspd,y, obj_platform)){ while (!place_meeting(x+sign(hspd), y, obj_platform)){ x += sign(hspd); } hspd = 0; } x += hspd; // jumping if (iJump){ if (place_meeting(x,y+1, obj_platform)){ vspd=-jump_impulse; } } //vertical collision and movment if (place_meeting(x,y+vspd, obj_platform)){ while (!place_meeting(x, y+sign(vspd), obj_platform)){ y += sign(vspd); } grav = 0.1; vspd = 0; } else { lift = false; } if (lift == false){y += vspd}; dla obj_platform /// @desc Random sprite sprite_index = choose(spr_platform_small, spr_platform_medium, spr_platform_large); vspd = 1; step /// @desc ? //platform movement y-= vspd; // lift the player if (place_meeting(x, y-1, obj_player)){ obj_player.y = (bbox_top-4); obj_player.lift = true; obj_player.grav = 0.1; obj_player.vspd = 0; } //destroy platform outside the height room if (y < 0){instance_destroy()}; Nie wiem czy to optymalne rozwiązanie, ale działa jak złoto. Żadnych bugów, perfekcyjna kolizja, śmiga wszystko. Może komuś się przyda, dlatego zostawiam to na forum.

Dla nauki robię swoją pierwszą gierkę i próbuję wykorzystać wiedzę, którą zdobyłem przerabiając różne tutoriale. Zamysł jest taki, że sterujemy kulką, platformy lecą do góry, a my skaczemy z jednej na drugą by nie wpaść do przepaści. Stworzyłem kod ruchu platformowego, z możliwością skakania i perfekcyjnych kolizji. Wszystko działa super gdy platformy się nie poruszają, ale przy ruchomych platformach potrzebuje jakiś modyfikacji. Problem jest taki, że nie wiem jak się za to zabrać, w necie łatwo o znalezienie tutoriali odnośnie platform poruszających się poziomo, ale z pionowym już gorzej (większość tutoriali pokazuje jak wykonać jakiś kod na odpieprz bez precyzyjnych kolizji). Próbowałem coś tam po swojemu kombinować, ale każdy sposób dawał opłakane rezultaty. Kod gierki wygląda tak: dla obj_player: create /// @desc Variables spd = 2; jump_impulse = 4; grav = 0.1; hspd = 0; vspd = 0; step /// @desc Main code // initialize input iLeft = (keyboard_check(vk_left)) || (keyboard_check(ord("A"))); iRight = (keyboard_check(vk_right)) || (keyboard_check(ord("D"))); iUp = (keyboard_check(vk_up)) || (keyboard_check(ord("W"))); iDown = (keyboard_check(vk_down)) || (keyboard_check(ord("S"))); iJump = (keyboard_check_pressed(vk_space)); // x direction dx = iRight - iLeft; dy = iDown - iUp; // horizontal speed hspd = dx*spd; // gravity if (grav<0.3){grav+=0.01}; vspd = vspd+grav; // horizontal collision and movment if (place_meeting(x+hspd,y, obj_platform)){ while (!place_meeting(x+sign(hspd), y, obj_platform)){ x += sign(hspd); } hspd = 0; } x += hspd; // jumping if (iJump){ if (place_meeting(x,y+1, obj_platform)){ vspd=-jump_impulse; } } //vertical collision and movment if (place_meeting(x,y+vspd, obj_platform)){ while (!place_meeting(x, y+sign(vspd), obj_platform)){ y += sign(vspd); } grav = 0.1; vspd = 0; } y += vspd; dla obj_platform create /// @desc Random sprite sprite_index = choose(spr_platform_small, spr_platform_medium, spr_platform_large); vspd = 1; step //platform movement y-= vspd; // colission with player if(place_meeting(x,y-1, obj_player)){ while (!place_meeting(x, y-sign(vspd), obj_player)){ obj_player.vspd -= sign(vspd); } obj_player.vspd = vspd; } Ten kod dla obj_platform jest bez sensu, ale to z ostatniej wersji. Kombinowałem różne warianty, ale nie mam już na to pomysłu i testuje jak leci.

dodałem ,a co tam i tak mnie to nic nie kosztuje

Wojzax, jak robisz model pod subsurface subdivision, to unikaj trójkątów i ngoenów. W paru miejscach można bardzo łatwo pousuwać krawędzie tak, że powstanie Ci w tym miejscu quad. Nie wiem ile siedzisz w 3d, ale jak dla mnie to dobry początek. Parę poprawek tu i uwdzie i będzie supcio.

Po cieniowaniu widzę, że tam jest od cholery goemetrii i topologia siatki jest taka, że nie nadaję się do animacji. Przy takim typie gry, gdzie postacie są dość w oddali, można by zmniejszyć ilość trójkątów drastycznie, a model nic by na tym nie stracił. https://polycount.com/ polecam zajrzeć na to forum, poprzeglądać wątki, samemu tam wstawiać modele i czytać komentarze użytkowników. Forum o tematyce low poly. Tak jak w programowaniu ważna jest optymilizacja kodu, tak w tworzeniu grafiki do gier, jest ważna optymilizacja pod tym kątem.

Ta jaszczurobaba, to model który jest użyty bezpośrdednio w grze? Jeśli tak, to trochę średnio się nadaje, w sumie wcale się nie nadaje. Nie wiem jakie masz doświadczenie w modelowaniu, ale bezpośrednich sculptów nie używa się w grach, choć to coś wyglądal jak baza pod sculpt. Badzo straszna nieoszczędność w geometrii i beznadziejna siatka do animacji. Nie hejtuje, ale trochę siedzię w 3d i ten model za bardzo do niczego się nie nadaje.

Tylko wyjaśniłem o co autorowi chodziło, bo dyskusja zeszła na temat tłumaczeń nazw popularnych programów, a "problemem" było całkiem co innego. Temat trochę wyczerpany, to może pogadamy o ikonie programu?

Przeczytaj to co napisałem wcześniej. Nie chodzi znaczenie nazwy, a o jedno małe słowo, które wykorzystywane jest zawsze przy amatorskich programach.

Jako użytkownik Game makera miej to w pompie, kto co myśli o twoim narzędziu. Używasz odpowiedniego narzędzie do wykonania danej pracy. Ludzie mają różne preferencje i nie ważne w czym się tworzy. Jak słuchasz muzyki, to Cię nie obchodzi na jakiej marce instrumentów została nagrana, jakiego DAWa użyto itd. Gracz gra w grę i obchodzi go sama gra. Jeden patrzy na grafę, drugi na fabułę a dla kogoś innego liczy się tylko sam gameplay. Co do petycji, to według mnie bez sensu. YoYo widocznie zrobiło sobie jakieś rozeznanie w tym temacie i doszli do wniosku, że jednak zmiana nazwy przyniosłaby więcej szkód niż pożytku. Może taki jest cel by właśnie przyciągać tych dzieciaków, którzy boją się tknąć Unity, bo za skomplikowane itd. Biznes to biznes i firmy zawsze działają tak by wychodzić na tym najlepiej. Blender w grafice 3d też się kojarzy z darmowym prostym narzędziem dla biedaków, a ja kilka lat tematu przeszedłem z 3dsmaxa do Blendera i mam gdzieś opinie innych ludzi. Jeśli masz jasno postawione cele, to bierzesz odpowiednie narzędzie i z niego korzystasz, a komentarze innych ludzi ignorujesz. Jedni tworzą wojny w stylu C++ vs Java, Xbox vs Playstation, a reszta ma to gdzieś.

Argument z Fruity loopsem jest z dupy. Żeby to miało sens to musiałbyś porównać Game makera do Music makera. Większość programów ze słowem maker, to zabawki dla dzieciaków, w których nie da się nic porządnego zrobić i o to się rozchodzi. Fruity loops to taka sama nazwa jak Reaper, Pro tools, Reason itd. Widzę, że większość osób nie rozumie w czym cały problem. Nie chodzi o głupią nazwę per se, tylko o skojarzenia. Oczywiście nazwa ma akurat najmniejsze znaczenie jeśli chodzi o jakość produktu, ale rozumiem, o co chodziło autorowi.

Jestem trochę nowy w tych sprawach i ciekawi mnie pewna sprawa. Wcześniej tworzyłem gry z użyciem produktów "Click Team'u" i tam cały kod tworzyło się w tzw. event editorze. Kod był zczytywany od góry do dołu. W GM pewnie jest tak samo, ale jak mam rozumieć czytanie kodu z różnych obiektów? Mam kod wewnątrz danego obiektu i on jest zczytywany od pierwszej linijki do ostatniej, ale w roomie mam wiele obiektów, a wątpię by kod był czytany równolegle. Czy kolejność wstawiania obiektów do rooma ma znaczenie?

gnysek, królu złoty, niech Ci bóg w dzieciach wynagrodzi :). Zamiast keyboard_check_pressed(vk_space) miałem keyboard_check(vk_space)

Jako początkujący użytkownik game makera przerabiam sobie różne tutoriale i sprawdzam różne możliwości napisania danego kodu. Oglądałem ostatnio takie jeden tutorial i na jego podstawie napisałem kod, który jednak nie działa tak jak trzeba. Kod: hit = instance_place(x,y, obj_enemy) if(hit != noone){ instance_destroy(); hit.hp-=1; } To zdarzenie powoduje, że zamiast jednego punktu życia wrogowi zostaje odebrane dużo więcej, tak jakby obiekt nie został od razu niszczony podczas kontaktu z wrogiem, tylko trwał trochę dużej, zabierał cały czas życie i znikał później. Pewnie to jakaś błahostka, ale w tutorialu nic więcej się w kodzie nie pojawiało co mogłoby naprawić ten problem. Patrząc na debugera, to za każdym razem inna ilość życia jest zabierana. Przeciwnik ma ustawione hp = 5. Czasami jeden atak zabije wroga, a czasami zada 3 obrażenia.

Najechaliście na autora wątku, a koleś trochę racji ma. Oczywiście nie ma co się przejmować opiniami innych, bo nasz twór powinien sam się bronić i użyte narzędzie nie jest ważne. Sama nazwa "Game maker" jednak brzmi jak taka zabawka, która pozwoli każdemu stworzyć grę, nawet jak nie ma totalnego pojęcia o programowaniu. Game maker, rpg maker, music maker, fps maker, ten dodatek "maker" zawsze kojarzy się z programami dla dzieciaków a nie profesjoanlistów. Proste w użyciu, ale ograniczone w możliwościach. Mniej się przejmować, więcej czasu przeznaczyć na tworzenie i przestać zamartwiać się opiniami innych.