Czy warto uprościć silnik gry oparty na postaciach do tego stopnia, że ​​nauka pisania skryptów / programowania nie jest konieczna?

Pamiętam i nadal uważam, że nie można nawet stworzyć prototypowej gry 3D, aby przetestować proste zachowania bez użycia gigantycznych narzędzi, takich jak jedność lub znajomość obszernego programowania w C ++, wzorców projektowych, przyzwoitego lub podstawowego silnika 3D itp.

Teraz zastanawiam się, ponieważ znam programowanie, czy mam więcej szczęścia niż ci, którzy muszą nauczyć się programowania, zanim będą wiedzieć, jak coś zrobić. Nawet skrypty, takie jak Unity, nie są przeznaczone dla dzieci i, moim zdaniem, mają tendencję do dyktowania swoich sposobów działania. Nie dotyczy to silnika takiego jak Ogre lub Irrlicht.

Teraz myślę, że gry oparte na postaciach zajmują dużą część rynku gier. Czy uważasz, że dobrym pomysłem jest stworzenie silnika zorientowanego na kontrolę postaci, który pozwala budować sztuczną inteligencję jedynie z wyłączeniem czegokolwiek innego?

Kiedy mówię prototyp, mam na myśli również „ogólny” w tym sensie, że można szybko wybrać zestaw parametrów gry, takich jak menedżer scen, POV kamery odtwarzacza, elementy sterujące, niektóre bardzo podstawowe zderzenia / fizyka i integracja podstawowego sterowania (na przykład OpenSteer). Główną ideą jest stworzenie piaskownicy AI, ale w 3D, dzięki czemu można ją zademonstrować bez ograniczeń 2D (a także lepiej dopasować do prototypu w 3D dla projektu 3D zamiast 2D).

Naprawdę podoba mi się niedoceniany silnik gry w Blenderze. (http://www.blender.org) Model czujnik-kontroler-urządzenie wykonawcze jest naprawdę łatwy do naśladowania, nawet dla nie-programistów, i możliwe jest stworzenie dość kompletnej gry (poruszanie animowaną postacią, strzelanie z broni, niszczenie celów , pokaż wynik, śledź stan zdrowia, zresetuj poziom lub przejdź do nowego) bez żadnego programowania.

Oczywiście, niektóre rzeczy wymagają programowania (zwłaszcza uzyskiwania wejścia myszy do FPS.) Jednak blender już zawiera Python, a skrypty Pythona są bardzo ładnie powiązane z modelem, więc nigdy nie musisz zastępować czujników-urządzeń wykonawczych Pythonem. Zamiast tego wystarczy przejść z bardzo prostego kontrolera „pass-through” na kompletny skrypt Pythona, który może odczytać wszystkie czujniki w scenie i przekazać sterowanie wszystkim siłownikom.

W ciągu kilku dni w Blenderze jest całkiem możliwe stworzenie prototypu gry (zrobiłem to dla projektu w lokalnym muzeum dla dzieci w zeszłym roku).

Oczywiście nic nie zastępuje dobrej starej wiedzy programistycznej i ostatecznie programista musi zrozumieć programowanie.

Niezależnie od mechanizmu wejściowego, pod koniec dnia nadal musisz skonfigurować jakiś sposób, aby powiedzieć grze, jaka jest logika. „Skrypty” to dobry termin na to. Zasadniczo więc nie zgadzam się z twierdzeniem, że można uprościć coś do tego stopnia, że ​​nie trzeba znać „skryptów”.

Biorąc to pod uwagę, nie wszystkie skrypty muszą być wykonywane przy użyciu tekstowego języka programowania. Było trochę pracy (ale niewiele) nad stworzeniem wizualnego systemu skryptowego. Narzędzie skryptowe na poziomie Unreal, Kismet, jest całkiem dobrym przykładem. Mechanizm źródłowy ma podobną mechanikę, ale wykorzystuje byty na świecie zamiast na płaskiej płaszczyźnie.

Zasadniczo masz pola, które przeciągasz w jakimś środowisku, które ma dane wejściowe i wyjściowe. Jeśli potrzebujesz jakiegoś rozgałęzionego wyjścia, masz jakieś pole, które ma jedno wejście i wiele wyjść. Te dane wyjściowe mogą przejść do działań, które mają powiązane z nimi dane (tj. „Przejdź do tego punktu”, „powiedz tę linię”, „zadaj to pytanie” itp.). Zazwyczaj jest to znacznie niższa bariera wejścia, aby uruchomić coś w języku wizualnym, ponieważ nie musisz znać słów kluczowych ani składni, masz tylko ograniczony zestaw pól do wyboru, z których wszystkie mają określone zachowania, a po prostu połącz je razem.

Jednak moim zdaniem silniki skryptów wizualnych nie są tak naprawdę warte kłopotów. Musisz być w stanie myśleć uporządkowany i logicznie, aby skutecznie powiedzieć silnikowi, co chcesz zrobić. Jeśli możesz tak myśleć, przeskakiwanie z pól z wejściami / wyjściami do podstawowych instrukcji rozgałęzień i wywołań funkcji w języku skryptowym nie jest aż tak wielkim problemem. W rzeczywistości część wizualna jest prawdopodobnie przeszkodą. Plus, to dużo więcej pracy po stronie silnika. Musisz robić takie rzeczy, jak implementacja cofania, kopiowania / wklejania, może mieć jakieś funkcje wyższego poziomu do organizowania skryptów. W języku tekstowym możesz pozostawić to wszystko IDE.

Zasadniczo będzie to kompromis. Jeśli naprawdę chcesz usunąć potrzebę wykonywania jakiegokolwiek skryptu, zwykle mówisz o stworzeniu jakiegoś interfejsu, który połączy skrypty w tle (lub po prostu połączy obiekty logiczne, czy coś takiego). Istnieją całe gry, w których jest to ich sedno, dobrze zdefiniowane środowisko, w którym przeciągnij i upuść funkcjonalność, aby zobaczyć, jak z nią współdziała.

Jednak na koniec dnia zawsze będzie to kompromis. Im prościej jest uczynić interfejs, tym bardziej uproszczone są rzeczy utworzone za pomocą tego interfejsu.