Amaterasu

Możesz korzystać z window_mouse_get_x/y()*, niezależnie od zooma zwróci pozycję myszy w osi X/Y relatywnie do lewego górnego rogu okna gry, nie do pozycji (0,0) w samej grze. *albo window_get_mouse_x/y(), nie pamiętam

&& to operator logiczny AND, jeżeli wyrażenia po lewej i po prawej stronie operatora są oba prawdziwe, wynik działania operatora również jest prawdziwy; w przeciwnym wypadku operator zwraca fałsz. xx i yy to zapewne zmienne, nazwane tak przez autora przykładu z braku pomysłu na lepszą nazwę. Wyrażenie "!x += 10" nie ma sensu (przynajmniej w GML), chyba że to jest jakiś obskurny kod...

pamiętam, jak się bawiłem pivotem, próbowałem nawet robić animacje 3D żeby zaimponować kuzynom

Gdybym miał na czym, to bym zagrał : / W każdym razie, wtłocz trochę życia w ten licznik, żeby tapnięcie nie dodawało punktów od razu, tylko w przeciągu, ja wiem, 0.5s, będzie lepiej wyglądało.

Na filmiku zaczyna się od 6973099 ...to nie licznik?

Co ma licznik do generacji punktów? Każde tapnięcie daje ilość punktów proporcjonalną do wyniku? Bo chyba niezbyt rozumiem.

Wiesz, gdy masz 5000 obiektów "blok", to nawet jeżeli dezaktywujesz te, które są poza viewem, to trzeba się zastanowić: jak GM robi, że obiekty poza viewem są dezaktywowane? Do tego są różne metody (brute force, BSP itp.), ale niezależnie od metody, wewnętrzny czas potrzebny na wykonanie akcji na N obiektach (np. dezaktywacja lub aktywacja) rośnie wraz ze wzrostem N. Teraz, jeżeli pomnożysz czas wykonania tej akcji przez ilość klatek na sekundę, dostaniesz coś w stylu f(N)*room_speed akcji na sekundę (f(N) zależy od metody, którą stosuje GM). Dla N=5000, f(N)=200log2(N) (dla BSP, optymistyczne założenie, 200 może być inną wartością zależnie od szybkości metody) i room_speed=30 dostajesz coś w stylu 72000 akcji na sekundę, każda zabiera ileś cykli procesora. Nie ma nic za darmo. Gdyby dało się zrobić tak, że aktywacja/dezaktywacja obiektów następowała tylko wtedy, gdy jest to absolutnie konieczne, gra mocno by przyspieszyła. A da się.

instance_activate_object(chunk) aktywuje wszystkie obiekty o nazwie chunk, użyj po instance_deactivate_all() Tyle że gdy w końcu dojdziesz do momentu, gdy w grze masz 1000 chunków, to gra i tak zacznie zamulać

GM jest przeznaczony głównie do gier 2D. Jego funkcjonalność 3D jest znikoma (T&L, brak możliwości importu popularnych formatów modeli 3D). Żeby zrobić w miarę wyglądającą grę 3D w GM, trzeba się narobić mocniej niż żeby zrobić w miarę wyglądającą grę 2D. Poza tym, zasady robienia gier w 3D są takie same, co w 2D. Dokumentacja opisuje dokładnie, jak wygląda przejście z grafiki 2D do 3D w sekcji z rysowaniem na ekranie.

Ten licznik punktów powinien zię zaczynać od zera, zwiększ generację punktów dziesięciokrotnie i zrób, żeby licznik się zmieniał ciągle, a nie żeby wartości skakały, bo to brzydko wygląda (nie żeby gra wyglądała lepiej, ale daj chociaż graczowi poczuć/zobaczyć, że cyferki rosną) stoczyłeś się karolo

Tak też można, po dwóch minutach trzeba byłoby już zacząć walczyć

No właśnie, optymalną strategią jest kryć się, gdy ma się więcej HP niż przeciwnik. Ale w sumie tak jest też w innych grach na czas (piłka nożna, koszykówka itp.) Może gdyby lustra dało się tymczasowo niszczyć, lub gdyby same się losowo dezaktywowały na jakiś czas...

Zapisałem już wszystko w komentarzu w projekcie : P GML //po dwoch minutach pola silowe znikaja //po trzech minutach lustra kopiują się i idą w przeciwnych kierunkach //po czterech minutach boty traca tarcze i przestaja ja regenerowac //po pieciu minutach boty zaczynaja tracic 6 hp/sek //po czterech sekundach od ostatniego trafienia boty zaczynaja regenerowac tarcze //regeneruja ja calkowicie po 0.5 sek</span> Wszystko jest całkowicie deterministyczne. Jedyne losowe efekty w grze to: -efekty cząsteczkowe -czas między tworzeniem kolejnych bonusów -typ bonusu

Po pięciu minutach boty tracą 6 hp na sekundę - pierwszy, który zginie, przegrywa Ciekawe co będzie, jeśli boty zginą jednocześnie...