Что такое скрипты и с чем их едят — Lua & C++

Нехорошо-то как! Редактирую пост несколько раз, выпускаю его на публичное осмотрение, а там автозавершение — вот такое было

	script.DoFile("script.lua");
	script.Close();

	// Пауза после скрипта
	_getch();
}
</lua_cfunction></lua_cfunction></lua_cfunction></lua_cfunction></lua_cfunction></int></int></char></char></time.h></windows.h></conio.h>

Хорош Lua, но не по душе мне паскалеподобный синтаксис, в свое время я выбрал язык Squirrel для своих скриптов.

А как вам мой вариант? habrahabr.ru/post/165765/
Я писал библиотеку, пытаясь облегчить написание биндингов, и, обходясь только C++11, не используя кодогенераторы.

А вообще, попробуйте swig, в нем с поддержкой lua, конечно, не всё гладко, но возможности впечатляют.

Кажется, автозавершение кода забаговано.
Иначе куда делись template<>, раз вместо них стоит template? :)

Скриптовый язык это классно, но необходимость общения через виртуальную машину съедает все профиты для среднесложного проекта. Проще написать какой-нибудь редактор XML и свой рудиментарный псевдоязык, который будет уметь десяток простых комманд, чем биндить в VM скриптового языка весь набор нужных классов, функций и объектов.
Отчасти поэтому многие не сильно сложные игры пишутся целиком на Lua.

Как можно в 21м веке использовать методы Create и Close вместо конструктора с деструктором?

Первая мысль — написать свой интерпретатор своего скриптового языка, выкидывается из мозга через несколько секунд. Логика игрока определенно не стоит таких жутких затрат.

Тут есть подвох. Ядро языка писать несложно, никаких больших затрат там не случается. А вот «вывести концы» собсвтенно объектной модели так, чтобы ей мог с удовольствием пользоваться скриптер, — вот это задача намного более сложная и интеллектоемкая. И она не решается простой прикруткой Луа, Питона или чего угодно еще.

Первый мой опыт в этой области касался AngelScript. Ну, это было давно, Луа еще был не на слуху, а вот этот ангельский скриптец казался нам тогда вполне годным. К тому же у него был сиподобный синтаксис, что с нашей программистской точки зрения было несомненным плюсом. Мы прикрутили скриптовый движок и тупо вывели интерфейсы один в один, но не все. Получилось, что у нас есть язык, на котором предполагается писать логику игры, который хуже чем плюсы, имеет меньше возможностей, чем плюсы, но при этом похож на плюсы и чтобы пользоваться им, надо знать плюсы. Скриптеры посмотрели на это дело, сказали: «как-нибудь в другой раз». В итоге сцены на всем этом мы же и писали, потому что больше некому.

Следующий опыт касался как раз Луа. Прикрутили Луа, дали скриптерам, они засели и быстро-быстро настрочили тонну говнокода. Им положено, они не программисты, они геймдизайнеры, им по штату положено делать сцены, а не код рефакторить. Естественно, вскоре застряли во всем этом и опять же разгребать все пришлось нам, программистам.

А вот в третий раз от меня ненадолго отвернулось начальство, и, пока никто не видит, я внезапно написал собственный язык с блекджеком и шлюхами. Точнее, писал его не я, я только программировал. Сам язык создавал по-сути Женя Гомельский, геймдизайнер, который просто знал, чего хочет и умел это сформулировать. Язык получился местами очень даже ничего. Там были предлоги, похожие на именнованные параметры в Обджектив-Си, местоимение «it», как в Хаскелевском ghci, метапрограммирование в стиле миксинов Ди, и даже некоторые уникальные вещи, как, например, переменная по умолчанию. Ну, можно было, например, написать цикл так: [for {i=0} {i++; i<10}], а можно так: [10x]. Во втором случае счетчиком цикла считалась переменная по умолчанию "?".

Мы выпустили с ним пару проектов, вполне между прочим успешных, а потом перешли на новую платформу и забросили скрипты вообще в пользу машины состояний и визуального программирования. И, честно сказать, это было определенное облегчение. Писать языки надо уметь, я не умею. Кроме красивых фичей, он закономерно оброс костылями и велосипедами. Если код на языке был вполне даже читаем, то код самого интерпретатора заболотило по самые осины. Его стало очень сложно поддерживать. Причем, не само ядро, конечно, там-то как раз ничего сложного изначально не было, а вот все эти «концы». Например, в одном проекте меню выезжает справа, в другом — снизу, и в язык попадают, условно говоря, две взаимоисключающие функции для красивого выезда меню. И вот так вот все.

То есть, какой вывод я хочу сделать. Программировать сложно. Без опыта и усердия любой выбор скриптового решения приведет к говну и костылям.

А туториал годный, кстати.

Плохая статья! Автор, для кого была написана эта статья? Если для тех к то не знаком с Lua, то она вообще ничего не объясняет и только запутает. Если для тех кто знаком с Lua, то тут вообще ничего полезного кроме как боле менее удобный способ получение аргументов функции (удобнее чем просто из стека руками вытаскивать), который приводится в любой статье про Lua + C++.

Давайте честно, если вы собираетесь вытащить бизнес логику в скрипты то наверно вам как минимум нужно перебросить на ту сторону игровые объекты, что бы из скриптов можно было бы работать именно с объектами а не свободными функциями. Я бы мог продолжать дальше, но это будет слишком долгий список.

В общем еще раз задумайтесь для кого эта статья и что вы хотели в ней описать.