Pental Stary

Ghost chyba spanikował :D . Ogólnie ciężko jest znaleźć na to sposób. @Kofel: Sprecyzuj.

Tylko PsichiX mały skok może tak zepsuć rozgrywkę :/ . Ogólnie lipa lekka.

To, co robiłeś było na poziomie "mniejszym niż zero", a ty taki skok do góry zrobiłeś :) . Jak dla mnie super, choć jest wiele niedociągnięć. 5 / 5 za postęp.

Właśnie przygotowuję rekwizyty.

Logiczne myślenie. A skąd ja mam wiedzieć? Może bohater zmienia kierunek jak naciśnie strzałkę, może jak włączymy grę, a może jak zdobędziemy dwa punkty? Wiele warunków zastąpimy eventami.

Nikas style.

To jest oczywiste, ale WM wzoruje się na SP, więc warto. Jak dla mnie SUPER. Kontynuuj!

Au! To najgorsze co może być! Wolę mieć laga, niż mieć kompletnie inny obraz gry niż inny gracz i psuć rozgrywkę :o .

Tak, ale co wtedy, gdy ping jest ogromny i dane dotrą za późno? Czy to będzie po prostu tzw. "lag", czy zmieni nieco postać rzeczy?

A Event to co? Przecie klocków z kodem mieszać się nie da, on na pewno korzysta z eventów - i słusznie.

Bo musiałeś taką głupotę napisać. Warto robić na klockach, jeśli są dla nas czytelniejsze i prostsze. I to mówię ja, ktoś, kto już ich nie używa. A to co napisałeś ori to głupota. Bo jeśli image_xscale wynosi -1, to zmieni się znów na -1, zamiast na 1. Powinno być: image_xscale *= -1. I lepiej już sobie daruj odpowiadanie na mój post, bo się spam zaczyna robić.

Tak, jest to klocek z pacmanem i dwoma strzałkami. Wystarczy w polu image_xscale wpisać image_xcale * -1 i odznaczyć relative.

Można łatwiej: image_xscale *= -1;

Co? Dawidsie, najbardziej prymitywny sposób dałeś, jaki istnieje. Nie dość, że w formie kodu, to jeszcze warunku używasz. Nie rób zbędnej dyskusji.

Generalnie sprawa wygląda całkiem prosto. Wszystkie jednak dane tu przykłady nie uwzględniają wypadku, że pozycja ekranu dojdzie w końcu do liczby uciekającej nieco od pierwotnej wersji. Powinno to wyglądać mniej więcej tak: GML sx = view_xview; sy = view_yview; To, gdy zaczyna się wariowanie. Podczas jego trwania: GML view_xview = sx + random( rozrzut ) - random( rozrzut ); view_yview = sy + random( rozrzut ) - random( rozrzut ); rozrzut += 1; // mozna wywalic A po zakończeniu: GML view_xview = sx; view_yview = sy; Wynik możesz oczywiście zaokrąglić funkcją round(), by uniknąć niechcianych "zamazanych pikselków". To tyle. Przykład: https://gmclan.org/up4218_11_example.html

Ogólnie pomysł dziwny, ale może zaistnieć sytuacja, kiedy będzie to konieczne.

Dokładnie, można jednak wykorzystać jego nieobecność. Ale powtórzę: metoda prób i błędów drogą do sukcesu :) .

Nie zrozumiałeś mnie, napiszę jeszcze raz. Mu chodzi nie o ścieżkę względną, lecz o to, że pliki są poza folderem z grą. Lokacja gry nie jest nigdy pewna, zaś ogólne drzewo tak. Wiemy, że plik jest przykładowo dwa foldery "do tyłu", więc piszemy: working_directory + '..\..\image.png' Koniec tematu, kropka.

Możesz tworzyć gry 3D oraz używać wielu bardzo przydatnych, wręcz niezbędnych funkcji ;) .

Przykład w porządku, jednak to tylko zwykłe skalowanie grafik. Powstrzymam się z oceną ;) .

OriPL, klocki są tak samo czytelne jak kod i ich używanie nie jest zabronione. Gdyby ich nie używano, to by je ostatecznie wyrzucono z GMa, a ten program straciłby zapewne swój potencjał.

Są dwie drogi: 1. Używasz klocka z napisem "var" (skrót od variable - zmienna) i wpisujesz w polu value image_xscale * -1, a w polu variable naszą zmienną, czyli image_xscale. 2. Drugi sposób to sprawdzanie klockiem z napisem "var", ile wynosi image_scale i na podstawie tejże informacji zmieniać kierunek sprite'a powyższym sposobem, lub też używając klocka z takim pacmanem i dwoma strzałkami. Osobiście polecam prostszy sposób, czyli pierwszy. Dlaczego image_xscale * -1? 1 - normalny sprite -1 - odwrócony 1 * -1 daje nam -1 -1 * -1 daje nam z kolei 1 Więc owe działanie ma sens :) .