Skocz do zawartości

w którym gm kontynuować projekt?


SIDek

Rekomendowane odpowiedzi

zacząłem robić projekt w gm8. strzelanka platformowa z celowaniem 360stopni, duzo skakania i strzelania.

parę dni temu ściągnąłem GM:S i zacząłem interesować się "physics worldem"

 

bardzo fajna sprawa, zwykła kulka turlająca się po schodach daje tyle radości, a co dopiero gdyby nadać "fizyczność" rozczłonkowanym przeciwnikom.

 

tylko z tego co zauważyłem (prosze mnie wyprowadzić z błędu jeśli się myle) jeśli room będzie fizyczny to przestają w nim działać wszelkie vspeedy, hspeedy, directiony itd. :(

 

czy da sie cos z tym zrobic, czy jesli już decydujemy się na kożystanie z physiców to wszystko musimy robić na nich? w takim wypadku musiałbym uczyć sie wszystkiego od nowa. jakie opcje jeszcze przestaja dziłac w fizycznym roomie?

Odnośnik do komentarza
Udostępnij na innych stronach

Pathe akurat mi nie potrzebne, głownie kożystam ze speedów, directiona i collisionów wszelkich.

A jeśli bym nie korzystał z fizyki to lepiej pisać na gm8 czy gms, w którym będzie szybciej gra śmigała?

 

Mam straszny dylemat, miał to być projekt prosty i szybki (co nie znaczy byle jaki) aby można było go ukończyć, nie wiem czy dla paru bajerów warto zaczynać praktycznie wszystko od nowa :/ Z drugiej strony fizyka i te shadery są kuszące i wyglądają efektownie...

Odnośnik do komentarza
Udostępnij na innych stronach

Pathe akurat mi nie potrzebne, głownie kożystam ze speedów, directiona i collisionów wszelkich.

Nic z tego nie zmieniło się w GM:S. Wszystko jest tak jak było. A jeżeli zaimportujesz grę to będzie od razu działać. W tym momencie nie ma już powodu by wracać do GM8.

Odnośnik do komentarza
Udostępnij na innych stronach

jeżeli zaimportujesz grę to będzie od razu działać.

To się nazywa hurraoptymizm :rolleyes:

Jeśli w GM8 nie korzystałeś z jednej z ponad setki funkcji, które w GMS zostały wycofane, to gra będzie od razu działać.

(pełna lista w dokumentacji http://docs.yoyogames.com/ w sekcji Reference->Obsolete functions)

Ale spróbować nie zawadzi :thumbsup: - szybkość "śmigania gry" w GMS i GM8 to niebo i ziemia.

Odnośnik do komentarza
Udostępnij na innych stronach

To się nazywa hurraoptymizm :rolleyes:

Jeśli w GM8 nie korzystałeś z jednej z ponad setki funkcji, które w GMS zostały wycofane, to gra będzie od razu działać.

(pełna lista w dokumentacji http://docs.yoyogames.com/ w sekcji Reference->Obsolete functions)

Ale spróbować nie zawadzi :thumbsup: - szybkość "śmigania gry" w GMS i GM8 to niebo i ziemia.

Tak ale większość z tych funkcji została po prostu zastąpiona przez inne i większość z tych funkcji mają swoje odpowiedniki w GMS, a jeśli nie mają to znaczy że były niepotrzebne. :)

Odnośnik do komentarza
Udostępnij na innych stronach

Tak ale większość z tych funkcji została po prostu zastąpiona przez inne i większość z tych funkcji mają swoje odpowiedniki w GMS, a jeśli nie mają to znaczy że były niepotrzebne. :)

Tu to się można spierać - są tacy którzy nie korzystali i tacy którzy wprost przeciwnie. Chodziło mi o to, że nie zawsze gra "od razu będzie działać". Moim grom to się nie przytrafiło :( . Nie działają.

 

Zmiana była baaardzo bolesna, ale miała sens, więc nie złorzeczę tylko cieszę się, że GMS jest lepszy i piszę sobie nową gierkę :rolleyes: .

Odnośnik do komentarza
Udostępnij na innych stronach

Wyleciały albo funkcje niepotrzebne (obsługa CD) albo takie które były bardzo szkodliwe dla aplikacji. Zostało pozmieniane kilka rzeczy by w końcu GM trzymał jakiś standard. Dlatego np execution_code (czy jak to się nazywało) jest już nie możliwe, i każdy programista (poza programistami Pythona :wacko: ) wyśmieje ten pomysł.

Odnośnik do komentarza
Udostępnij na innych stronach

akurat execute_string i (zwłaszcza) object_event_add to były bardzo fajne wynalazki dające ciekawe możliwości (np. obsługa modów lub wczytywanie kodu z oddzielnych zasobów kiedy exe robiło się zbyt ciężkie)

 

a co do portowania gier z gm8.1 do studio, zmieniło się też sporo niby subtelnych drobiazgów, więc jeśli gra miała rozwiązania bazujące na nich (używanie exit to wyjścia z pojedynczego bloku execute code zamiast z całego eventu, wczytywanie zasobów, surfejsy na cały ekran, etc), to masz babo placek

Odnośnik do komentarza
Udostępnij na innych stronach

akurat execute_string i (zwłaszcza) object_event_add to były bardzo fajne wynalazki dające ciekawe możliwości (np. obsługa modów lub wczytywanie kodu z oddzielnych zasobów kiedy exe robiło się zbyt ciężkie)

 

a co do portowania gier z gm8.1 do studio, zmieniło się też sporo niby subtelnych drobiazgów, więc jeśli gra miała rozwiązania bazujące na nich (używanie exit to wyjścia z pojedynczego bloku execute code zamiast z całego eventu, wczytywanie zasobów, surfejsy na cały ekran, etc), to masz babo placek

 

Amen! Bajery w stylu execute_string to ogromna zaleta języków skryptowych i pozwala na całą masę fajnych rzeczy, nawet jeśli te funkcję są za drogie do wywoływania co update. W Cinders ślicznie nam to pozwalało na trzymanie całych scenek i ich eventów w prostych, czytelnych plikach tekstowych, w których na dodatek można było mieszać nasze własne oskryptowanie z czystym GML (np. głupieactor.depth+=1, żeby w scence customowo przesunąć postać trochę dalej niż stoi z defaultu).

 

Wiadomo czemu te funkcje poleciały i chyba zalety YYC są jednak większe. Niemniej jednak to nieodżałowana strata jeśli chodzi o elastyczność w pisaniu bardziej data-driven rozwiązań.

Odnośnik do komentarza
Udostępnij na innych stronach

  • Administratorzy

Można to zastąpić odpowiednimi ds_mapami i JSONem :) Wtedy też można trzymać eventy w prostych, czytelnych plikach (np. YAML i konwertować do JSON, a potem robić z tego ds_mapy ). Z racji, ze GM ma opcję oznaczania podmap/podlist i przy konstrukcji ze stringa JSONowego sam oznacza wszystkie postruktury, usuwając główną usuwamy całość i w ten sposób wylatuje nam to z RAMu :) Wystarczy więc np. zrobić tablicę/listę z JSONami i stworzyć skrypt który odpala nam eventy z takiego czegoś po jakimś ID. Przykładowo takie JSONy wyglądałby tak:

 

