главное чтоб была нормальная холодная питьевая вода

и корочка хлеба

А мне сказали: правила одни на всех!

Какие нафиг правила, а если это удалёнщики, может они на пляже сидят и в скайпе пишут. Ну и кроме того, пусть они определятся, в чём их главная задача — косить бабло, или следовать правилам.

на Мальте тепло и море

как я вас понимаю...

Да, в американке есть игра с руки, после забития битка в лузу можно играть с произвольной точки на столе, разбивать пирамиду вначале можно с любой точки на половине стола. В снукере есть игра из сектора. Перед ходом в американке, по правилам, нужно указать прицельный шар и лузу. В большинстве игр биток только один (белый обычно), в русском бильярде может быть любой шар. Вылетевший шар не во всех играх возвращается. Можно также играть и без соблюдения правил, не обращая внимания на фолы, принудительного следования правилам там нет. Скриптовать можно не только правила, всю полностью логику можно было бы написать на скрипте, без потери производительности, что в дальнейших проектах и было реализовано.

Трение о полотно и подкрутка движком конечно учитываются. Для рендеринга физики используется движок от newtondynamics с некоторой кустомизацией, разработанный для расчётов физики сплошных твёрдых тел. Если ударить не по центру шара, в любом случае будет подкрутка. Если это удар сбоку (боковик), шар можно подкрутить так, чтоб катился по дуге, и на эту тему в игре есть даже один простой бильярдный фокус, боковик от борта, когда шар ударяет в борт, обходит по дуге другой шар, и забивает в лузу ещё один.

Battle Of Europe писал не я, это проект был до меня. Игра вообще сделана со вкусом, хоть и не выдерживает конкуренции с «ИЛ-2 штурмовик», появившейся позже. Все модели — разработаны в 3ds max, используются в своём формате (для чего написан плагин под max), а весь код в игре полностью на С++. Только интерфейс описывается скриптом, но не исполнительным, а декларативным. Так же как и в бильярде в дальнейшем, поскольку юзается один движок. Уровни программировал тот же разработчик, который писал и остальной код, и помимо уровней там и других задач достаточно.

А какая нужна скриптовая логика для бильярда?

Есть порядка 50 видов бильярдных игр с разными правилами, в симуляторе заложены наиболее распространённые: 8-ка (на американском столе), 9-ка, русский бильярд (русский стол), карамболь (французский стол, без луз), снукер (английский, снукерный стол), и некоторые ещё. Правила игр вполне чёткие, и строго в соответствии им были запрограмированны. Там есть «ядро» геймплея на столе, которое посылает в «оболочку» правил игры события: коллизия между 2 шарами, шара с бортом, с фишкой, попадание в лузу, вылет за борт и т.п. Дальше витиеватая логика решает, как на это реагировать. Также сделана реальная физика бильярдных ударов: можно менять силу удара, точку удара по битку, угол наклона кия, и таким образом, делать боковики, удары накатом, оттяжку. Разве что пихать кием биток нельзя, но это всё равно запрещено правилами. Шары при некоторых ударах могут прыгать, и вылетать за борт. Эргономика управления кием на мой взгляд очень удобная. Ещё в игре предоставляется делать некоторые бильярдные трюки, я подобрал наиболее зрелищные, не связанные с лишними махинациями на столе. Например «бабочка» — когда 6 шаров 1 ударом разлетаются в лузы. Соответственно, рассчитаны позиции, показывается пример (можно замедленной съёмкой) и даётся возможность повторить.

написать игру на движке Unity в жанре Tower Defence за 2 дня, минимум 2 уровня

Ну ты хоть спала между 1-м и 2-м днём?

Раньше я работал на soft-Xpansion (бывший Maus software), где главным образом писал код 3D симулятора бильярда, затем перешёл в небольшую команду с разработкой игр для казино. С soft-Xpansion срок NDA истёк, со второй командой не подписывал, поскольку основной разработчик C++, неуместно как-то :)

