Физика

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

В синглплеере вы можете спокойно использовать большое количество физически зависимых объектов. Просто посмотрите в showbudget`е графу Physics, чтобы посмотреть, не много ли вы их(объектов) используете. Всегда помните, что физически зависимые объекты в движении расходуют больше ресурсов, чем если бы они находились в покое.

В мультиплеере на физику накладываются большие ограничения, т.к. очень сильно увеличивается объем данных, пересылаемых по сети, что может замедлить работу сети и игры соответственно. Возьмите за правило использовать в мультиплеере меньше физики, чем в  сингплеере. Вам следует помнить, что в мультиплеере качество имитации физики ниже(например, вам кажется, что платформа едет прямо, но, если вы попробуете проехаться на ней, то она будет двигаться рывками, особенно, если она поднимается вверх); это сделано для понижения траффика и для уменьшения обработки со стороны клиента(см. ниже). Вы также можете пожертвовать качеством физики для увеличения скорости, используя prop_physics_multiplayer вместо prop_physics, тогда объекты будут работать быстрее. Может возникнуть проблема с некоторыми моделями(полотно пилы, например), в этом случае лучше не использовать такие вещи.

Всегда, когда вам приходится облегчать физику на карте, используйте систему упрощения(constraint system) при помощи ентити phys_constraintsystem. Она упрощает работу движка, что выражается в более быстрой и гладкой симуляции.

Если объект не нуждается в симуляции физики(он не будет перемещаться в игре или будет, являясь прикрепленным к чему-нибудь при помощи parent`а), его не надо делать физическим объектом. Превратите детали(props) в prop_dynamic или prop_dynamic_override. А в брашах вместо func_physbox используйте func_brush (если он двигается пассивно, т. е. в связке с parent`ом) или func_movelinear (если он перемещается по прямой).Все эти func_* работают быстрее, чем func_physbox.

Шейдеры

Шейдеры - это класс новой изящной технологии, доступной в последних версиях DirectX. С их помощью осуществляются очень реалистичные и красивые эффекты - в Сорсе в основном они применяются для того, чтобы делать объекты отражающими, преломляющими или все вместе. Например, вода в Сорсе - это комплексные шейдеры. Другим примером могут служить двери с рифленым стеклом, линзы, подобные очкам, увеличительные стекла в лаборатории доктора Кляйнера, и та странная прозрачная жидкость в резервуарах.

Использование шейдеров может заметно сказаться на производительности игры, особенно это зависит от видеокарты(несмотря на то, что в Valve сделали много для того, чтобы у людей со слабыми видеокартами шейдеры работали быстрее). Убедиться в том, что шейдеры являются причиной тормознутости вашей карты, вы можете взглянув на showbudget: Swap Buffers вам подскажет:).

Вода - специальный шейдер, и может быть причиной проблем на карте, используясь неправильно. Есть два типа воды: быстрый и качественный. Быстрая вода прорисовывается движком более быстро, а качественная - красивее(с отражениями). Если вы хотите разместить воду у себя на карте, используйте water_lod_control, чтобы определить, насколько далеко от игрока движок игры будет использовать быструю воду, а потом - качественную.

Если что-то из шейдеров, кроме воды, замедляет работу вашей карты, вам следует уменьшить количество материалов и ентитей, использующих шейдеры, или сделать так, чтобы меньшее их количество одновременно попадало в поле зрения игрока.???

Клиент/Сервер

Этот раздел касается только мультиплеера. Сетевой траффик обычно дорог, и мапперам следует это помнить, когда они используют на картах что-нибудь мудреное(физика, логические ентити, связанные инпуты/аутпуты). Вам следует также учитывать, что ваша карта во время игры на ней обрабатывается в трех местах:

• Она обрабатывается на сервере - это работа со стороны сервера.
• Она обрабатывается на каждом клиенте(компьютерах игроков). Для простоты мы будем рассматривать только один клиент, как абстрактное представление всего, что происходит с каждым компьютером - это работа со стороны клиента.
• Большое количество информации посылается по сети, чтобы игровое окружения оставалось одинаковым и на сервере и на клиенте - это сетевой траффик.

Сеть обычно самое медленное место в мультиплеере, и очень затратно посылать информацию через нее(особенно это касается модемщиков, широкополосных пользователей, и в некоторой степени - LAN-игроков). Многие события на карте генерирует траффик, и для вашей карты лучше было бы уменьшить его количество, насколько это возможно. Один из способов в Сорсе - это отправка тех событий клиенту, которые будут происходит независимо от сервера. Например, клиент может спокойно передвигать ящики без помощи сервера, поэтому все передвижения ящиков осуществляются клиентом вместо сервера, что приводит к экономии траффика. Другие вещи, такие как траектория полета пуль, должны осуществляться сервером. Движок Сорса сам определяет, какие вещи должны быть сделаны сервером, а какие - клиентом. Как маппер вы не сможете этого контролировать, но об этом следует помнить.

Как это поможет вам в оптимизации карты? Давайте рассмотрим один пример: предположим, что вы хотите красную мигалку наверху вашей башни. Она находится далеко от игрока, поэтому вместо света можно поставить спрайт(env_sprite), чтобы он зря не расходовал ресурсы системы. К сожалению, спрайт не анимирован, так что придется анимировать своими силами. Первый способ, который приходит в голову - это использование logic_timer, который будет включать спрайт каждую секунду. Этот способ работает отлично... но что происходит, когда таймер включается? Посылает ли сервер клиенту указание включить спрайт? Или таймер симулируется клиентом, и не надо посылать никаких указаний? Я, вообще-то, не знаю; но знаю, как сделать так, чтобы точно уверенным, что работу будет выполнять клиент: вместо использования logic_timer в свойствах спрайта поставьте Slow Strobe. Это чисто визуальный эффект,и он будет выполняться клиентской стороной. Удалось ли нам сэкономить какую-нибудь часть трафика? Может быть - да, может быть - нет, но я думаю, что этот пример проиллюстрировал то, как можно просто избавиться от некоторых проблем.

Вот вам еще парочка полезных советов:

• Объекты без имени имеют больше шансов сэкономить траффик, не давайте объектам имена без необходимости.
• Если вам нужен одноразовый таймер, то вместо logic_timer используйте Delay в настройках Output`ов.
• Избегайте элементов, активно нагружающих сеть(см. раздел физики).
• Каждый раз, когда Output влияет на какие-нибудь заметные действия(шум, искры, открытие двери и т.п.), объем траффика будет увеличиваться.
• Если ентитя не имеет Output`ов(не считая OnUser), тогда она, скорее всего, будет обрабатываться клиентом. Например, env_spark.
• Если ентитя не имеет Output`ов или Input`ов(исключая OnUser и FireUser), то, очень вероятно, будет обрабатываться клиентом.
• Не используйте OnUser/FireUser output`ы для logic_relay. Обычно это приносит ущерба, но в некоторых случаях, эта штука может попытаться сделать некоторые вещи сетевыми.

В любом случае сеть будет использоваться, так что не надо заходить слишком далеко, пытаясь что-то улучшить в этом отношении. Этот раздел скорее информационный, посмотрите раздел физики - те способы намного лучше снижают сетевой траффик. Если вы решили серьезно заняться оптимизацией карты на данном этапе, то лучше перед тем, как начать, посоветуйтесь с кодером из вашей мод-команды.

Динамический свет

Движок Сорса не очень хорошо приспособлен к динамическому свету. Вам следует ограничить его использование, если вы заботитесь о FPS игроков на вашей карте. Возьмите за правило не использовать более одного динамического источника света???.

Большая часть освещения в Сорсе просчитана заранее на этапе компиляции карты RAD`ом. Свет - очень медленная часть карты, но имеет огромную роль в ее облике, геймплее, поэтому освещение просчитывается заранее, чтобы карта была приятнее и не тормозила. Ограничение здесь состоит в том, что такие источники света не изменяют своих свойств во время игры. Динамический свет же снимает эти ограничения: он может мерцать, перемещаться в игровом пространстве и т.п. Но следует помнить, что освещение ресурсоемко, просчитывать освещение прямо во время игры возможно, но не желательно - старайтесь избегать этого настолько, насколько это возможно. Если же вам просто необходим динамический свет, старайтесь все-таки размещать его на карте как можно меньше.

Все, что говорилось о динамическом свете, касалось не только ентити light_dynamic, но также и некоторых light или light_spot ентитях. Кроме того,  point_spotlight тоже будет источником динамического света, если убрать флаг No Dynamic Light в ее свойствах.

Как обычно, чтобы узнать, тормозит ли динамический свет вашу карту, нужно посмотреть в showbudget и проконсультироваться с  Dynamic Light Rendering.