Читатель, некоторое представления на эту тему ты уже имеешь. Например, известный факт, что если не удалять созданные спецэффекты, то игра через некоторое время начнет сильно тормозить. Поэтому, даже если спецэффект мгновенного действия и через некоторое время уже не виден, его все равно нужно удалять. Почему так происходит? Потому что каждый спецэффект - это игровой объект. Когда мы создаем новый спецэффект, он попадает в память. Если его не удалять, то он останется в памяти до конца игры.
Аналогичная история с юнитами в ТД, Дотах или Аеонах. Умершие юниты должны быть удалены действием Remove Unit, чтобы не занимать место в памяти.

Оказывается, что такая же ситуация наблюдается и с остальными игровыми объектами. Предметы, декорации, регионы, точки, группы юнитов, плавающий текст, модификаторы видимости - все они с тем же успехом способны засорить память. Да, конечно объект типа точка занимает в памяти гораздо меньше места, чем юнит - в точку нужно записать только координаты X и Y, а в юнит - все его параметры. Но, вообще говоря, утечки в памяти склонны к накоплению. И постепенно игра становится все более тормознутой.

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

Результат не заставил себя ждать. Через 2 минуты работы сценария, начиналось такое торможение, что дальнейшая игра не имела смысла. Я догадывался об утечках памяти, пытался сделать все проще и эффективнее. Удалось увеличить период игры с 2-х до 5 минут. Да и то, при условии, что играет 1 человек, а ведь чем больше - тем хуже. Разгадку утечки помог найти Alexey B.H.

Дело было в том, что для вычисления координат юнита я использовал стандартные операции worldedit с полярными координатами. А сделаны они, как оказалось, очень коряво. Каждый раз, когда ты используешь функцию point with polar offset, в игре создается новый объект типа точка. Обычно, даже не один, а два объекта. А теперь представь, что у нас работает периодический триггер, запускаемый 20 раз в секунду. И при каждом запуске, создаются новые объекты, которые не будут удаляться до конца игры. 40 точек в секунду, все равно что 80 параметров типа real. А если функцию полярных координат применять не один, а несколько раз в периодическом триггере (к примеру, чтобы вычислить положение камеры), да еще и вычислять координаты для 4-ех игроков - то... Получаем торможение игры.

Вариант устранения утечки подсказал Какодемон. К примеру, если мы хотим вычислить полярные координаты точки, полученной из точки p заданной положения юнита u при угле a равном углу между точкой p и какой-то точкой p2. Для этого можно воспользоваться действиями:

set p = GetUnitLoc(u)
set a = AngleBetweenPoints(p, p2)
call MoveLocation(p, GetLocationX(p) + 50 * CosBJ(a), GetLocationY(p) + 50 * SinBJ(a))

Теперь давай проанализируем. Сначала мы переменной p присваиваем положение юнита u. Следующим действием мы ПЕРЕМЕЩАЕМ точку p в другое место. А что это за место? Вообще, в чем суть команды MoveLocation?
Если бы мы написали

call MoveLocation(p, 10, 15) 

то координаты точки p стали бы (10,15)
Если бы мы написали

call MoveLocation(p, GetLocationX(p) + 50, GetLocationY(p) + 60) 

то точка p сместилась бы на вектор (50,60) относительно текущего положения.
А форма записи

call MoveLocation(p, GetLocationX(p) + r* CosBJ(a), GetLocationY(p) + r * SinBJ(a))

означает, что точка p сместится в точку, полученную пересечением окружности радиуса r и луча, проведенного из точки p под углом a. Т.е. это и есть по сути полярные координаты.
Если известно положение текущей точки (X,Y) и нужно найти координаты точки, полученной из текущей при смещении в направлении a на расстояние r – то ее координаты будут (X+r*cos(a), Y+r*sin(a)). Это все известные в математике факты.

Но в чем преимущество нового метода по сравнению со стандартной функцией вычисления полярных координат? Преимущество в том, что МЫ НЕ СОЗДАЕМ НОВУЮ ТОЧКУ, чтобы вычислить полярные координаты. Вместо этого мы ПЕРЕМЕЩАЕМ СУЩЕСТВУЮЩУЮ ТОЧКУ.

Есть конечно еще один нюанс. Обрати внимание на команду:

set p = GetUnitLoc(u) 

