В принципе, это только личные наблюдения и каждый волен делать так, как он хочет, однако на мой взгляд, это поможет делать более выверенные с точки зрения логики миссии, избежать их "тормознутости" на несильных машинах и просто сделать их создание и редактирование более удобным (кстати, вот неплохой сайт, где можно скачать игры на андроид 4.1 — прим. ред ).

Ошибка Первая:

Очень многие картоделы вовсю используют вэйпоинты. Часто это приводит к тому, что миссия начинает сильно тормозить. И если ещё можно оправдать использование их для движения или патрулей, то очень некрасиво выглядит их установка для задания поведения, формации и тд. Часто можно встретить вэйпоинт, стоящий на том же месте, что и юнит, который всего-навсего указывает построение в линию или говорит, что юнит должен "сесть".

Это в корне неверно! Пара десятков лишних вэйпов уже заметно снижает производительность миссии. Почему это происходит? Стоит просто посмотреть, как выглядит описание ВП в mission.sqm, там один вэйпоинт занимает порядка двадцати строчек кода, а в богатых ими миссиях это до сорока процентов всего файла! Ну, кому хочется, чтобы его миссия тормозила на 40% больше, чем могла бы? И заметьте, это порой встречается даже у опытных картоделов!

Вывод: Используйте setBehaviour, setFormation, setCombatMode и подобные им команды в строке инициализации юнита, такая запись занимает всего одну строчку против двух десятков строк вэйпоинта. Иногда можно отказаться от использования ВП и при передвижении, используйте Move Getpos и GetMarkerPos. Такая запись будет гораздо короче использования любого вэйпа, а значит и не создаст "тормозов" в миссии. По опыту скажу, что у меня есть миссии вообще без вэйпоинтов и пока никто этого не заметил:-)

Ошибка Вторая:

Многие картоделы, и не только начинающие, сажая группу в вертолёт или раздавая определённое оружие, просто пишут в инициализации каждого юнита This MoveInCargo Vert или This AddWeapon "Binocular". Зачем делать лишнюю работу, редактируя каждого юнита в группе из десяти человек? А если таких групп несколько?

Вывод: Всё очень просто, делайте всё это, привязывая неопределённую переменную к массиву группы!
На практике это это выглядит примерно так - "_x MoveInCargo Vert" foreach units group this. Написав это в инициализации командира группы, мы получим всех болванчиков сидящими в вертолёте.

Другой пример - раздача оружия. Допустим, надо раздать очки ночного видения каждому члену отряда, пишем у командира следующее - "_x addweapon ""NVGoggles""" foreach units group this. Обратите внимание, что то, что должно быть в кавычках (название оружия, модель поведения, формация итд), в этом выражении должно стоять в двойных кавычках! Это можно использовать для любых действий с массивами и не только с группами. Если, к примеру, надо высадить из техники троих произвольных солдат, пишем вот что - "unassignVehicle _x" foreach [sold1,sold2,sold3], три дядьки под этими именами послушно вылезут из машины:-)

Ошибка Третья:

Этот ляп тоже присутствует и у довольно опытных скриптописцев.
Часто в скрипте можно встретить примерно такой тип проверки условия

#Proverka
? Peremennaya : goto "Dalshe"
~0.5
goto "Proverka"

Что нам это даёт? Да ничего. Хорошего. А что плохого?

Через каждые полсекунды скрипт будет возвращаться в начало и снова проверять, не свершилось ли условие (которое может вообще не свершиться по ходу миссии). Это требует от процессора снова пересчитывать условие и выводить результаты. Если таких скриптов одновременно запущено несколько и вместо полсекунды там стоит нечто более микроскопическое типа 0.0001, слабая машина может вообще повиснуть! Нужно ли нам такое растранжиривание процессорного времени? А если это сетевая миссия, что бы вы сделали с её создателем?

Вывод: Всё просто, как морковь. Приведённую выше неуклюжую конструкцию прекрасно заменит следующая строчка @ Peremennaya

Всё! Пока Peremennaya не будет истиной, скрипт дальше не пойдёт. Длинные скриптовые конструкции не только да и не столько приводят к тормозам, сколько просто неудобны для написания и понимания.

Ошибка Четвёртая:

И она присуща очень многим. В скриптах диалогов и мультиков пишут нечто вроде titletext ["Вася - Пете, приём!","plain down"]. А теперь давайте подумаем, во что это выливается, а точнее, что мы при этом теряем...

Мы теряем возможность сделать кампанию\миссию\аддон, или что там у вас, сразу на нескольких языках (а почти во всех аддонах и родной забывают). Взамен мы получаем жутко захламлённые скрипты. Оно нам надо?

Конечно нет! Для этого используем stringtable! Это даст нам возможность через запятую перечислить строки для разных языков. В подробности составления трынгтаблей вдаваться не буду, проще прочесть это здесь, однако обратим внимание на различие употребления стрингов в разных исходниках.

Так, если в скрипте надо писать примерно вот так:

titletext [localize "STR_string","plain down"],
то в description, конфиге аддона и main.cpp нужно писать следующее:
OnLoadMission = $STR_string;

или

DisplayName = $STR_unit_name;

А вот если мы хотим обозвать таким образом маркер или триггер в редакторе, в поле текст пишем: @STRD_marker1, то же самое для названия миссии.

Вот пока и всё. Надеюсь, эти советы помогут Вам избежать обидных ошибок и недочётов и в конечном итоге приведут к тому, что мы скоро увидим Ваши отличные миссии и аддоны!

И заметьте, здесь я не открываю чего-то сверхсложного или нового - заумных руководств и справочников туевы, что называется, хучи на OFPEC. Постарался лишь поделиться основными приёмчиками, отличающими миссии, сделанные "по руководству" от сделанных "от себя". Всегда помни, будущий прораб, комрефы и туториалы - это только инструмент, а работаешь ты своей головою.

ЗЫ: Как выяснилось, это утверждение действительно справедливо. Сразу после публикации посыпалось множество вопросов и просьб рассказать по подробнее о той или иной фиче. А ведь казалось бы, уже не новички, все комреф под рукой держат, с "ринзой" спать ложатся...

Да и рассказывал я о не Бог весть каких сложных вещах. А посему, по многочисленным заявкам трудящихся, скоро выложу вторую часть статьи, почти полностью посвящённую созданию качественных мультов.

Dead Kennedy [GSS]