W jakich przypadkach języki skryptowe są lepsze od innych?

Wszystkie odpowiedzi są mile widziane, podaj opis i opisz, w jakich przypadkach język się wyróżnia.

(Pamiętaj, jeden język na odpowiedź)

Lua jest szeroko stosowany w branży gier . Od niezależnych gier ( Aquaria ) po tytuły AAA (Civilization).

Zasadniczy powód? Powiedziałbym, ponieważ jest łatwy do nauczenia się i łatwy do włączenia do twoich gier. Ale to samo można powiedzieć o Pythonie, jestem pewien. Skrypty w ogóle nie są trudne. Myślę, że prawdziwym powodem, dla którego powinieneś wybrać się z Luą, jest to, że zostało to udowodnione, dzięki czemu masz o wiele więcej zasobów do nauki. Jeśli masz ochotę eksperymentować z czymś poza normą, zacznę zadzierać z innym językiem.

Wiewiórka

Wiewiórka ma ciekawą historię. Został zbudowany po tym, jak architekt gry miał problemy z nieprzewidywalnym zbieraniem śmieci przez Luę, a szalone wszystko jest zerowe, nawet jeśli nie istnieje .

Wiewiórka to język sriptingowy używany w Left 4 Dead 2 . Interfejs API jest bardzo podobny do lua (autor Squirrel uwielbia design Lui ).

Wiewiórka jest niesamowitym językiem, ponieważ jest Lua drugiej generacji. Wziął dobre pomysły i usunął irytujące dziwactwa.

To samo z Lua:

• coroutines
• tabele i metatable
• dynamiczne pisanie
• dużo więcej

Nowy wiewiórka:

• zajęcia
• tablice
• regexs zamiast składni dopasowania Lua.
• Język w stylu C / C ++ / Java / C # zamiast stylu Pascal / Delphi.
• dużo więcej

Główną wadą wiewiórki jest to, że nie jest to Lua. Lua jest znacznie szerzej stosowany. Ale jeśli to nie jest problem, Wiewiórka jest łatwą wygraną. Jednak często popularność języka jest przydatna sama w sobie, więc decyzja nie jest tak jednoznaczna.

JavaScript V8 z Google.

PRO:

Dość łatwy w użyciu

Ciągle się poprawia

Mocny i elastyczny

Inne Jak już wspomniano, javascript jest popularnym narzędziem programistycznym. Dodanie go do moich gier otworzyło znacznie więcej osób, które czują się zdolne niż inne języki. Obsługuje również ogromną liczbę rzutów i konwersji, aby zaoszczędzić na pracy programisty, sprawia również, że jest naprawdę łatwy w użyciu, działa dobrze z STL.

Możliwe CON:

Dokumentacja może być myląca. To naprawdę nie jest najlepsze.

Przykłady Często sieć dziwności. Brak solidnej prostoty wydaje się być o wiele wyższy niż jest.

Szablony Czasami są nienawidzone lub unikane.

SDK Codebase size Wygenerowany rozmiar kodu można uznać za nadęty.

To zależy od gry i platformy docelowej.

Gra, w której działa 100 postaci nie będących graczami (gry RTS), ma inne potrzeby niż gra, która działa tylko 2 (Street Fighter). Gra działająca na komputerze PC ma inne potrzeby niż gra działająca na konsoli.

Lua jest popularna

GameMonkey jest używany przez kilka zespołów. Jest szybszy niż Lua i lepszy w nawlekaniu.

Python był używany w kilku grach.

JavaScript jest możliwą opcją, ponieważ możesz pobrać silniki JavaScript. Jest więcej programistów JavaScript niż jakikolwiek inny programista.

Istnieją również języki specjalistyczne.

SCUMM został użyty w kilku grach przygodowych i jest szczególnie odpowiedni do tych gier.

Dla zachowania kompletności inną opcją jest mono-skrypt , który pozwala na użycie implementacji frameworku .NET w systemie Novell. To co Unity używa. Oto kolejna strona na temat osadzania mono w twojej aplikacji.

Framework Mono jest szybszy niż większość (a może wszystkie) języków skryptowych, ponieważ nie jest interpretowany, a ponieważ między kompilatorem a zestawem instrukcji jest warstwa, pozwala programować w różnych językach, w tym C # i dialektach Python, Lua i JavaScript.

Nie jestem jednak pewien, czy jest bezpłatny na wszystkich platformach.

Osobiście uważałem, że AngelScript (patrz link poniżej) jest o wiele łatwiejszy do powiązania z C ++ niż Lua, kiedy wybrałem język skryptowy dla mojego własnego projektu. (Właściwie napisałem małą bibliotekę opakowań, aby była jeszcze łatwiejsza w użyciu, kosztem pewnej elastyczności).

http://www.angelcode.com/angelscript/

Biorąc to pod uwagę, podejrzewam, że Lua ma kilka zalet, które sprawiają, że jest ona atrakcyjna dla twórców gier komercyjnych:

(a) Jest bardziej dojrzały i rozpowszechniony niż AngelScript

(b) Jego składnia jest łatwiejsza dla programistów (AngelScript jest bardzo podobny do C ++)

(c) Ma mniejszą powierzchnię niż AngelScript (przynajmniej o ile pamiętam)

Jeśli piszesz tylko projekt hobby, powiedziałbym, że AngelScript jest co najmniej wart obejrzenia.

