Jaki język skryptowy powinienem wybrać dla mojej gry? [Zamknięte]


53

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ź)

Odpowiedzi:


39

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.


8
Lua jest bardzo popularny, ponieważ zapewnia funkcje „metajęzyka”. Możesz zaimplementować struktury obiektowe lub funkcje czysto proceduralne itp. Ma bardzo prosty interfejs C i zapewnia programistom silnika dużą elastyczność w samym języku.
Karantza

3
Nie jestem przekonany, czy python byłby dobrym wyborem. Powiązania C dla Pythona są znacznie bardziej ukierunkowane na rozszerzenie Pythona o C, a następnie osadzenie Pythona w C.
SpoonMeiser

5
Z tego, co słyszałem, Łua ma również dobrą wydajność w czasie wykonywania w porównaniu do innych języków skryptowych, takich jak Python. (i ma pełne wsparcie dla zamknięć - naprawdę fajna funkcja, jeśli mnie zapytasz ..)
thbusch

2
W rzeczywistości Civilization IV używa Pythona ...
Emiliano,

2
@happy_emi Rzeczywiście, podczas gdy Civ V używa Lua
Tobias Kienzler,

22

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.


9

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.


Jeden oszust dla mnie był rozmiarem. Jeśli budujesz prostą / swobodną grę, silnik v8 jest dość duży, a nawet może być wiele razy większy niż cała gra.
Zack The Human

To prawda, ale czy jest to poważny problem jako samodzielny plik .lib? Po prostu umieszcza się obok SDL lub lua. Jeśli miałeś na myśli wygenerowany rozmiar kodu, cóż, nie testowałem jego wielkości, ale to nie jest zły punkt.
odkrycie podkreślone

Miałem na myśli wygenerowany rozmiar kodu. Podejrzewam, że nie jest tak duży, biorąc pod uwagę rozmiar większości dzisiejszych gier.
Zack The Human

1
Testowany, domyślny shell.cc z najnowszymi zegarami SVN w 1.441 MB bit.ly/9DNn8J . Chociaż wydaje się to dość duże, większość bibliotek potrzebnych do zrobienia czegokolwiek innego (sieci, grafiki) doda do tego równie dramatycznie. Mój poboczny projekt z wersjami v8, phoenixGL, ENet, pakietami doładowania i wieloma innymi kodami wewnątrz rozwiązania (takimi jak kompresja, szyfrowanie, biblioteki GUI, awesomium) osiąga 2,5 MB w Visual Studio 2008 - i jest zapakowany w „ release ”buduje wagi w 861 KB. Dla mnie nie jest tak źle. Na niektórych platformach widziałem, że jest to kłopotliwe - choć nie dla większości :)
underscorediscovery

1
Użyłem V8 kilka razy wcześniej w moich projektach. IMO Javascript jest najbardziej idealnym językiem dla skryptów gier. Natura oparta na zdarzeniach i obiekty oparte na prototypach sprawiają, że wszystko jest takie proste. :)
Stephen Belanger

7

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.


JavaScript to naprawdę dobry pomysł. Zastanawiam się, dlaczego wydaje się, że nie ma przyczepności w tej przestrzeni? Jakieś pomysły?
cflewis

JavaScript ma przyczepność. Unity tego używa. Podobnie jak Wolfire Games dla ich silnika.
AA Grapsas

Dwa silniki naprawdę nie zapewniają przyczepności. Sądzę, że powodem, dla którego jest to dopiero ostatni rozwój, jest to, że nie było wielu dobrych interpreterów JavaScript przed Mono i V8. SpiderMonkey nie jest dokładnie tym, na co patrzysz i mówisz: „Tak, chcę, aby moja gra była tak szybka, chuda i stabilna!”

4

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.


4
Pamiętaj, że jeśli tworzysz konsolę, kod JITing najwyraźniej nie wchodzi w rachubę, ponieważ nie możesz oznaczyć stron danych jako wykonywalnych. IL musi być wstępnie skompilowany na platformie docelowej.
Jeff

3
Problem JIT dotyczy także systemu iOS. Również Mono ma ograniczenia licencyjne. Potrzebujesz licencji komercyjnej, jeśli chcesz korzystać z niej w środowisku, w którym użytkownik końcowy nie może / nie może zaktualizować środowiska wykonawczego Mono.
Sam

4

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.


2

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.


2

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.


1

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.


0

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


0

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.


0

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.


-2

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.


-2

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]


Napiszę interpreter lub kompilator jit w haskell dla czegoś takiego jak lisp / schemat lub bash lub python lub lua lub erlang (cokolwiek bez standardowych bibliotek) w ciągu jednego lub dwóch dni. Nie sugerowałbym pisania interpretera np. W C ++ lub Javie, o ile nie służy on do interpretacji czegoś takiego. Ale tak czy inaczej to nie było pytanie.
comonad

Myślę, że pytanie było bardziej ukierunkowane na zalety i wady języków skryptowych, a nie na to, jak zdecydować, który z nich użyć. Myślę, że nadal jest pomocny.
Michael Coleman
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.