Оптимизация карты(не геометрия)
Содержание
1 Физика
2 Шейдеры
3 Клиент/Сервер
4 Динамический свет
Физика
Одной из замечательных сторон Сорса
является супер реалистичная
физика, и конечно же физически зависимые объекты будут присутствовать
на многих картах. Однако, имитация физики для большого количества
объектов в игре может заметно сказаться на производительности, особенно
в мультиплеере.
В синглплеере вы можете спокойно использовать большое
количество физически зависимых объектов. Просто посмотрите в
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.
|