Skocz do zawartości

Amaterasu

Użytkownicy
  • Postów

    390
  • Dołączył

  • Ostatnia wizyta

Treść opublikowana przez Amaterasu

  1. 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
  2. && 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...
  3. Amaterasu

    Galeria Grafik

    pamiętam, jak się bawiłem pivotem, próbowałem nawet robić animacje 3D żeby zaimponować kuzynom
  4. 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.
  5. Na filmiku zaczyna się od 6973099 ...to nie licznik?
  6. Co ma licznik do generacji punktów? Każde tapnięcie daje ilość punktów proporcjonalną do wyniku? Bo chyba niezbyt rozumiem.
  7. 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ę.
  8. 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ć
  9. 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.
  10. 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
  11. Amaterasu

    Epizod 2 - 1vs1

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

    Epizod 2 - 1vs1

    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...
  13. Amaterasu

    Epizod 2 - 1vs1

    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
  14. Amaterasu

    Epizod 2 - 1vs1

    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...
  15. Amaterasu

    Epizod 2 - 1vs1

    Przydałoby się dodać jakiś HUD, żeby było widać ile HP i tarczy ma każdy z botów, ale to już przy robieniu z tego filmu raczej
  16. Z roomu 1 do roomu 2 nie przechodzi się gładko. Przy każdym przejściu do kolejnego roomu usuwane są obiekty z roomu 1 (o ile room 1 nie jest persistent), tworzone są obiekty z roomu 2 (o ile wcześniej w nim nie byłeś i nie ma zaznaczonego persistent), wszystkie te operacje kosztują trochę procesora. W dodatku, do danych obiektów z roomu 2 nie masz żadnego dostępu, jeżeli jesteś w roomie 1. Rozszerzanie roomów jest możliwe, ale jak dokumentacja wskazuje: zatem żeby zmienić szerokość danego roomu, nie może być to room aktywny. Te limity są kompletnie bez sensu, gdy ma się do czynienia z grami proceduralnymi z otwartym światem (jak ta, którą chcesz zrobić). Dlatego, aby zrobić taką grę proceduralną, należy odejść od koncepcji roomów. (tzn. nie mówię, że kompletnie się nie da tego zrobić, ale trzeba się bardzo, bardzo natrudzić - taki to urok proceduralnego generowania)
  17. Prosisz o coś trudnego do zaimplementowania, zwłaszcza w GameMakerze. Na początek powinieneś wiedzieć, jak zrobić coś takiego w ograniczonej przestrzeni. Z tego co rozumiem, chcesz wersję w 2D. Przeczytaj najpierw uważnie ten artykuł o Perlin Noise. Tam jest zastosowana siatka 64x64, ale taka sama zasada jest dla siatki 64x1 (w praktycznym sensie: zwykła tablica jednowymiarowa*) i taką też siatkę sobie przyjmiemy. Perlin Noise to obrazek utworzony przez nałożenie na siebie n oktaw (w artykule to te sześć czarno-niebieskich rozmytych obrazków). Przyjmiemy n=5. Z natury ograniczenia rozmiaru obrazka, sam obrazek nie jest nieskończony. Można natomiast, korzystając z danych nt powstałych oktaw, otrzymać bezszwowe połączenie do następnego obrazka 64x1. Metoda działa następująco: 1) Tworzysz pierwszy obrazek: 1-) Ustawiasz set_texture_interpolation(1) (czy jakoś tak) 1a) Tworzysz surface 64x1 (S) 1b) Tworzysz pięć oktaw (O1-O5) o rozmiarach odpowiednio (możesz w pętli): 4x1, 8x1, 16x1, 32x1, 64x1. Każda oktawa to osobny surface - najpierw zamalowujesz go na czarno, a następnie zamalowujesz go białymi pikselami, przy czym dla każdego piksela ustawiasz losową alphę z zakresu od 0 do X (proponuję za X ustawić 0.4) 1c) Rysujesz każdą z oktaw O1-O5 na S, przy czym: -blending podczas rysowania musi być ustawiony na bm_add (funkcją draw_set_blend_mode) -każda z oktaw musi być rozciągnięta na całym S (użyj draw_surface_stretched) -po skończeniu rysowania oktaw, ustawiasz blending na bm_normal 1-) Ustawiasz set_texture_interpolation(0) 2) Kiedy tylko chcesz wygenerować sąsiedni chunk, musisz wykonać następujące kroki: 2a) Tworzysz nowy surface 64x1 (Snew) 2b) Tworzysz nowe pięć oktaw (Onew1-Onew5), tak jak wyżej 2c) (NAJWAŻNIEJSZE) Ustawiasz brzegowe piksele oktaw, aby ładnie się zszywały z sąsiednim chunkiem. Ten krok zależy od tego, po której stronie nowego chunka leży sąsiedni chunk: -Jeżeli po lewej: Pierwszy piksel (od lewej) każdej z nowej oktawy jest ostatnim pikselem (czyli od prawej) każdej oktawy sąsiada -Jeżeli po prawej: Ostatni piksel (od prawej) każdej z nowej oktawy jest pierwszym pikselem (czyli od lewej) każdej oktawy sąsiada 2d) jest jak 1c), ale z nowymi surface'ami. To jest pierwsza część. Jest jeszcze dużo do zrobienia, ale to wyżej to właściwie całe generowanie terenu. Jeżeli załapałeś, daj znać, bo nie wiem, czy mam dalej tłumaczyć. PS. Mam coś podobnego, ale dla obrazków NxN. Większość kodu to tworzenie grywalnej mapy, ale jest tam, w środku gdzieś, generowanie Perlin Noise. *tablice w GM są do kitu, lepiej używać ds_list()
  18. Te roomy mają być łączone bezszwowo (jak w Minecrafcie), czy mają to być oddzielne pomieszczenia (Binding of Isaac)?
  19. Jak robiłem swój silnik fizyczny w C++, to na wektorach działało szybciej. Tyle że w C++ można zbudować klasy, do elementów których bezpośredni dostęp jest szybki. W GM struktury ds_ mają, w porównaniu, długi czas dostępu do zawartości - może się okazać, że metoda z wektorami i iloczynem skalarnym jest niewiele szybsza od metody z funkcjami trygonometrycznymi. Niezależnie natomiast od metody, trzeba by napisać własny quadtree w przypadku, gdy ma się zamiar kłaść dużo wielokątów. To jest nieciekawa sprawa, ciężko mi sobie wyobrazić kod w GML, który by za to odpowiadał. @Sheriff99, zostają dwie realistyczne opcje: 1) Metoda Sutikku jest najprostszą metodą i tę metodę polecam, nie widzę powodu, żeby budować wokół Twojego problemu jakiś niesamowity silnik fizyczny. 2) GM ma wbudowany silnik fizyczny, który robi praktycznie wszystko to, co jest na przykładzie Jakima, w dodatku w całości jest opisany w dokumentacji. Dla wymagających jest odpowiednią metodą. Jakim, nie bardzo rozumiem, co mają macierze do implementacji kolizji, chodzi o 3D? Bo ja robiłem to w 2D i nigdzie nie korzystałem z macierzy. A może chodzi o inne rzeczy związane z fizyką?
  20. Nowa wersja (oznaczmy ją 1.1), a w niej: -Dodane: opcja łączenia ze sobą dziur korytarzami o wybranej szerokości. Metoda póki co prymitywna - łączone są ze sobą środki dziur, co nie zawsze oznacza, że dziury zostaną połączone. -Dodane: preset small_closed_mountain (jak wam się poszczęści, to zobaczycie w nim problemy tej metody łączenia dziur) -Naprawione: błąd związany ze zmianą rozdzielczości mapy przed jej wygenerowaniem, co powodowało problemy z ponownym generowaniem mapy z istniejącego szumu -Naprawione: Opcja holes diagonal check nie pokazuje już swojej liczbowej wartości -Wczytanie starszych presetów nie wywoła błędów W planach: -Dodanie kompatybilności presetów -Ulepszenie metody łączenia dziur ze sobą -Dodanie pomieszczeń (na poziomie mapy) LINK
  21. No tak, ale nie bardzo rozumiem, czym, i gdzie, miałby być "środek planszy". Mój generator dla map o wymiarach nie będących tymi samymi potęgami dwójki bierze wycinek szumu z najmniejszego kwadratu większego od mapy, z samego środka, i dopiero na nim wykonuje wszystkie operacje. Chodzi o bounding box mapy? Takie coś też dałoby się zrobić, ale czy jest potrzeba? Zrobiłem już łączenie jaskiń, niedługo wystawię kolejną wersję.
  22. Zaznaczenie "Room persistent" (czy coś w tym stylu) w opcjach rooma spowoduje, że room pozostanie w swoim stanie po wyjściu aż do ponownego wejścia. Działa z game_save(). Rzecz w tym, że jeżeli masz: -struktury z przedrostkiem ds_ -buffery -surface -mp_gridy -ręcznie dodawane sprite'y i inne assety -sockety to game_save nie zapisze tych danych. W przeciwnym wypadku, wystarczy zaznaczyć "Room persistent" w opcjach rooma.
  23. Wiem na czym polega błąd. Zajmę się tym za chwilę, jak również łączeniem jaskiń. Czym miałoby być centrowanie mapy?
×
×
  • Dodaj nową pozycję...