Мой подход состоял в том, чтобы максимально ограничить то, что подвергается воздействию 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.