Autor Wątek: Generatory parserów do prostych języków skryptowych - warto?  (Przeczytany 3896 razy)

Offline Xirdus

  • Redaktor

# Styczeń 27, 2014, 23:07:55
Kolejny z serii moich wyimaginowanych problemów z przedprojektowaniem grotwórcy. Tym razem chodzi o język skryptowy.

Planuję zrobić edytor do gier przygodowych. Jednym z elementów mi potrzebnych będzie prosty język skryptowy, a nawet dwa: jeden do poruszania postaciami i tym podobnych rzeczy na scenie, drugi do dialogów (dialogi będą bardzo ważną częścią gry - featury, które miałyby być w skryptach dialogów, to tworzenie i zmiana obrazków/animacji postaci, poruszanie nimi w dowolny sposób, synchronizacja ruchu, tekstu i podkładu głosowego). Język głównie do użytku wewnętrznego generowany przez edytor, choć myślę, że możliwość pisania skryptów z palca nie byłaby zła. Bajtkod byłby fajną rzeczą.

Jak sobie zacząłem rozmyślać, to w parę minut doszedłem do wniosku, że przydałyby się obiekty. Chociażby w przypadku animacji w dialogach - każda postać miałaby multum różnych animacji gadania, między którymi przełączałoby zależnie od jej nastroju, nie wspominając o tym, że mamy stronę lewą i prawą, i lustrzane odbicie mnie nie zadowala :P Do tego tych postaci będzie nieokreślona ilość - czyli tyle, ile w scenie będzie potrzeba (deklarowane jak zmienne).

Są cztery możliwe rozwiązania problemu. Pierwsze to użycie gotowego, kompletnego, rozbudowanego i posiadającego wszystko, co jest mi zbędne, języka skryptowego, np. Lua - to rozwiązanie odpada z oczywistych względów. Drugie to stworzenie własnego parsera języka, który miałby udawaną obiektowość, tzn. zahardkodowane typy, które posiadają pola składowe. Trzecie to oparcie wszystkiego na stringach, czyli funkcje w stylu create_animation Hero HeroNormal; place_animation Hero 200 200; set_animation Hero HeroSad; itd., i mapowanie kolejnych argumentów na odpowiednie pola w prawdziwych strukturach byłoby odpowiedzialnością engine'u gry. Czwarte użycie narzędzia pokroju ANTLR do wygenerowania w pełni funkcjonalnego parsera z takimi ficzerami jakie mi są potrzebne.

Pytanie jest chyba oczywiste - czy sposób czwarty jest warty świeczki, czy w ogóle ANTLR potrafi robić obiekty (struktury w stylu C), czy może lepiej wziąć się za 2 albo 3?

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Xion

  • Redaktor
    • xion.log

  • +1
# Styczeń 27, 2014, 23:12:47
Cytuj
Pierwsze to użycie gotowego, kompletnego, rozbudowanego i posiadającego wszystko, co jest mi zbędne, języka skryptowego, np. Lua - to rozwiązanie odpada z oczywistych względów.
What?! Niby dlaczego? Podepnij np. Pythona i wszystkie wymagania masz elegancko spełnione od razu.

Offline laggyluk

  • Użytkownik
    • twitter

# Styczeń 27, 2014, 23:13:27
oczywiście że lua ;)

Offline ArekBal

  • Użytkownik

# Styczeń 27, 2014, 23:41:31
Oczywiście że użyj(kolejność podług wymagań/prędkości/możliwości):
- silnika templateów,
- generatorów c++ np. z c#,
- xml z hierarchią wyrażeń,
- pythona,
- lua

Offline Veldrin

  • Użytkownik

# Styczeń 28, 2014, 02:02:07
Lua - jakie są te "oczywiste względny"?

Możesz swobodnie pisać w sposób obiektowy, obiektowo-funkcyjny, proceduralny, komponentowy, mixować do woli itp. itd.

Offline Xender

  • Użytkownik

# Styczeń 28, 2014, 09:24:40
Oczywiście że użyj(kolejność podług wymagań/prędkości/możliwości):
- silnika templateów,
- generatorów c++ np. z c#,
- xml z hierarchią wyrażeń,
- pythona,
- lua
- Jak ma sie silnik template'ów do skryptowania? Dialogi to tylko część tego, co OP chce zrobić.
- Generator C++ to słaby pomysł - rekompilacja gry po każdej zmianie dialogu? Co, jak dialogi będzie poprawiał nie-programista?
- Jeśli już język opisu danych, to czemu XML a nie JSON albo YAML? https://en.wikipedia.org/wiki/JSON#Samples