Powinieneś wybrać język skryptowy, który ma stabilne i dobrze obsługiwane powiązania z głównym językiem programowania gry. Jeśli piszesz swoją grę w języku C lub C ++, dostępne są dość solidne powiązania dla Python i Lua. Jeśli piszesz grę na platformę .NET (używając C # lub innego języka), zdecydowanie polecam użycie IronPython lub IronRuby. Oba są kompletnymi implementacjami językowymi, które wykorzystują Microsoft Dynamical Runtime (DLR) firmy Microsoft, który zapewnia doskonałą wydajność i bardzo ścisłą integrację z .NET Framework. Współdziałanie między C # a IronPython / IronRuby jest obecnie dość płynne, szczególnie po wprowadzeniu dynamicznego wiązania strony wywoławczej w C # 4.0.

Schemat

Cóż, konkretnie podstęp .

Za pomocą podstępu możesz mieć swój własny DSL (Domain Specific Language) tylko dla swojej gry. Kiedy już przyzwyczaisz się do nawiasów i notacji prefiksów, schemat jest rajem do pracy.

Jeśli zamierzasz użyć podstępu w poważnej grze, poczekam kilka miesięcy, aż do wydania 2.0, ponieważ będzie to obejmować IIRC, interpreter Ecmascript, a także obecny schemat. Możesz także spodziewać się dużych ulepszeń prędkości.

To zależy od tego, czego potrzebujesz. Jak zauważa David, Lua jest bardzo popularny, chociaż jeden twórca gry zauważył, że nie był do końca pewien, dlaczego. Myślę, że jego lekkość jest częstym powodem, ale w tym momencie spodziewałbym się, że wiele osób użyje Lua, ponieważ stało się to de facto standardem. Wydaje się najlepszy w przypadku bardzo lekkiej modyfikacji.

Dla pełniejszego podejścia powiedziałbym, że Python jest właściwym wyborem. Civ IV użył go do przyzwoitego efektu.

Wybór jednego języka skryptowego na inny zależy od konkretnych wymagań.

Niektóre opcje do wyboru to:

Szybkość interpretera - jeśli funkcja skryptu jest wykorzystywana wyłącznie przez programistów, tj. Przez programistów do skryptu, zachowanie statyczne, szybkość i pełnoprawny i rozszerzalny interfejs API mogą być najważniejszym aspektem. Miałem tam dobre doświadczenia z LUA.

Łatwa do nauczenia się, dostępność - dla projektanta treści / poziomu może być trudno nauczyć się bardziej złożonych języków skryptowych (zależnie od tła) w celu wygenerowania dynamicznego zachowania. W takim przypadku użycie łatwiejszych do nauczenia się (tj. Powszechnie używanych) i dobrze udokumentowanych języków mogłoby być bardziej odpowiednie tutaj. JavaScript lub Python mogą być dobrym rozwiązaniem tutaj.

Integracja przepływu pracy - jeśli masz konkretny potok produkcyjny z już istniejącymi narzędziami, złym pomysłem może być użycie języka, który wydaje się działać najlepiej w danym przypadku, jeśli inne narzędzia działają z zupełnie innym. Jest to szczególnie ważne, jeśli kilku programistów pracuje nad różnymi narzędziami. W takim przypadku bardziej efektywne może być użycie języka „niezupełnie”.

Jeśli pracujesz nad tytułem dla systemu Windows i piszesz zarządzany kod działający w środowisku Common Language Runtime (CLR) - powiedzmy np. W języku C # - sugeruję przyjrzenie się integracji (żelaznego) Pythona jako języka skryptowego.

Z mojego doświadczenia, Python jest bardzo łatwy do nauczenia dla nie-programistów / projektantów. Jeszcze łatwiej jest go wybrać dla programistów, ponieważ zasadniczo czyta się jak pseudokod. Dynamiczne pisanie na maszynie jest tylko jednym z aspektów, które pomagają szybko i szybko uruchomić ludzi z tym językiem.

Oprócz tego, że język jest łatwy do nauczenia się i potężny, CLR i zespoły językowe w firmie Microsoft (Anders Hejlsberg, Eric Lippert, Mads Torgersen, Jim Hugunin i in.) Wykonali świetną robotę, pokazując funkcje kompilatora i środowiska wykonawczego za pomocą nowego Dynamic Language Runtime (DLR) w .NET 4, dzięki czemu współdziałanie między kodem statycznym a kodem dynamicznym jest znacznie prostsze. Z tego, co widziałem i wypróbowałem do tej pory, kod płyty głównej jest zredukowany do minimum. Utrzyma twoją bazę kodów w czystości i utrzymaniu.

Możesz to wykorzystać, aby utrzymać tarcie między skryptowymi częściami gry a silnikiem na bardzo niskim poziomie. Uruchomienie obu w tej samej maszynie wirtualnej pozwoli również środowisku wykonawczemu zoptymalizować więcej kodu podczas wykonywania.

Odpowiedź zależy w dużej mierze od twojego środowiska. Obecnie pracuję z Unity, więc używam języka opartego na mono (w moim przypadku C #, ale Javascript i Boo są również opcjami). Odpowiedź zależy całkowicie od konkretnych okoliczności.

ActionScript to hybrydowy język o typie dynamicznym / statycznym używany do tworzenia gier Flash, który może być szeroko rozpowszechniany w Internecie. Jest dość dobrze obsługiwany w bibliotekach takich jak Flixel, FlashPunk i Box2d.

Jeśli masz istniejący zespół, który będzie korzystał z języka skryptowego lub główny projektant (poziom), który będzie korzystał ze skryptów, wybierz dowolny język. Będą spędzać z tym czas, więc należy się nimi zająć.

[ziarno soli] Jeśli nie masz nikogo lub nie planujesz długoterminowo, rzuć własnym . tak, napisanie kompilatora i / lub interpretera dla języka skryptowego może potrwać tydzień lub dwa, ale w dłuższej perspektywie elastyczność zapłaci wiele razy. Po prostu nie idź na manowce i wymyśl pieprzone mózgi. [/ziarnko soli]