Skocz do zawartości

Konrad-GM

Użytkownicy
  • Postów

    2 728
  • Dołączył

  • Ostatnia wizyta

  • Wygrane w rankingu

    44

Odpowiedzi opublikowane przez Konrad-GM

  1. Takiej konstrukcji "jakisSet == 7" nawet nie ma python, jakbym zobaczył kogoś z pracy overloadującego tak operatory, udusiłbym gołymi rękoma. Tworzysz "set" czyli zbiór, w GML możesz wykorzystać do tego ds_map albo właśnie tablice i funkcja array_contains powinna być wystarczająca, ale ds_mapy mogą być szybsze przy dużym zbiorze liczb - przez praktycznie liniową złożoność hashowania i podejrzenia, czy klucz istnieje.

  2. Jak dla mnie wygląda to na shadowing zmiennych, puszczasz wartość `-1` w argumentach:

    function play_sound(snd, gain = 1, pitch = 1, sound_player = -1) <--- tutaj

     

    Definiujesz to jako zmienną lokalną funkcji (nie instancji), a potem zamieniasz jej wartość tutaj:

    sound_player = audio_play_sound

     

    Wygląda mi to na zwyczajny shadowing, a ta zmienna ma scope funkcji a nie instancji w której ta funkcja jest odtwarzana, zwyczajnie `sound_player` zawsze jest `-1` (zakładając, że podstawiasz do niej wartość -1 z innej zmiennej podczas jej wywołania, bądź pozostawiasz argument "pusty", który jest zastępowany wartością domyślną, `-1`).

     

    Pewnie szukasz czegoś w rodzaju:
    variable_instance_set (yoyogames.com)

    variable_instance_get (yoyogames.com)

     

    Ewentualnie po prostu zwracaj ID (wartość po wywołaniu audio_play_sound) odtworzonego dżwięku zamiast posiłkować się taką "adresacją".

  3. Teraz działa spoko 👌 Fajna i dość rozbudowana gierka, chowanie się za przeszkodami, różne rodzaje broni, może AI wymaga trochę dopracowania, bo jak raz zaalarmujesz przeciwnika to ten leci bezpośrednio do nas a nie ostatniej znanej pozycji, byłoby to nawet ciekawe do ściągania i flankowania wrogów.

  4. Nawet spoko gierka, przeszedłem całe demko, ale przyznam, że przez ten stos dialogów to trochę nuży, nawet większości nie czytałem :P Co do sterowania to zdecydowanie wolałbym ośmiokierunkowe, jak w Hotline Miami. Dodatkowo trochę niepotrzebne te cofanie się do domu jak już pogadamy z pojmanym żołnierzem, nie można by radiostacji przenieść do tego samego budynku? Po pojmaniu niemca to idąc w obie strony praktycznie nic się nie dzieje. Jeszcze mógłbym się przyczepić do gigantycznej maski kolizji, gracz nie podejdzie do ściany bliżej jak metr odstępu co trochę wkurza jak próbowałem trafić w drzwi na ostatnim odcinku mapy (żeby się schować).

  5. Chcesz zasymulować fizykę bez znajomości chociaż podstaw newtonowskiej fizyki? To myślę może już lepiej byłoby to zlecić komuś do zrobienia i nie zaglądać w kod. Jak tak bardzo chcesz uprościć fizykę, to chociaż zawsze aplikuj przyśpieszenie grawitacyjne, przynajmniej do momentu, aż ludzik nie zastygnie na platformie. IMO napisałeś za mało szczegółów, jak Twój kod aktualnie wygląda i chociaż dołącz krótki filmik, żeby było widać w czym problem.

  6. Godzinę temu, Adriann napisał:

    W ogóle myślicie że taki rts z setkami jednostek jak nie tysiącami licząc chłopów i inne obiekty z mgłą wojny(+ rysowaną na minimapie :P ) jest realny? A i często większą mapką niż to co mamy tu

    Tak szczerze powiedziawszy, bez sensownego dostępu do wielowątkowości, to byłoby to zapewne trudne do osiągnięcia - ale jakby mocno skupić się na optymalizowaniu, to może nawet w miarę sensowny klatkarz można uzyskać.

     

    Kilka propozycji jak można zoptymalizować rysowanie fog of war:

    • Nie aktualizuj wszystkich jednostek, ale tylko komórki, które są zajęte przez jednostki. Do tego możesz wykorzystać "słownik", np. tworzysz loopa po liście monitor_list tak jak do tej pory, ale przy okazji zapisujesz w której to komórce jednostka rysowała swój fog of war i np. przed shroud_clear_position może sprawdzić, czy tej komórki już nie liczyłeś, taki pseudo kod:
      var dict = new Dictionary
      for unit of unit_list:
        if dict.has(key: unit.x + '_' + unit.y)):
          continue
        shroud_clear_position(unit.x, unit.y)
        dict.set(key: unit.x + '_' + unit.y, value: unit.shroud_radius)

       jeżeli każda jednostka ma własny shroud_radius, to możesz przed shroud_clear_position zapełnić nową listę ale tylko z jednostkami o największym shroud_radius na daną komórkę.

    • Dodatkowo możesz zoptymalizować samą funkcję shroud_clear_positionhttps://www.redblobgames.com/grids/circle-drawing/ polecam
    • Nie modyfikuj tablicy shroud_grid jednostkami poza ekranem, monitor_list powinien posiadać tylko jednostki, której pierścień fog of war może być widoczny.
    • Możesz spróbować też brać tylko wycinek z listy monitor_list i co kolejna klatka aktualizować tylko część jednostek - jeżeli aktualizacja tablicy będzie się działa np. 15x na sekundę to raczej nikt nawet nie zauważy zastosowanego triku.

    Jeżeli jeszcze na coś wpadnę to chętnie się podzielę pomysłami.

  7. Jeżeli chodzi o mikro-optymalizacje, to przełączanie stanu karty graficznej np. `gpu_set_blendmode` wyrzuciłbym poza loopa, ale to pewnie niewiele zmieni i tak. Tego typu fog of war można też zrobić na tablicach, większe komórki i aktualizowałbyś je jedynie gdy jednostka przekroczy jej granicę. A rysować mógłbyś też tylko wycinek takiej tablicy na surface bez znaczenia ile jednostek jest na ekranie. Minus taki, że byłoby to bardziej "rozpikselowane", ale możesz spróbować wygłądzić krawędziie jakimś shaderem.

  8. 2 godziny temu, Adriann napisał:

    Tu fpsy są spoko i podąża za kamerą ale niestety światło i wypełnianie go się nie rysuje tak jak trzeba. 

    Jeżeli rysujesz duszki na surface to X i Y będą zawsze 0,0 i nie "podąża" za kamerą tak jak by można było się spodziewać, ale możesz spróbować odjąć pozycję kamery żeby przesunąć rysowanie duszków na właściwą pozycję, oraz duszka "black rectangle" możesz rysować na pozycji 0,0

  9. W dniu 6.08.2021 o 17:46, Wojzax napisał:

    Z drugiej stony chciałem dać graczowi możliwość strzelania wyżej/niżej

    W The Ascent jest przycisk podnoszący celownik, może zrobienie podobnego celowania byłoby wystarczające? Normalny tryb to celownik zawieszony na jednej płaszczyźnie, ale np trzymając alt/ppm można by celować po raytracingu z kamery, wtedy celowanie w konkretny punkt też byłoby możliwe.
    Edit: Może z celownikiem laserowym też inaczej by się grało :P 

  10. Też mam tego buga z nieznikającą eksplozją po granacie, wali po oczach niemiłosiernie, aż do tego stopnia, że unikałem granatów :P Moim zdaniem gra ma potencjał, ma ciekawą mechanikę, przyjemnie się likwiduje przeciwników, ładnie i spójnie się komponuje, ale czasami sterowanie jest dość toporne jakby sterowało się czołgiem. Dodatkowo celowanie koniecznie do poprawy, jest nieintuicyjne i czasami nie wiadomo gdzie nasz gostek celuje - może zablokowanie celownika do płaszczyzny byłoby lepsze? Może to kwestia level designu, ale czasami elementy otoczenia znikają i pojawiają się dość chaotycznie i ciężko się orientować. Jak dla mnie gra bomba, trochę szlifów w sterowaniu, level design i mógłbym grać bez przerwy.

  11. 1 minutę temu, pankracy napisał:

    Używalem już.

    I tylko działa to kiedy graczem bedąc w wodzie nie wykonuje ruchów lewo prawo góra dół.Jak się poruszę w wodzie obojetnie w jakim kierunku to wtedy przyspiesza animacja sprita.To jest ten problem

    4 godziny temu, pankracy napisał:
    image_index += 2;

     

    Bo ją sam przyśpieszasz, wywal tą linię i z głowy.

  12. W dniu 15.06.2021 o 21:34, pankracy napisał:

    animacja która powinna być odtwarzana co 5 sekund w całości

    Nie rozumiem, a to nie odtwarza się w całości czy jak, a ta animacja trwa aż 5 sekund?
     

    W dniu 15.06.2021 o 21:34, pankracy napisał:

    zresetować grawitacje mam bezpośrednio w instancji par_entity ok ale jak konkretnie ma to wyglądać?

    Może wystarczy tylko sprawdzanie, czy stoi na ziemi? `if !place_free(x, y+1) g = 1.0;`

  13. 50 minut temu, pankracy napisał:

    tak nie zadziała,bo nie będę miał zdeklarowanej zmiennej w create trampoliny i wywali mi komunikat o braku zmiennej start.

    To dodaj zmienną `start` w Create obj_trampolina. Jeżeli ten obiekt dziedziczy z innego obiektu Create, to na początku skryptu użyj event_inherited() to wtedy Create rodzica również zostanie wywołany.

     

    50 minut temu, pankracy napisał:

    Chyba,że użyć var w step zdarzenia i dodać zmienną start?

    Nie, bo zmienna `start` będzie widoczna tylko i wyłącznie w tym bloku kodu, jak tylko go opuści to zostanie usunięta - nie będzie miała żadnej wartości, ani true ani false, przestanie kompletnie istnieć.

    Polecam przejrzeć:
    https://docs.yoyogames.com/source/dadiospice/002_reference/001_gml language overview/variables/index.html - w tym podartykuły instance variables oraz local variables.

  14. 11 minut temu, pankracy napisał:

    kod nie działa. Nadal animacja trampoliny nie jest odtwarzana co 5 sekund i w trakcie trwania animacji gracz może odbić się od trampoliny.

    może jeszcze flaga start musi być gdzieś zdefiniowana a nie tylko w alarmie0?

    W kodzie Step nie masz ustawianej flagi `start = true` więc technicznie flaga nigdy się nie zmienia. Wstaw `start = true` zaraz pod `alarm[0] = room_speed * 5`. Dodatkowo w Step nie sprawdzasz czy `start == false` żeby uruchomić blok odpowiedzialny za skok. Np. `if start == false && place_meeting(x,y,par_entity) {`.

  15. 1 godzinę temu, pankracy napisał:

    Słuszne jest zmiana grawitacji po bloku with par_entity prawda? Bo wtedy odwołamy się bezpośrednio do tej instancji

    Tak, jest to jak najbardziej poprawne.
     

    1 godzinę temu, pankracy napisał:

    Teraz pytanie gdzie powinno się resetować grawitacje do wartości 1

    obj_trampolina zmienia grawitację tylko wyłącznie kiedy dotknie par_entity, imo najlepiej byłoby przywrócić wartość w Step par_entity kiedy opadnie już na ziemię.

     

×
×
  • Dodaj nową pozycję...