Skocz do zawartości

Muuuuczek567

Użytkownicy
  • Postów

    1 472
  • Dołączył

  • Ostatnia wizyta

Treść opublikowana przez Muuuuczek567

  1. mp_grid korzysta właśnie z algorytmu A*. Jest to jeden z szybszych algorytmów wyszukiwania ścieżek. Znajduje też zastosowanie w izometrii, jako że to jest tak samo dwuwymiarowa mapa, tylko pokazana w innym rzucie. @karolo320: zacina się, gdy postać wyjdzie poza obszar siatki algorytmu A*.
  2. No, Bedziom, idź zażyć swoje tabletki przed snem. Ja zaczynałem od układania prostych gierek z klocków. Od najbanalniejszych ("Catch the Clown"), do ambitnych(strzelanka 4-kierunkowa, w której granaty rzucało się garściami o.O). Potem znalazłem program "Action Decoder" (jest w dziale Download), który przetłumacza klocki na kod, to mi bardzo ułatwiło przejście na samo pisanie skryptów, już bez klocków. W międzyczasie doszkalałem się, czytając dokumentację. Najlepiej przeczytać dwa pierwsze działy o GML-u, później można kształcić się na bieżąco. Tutoriale i samouczki nie są aż tak bardzo potrzebne, jeżeli masz rozwiniętą zdolność logicznego myślenia. Większość mojej wiedzy zdobyłem, samemu sprawdzając różne funkcje i skrypty (jest tego przeszło 300 projektów!). Mogę powiedzieć, że całkiem nieźle znam się na GML-u. Jeśli jednak nie wiesz kompletnie, od czego zacząć, proponuję przestudiować tutoriale z tej strony: http://sandbox.yoyogames.com/make/tutorials (o ile znasz dobrze język angielski, zawsze też przychodzi z pomocą Google Tłumacz ;)).
  3. Mimo iż nie mam konta na Dropboksie, jestem za. Na dłuższą metę to dość korzystne.
  4. Ja zawsze w platformówkach robiłem tak, że bohater ma "y" platformy, na której stoi minus wysokość sprite'a bohatera. Tylko jeden collision_point w Stepie. Zero place_meeting. Oczywiście działa tylko z poziomymi platformami.
  5. Pewnie. Dzięki temu można zrobić mnóstwo zapętlonych alarmów używając jednej zmiennej.
  6. Ech... To nic nie da. Zastanów się, dlaczego.
  7. Ewentualnie możesz zrobić zmienną globalną global.time i co step zwiększać jej wartość o 1. Wtedy kod wyglądałby tak: Step GML if(global.time mod 5) {/*kod*/}
  8. Klękaj i proś o rękę (-1 more to go!) Jeśli prosisz kogoś o rady odnośnie podrywania, to daleko nie zajedziesz. Wysil się i wymyśl coś oryginalnego; skoro jest miła i inteligentna, to na pewno to doceni. @IamTheLaw: :twisted: EDIT: o.O ok, można z tego już zrobić temat filozoficzny
  9. Hmm... ...no więc najprawdopodobniej będzie to coś w stylu Wormsów. Silnik gry pozwala na płynną grę ok. 160 graczy (zależne od sprzętu, u mnie jest ok. 80), można już robić drużyny, mapa będzie mogła mieć rozmiary od 64x64 do 512x152, być może w terenie będą poukrywane skrzynki z niespodzianką (nowy sprzęt, uzdrowienie, eksplozja itd.), prawdopodobnie wieżyczki nie będą wieżyczkami i będą się poruszać. Możliwe tryby gry: Deathmatch, TeamDeathmatch, Capture The Flag, Domination i inne (ograniczeniem jest inwencja). Na pewno będzie multiplayer na jednym komputerze, gracz vs. gracz, gracz vs. AI i kombinacje zależne od ilości drużyn. Nie wiem, czy zdołam zrobić multi przez internet... ale do tej fazy projektu długa droga. No i kolorystykę gry i terenu będzie można zmienić. Teraz zajmę się robieniem interfejsu, bo nie mam broni do testowania. Byłoby fajnie, gdybym po ponownym zajrzeniu do tematu mógł wybierać spośród co najmniej kilkunastu broni. : )
  10. Ja kiedyś skasowałem cały projekt, bo nie mogłem znaleźć sposobu, żeby się odwołać do obiektu. Dopiero później przeczytałem w dokumentacji o "id" : o A jeszcze później - że w konstrukcji "with" można odwoływać się do obiektu przy pomocy "other" : O
  11. Terrain Drillers (strategia o nieokreślonej jeszcze mechanice) Póki co jedynie demo technologiczne. Sprawa na ten moment wygląda tak: stawiasz wieżę (PPM) na mapie 512x512 i strzelasz (LPM), używając dostępnych broni ([spacja]; po zmianie broni musisz postawić nową wieżyczkę). Kamerą poruszasz strzałkami. Jest jednak kilka rzeczy, o ktorych trzeba wspomnieć: 1. Choć wydaje się, że 512x512 to mało, w rzeczywistości jest to bardzo dużo. Mapa (generowana przy rozpoczęciu gry, co zajmuje ok. 8-10 sekund) zostaje bowiem powiększona szesnastukrotnie w każdą stronę. 2. Mapa w grze jest trójwymiarowa, ale wyświetlana w dwóch wymiarach (top-down). Każda komórka ma swoją wysokość (na ekranie: im jaśniej, tym wyżej). Kąt strzelania zmieniasz kółkiem myszki. 3. Cały teren gry jest niszczalny (dopóki całkiem "nie sczernieje"). Na razie nie ma to zastosowania, ale w poźniejszych etapach produkcji będzie miało - i to bardzo duże. 4. Każda broń w grze jest w pełni edytowalna. Można już teraz bez problemu stworzyć własną broń i siać nią śmierć i zniszczenie. Wystarczy jedynie przeanalizować przykłady broni w folderze i przeczytać plik "ReadMe.txt". I tutaj główny powód, dla którego zamieszczam to demo: apel do Was. Wykażcie się inwencją i stwórzcie jak najwięcej jak najdziwaczniejszych, jak najróżniejszych i jak najfajniejszych broni! Wykażcie się pomysłowością i piszcie w komentarzach jak najwięcej pomysłów, jak wzbogacić mechanizmy gry. To od Was zależy, czy ten obiecujący projekt będzie kontynuowany! Autorzy: Programowanie: ja (Muuuuczek567) Fabuła: brak Grafika: jeśli grafiką można nazwać wygląd wieżyczki, to ja (Muuuuczek567) Muzyka: póki co brak Screeny (niewiele się różnią, bo tak naprawdę nie ma dużo do pokazywanie pod względem grafiki): Link: tu (1.32 MB)
  12. Muuuuczek567

    Matematyka.

    wow Sam egzamin nie będzie aż tak trudny. Będą po prostu zadania wielokrotnego wyboru, a w humanistycznym trzeba będzie wykazać się pamięcią. ostatnio sporo powtórzeń w moich postach
  13. Zastanawia mnie dlaczego, mimo dwóch projektów z Twojej sygnatury, zaczynasz robić kolejny.
  14. Muuuuczek567

    Galeria Grafik

    Też się zgadzam, że skrzydła są trochę za mało szczegółowe. Zauważyłem tylko, że słowo "detaliczny" w odniesieniu do szczegółów jest już przestarzałe. A odpowiedź "nie" była w odniesieniu do pierwszego znaczenia. Hełm jest znakomity! Ile czasu go robiłeś?
  15. @alwin: uuu... Ten "Perlin noise" na jednej oktawie tworzy się w 1563 ms, mój na pięciu - w 1344 ms. Tamten na pięciu oktawach - w 2640 ms, mój na jednej - w 33 ms. Słabo...
  16. Chodzi o definicję okręgu? Czy o co?
  17. Event Animation End: GML if sprite_index = animacja_ataku sprite_index = chodzenie
  18. Byłoby miło :rolleyes: W C++ będzie dużo szybciej generować szum niż w GM, więc przyda się bardziej. Znalazłem na YoYo przykład korzystający praktycznie z tego samego kodu do generowania szumu, co mój. Co ciekawe, ponoć jest to 'Perlin noise', co jest bzdurą. Co jeszcze ciekawsze, ponoć bardzo szybko to działa. Biorąc pod uwagę, że kod jest prawie identyczny do mojego, też jest to bzdura.
  19. @kt1117: coś w tym stylu. Możesz przeczytać więcej na różnych stronach (głównie po angielsku). @Sernat: widocznie źle cię zrozumiałem; myślałem, że masz na myśli, żeby kształty w tym szumie coś przypominały, np. litery, figury itp. To oczywiste, że ogólna struktura takiego szumu powinna być jednolita (żadnych przeskoków z niskich do wysokich wartości i vice versa).
  20. @TheMarcQ: takie losowe piksele nie będą przypominały chmur, nie przydadzą się przy robieniu map wysokości itp. @Sernat: Nikt nie jest idealny : (
  21. @TheMarcQ: 1. to nie jest 'Perlin noise' 2. nie wiem, czy jakikolwiek algorytm wykonałby w GM-ie generowanie dobrej jakości szumu w czasie rzeczywistym. @Sernat: Już nie będę :3 Tzn. jeśli Cię uraziłem, to od razu mówię, że nie chciałem. Ale to już nie byłby przykład 'value noise', ale 'jak namalować różne piksele na surface'u'. No trochę tak. Mnie jednak wystarczyło, żeby wykonać przykład. Można się spierać, czy to, co zrobiłem, można uznać za generowanie proceduralne (w końcu surface'y przechowywane są w pamięci), ale być może komuś się przyda.
  22. Hmm... Jeśli znasz algorytm do generowania szumów, który będzie w GM-ie szybszy (lub lepiej - napiszesz jego implementację), to tutaj napisz. Jestem bardzo ciekaw. (poważnie : D) Być może pominąłeś fakt, iż YXE wspominał coś o tym, że do generowania terenu na konkurs może być przydatny 'Perlin noise'. Choć to też niewiele świadczy. Rzeczywiście. Szum musi mieć "regularne i logiczne kształty" ; ) To zależy od parametrów i od funkcji losującej. E: zbadałem złożoność obliczeniową tego szumu. Liczba zamalowań pikseli wynosi: p1^2*((4^n-1)/3), gdzie: p1 - to długość boku pierwszego surface'a; w przykładzie równy 8 n - liczba oktaw - w tym przypadku 5 W przykładzie wykonuje się 21824 zamalowań pikseli, a największy surface ma ich 16384.
×
×
  • Dodaj nową pozycję...