Думаю можно чутка поднять тему и расписать пару моментов, которые будут полезны в целом для любого проекта:
1. Lua -> C++ -> Lua
Соль: Конвертации данных из Lua в C++/C++ в Lua - не особо дешёвое удовольствие. Давайте рассмотрим на примере ПЫС функции в оригинале и энхансед (спасибо ребятам из Матабу за один из лучших примеров):
Оригинал:
-- Достигнут ли я отрядом выбравшим меня как цель.
function se_smart_terrain:am_i_reached(squad)
local squad_pos, squad_lv_id, squad_gv_id = squad:get_location()
local target_pos, target_lv_id, target_gv_id = self:get_location()
if game_graph():vertex(squad_gv_id):level_id() ~= game_graph():vertex(target_gv_id):level_id() then
return false
end
if IsMonster(alife():object(squad:commander_id())) and squad:get_script_target() == nil then
return squad_pos:distance_to_sqr(target_pos) <= 25
end
return squad.always_arrived or squad_pos:distance_to_sqr(target_pos) <= self.arrive_dist^2
end
Матабу эдишен:
-- Достигнут ли я отрядом выбравшим меня как цель.
function se_smart_terrain:am_i_reached(squad)
local squad_pos, squad_lv_id, squad_gv_id = squad:get_location()
local target_pos, target_lv_id, target_gv_id = self:get_location()
if gg_vertex_level_id(squad_gv_id) ~= gg_vertex_level_id(target_gv_id) then
return false
end
if IsMonster(alife():object(squad:commander_id())) and squad:get_script_target() == nil then
return squad_pos:distance_to_sqr(target_pos) <= 25
end
return squad.always_arrived or squad_pos:distance_to_sqr(target_pos) <= self.arrive_dist^2
end
> if game_graph():vertex(squad_gv_id):level_id() ~= game_graph():vertex(target_gv_id):level_id() then
Что ж тут такого страшного, что это решили переделать?
Стучим в C++ (game_graph()) -> возвращаем в луа -> стучим в C++ vertex(squad_gv_id) -> возвращаем в луа -> Стучим в C++ level_id() -> возвращаем в луа.
Итого, на левую часть условия происходит порядка ~7 конвертаций данных туда и обратно. И грубо говоря единая C++ функция gg_vertex_level_id(squad_gv_id) будет иметь всего ~3 конвертации, что кратно дешевле.
Да, это всё "спички", если не обращать внимание на кол-во таких вызовов в тике.
2. Файлы логики (да гори оно огнём)
И речь тут пойдёт не столько о сложных схемах, сколько о кол-ве символов на операцию.
Логика в X-Ray имеет свой кастомный лексер, который по факту перебирает посимвольно каждую операцию, что вы туда вбиваете. Помимо самих символов - роляет и содержание. Если у Вас есть сложные условия с несколькими инфопорциями или скриптовыми кондишенами - схлопните в одну Луа функцию. Такой код будет дешевле для понимания системе xr_logic. Ибо он всё равно будет "генерить" функции для переваривания ваших кондишенов.
3. Рестрикторы - Наследие ПЫС
string4096 m_temp;
for (u32 i=0, n=_GetItemCount(*restrictions); i<n; ++i)
if (!xr_strcmp(restriction,_GetItem(*restrictions,i,m_temp)))
return (true);
return (false);
Это кусок кода из апдейта рестрикторов.
В чём соль:
Сюда приходит название рестриктора и огромная строка со списком всех рестрикторов на локации через запятую.
_GetItem итеративно перебирает огромную строку в поиске нужной. Посимвольно. С первого символа. Каждый. Раз.
По хорошему, это лучше исправить в самом движке. Но для модмейкеров могу сказать лишь одно: компактные названия рестрикторов имеют смысл.
Сорри, лишний раз поднимать это всё не было желания. Да и говорить о том, к чему я не причастен - только сплетни по кругу гонять. Надеюсь на нормальный ремейк без CoC систем..png)