I ta kolejność to w którą stronę idzie? Bo IMHO języki skryptowe są do tego celu bardziej potężne, niż cokolwiek innego z tej listy.

Nie wiem, czy Python to nie będzie overkill w porównaniu z Lua - chociaż Lui za dużo nie widziałem, słyszałem tylko, że ma bardzo lekki interpreter, Python chyba jest grubszy (?).

Offline ArekBal

  • Użytkownik

# Styczeń 28, 2014, 11:35:12
Cytuj
- Jak ma sie silnik template'ów do skryptowania? Dialogi to tylko część tego, co OP chce zrobić.
Była mowa w poprzednim temacie xirdusa że o przygodówkę chodzi. Do przygodówki taki silnik wystarczy. Mam wrażenie że nie doceniacie takiego silnika.

Cytuj
- Generator C++ to słaby pomysł - rekompilacja gry po każdej zmianie dialogu? Co, jak dialogi będzie poprawiał nie-programista?
Dlaczego gry, a nie modułu(.dll)???

BTW. 1. do przechowywania dialogów służą inne narzędzia niż pliki wykonywalne.
BTW. 2. Jeżeli ktoś już trzyma dialogi w pliku wykonywalnym to i tak je będzie zmieniał edytorem resourceów, a nie przebudowywał program.

Cytuj
Jeśli już język opisu danych, to czemu XML a nie JSON albo YAML? https://en.wikipedia.org/wiki/JSON#Samples
Bo jest bardziej kompletny... namespacey, character entities, idki. Więcej zrobisz z xml. Jak potrzebujesz czegoś lżejszego to jasne, że warto spojrzeć na to.

Cytuj
I ta kolejność to w którą stronę idzie? Bo IMHO języki skryptowe są do tego celu bardziej potężne, niż cokolwiek innego z tej listy.
Czym dalej w dół tym ciężej i mocniej (no może z wyjątkiem lua vs python ale python postawiłem wyżej bo go lubię ;) )

Offline laggyluk

  • Użytkownik
    • twitter

# Styczeń 28, 2014, 11:55:15
jeżeli ten silnik ma mieć grafę jak bf4 to własny język skryptowy pewnie będzie lepszą opcją ale jeżeli nie to czy warto 'tracić' na to czas? lua jest zajebista, pythona nie znam ale dadzą skypterom dużo możliwości które w inny sposób albo były by niemożliwe do osiągnięcia albo musiałbyś się nad nimi napracować

Offline ArekBal

  • Użytkownik

# Styczeń 28, 2014, 12:35:36
jeżeli ten silnik ma mieć grafę jak bf4 ale zubożoną logikę  to własny język skryptowy pewnie będzie lepszą opcją
FTFY :D

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Styczeń 28, 2014, 14:24:30
Cytuj
Planuję zrobić edytor do gier przygodowych. Jednym z elementów mi potrzebnych będzie prosty język skryptowy, a nawet dwa: jeden do poruszania postaciami i tym podobnych rzeczy na scenie, drugi do dialogów (dialogi będą bardzo ważną częścią gry - featury, które miałyby być w skryptach dialogów, to tworzenie i zmiana obrazków/animacji postaci, poruszanie nimi w dowolny sposób, synchronizacja ruchu, tekstu i podkładu głosowego).
Jeżeli chodzi o manipulację sceną - przejrzyj języki jakie są i zdecyduj, czy któryś jesteś w stanie wykorzystać. Zrobienie porządnego języka to mega duża robota i jeżeli nie daje Ci to proporcjonalnie dużej korzyści, a możesz wykorzystać coś gotowego, to to zrób.

Jeżeli chodzi o dialogi - tutaj raczej żaden typowy język programowania się nie sprawdzi. "Raczej", bo można próbować coś podpiąć i oprzeć dialogi na mikrowątkach, ale nadal będzie to bardziej dzierganie na piechotę w kodzie niż tworzenie samego dialogu.

