Skocz do zawartości

Amaterasu

Użytkownicy
  • Zawartość

    390
  • Rejestracja

  • Ostatnia wizyta

Zawartość dodana przez Amaterasu

  1. Skalowanie obiektów

    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. Temat zbiorczy na drobnostki

    && 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. Galeria Grafik

    pamiętam, jak się bawiłem pivotem, próbowałem nawet robić animacje 3D żeby zaimponować kuzynom
  4. Banana Massager [GooglePlay wow]

    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. Banana Massager [GooglePlay wow]

    Na filmiku zaczyna się od 6973099 ...to nie licznik?
  6. Banana Massager [GooglePlay wow]

    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. gra 2d/3d

    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. Banana Massager [GooglePlay wow]

    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. Epizod 2 - 1vs1

    Tak też można, po dwóch minutach trzeba byłoby już zacząć walczyć
  12. 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. 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. 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. 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. Łączenie room'ów w jeden (nieskończona mapa)

    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. Łączenie room'ów w jeden (nieskończona mapa)

    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. Łączenie room'ów w jeden (nieskończona mapa)

    Te roomy mają być łączone bezszwowo (jak w Minecrafcie), czy mają to być oddzielne pomieszczenia (Binding of Isaac)?
  19. [EP2]Walki robotów - Dyskusja

    Gdziewalkirobotów
  20. Wchodzenie pod górkę

    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ą?
  21. Generatory to potężne narzędzia, pozwalające na ułatwienie życia designerowi (do pewnego stopnia - projektant musi zdecydować, jak dane obiekty mają być generowane). Ten generator ma za zadanie stworzyć, na podstawie zdefiniowanych przez użytkownika parametrów, coś na kształt poziomu do gry. Wychodzi mu to nieźle, wg mnie, więc szkoda by było, gdybym się tym z nikim nie podzielił. Zatem, proszę. LINK Generator ma następujące opcje: a ) Modyfikacja metody działania algorytmu generowania pierwotnego szumu Zanim wyjaśnię, przejrzyjcie artykuł o zastosowanym algorytmie generowania szumu. Iteration flags oznacza, które iteracje zostaną wykonane - tzn. dla liczby 27 (011011) zostaną wykonane iteracje 1, 2, 4, 5 - to spowoduje, że szum będzie miększy, a mapa - bardziej gładka. Im większa mapa, tym więcej iteracji - ilość iteracji rośnie logarytmicznie do większego z rozmiarów mapy (dla mapy 80x64 log2(80)=6.32<=7, zatem zostanie wykonanych 7 iteracji). Iteration amplification start pokazuje, jak duży wpływ będzie miała pierwsza iteracja, a iteration amplification speed - jak duży wpływ będą miały kolejne iteracje. b ) Tworzenie losowych bąbli Bąble można sobie wyobrazić jako łagodne pagórki (lub strome, zależnie od blob intensity). Można regulować ich liczbę (blob number) i ich rozmiar (blob radius - promień każdego bąbla mieści się w przedziale od blob_radius/2 do blob_radius). c ) Tworzenie pierścienia Pierścień powoduje stworzenie doliny lub wzniesienia na środku. Zależnie od ring radius, pierścień będzie obejmował całą mapę (1), nic (0), lub pewien fragment (wartości pośrednie). Wysoki ring inner intensity stworzy wzniesienie, a wysoki ring outer intensity - dolinę. Uwaga - liczy się różnica między ring inner a ring outer, nie ich absolutne wartości. d ) Tworzenie linii (korytarzy) Linie można sobie wyobrażać jako coś na kształt bruzdy - im większe line intensity, tym większa szansa, że w tym miejscu będzie podłoga. Można modyfikować ilość linii (line number) i ich szerokość (line width). e ) Tworzenie ściany zewnętrznej Ściana zewnętrzna to użyteczny modyfikator, który zamyka teren naokoło mapy. Od border intensity zależy, jak duże szanse są na powstanie ściany, a od border inner edge i border outer edge zależy grubość ściany. (UWAGA: w tej chwili jest bug powodujący, że zmiana outer edge nie działa tak, jak powinna - niewielki problem, bo i tak zwykle jest na wartości 1, ale na razie nie zmieniać) f ) Zmiana wielkości mapy Niby nic, a cieszy. g ) Modyfikacja progu tworzenia ścian Dzięki tej opcji, niezależnie od jakości szumu, powstała mapa zawsze będzie zawierała zdefiniowany przez bias floor percentage procent pól będących podłogą (bierze pod uwagę jedynie szum, modyfikacja mapy może spowodować, że mniejszy procent pól będzie podłogą). Bias randomization to parametr definiujący, jak mocno krawędzie ścian będą poszarpane (zależnie od kontrastu szumu, ten parametr powinien być mały lub całkiem spory - domyśnie 0). h ) Usuwanie dziur w ścianach Ustawienie holes removal na Y spowoduje, że zostaną zlikwidowane wszystkie dziury, których wielkość jest nie większa niż holes minimum size. Dla algorytmu dziurą jest każde pole, które jest podłogą, a rozmiarem dziury - ilość wszystkich pól, do których można dotrzeć z danego pola bez przechodzenia przez ściany. (Holes diagonal check oznacza, że pola, które sąsiadują z dziurą jedynie po przekątnej również są dołączane do dziury) Pozostałe opcje są jedynie pomocnicze: Generate from current noise wczytuje ponownie mapę z wygenerowanego wcześniej szumu, wykorzystując parametry z punktów g) i h) Save/Load preset pozwala na zapisanie/wczytanie ustawień modyfikowanych w programie, aby móc z nich generować własne mapy Save map zapisuje mapę do pliku, jeżeli masz chęć wykorzystać wygenerowaną mapę w swojej grze. Odczyt wykonuje się za pomocą funkcji file_to_map, znajdującej się w projekcie. Ściana to 0, podłoga to 1. Mapa jest wczytana do ds_grid. Sterowanie: Spacja - generuj nową mapę Shift - przełączaj pomiędzy widokiem minimapy (noise/map) Ctrl - przełączaj pomiędzy trybem interfejsu (pre-processing, post-processing) Strzałki - zmiana pozycji widoku To chyba tyle póki co. Projekt jest w wersji 1.0, na razie nie mam ochoty tego ulepszać : P
  22. 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
  23. 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ę.
  24. Zapis stanu pokoju

    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.
×