Skocz do zawartości

Amaterasu

Użytkownicy
  • Postów

    390
  • Dołączył

  • Ostatnia wizyta

Odpowiedzi opublikowane przez Amaterasu

  1. Zależy, co chce zrobić:

    1. ma poruszać się tylko, gdy kliknięty jest RMB:

    GML
    //Event Step

    if(mouse_check_button(mb_right)&&targeted)

    {

    xx=mouse_x;

    yy=mouse_y;

    if(distance_to_point(xx,yy)>32) mp_potential_step(xx,yy,v,false);

    }

    2. kliknięcie ma tylko wybierać cel, do którego obiekt ma się dostać, sam obiekt ma cały czas się poruszać, dopóki nie dotrze do celu:

    GML
    //Global RMB button released

    if targeted

    {

    xx=mouse_x;

    yy=mouse_y;

    }

    GML
    //Event Step

    if(distance_to_point(xx,yy)>32) mp_potential_step(xx,yy,v,false)
  2. Rozmiar save'a nie jest problemem (np. w Spellforce save'y ważą po kilka MB), ale lepiej go zaszyfrujcie albo coś, bo to żadna frajda podmienić sobie parę linijek w save i przejść całą grę na godmode.

  3. Napis powinien wyglądać mniej więcej w tym stylu:

    GML
    str = string(miejsce)+f_miejsce(miejsce)+' '+nazwa+' '+string(punkty)+' pnk'

    draw_text(xx,yy,str)

    Funkcja f_miejsce wybierze, czy po numerze miejsca powinno pisac 'st', 'nd', 'rd', czy 'th':

    GML
    switch argument0

    {

    case 1: return 'st'

    case 2: return 'nd'

    case 3: return 'rd'

    default: return 'th'

    }

  4. Jestem pod wrazeniem, jak mocny musi byc twoj komputer. Twoj drugi kod tworzy wszystkie bloki naraz. A raczej tworzylby, gdybys w polowie kodu nie zapomnial usuwac ifa z Ctrl-C - Ctrl-V.

    W sumie ten drugi kod jest bez sensu, skoro pierwszy w zamierzeniu robi dokladnie to samo.

  5. Ach, czyli nie ma to być jakaś super realistyczna symulacja wody, ale oparta na blokach. W takim przypadku poczytaj sobie o automatach komórkowych, a następnie zbuduj taki, który kontroluje ruch wody w twojej grze.

    Z matematycznego punktu widzenia jest to dosyć proste, natomiast aby to rozwiązanie działało w czasie rzeczywistym, trzeba pomyśleć nad strukturą wody w grze (np. częstotliwość symulacji, zachowanie i przeznaczenie obiektów-woda znajdujących się w grze i na ekranie).

  6. Zależy, ile tej wody ma być. Jeżeli chcesz mieć jakieś morze, to lepiej po prostu zrobić wszystko jako efekt graficzny, a jeśli chcesz móc przelewać wodę z miejsca na miejsce, wtedy tej wody nie może być zbyt dużo, bo komputer ci się stopi.

    Najważniejsza sprawa: ta twoja gra, ma być 2D platformówką, top-down, izometryczna czy 3D?

  7. To powiedz jak zrobić taki edytor, jak tak pomysłem błysnąłeś...

    1. Stwórz listę, w której będziesz przechowywał indeksy załadowanych grafik

    2. Stwórz strukturę danych, w której będziesz przechowywał dane nt. kości (czyli ID obiektu-kości, ID parenta kości) oraz zapisz w każym obiekcie-kości dane nt. jej graficznej reprezentacji (np. sprite kości, długość kości, kierunek, w którym kość jest skierowana)

    3. Stwórz zestaw funkcji, które pozwolą ci na edycję danych nt. kości w trybie graficznym (przeciąganie kości, zmiana jej rozmiaru, dodawanie/usuwanie kości)

    4. Stwórz key editor, czyli obiekt, który pozwoli ci na zapisywanie i edycję informacji nt. animacji kości (m. in. ilość klatek animacji, zapis matematyczny każdej kości w każdej klatce, typy interpolacji dla każdej kości)

    5. Stwórz możliwość zapisania animacji w takim formacie, aby mogła z niej korzystać twoja gra w czasie rzeczywistym

     

    I tyle, jeśli chodzi o najważniejsze elementy : )

    Interpolacja tez działa w draw_sprite ?

    draw_sprite przyjmuje za argumenty pozycje X i Y, to, w jaki sposób modyfikujesz te pozycje zależy tylko od ciebie. Czyli, interpolacja działa.

  8. Poprawiłem czytelność kodu, nie zmieniłem w nim żadnej funkcjonalności:

    GML
    switch other.sprite_index

    {

    case spr_lrocket1:

    {

    x = other.x+12; y = other.y+12

    if vspeed = 5 {vspeed = 0; hspeed = 5}

    else if hspeed = -5 {hspeed = 0 vspeed = -5}

    else if(vspeed = -5)||(hspeed = 5) {instance_destroy()}

    break

    }

    case spr_lrocket2:

    {

    x = other.x+12; y = other.y+12

    if vspeed = -5 {vspeed = 0; hspeed = 5}

    else if hspeed = -5 {hspeed = 0 vspeed = 5}

    else if(vspeed = 5)||(hspeed = 5) {instance_destroy()}

    break

    }

    case spr_lrocket3:

    {

    x = other.x+12; y = other.y+12

    if vspeed = -5 {vspeed = 0; hspeed = -5}

    else if hspeed = 5 {hspeed = 0 vspeed = -5}

    else if(vspeed = 5)||(hspeed = -5) {instance_destroy()}

    break

    }

    case spr_lrocket4:

    {

    x = other.x+12; y = other.y+12

    if vspeed = 5 {vspeed = 0; hspeed = 5}

    else if hspeed = 5 {hspeed = 0 vspeed = 5}

    else if(vspeed = -5)||(hspeed = -5) {instance_destroy()}

    break

    }

    default: break

    }

    Wiele rzeczy w twoim kodzie powtarza się niepotrzebnie. Zerknij na funkcję dot_product i zastanów się, w jaki sposób pomoże ci załatwić ten problem w jednej-dwóch linijkach.

  9. Chodzi o tekstury, modele?

     

    -Budynek i drzewo porażają swoją kanciastością. Nawet w GM-ie można rysować modele, które nie są prostopadłościanami.

    -Brak rozdzielenia na światło i cień powodują, że powstają jednolite plamy barwne, które wyglądają paskudnie

    -Nie istnieją kontury obiektów, co sprawia wrażenie patrzenia na płaski rysunek

    -Brak tekstur lub niska ich jakość dopełniają dzieła zniszczenia

    -Brak antyaliasingu powoduje powstawanie "ząbków" na krawędziach obiektów, a na teksturach widoczne są prążki moiré (nie chce mi dodać linku z polskimi znakami, ale można wyszukać na wikipedii)

     

    To tak z grubsza, nie poruszyłem sprawy odwzorowania budynku na podstawie danych historycznych, kompozycji barwnej, czy kształtu drzewa (które nie powinno być kuliste).

×
×
  • Dodaj nową pozycję...