Rozwiązaniem dla dialogów może być użycie XML, o ile znajdziesz jakiś edytor w którym dało by się ładnie edytować drzewko. Wtedy rzeczywiście możesz edytować sam dialog, a dodatkowe elementy wpinać jako nazwy skryptowych funkcji do wywołania, czy dodatkowe $(ZmienneWplecioneWTekst). No i masz przy relatywnie niewielkim wysiłku otwartą drogę do Unicode. :)

Offline koirat

  • Użytkownik

# Styczeń 28, 2014, 14:32:30
Jeśli chodzi o te drzewka można by spróbować jakiegoś UML to xml convertera.

Offline ArekBal

  • Użytkownik

  • +1
# Styczeń 28, 2014, 15:18:38
a dodatkowe elementy wpinać jako nazwy skryptowych funkcji do wywołania, czy dodatkowe $(ZmienneWplecioneWTekst).
TO jest właśnie silnik templatów jak np. mustache. :)
Nie wiem na ile akurat port c++ obsługuje lambdy ale oryginał jak najbardziej. Z resztą napisanie czegoś takiego byle jak to banał. Zagadnienie prostsze niż "język skryptowy" a o ile lepiej pasuje do tego co tutaj ma się dziać.
Koniec końców struktura projektu też na tym zyska (na wyraźnym podziale na hierarchię contextów, templaty, i logikę).
https://github.com/mrtazz/plustache

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Styczeń 28, 2014, 16:13:18
Cytuj
TO jest właśnie silnik templatów jak np. mustache. :)
Który przy okazji najprawdopodobniej sprawi więcej problemów niż pożytku. A przy okazji jest to wybiórcze cytowanie jedynego fragmentu, przy którym taka rzecz może się przydać.

Zauważ, że nie wypełnianie templatów jest tutaj głównym celem, ale przechodzenie drzewa i jego ewentualna modyfikacja. Samo inlinowanie pojedynczych zmiennych to jeden ekran kodu C++ i nie ma sensu na to wyciągać armaty.

Offline Xirdus

  • Redaktor

# Styczeń 28, 2014, 16:23:15
Gotowego języka skryptowego ogólnego przeznaczenia z początku nie chciałem, bo za dużo ficzerów może zdestabilizować silnik w nieprzewidywalny sposób - tak mi się przynajmniej wydaje. Druga sprawa to to, że skrypty w zdecydowanej większości będą generowane maszynowo przez edytor - jak trudne będzie generowanie skryptów Lua tak, żeby nie zabić niechcący wydajności i żeby nic mi się nie spsuło ze zmiennymi?

Template'y mi się nie podobają, bo zrobienie czegokolwiek poza wyświetleniem tekstu będzie okropne składniowo. Skrypty dialogów nie będą przechowywać tekstu, tylko odwoływać się do niego po ID (int lub string - do rozważenia). Ostatecznie chyba zdecyduję się na Lua, bo Python to overkill.

Dzięki wszystkim za pomoc.

Offline ArekBal

  • Użytkownik

# Styczeń 28, 2014, 16:36:54
Zauważ, że nie wypełnianie templatów jest tutaj głównym celem, ale przechodzenie drzewa i jego ewentualna modyfikacja. Samo inlinowanie pojedynczych zmiennych to jeden ekran kodu C++ i nie ma sensu na to wyciągać armaty.
Wyraźnie się nie zrozumieliśmy. Poznaje po tym że nie wiem co masz na myśli.. :)
Ale spróbuję...

To "podmienianie" zmiennych, wywoływanie delegatów itp. to nic trudnego jak sam zauważyłeś i jest to porządne rozwiązanie do czego koniec końców próbuję przekonać Xirdusa.

Ten drugi problem o którym mówisz nie mam pojęcia w jaki sposób miałby rozwiązać język skryptowy i jak miałby to zrobić lepiej niż każde z wymienionych przeze mnie rozwiązań. Jakiś przykład byłby przydatny...

BTW. Xml jako edytowalny nośnik struktury dla projektantów nie wykluczam, polecam.

Xirdus: Mieszanie dialogów z logiką to overkill dla projektanta...
{% if is_logged_in %}Thanks for logging in!{% else %}Please log in.{% endif %}
{% for story in story_list %}
Jeśli uważasz że to jest brzydkie to rzeczywiście sobie odpuść...