Стратегия программирования на UnrealScript

Здесь мы рассмотрим несколько моментов, касающихся эффективной разработки кода на UnrealScript, использования сильных сторон UnrealScript, и способов предотвращения возможных ошибок.

Код на UnrealScript медленее, чем код на C или C++. Обычная программа на C++ работает примерно в 20 раз быстрее, чем сценарий на UnrealScript. Философия программирования при написании наших собственных сценариев заключается в следующем: создавать сценарии, которые почти всегда простаивают. Другими словами, используйте UnrealScript только для обработки "интересных" событий, реакции на которые вы хотите настроить, а не для выполнения механических задач, таких как расчет движения, которые решаются физической подсистемой движка Unreal гораздо эффективнее. Например, при написании сценария снаряда обычно пишутся функции HitWall(), Bounce() и Touch (), описывающие действия, выполняемые при наступлении основных событий. Таким образом, 95% времени сценарий для вашего снаряда не выполняется, а только ждет уведомления от физической подсистемы. Такой подход по своей сути очень эффективен. Хотя UnrealScript гораздо медленнее, чем C++, код на UnrealScript в среднем занимает 5-10% процессорного времени.

Используйте как можно больше латентных функций (таких, как FinishAnim и Sleep). Основной поток ваших сценариев состоит из них, вы создаете код для управления анимацией или код, выполнение которого основано на течении времени. Подобный код является достаточно эффективным в UnrealScript.

Во время тестирования сценариев регулярно заглядывайте в журнал Unreal. Система исполнения сценариев UnrealScript часто выводит в журнал полезные предупреждения, которые уведомляют о наличии нефатальных проблем.

Будьте осторожны с кодом, который может привести к бесконечной рекурсии. Например, команда "Move" перемещает актор и вызывает функцию Bump() при столкновении. Поэтому, если вы используете команду Move в функции Bump, вы рискуете получить бесконечную рекурсию. Будьте осторожны. Бесконечные рекурсии и бесконечные циклы - это две ошибки, которые UnrealScript не обрабатывает корректно.

Создание и уничтожение акторов на стороне сервера - это довольно дорогостоящие операции, и крайне дорогостоящие операции в сетевой игре, потому что создание и уничтожение расходует пропускную способность сети. Используйте их разумно и рассматривайте актор как "тяжеловесный" объект. К примеру, не пытайтесь создавать системы частиц путем создания 100 уникальных акторов и их отправления по различным траекториям с использованием физической подсистемы. Это будет ОЧЕНЬ медленно.

Используйте объектно-ориентированные возможности UnrealScript как можно более полно. Создание новой функциональности путем переопределения существующих функций и состояний приводит к чистому коду, который легко модифицировать и легко интегрировать для разработки с участием других людей. Избегайте использования традиционных методов C, при обработке состояний объектов и акторов не используйте конструкции switch(), потому что такой код бесконтрольно разрастается по мере добавления новых классов.

.u пакеты UnrealScript собираются строго в порядке, установленном в списке EditPackages.ini файла, при этом каждый пакет может ссылаться только на объекты, входящие в состав текущего пакета, в состав ранее скомпилированных пакетов, но никогда не может ссылаться на пакеты, собираемые после текущего. Если вы обнаружите возникновение циклических ссылок между пакетами, то есть два решения:

• Пакет с набором базовых классов ставится на сборку в первую очередь, а за ним пакет с набором дочерних классов. Также убедитесь, что базовые классы никогда не ссылаются на дочерние классы. В этом заключается хорошая практика программирования и это обычно работает.
  Заметим, что если класс C должен ссылаться на класс или объект O в пакете, компилируемом позднее, то вы можете разбить класс на две части: абстрактный базовый класс определить как С (но не включать значения по умолчанию для его переменных в свойства по умолчанию), а производный класс D поместить во второй пакет, для которого указываются правильные значения по умолчанию.
• Если два.u пакета неразрывно связаны между собой ссылками, то объедините их в один пакет. Это будет более разумно, потому что пакеты предназначены только для разделения кода на модули и вы не получите реальной пользы (например, экономии памяти) от разделения классов на несколько пакетов.

Дата добавления: 2015-11-14