В проекте «Battle Of Europe» выпущенном в 2006 года от soft-Xpansion скриптование вообще не использовалось, уровни со всеми данными и логикой — написаны на C++. И там проблема даже не в инициализации объектов, как в самом вермешелеобразном коде геймплея. Один из switch с перебором состояний и деревьями условий например занимает порядка 3000 строк. При любом изменении логики состояний, что-то меняется во многих местах такого кода, и это всё надо тестировать. Это одна из причин, почему логику лучше скриптовать.

В проекте бильярда правила игр уже скриптовались, правда уровень абстракции хостового API небольшой. Инициализация «уровня» (комната, стол, кий, шары) делается в скрипте, там же прописаны функции-отклики на события. В дальнейшем, в играх для казино уровень абстракции уже достаточный, чтобы можно было написать полностью новую игру без изменений в коде на С++ (никаких функций-откликов на события и колбэков — нет). Хостовый код и движок конечно при этом постоянно развивается, без привязки к каким-либо данным или логике игр. Если сопоставить трудоёмкость, где-то 80% времени занимает скриптование логики, по сравнению с модификациями движка.

Насчёт рендеринга. В 3D строится граф объектов (мешей, источников света), при графическом рендеринге движок обходит граф, и отрисовывает узлы каждый кадр. Но сначала физический рендер пересчитывает физические параметры, определяет коллизии. Также каждый кадр возобновляется работа ряда Lua-коротинов, которые выполняют какой-то квант работы над каким-то объектом (перемещают, поворачивают), собственно именно в них и крутится вся логика. Стоимость вызова функции хостовой C++ точно такая же, как и стоимость вызова любой стандартной функции. luabind лично я не использую по ряду причин, для связки юзаю модифицированный класс Luna, который лежит где-то на официальном сайте от разработчиков lua. К тому же это больше возможностей, хостовые функции могут например принимать и возвращать переменное число аргументов и разных типов, в зависимости от ситуаций. JIT компилятор использовать идея хорошая, только он не поддерживает спецификацию 5.3. Даже без JIT выдаётся вполне приличный FPS, без вертикальной синхронизации на Core i7 порядка 1200-1800 кадров в сек. Поскольку полигонов немного по современным меркам, видюха значения не имеет. Чтобы свести к минимуму работу скриптов, некоторые операции над объектами выполняются над списком сразу. Ну и естественно, инициализация всего по возможности выносится на период загрузки ресурсов, все ресурсы — кэшируются.

Дизайнеры работают в основном под 3DS MAX и в фотошопе, и под это затачивается разработка. Ну разве что только в высокобюджетных проектах есть отдельно взятые дизайнеры уровней, которые сидят в специально для них сделанных редакторах уровней, типа Far Cry, и прочие люди с узким кругом задач.

Общая схема такова. Есть небольшая надстройка над движком, которая поставляет хостовый API для скриптов. Если архитектура организована правильно, то хостовый API на C++ выполняет только низкоуровневые нагруженные операции, а вся логика крутится в скриптах. Для всех объектов создаётся репрезентация в Lua-скриптах, где определяются все свойства, логика поведения и вобщем весь геймплей. Например, создаётся userdata-объект, биндится загруженным из ресурсов мешем, инициализируется согласно какой-то логики нужными значениями, и дальше скрипты как-то крутят его в общей сцене. Скрипты можно компилировать и выполнять в рантайме, и соответственно прямо на лету можно редактировать свойства и логику.

Что, вручную создавать GUI-редактор (и, что ещё хуже, поддерживать его) для каждого-каждого класса, которых в игре могут быть около сотни?

Могу подсказать решение этой проблемы, если вам интересно. Не нужно вообще никаких редакторов, достаточно просто иметь возможность изменять скрипты в рантайме. А это сделать несложно. Тогда вы будете не только менять константы на лету, но и алгоритмы.

почему не попросили пофиксить проблему?

Тогда уже не отвертеться, пришлось бы соглашаться на 5000$, сами понимаете...