w którym gm kontynuować projekt?

[SIDek]

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?

[Uzjel]

Tak. Przepisanie gry na GMową fizykę, to napisanie gry praktycznie od nowa i mniej ułatwień (np pathe nie działają).

[SIDek]

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...

[Threef]

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.

[DangBean]

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.

[Lechu4444]

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. :)

[DangBean]

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: .

[Threef]

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ł.

[Jaklub]

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

[gnysek]

Eeej, PHP i JS też mają EVAL czyli to samo co execute string. Ta funkcja poleciała, bo z YYC nie mogła by działać, bo by cały sens binarki psuła.

[Jaklub]

szkoda, że nie ma jej poza yyc, ale cóż zrobić

[TeeGee]

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ń.

[gnysek]

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.

[TeeGee]

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.

 

[*]