Skocz do zawartości

Threef

Moderatorzy
  • Postów

    2 911
  • Dołączył

  • Ostatnia wizyta

  • Wygrane w rankingu

    14

Treść opublikowana przez Threef

  1. Spróbuj lepiej wytłumaczyć. Nie wiemy co siedzi w twojej głowie. Ja mogę spróbować namówić Cię na przerobienie twoich tablic. Zamiast robić osobne tablice do różnych rodzai bronie zrób jedną tablicę dla wszystkich broni. GML wpn[0,0]=1 wpn[0,3]="wand" //Albo najlepiej używaj intów wpn[0,2]=spr_stf2 wpn[0,1]='Grass Wand'
  2. Nie, nie, nie. Ogarnij to bo nie powinno być żadnych problemów. Ja ostatnio zrobiłem test z 10000 obiektów latających w 60FPS na Pentium 4. To musi działać.
  3. Wyłącz backgroundy i zobacz czy pomoże. Jak tak to pomyśl jak to zoptymalizować. ;)
  4. Dokładnie. Najmniej szkodliwy sposób to są cheaty (bo możesz je potem łatwo wyłączyć), ale możesz np.: edytować swoje mapy i ustawiać gracza w momencie który chcesz etc. Wygląda na to że nie pomyślałeś wcześniej o takiej potrzebie i teraz masz lekki problem. :)
  5. Dobra, to gdzie mam się ustawić w kolejkę do tego ssania?
  6. Zrób cokolwiek i podeślij komuś kto ma ten system? Jak nie zadziała to pomoże przesiadka na darmowe GM:S albo kompilowanie na Win7.
  7. To działa w inną stronę. Jeżeli skompilujesz grę na Win7 nawet w GM7 to będzie działać. Nie jestem pewien czy w GM8 już było to poprawione, ale to tak jakby gra wykożystwała stare biblioteki których już w nowych systemach nie ma. Jak zrobisz grę na nowym systemie to będzie działać.
  8. Nie przesłuchałem jeszcze całego, ale wchodzi przyjemnie i dziś cały album jest za "pay what you want". Słychać tu mocno chiptune ale zmieszany z innymi gatunkami i w miarę dobrym wokalem. Nazwałbym to chyba Pop-Chiptune. Rated Heart by Professor Shyguy Edit: Byłem blisko! "Genre: Chip-Pop"
  9. Wydaje mi się że pomoże Ci dodanie kolejnego wiersza w tablicach który będzie ożnaczać rodzaj bron8i.
  10. Nie chciałem pisać o Firebugu bo nie jestem pewien czy już jest wewnątrz Firefoxa czy dalej jako plugin. :P
  11. Ramka to nie tło. Ramka to ramka czyli border. Poza tym nauczę cię ciekawej sztuczki. Możesz przejrzeć kod każdej strony. ;) A w chrome np możesz w ogóle kliknąć na element który Ci się podoba i wybrać "Zbadaj element" żeby zobaczyć wszystko na jego temat.
  12. Ok, czyli pierwotnym problemem było to że maski miały różne rozmiary. :) A co do nowego pytania: Jest to bardzo trudne zagadnienie które można zrobić na wiele sposobów. Zazwyczaj unikam odsyłania ludzi do tutoriali na YT ale ten w tym wypadku się sprawdzi.
  13. W twoim przypadku place_meeting() lepiej się sprawdzi niż position_meeting(). Ale wydaje mi się że solid sam z siebie ma tak że nie może mieć kolizji z innymi obiektami solid. A może po prostu ustawiłeś złą maskę? Zapomnij o ustawianiu kamery w room i od dziś ustawiaj jej pozycję samemu. GML view_xview[0] view_yview[0] Do dokumentacji!
  14. Twój room może mieć dowolny rozmiar, a wszystkie instance mogą być na dowolnych pozycjach. Nie jesteś ograniczony rozmiarem room w żaden sposób musisz tylko samemu zarządzać kamerą. Co do pierwszego to domyślam się że twój o_parent jest w rzeczywistości parentem dla innych obiektów. Dlatego przy sprawdzaniu kolizji z parentem brane są pod uwagę też jego dzieci.
  15. instance_exists() Przejrzyj wszystkie funkcje w dokumentacji. Na prawdę w jeden wieczór poznasz wszystko.
  16. Threef

    Galeria Grafik

    Thx. Dopiero teraz sobie uświadomiłem że te góry są jeszcze ze starej wersji, a to oznacza że były rysowane przez 10 minut na Jamie. Teraz też ogarnąłem że autotiler (tak to się chyba fachowo nazywa) ma spore błędy jeszcze. W ruchu oczywiście lepiej to wygląda z paralaxą i dynamiczną kamerą. No i co do kamery to nie jestem jeszcze pewien czy to jest dobry 'zasięg widzenia'. :mellow:
  17. Threef

    Galeria Grafik

    A ja bazgram coś takiego:
  18. Ostatnia rzecz o jakiej napisałem przy ds_grid_get_sum(). ;) Zrób warunek żeby nowy pokój stawiany był tylko gdy będzie częścią starego pokoju, ale nie zajmował zbyt wielu % starego pokoju. Próbuj. Zmieniaj wartości aż w końcu coś Ci się spodoba.
  19. Threef

    Galeria Grafik

    Czemu koncepty wyglądają tak spoko, a mockup (bo to jeszcze nie screen?) wyglądają tak płasko?
  20. Już się bałem że mi napiszesz "Ale mi potrzebne było tylko ds_grid_set_region()". :lol:
  21. *wynurza się z czeluści piekielnych po usłyszeniu słów inkantacji* Widzę że ogarnąłeś całkowite podstawy więc teraz już będzie z górki. Ogółem wszystko co będziesz robić będzie bazowało na tablicach (albo ds_grid). Każda komórka będzie zawierała id (twoje wymyślone, nie id obiektu). Na początek uznajmy że id=0 to powietrze a id=1 to ściana no i róbmy to na ds_grid (muszę porobić testy czy wciąż jest szybszy od tablic, ale użyjemy go z innego powodu). Jeszcze przypomnę o różnicy pomiędzy random() a irandom(), bo możesz mieć przez to czasami problemy. ;) Wypełnij całą mapę (tak teraz będę nazywał nasz ds_grid) wartością 0 używając ds_grid_clear(), a połowę ustaw na 1 przez ds_grid_set_grid_region(). Robimy to tylko dla testów więc teraz zrób ds_grid_shuffle() i mamy testowe dane. Teraz zabierz się za wyświetlanie tego wszystkiego w room. Najprościej jest przelecieć całą mapę przez podwójny for: GML for(var _y=0;_y<ds_grid_height();_y++) for(var _x=0;_x<ds_grid_width();_x++) {} Na podstawie wyciągniętych danych z mapy wstawiaj odpowiedni instance w room na odpowiedniej pozycji. Nie masz pojęcia jak? _x*szerokość ściany etc. Jeżeli dobrze wszystko ustawisz to nie będziesz musiał się nawet bawić w depth ze ścianami w izometrii. ;) Jak wszystko jest ok to możesz zabierać się za generator. (uwierz że wcześniej nie ma sensu bo nie będziesz widzieć efektów, co prawda ja kiedyś się bawiłem w rysowanie tego co mi wyszło przez draw_point() ale po co?) Więc twój pierwszy punkt jest jak najbardziej poprawny i jest całkowitą podstawą. Pierw ds_grid_clear(,1) a potem ds_grid_set_region() z 0 na środek. I mamy nasz pierwszy pokoik. Teraz twój drugi punkt wymagałby podania większej ilości informacji. Co rozumiesz przez "przejście"? Zwykłe drzwi czy korytarz? Zrobienie drzwi nie jest proste bo muszą łączyć 2 sąsiadujące pokoje, za to korytarze można stawiać na setki sposobów. Olejemy drzwi bo nie mam zamiaru rozpisywać się. Opiszę za to 3 bardzo proste sposoby. 1. Korytarz łączy dwa pokoje. Losujemy wartości naszego pokoju: wysokość, szerokość, pozycję x i y. Pamiętając aby nie próbować stawiać pokoi poza rozmiarem mapy! Przed postawieniem pokoju sprawdzamy czy nie ma tam już innego pokoju. Jak? Dzięki ds_grid_get_min()! Funkcja ta zwraca najmniejszą wartość wewnątrz prostokąta, to oznacza że jak wewnątrz naszej pozycji dla nowego pokoju będzie jakiś kawałek innego pokoju (wartość 0 czyli brak ściany) to będziemy o tym wiedzieć. Nasz punkt 1 jest pętlą do, a punkt 2 warunkiem w until() Gdy mamy pozycję na pokój stawiamy go przy pomocy ds_grid_set_region() Teraz zaczyna się magia: x i y naszego pokoju dodajemy do dwóch ds_list. Nazwijmy je list_rooms_x i list_rooms_y. (Muszą tam też być x i y pierwszego pokoju! lol) Punkty 1-4 wykonujemy aż zabraknie możliwości albo nastąpi inny warunek kończący. Korytarze: Dopóki wewnątrz list_rooms_x jest więcej niż 1 dana ( while(ds_list_size(list_rooms_x)>=2){} ) wykonuj punkty 7-8 Wstaw korytarz. Tu możesz puścić wodze fantazji. Musisz po prostu wyryć drogę pomiędzy x i y jednego pokoju a x i y drugiego. Możesz spróbować narysować pogrubioną linę pomiędzy punktami, ale jest to trudniejsze niż się wydaje. :P Najprostsze rozwiązanie to... narysowanie obwodu prostokąta. Nie ma do tego funkcji w GM więc musisz napisać sobie coś takiego ds_grid_set_region(mapa,x1,y1,x2,y1,0) Usuń jedną parę punktów z naszych ds_list. Przy rysowaniu polecam losować tylko x (y będzie na tym samym index) a do pary brać parę o następnym index. Jeżeli czegoś nie pomyliłem to wyszedł algorytm z bardzo długimi korytarzami. Możesz teraz zacząć się bawić w jego customizację. Robić grubsze korytarze, albo losować aby wejście do korytarza nie było zawsze na środku pokoju. Moje ulubione może być sprawienie aby pozycja pokoju usuwała się z lista tylko czasami, dzięki temu jeden pokój będzie połączony z kilkoma. Efektem może być coś takiego: Sorry że gif, ale innego nie miałem. (gif w ogóle przedstawia skrypt dungeon crawlera. Postać sama chodzi po labiryntach aż nie spotka czegoś interesującego jak przeciwnik, albo nie zwiedzi całego labiryntu) 2. Najprostszy algorytm ever. Są to punkty 1-3 z poprzedniego algorytmu... z tym że warunek jest odwrócony i stawiamy pokój tylko gdy będzie miał wspólną część z innym pokojem. Ta! da! Banalny i piękny. Żadnych korytarzy! To już działa! Możesz się teraz pobawić z jego customizacją i olać wszystkie inne algorytmy bo ten wystarczy Ci do końca życia. Spróbuj wymusić aby pokoje nigdy nie były kwadratami a zawsze były płaskie albo długie, a algorytm zacznie rzeczy niesamowite! Jego wadą niestety jest jego prostota, bo przez to jest bardzo nieprzewidywalny. 3. Kopanie Algorytm działający właśnie tak jak opisałeś. Od pierwszego pokoju wybieramy kierunek i losujemy długość korytarza. Stawiamy korytarz w wybranym przez nas kierunku i długości. Miejsce w którym zakończyliśmy będzie teraz miejscem nowego pokoju. Stawiamy pokój i wykonujemy te 3 punkty jak długo potrzebujemy. Tak napisany algorytm będzie działać od razu (i jest dość prosty) ale wymaga godzin customizacji. Być może chcesz aby korytarz nie tworzył się już w kierunku z którego przyszedłeś, ale dzięki temu będą powstawać ślepe zaułki. Może chcesz aby korytarze były dłuższe, a może krótsze? Może żeby się nie przecinały? Algorytm z Nuclear Throne też jest dość fajny. OK. To pora na jeszcze trochę lektury. Jest jedna poważna wada każdego z tych sposobów. Wszystko poza wnętrzem pokoi jest obiektem ścianą. Wszędzie gdzie gracz nie może wejść jest masa nie potrzebnych obiektów. Trzeba bawić się w optymalizację tego, bo nie można tego tak zostawić. Stawianie przeciwników odbywa się bardzo prosto. Losujesz pozycję startową tak długo aż nie będzie kolizji. Automaty komórkowe! - Yep! Tym razem nie zapomniałem. W przypadku tych akurat algorytmów mogą się nie przydać ale warto o nich pamiętać. Wszystko polega na budowaniu zasad które wykonywane są po skończonym generowaniu. Np.: "jeżeli ściana jest jakimś cudem sierotą i nie ma żadnych sąsiadów to ją usuń", albo "usuń ścianę jeżeli w okręgu 4 jest mniej niż 60% ścian". No i jak na razie nie udało mi się znaleźć jakiegoś ultra szybkiego sposobu na zrobienie tego. :/ I ja porównuję zwyczajnie sąsiadujące komórki. Zawsze zostawiaj przynajmniej po jednej zapełnionej komórce przy krawędziach mapy. Przez pomyłkę gracz może tak wyjść za mapę! Leniwy sposób to po skończonym generowaniu zarysowanie okręgu. Przy używaniu ds_grid uważaj na różnice pomiędzy add a set. Czasami możesz mieć głupi błąd przez swoje nie dopatrzenie. Funkcje do sprawdzania wartości wewnątrz prostokąta są bardzo przydatne. Możesz poznać najmniejszą, największą, sumę albo średnią z komórek. I tak, możesz tego użyć przy prostych automatach komórkowych o ile operujesz tylko na wartościach 0 i 1. GML if(ds_grid_get_sum(map,x-2,y-2,x+2,y+2)>13){jest ponad 50% ścian} A ja ostatnio pisałem kumpeli program na studia i wyszedł tak wyrąbisty i prosty algorytm że będę się przy nim masturbował jeszcze przez kilka lat.
  22. Ale chcielibyśmy wiedzieć co pomogło. :)
×
×
  • Dodaj nową pozycję...