a[0] = '{type:"message", text:"Hej, jestem dobrą wóżką!", action:"actorLeftDeph", arg0:1, next: 1}';
a[1] = '{type:"action", action: "changeRoom", arg0: 2, next: -1}';

 

No i korzystając z XMLa z zasobami można by w takim edytorze nazwy obiektów, roomów itd. wyświetlać tekstowo, bo niestety w zapisie muszą być jako ID (no na siłę można by zrobić listę zasobów pętlą while od 0 i xxx_get_name tak długo jak xxx_exists, np. sprite_exists, script_exists, itd.

Trochę zabawy za pierwszym razem, ale potem taki zestaw pozwala na naprawdę wiele i można zrobić całą grę nie otwierając już więcej GM.

Odnośnik do komentarza
Udostępnij na innych stronach

No właśnie to już nie jest przesadnie czytelne, bo normalnie masz 5x dłuższy tekst i 5x więcej funkcji per linijka, każda z 3-5 argumentami. Oczywiście na co dzień i tak korzystamy z edytora, ale wyobraź sobie wysyłanie takiego tekstu do korektora, który nie ma pojęcia co to wszystko znaczy. W zasadzie rodzi to potrzebę posiadania oddzielnej tablicy stringów, a to znowu komplikacja.

 

No i przy takim rozwiązaniu każdą jedną rzecz musisz ująć we własny skrypt. Czyli już nie starczy actor.depth+=1 wiszące luzem, ale właśnie coś w stylu: "action:"actorDepth", arg:1, arg0:1". Pozornie to mała różnica, ale przy debugu i późnym polishu możliwość szybkiego zrobienia poprawki poprzez bezpośrednie wstawienie GML bardzo się przydaje.

 

Więc tego. Wiadomo - wszystko się da i to niby nie problem. Ale jednak execute_string pozwalało na więcej elastyczności i wygody przy edycji.

 

[*]

Odnośnik do komentarza
Udostępnij na innych stronach

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się
  • Ostatnio przeglądający   0 użytkowników

    • Brak zarejestrowanych użytkowników przeglądających tę stronę.
×
×
  • Dodaj nową pozycję...