Lua и C++: разделение обязанностей
Помогите классифицировать способы организовать C++/Lua игровой код и разделить их обязанности. Каковы наиболее удобные способы, какой Вы используете?
Например, Lua может использоваться для инициализации объектов C++ только или при каждом игровом повторении цикла. Это может использоваться для игровой логики только или для графики, также. Некоторые игровые механизмы предоставляют полный контроль всем подсистемам из сценариев! Мне действительно не нравится этот подход (никакое разделение вообще).
Действительно ли это - хорошая идея реализовать все игровые объекты (npc, местоположения) как таблицы Lua без объектов C++? Или лучше зеркально отразить их (таблицы Lua для управления объектами C++)? Или что-то еще?
Спасибо.
Править. Моя классификация: Lua и C++: разделение обязанностей.
Продолжение темы: Lua, игровое состояние и игровой цикл
3 ответа
Мой подход заключался в том, чтобы ограничить то, что подвергается воздействию Lua как можно больше. Я никогда не встречал необходимости в «главной» или другой подобной функции, которая вызывается каждый раз при рендеринге сцены (или более). Однако некоторые движки Lua (например, LOVE) делают это. Я предпочитаю определять объекты с дополнительными функциями обратного вызова для общих событий, на которые вы можете захотеть, чтобы объект реагировал, например, на столкновение, щелчок мышью, вход или выход из игрового мира и т. Д.
Конечный результат очень декларативен, почти конфигурационный файл для объектов. У меня есть функция для создания классов или типов объектов и еще одна для создания объектов на основе этих типов. Затем у объектов есть набор методов, которые можно вызывать при ответе на различные события. Все эти методы Lua сопоставляются с методами C / C ++, которые, в свою очередь, изменяют частные свойства объекта. Вот пример объекта ведра, который может захватывать объекты шара:
define {
name='ball';
texture=png('images/orb.png');
model='active';
shape='circle';
radius=16;
mass=1.0;
elastic=.7;
friction=.4;
}
define {
name='bucket';
model='active';
mass=1;
shape='rect';
width=60;
height=52;
texture=png('images/bucket.png');
elastic=.5;
friction=.4;
oncontact = function(self, data)
if data.subject:type() == 'ball' then
local a = data.subject:angleTo(self:getxy())
if a < 130 and a > 50 then
--update score etc..
end
end
end;
}
Я бы не стал рассматривать это как «единственный верный способ» реализации вашего скриптового API. Одно из достоинств Lua заключается в том, что он поддерживает множество различных стилей API.Это как раз то, что я обнаружил, хорошо работает для игр, которые я делаю - игры, основанные на 2D-физике.
Начните с малого. Разрешите доступ к игровым объектам, чтобы вы могли выполнять сценарии, специфичные для карты / уровня. Поведение, которое единообразно на всех картах / уровнях, вероятно, не требует написания скриптов.
Также разрешайте доступ только к общедоступному интерфейсу ваших объектов.
Предлагаю такую классификацию:
Экстремальный вариант: скрипты Lua управляют всем (логика игры, графика, AI и др.). Более того: скрипт работает как host-программа, владеет игровым циклом. Некоторые двигатели так поступают. Ба-ад: никакого разделения обязанностей и безопасности сценария.
Скрипты Lua поддерживают состояние игры и обрабатывают игровую логику. Вероятно, скрипты вызываются на каждой итерации игрового цикла.
Скрипты Lua редко используются для инициализации, настройки и обратного вызова. Хост-программа предоставляет (связывает) очень минималистичный интерфейс для скриптов. Итак, скрипты строятся из таких хорошо продуманных и предоставленных блоков.