Присваиваем точке p положение юнита u. Но переменная со ссылкой на объект и сам объект - это разные вещи. До этого действия, переменная p была пустой. Объект точка с положением юнита не существовал. После действия, переменная p начала ссылаться на какую-то точку. Какой вывод? Игра создала объект типа точка и сделала на него сслыку в переменной p. Т.е. даже когда ты используешь элементарную функцию - определит положение юнита, в игре создается объект. И он тоже засоряет память - и это тоже станет заметно в триггерах с малым периодом.
Чтобы окончательно избавиться от утечки, необходимо применить действие для удаления объекта типа точка из памяти. В триггерах ты такой команды не найдешь. В jass эта команда выглядит следующим образом:

call RemoveLocation(p) 

Можешь посмотреть, как это сделано в примере, который я выслал в прошлый раз.

Ну, вроде с утечкой из-за точек разобрались. Но, увы, есть и другие виды утечек. Группы юнитов. Вообще-то есть переменные типа unit group. Это из той же серии. Переменная есть ссылка. А на что ссылается переменная unit group? На некий объект. Делаем выводы: объекты, на которые может ссылаться переменная unit group могут создаваться по ходу игры. И не только могут, но и создаются. И засоряют многострадальную память :).
Каждый раз, когда ты применяешь функцию pick every (unit in unit group) and do actions - ты в качестве unit group указываешь определенную функцию. Например, [units of type] или [units in range matching conditions]. Вот тут и скрывается зло. Именно из-за таких функций создаются объекты, которые будут торчать в памяти (кстати, во втором случае еще и точка может выплыть). И, как ты догадываешься, в триггерах с малым периодом - это означает торможение.
Так что если хочешь создавать, к примеру, огонь, который каждые 0.25 секунд наносит повреждения всем юнитам в такой-то области, нужно уметь бороться с утечками. А борьба будет просиходить по схеме:

1. Создай переменную, например ug типа группа.
   
2. Перед действием pick every unit нужно занести в переменную ug группу, которую мы будем использовать. Например: set ug = [units in range matching conditions]
   
3. Во время действия pick every unit в качсестве группы указываем переменную ug.
   
4. После действия pick every unit вставляем команду:
   

call DestroyGroup(udg_ug)

- уничтожить группу из глобальной переменной ug.

Итак, подведем итог: в большинстве сценариев, утечки могут возникать из-за

• юнитов (создаем много и не удаляем)
  
• спецэффектов
  
• функция для работы с точками
  
• функций для работы с группами
  

Могут быть и другие варианты, но они встречаются реже.
Утечки особенно опасны, для триггеров с малым периодом.

Читатель, если удалить все основные утечки, то для 99,99% сценариев больше ничего не нужно оптимизировать. Но, как оказалось, существуют и другие виды утечек. Например, куда девается локальная переменная после того, как триггер кончил исполнение? На самом деле они продолжают сидеть в памяти. И хотя занимают они очень мало, но на протяжении длинной игры, их может накопиться порядочно. Чтобы этого избежать, имеет смысл обнулять локальные переменные после окончания действия триггера (по крайней мере, переменные объектного типа).

Ты наверное замечал уже это в примере, который я присылал. В конце триггера идут строки типа

set i = 0
set r = 0
set s = ""

А как обнулять переменные со ссылками на юниты, точки и пр.? Есть способ. Для всех объектных переменных ноль это null.
Т.е. мы пишем

set p = null
set u = null

и т.д. И переменные обнуляются.

Есть еще одна интересная возможность увеличить ресурсы памяти для длинных сценариев. Для этого нужно в какой-нибудь триггер с событием Map Initialization добавить команду:

call DoNotSaveReplay()

- Эта команда заставит war3 не писать реплей игры. А значит, снизит ее загрузку.

Примечание. Мой друг картостроитель, прочитал про утечки и начал думать, что же с этим теперь делать? Глянул на свой проект и приуныл. Столько всего оптимизировать... Раньше для него не было проблемы утечек, а теперь пришлось думать, что с этим делать. А я думаю, может быть и не стоит так уж усердствовать? Во всяком случае не все сценарии требуют дотошно оптимизировать и удалять все утечки. В первую очередь, конечно, должны оптимизироваться сценарии для сетевой игры и сценарии, где есть триггеры с малым периодом. Остальные – надо смотреть по обстоятельствам. Если есть торможение, можно попробовать от него избавиться.
Вообщем, jass поможет вам решить проблемы, которые до его изучения не существовали. :)