Пользователь
0,0
рейтинг
18 февраля 2010 в 21:31

Сетевые игры — «Ты помнишь, как всё начиналось?...» перевод

image
Под катом — перевод первой части статьи What every programmer needs to know about game networking, об истории становления и принципах устройства мультиплеерных сетевых игр. Автор Glenn Fiedler.

Введение


Вы — программист. Вы когда-нибудь задумывались о том, как работают мультиплеерные игры?

Снаружи это похоже на магию: два и более игроков по сети принимают участие в одних и тех же согласующихся между собой событиях, как будто существуют в одной общей виртуальной реальности. Однако с точки зрения программиста понятно, что суть происходящего на самом деле не такая, какой может показаться на первый взгляд. Оказывается, это иллюзия. Масштабный обман, ловкость рук. То, что мы воспринимаем как общую реальность, на самом деле — лишь приближение, уникальная для каждого отдельного игрока, его положения в пространстве и точки наблюдения.

Далее я опишу ряд уловок, используемых программистами в разных жанрах сетевых игр, а также историю их разработки.

Жёсткая синхронизация по пиринговым сетям


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

Идея подхода заключается в разбиении игры на серию шагов (итераций), на каждом из которых дальнейшее игровое состояние определяется с помощью некоторого набора управляющих команд. Например, «передвинуть юнита», «атаковать юнита», «построить здание». Всё, что требуется делать в данном случае — выполнять один и тот же набор команд на всех игровых машинах, начиная с некоторого общего для всех игрового состояния.

Конечно, такое объяснение слишком просто звучит и не раскрывает множество тонких моментов, однако наглядно демонстрирует идею работы современных RTS. Более подробно об этом можно почитать тут: 1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond.

Решение кажется простым и элегантным, но у него есть несколько ограничений.

Во-первых, чрезвычайно сложно обеспечить полную детерминированность игры; чтобы каждый ход обыгрывался одинаково на всех машинах. Например, один и тот же юнит на разных машинах может двигаться по слабо различающимся маршрутам, при этом на одной из них он прибудет на место назначения заранее и «спасёт положение», а на другой машине он может безнадёжно опоздать. Также как бабочка, взмахами крыльев вызывающая ураган на другом краю света, одно небольшое отклонение со временем может привести к полной рассинхронизации.

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

Причиной третьего ограничения является тот факт, что игра рассылает по сети лишь те управляющие сообщения, которые изменяют игровое состояние. Чтобы всё это работало, начальное состояние игры должно быть одинаковое для всех игроков. Это значит, что игроки перед началом игры соединяются и находятся в специальном режиме готовности (в курилке). Хотя с технической точки зрения возможно организовать подключение игроков уже во время игры, обычно первый вариант более распространён, т.к. достаточно сложно обеспечить захват и передачу полностью детерминированного начального состояния нового игрока в течение игры.

Несмотря на все эти ограничения, такая модель работы хорошо подходит для RTS и применяется в таких играх как Command And Conqurer, Age Of Empires, Starcraft. Причина в том, что игровое состояние в этих играх обычно включает в себя информацию о большом количестве объектов (юнитов), которую затратно целиком передавать по сети. Вместо этого отсылаются управляющие команды, влияющие на эволюцию этого состояния.

Тем временем, в других игровых жанрах прогресс не стоит на месте. Рассмотрим эволюцию action-игр, начиная с Doom, Quake и Unreal.

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


В эру динамичных action-игр ограничения предыдущего подхода стали очевидны в игре Doom, которая хорошо работала только по локальной сети, и ужасно — по интернету:
Хотя возможно соединить по интернету две машины с работающим Doom, используя модем, игра получится медленной, варьируясь от совершенно неиграбельной (например, при PPP соединении 14.4Kbps) до с трудом играбельной (например, при соединении 28.8Kbps по протоколу SLIP со сжатием). Поскольку такие виды соединений имеют минимум практического применения, этот документ будет рассматривать только прямые соединения (faqs.org).

Несомненно, проблема была в том, что Doom проектировался для работы только по локальным сетям и использовал описанный выше подход для организации сообщения между машинами. На каждом шаге ввод игрока (нажатия клавиш, и т.д.) передавался с его машины на другие игровые узлы сети, и перед симуляцией очередного шага на каждой машине требовалось, чтобы были получены события ввода от всех остальных игроков. Другими словами, прежде чем двигаться или стрелять, надо было дождаться, пока от самого лагающего игрока поступят события ввода. Только представьте, как бы скрипели зубами те ребята, которые написали выше, что «такие виды соединений имеют минимальное практическое применение» :).

Чтобы выйти за рамки LAN и не ограничиваться лишь хорошо работающими локальными сетями университетов и крупных компаний, нужно было менять модель сетевого сообщения. Именно это и сделал в 1996 Джон Кармак (John Carmack), создавая Quake с использованием модели клиент/сервер вместо однорангового подхода.

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

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

Это был значительный шаг вперёд. Качество игры теперь зависело от скорости соединения между клиентом и сервером, а не от скорости соединения самого лагающего игрока. Также стало возможным подключать новых игроков в середине игры, и возросло общее количество играющих, т.к. уменьшилась средняя нагрузка на канал в рассчёте на каждого игрока.

Но и тут возникли проблемы:
В то время как я могу вспомнить и оправдать все мои решения, использованные в сетевой модели, начиная с Doom и заканчивая Quake'ом, суть была всегда одна — основные предположения, из которых я исходил при разработке, никуда не годились для хорошей интернет-игры. Изначально я рассчитывал на задержки соединения менее 200ms. Люди, имеющие цифровое подключение через хорошего провайдера, не испытывали трудностей в игре. К сожалению, 99% пользователей подключены через модем, и, как правило, через хренового перегруженного провайдера. Из-за этого задержки становятся равными как минимум 300ms. Клиент. Пользовательский модем. Сервер. Модем провайдера. Пользовательский модем. Клиент. Это полный отстой.

Пожалуй, грубовато выразился. У меня дома стоит T1, так что я был плохо знаком с жизнью на PPP. Теперь я буду иметь это в виду.


Конечно, проблемой стали задержки передачи данных.
То, что сделал Джон, когда выпускал QuakeWorld, изменило индустрию игр навсегда.

Прогнозирование на стороне клиента


В оригинальном Quake'е всегда ощущалась задержка соединения между клиентом и сервером. Нажмите «вперёд» и будете ждать сколько угодно долго, пока пакеты дойдут до сервера и обратно, и потом только начнёте двигаться. Нажмите «огонь», и будете ждать столько же, пока вылетит пуля.

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

Эта проблема исторически была решена в два захода. Сначала Джоном Кармаком была разработана система прогнозирования на стороне клиента для QuakeWorld, позже доработанная и использованная в игре Unreal Тимом Свини (Tim Sweeney). Вторым этапом явилась система компенсирования задержек, разработанная Яном Бернье (Yahn Bernier) из Valve для CounterStrike. Остановимся на первой из двух частей — как прятать задержку между поступлением ввода от игрока и откликом игры.

Джон Кармак так писал в своих планах по поводу готовящейся к выходу QuakeWorld:
Теперь я позволил клиенту самому догадываться о результате движения игрока ещё до того, как придёт ответ от сервера. Это очень большое изменение в архитектуре. Клиент теперь должен различать сплошные объекты, знать про физические характеристики, такие как масса, трение, гравитация, и т.д. Мне грустно осознавать, что элегантная модель клиент/сервер в чистом виде уходит в прошлое, но я скорее практик, нежели идеалист.

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

После нажатия клавиши «вперёд» движение будет происходить сразу, и не придётся ждать, пока пакеты пропутешествуют от клиента до сервера, и обратно.

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

Теперь вы, возможно, удивитесь. Эй, как же так? Если клиент управляет движением персонажа, почему бы не сделать его главным в этом процессе? Клиент мог бы просто вычислять движение и отсылать на сервер необходимую информацию. Проблема в том, что если бы каждый клиент мог говорить серверу «вот тут моя текущая позиция», не составило бы никакого труда хакнуть клиент так, чтобы, например, постоянно уклоняться от ударов, или телепортироваться за спины других игроков, чтобы подстрелить их сзади.

Таким образом, необходимо, чтобы в таких играх сервер имел высший приоритет при управлении персонажами, несмотря на тот факт, что каждый игрок локально может предугадывает своё движение, чтобы избежать задержек. Как пишет Тим Свини в The Unreal Networking Architecture, «Сервер — это начальник».

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

Если бы клиент вносил коррективы без всяких изменений, «как есть», ему пришлось бы откатить всё, что он вычислил после того момента, и фактически вернуться назад во времени. Как обойти это, в то же время позволяя клиенту продолжать прогнозирование далее?

Решением является использование циклического буфера, в котором хранится информация о предыдущих состояниях игрока и событиях ввода. Когда клиент получает коррективы от сервера, он отбрасывает всю информацию, которая старше корректируемого момента времени, после чего заново пересчитывает состояния игрока, начиная от только что скорректированного, заканчивая последним спрогнозированным, при этом используя имеющуюся в буфере информацию о произошедших в этот период событиях ввода. Фактически клиент незаметно «перематывает назад и заново проигрывает» последние n кадров анимации персонажа, при этом оставляя весь остальной игровой мир фиксированным.

При таком подходе игрок может управлять своим персонажем без задержек, кроме того симуляция становится полностью детерминированной — даёт один и тот же результат на клиенте и сервере, и необходимость вносить коррективы появляется редко. Тим Свини так говорит об этом:
… лучшее из обоих вариантов: в любом случае сервер остаётся главным в процессе управления. Практически всё время симуляция движения игрока на клиенте в точности отражает то, что происходит на сервере, поэтому состояние игрока редко корректируется. Только в некоторых случаях, например, когда в игрока попадает ракета, или он сталкивается с противником, его позиция изменяется сервером.

Другими словами, положение игрока корректируется только в том случае, когда на него действуют какие-то внешние факторы, которые нельзя спрогнозировать локально. Конечно, это только если игрок не использует читы :)
Перевод: Glenn Fiedler
Common Sense @gcc
карма
5,0
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (57)

  • –59
    Сегодня день К.О.?

    ЗЫ ой ща заминусуют))
    • +10
      Материал хоть и очевидный но действительно интересный та что зря ты так.
      P.S. Напомнило фразу Андрэ Ла Мота: «Если вы хотите доставить другим радость, то можете не сомневаться, что видеоигры- это то, что надо! Видеоигры- это способ выражения самых фантастических идей и замыслов»
      P.S.S.Почему хром подсвечивает слово «видеоигры»?
      • 0
        Кармак, конечно же, молодец. Он внес свой неоценимый вклад в наше игровое будущее.
    • +8
      не моё это дело, но всё же
      93 год рождения, а такой интересный материал уже прост и очевиден…
      это только факты, я удержусь от комментариев
  • +15
    Спасибо, очень интересно и понятно расписано. Жду продолжения.
    • +1
      У меня по этому поводу уже давненько валяется какой-то переводец.
      Подчищу — и на хабр?
      • 0
        Конечно, чего же ему без дела-то валяться.
      • 0
        Если «переводец» такой же правильный и интересный – конечно, почему бы и нет?
  • +1
    Интересно было бы почитать про различные подходы при написании сетевой части Quake 2, Quake 3 (благо исходники есть и того и другого), а также Counter-Strike (что есть сильно переделанный Quake 2).
    • +2
      Counter-Strike (а точнее Half-Life) есть сильно переделанный Quake 1. Ключевое слово _сильно_, я не уверен, что там сохранился сетьевой код первого Quake.
      • 0
        Правы в каждой букве. =)
        • +5
          >сетьевой код

          Совсем в каждой?
      • +5
        Практически любая программа это _сильно_ переделанный «Hello, World!» :) Ключевое слово сильно :)
  • +1
    А по-моему правильно «Tim Sweeney» (Тим Свини) а не Тим Суинли (Tim Sweenly).
    • 0
      > Вторым этапом явилась система компенсирования задержек, разработанная Яном Барньером (Yahn Barnier) из Valve для CounterStrike.
      а его имя пишеться как Yahn Bernier, см. www.valvesoftware.com/people.html
      • +1
        Yahn Bernier

        Яном Барньером

        Яном Бернье, если на то пошло

        пишеться

        тыц
        • 0
          Исправил, спасибо
    • 0
      Именно. en.wikipedia.org/wiki/Tim_Sweeney_(game_developer)
    • 0
      Спасибо, updated
  • +3
    Спасибо, хороший перевод и статья замечательная.
    Хоть какая-то тематика, отличная от веба и гаджетов на хабре :)
    Переводите и пишите еще!
  • 0
    Сеть вообще одна большая иллюзия
    • +1
      МатрицаМир вообще одна большая иллюзия.
  • +2
    Прекрасная статья, не знал про систему прогнозирования на стороне клиента…
    • +2
      меня она раздражает. глюканет инет, навесишь 5 хэдшотов, а потом просыпаешься и все это оказалось сном и тебя зарезали ножом пока ты стоял неподвижно(вспоминаю CoD:MW).
  • +3
    Было бы интересно прочитать про реализацию сетевой игры в Дюк Нюкене 3Д…
    Сколько же часов было убито, в своё время, в нём… ;)
    • 0
      И не говорите! Зато там ведь летать можно было! С ракетницей, причём.
  • +5
    Интересное:

    В WoW передвижение персонажа (и только оно) практически полностью доверяется клиенту. Фактически, клиент действительно может читерить и бегать быстрее. На деле это просто заметят и человек рискнет баном своего (платного!) аккаунта.

    Если вы не верите, обратите внимание: вы можете ворваться на верховом животном в помещение (где езда запрещена), и только по прошествии лага*2 вас насильно снимут с вашего тигра, но расстояние, которое вы успеете пробежать, останется за вами и отменено не будет.

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

    Я до сих пор не понимаю, как сервер согласовывает такие эпизоды, как карусель, когда разбойник пытается забежать со спины, а жертва вертится за ним следом.

    А ведь есть ещё способности типа «отражение заклинания» и Ice Block магов, позволяющих им на время застыть неуязвимыми. Они требуют отличного тайминга, и все равно ими вполне реально пользоваться.

    Чёрт возьми, как это работает??
    • 0
      По принципу «нам пофиг что показывает клиент, главное то, что на серве» с погрешностями и прогнозирующими вычислениями на стороне сервера… Наверное как нить так
      • 0
        нет, клиент в WoW действительно главный, когда речь заходит о положении игрока. а то, как близы защищают свой клиент от взлома — это тема отдельной статьи.
    • +1
      Магия ;)
    • 0
      Хреново это работает :-) Фактически, двигаешься на опережение.
    • +5
      если коротко: вы платите — оно работает.
    • 0
      Вот этого продолжения истории мы и ждём от gcc. )))
    • 0
      дело в том, что в ВоВе лаги намного меньше влияют на геймплей из-за отсутствия (почти) необходимости прицеливаться. В квейке одной из основных проблем был полет снарядов и все, что связано с выстрелами, в итоге Кармак так и не решил поставленную себе задачу — нормальная игра через модем (можно было бежать впереди своей ракеты и т.п.)…
      А в ВоВе все просто, есть цель, есть текущий удар/спелл, задача клиента — нарисовать траекторию от игрока до цели. Лаги дают интересные эффекты типа файрболлов летающих по дуге за угол вслед за целью :-)
      В случае АоЕ клиентам тупо с сервера приходит информация о повреждениях, и не важно, как далеко ты успел убежать от эпицентра с локальной точки зрения.
      Что до Ice Block и т.п., то с большим лагом ими все равно не воспользуешься эффективно, а лаги в пределах 500-600 мс не так существенны для спеллов с временем действия под 10 секунд.
      Более того, из-за достаточно низких требований к лагам, сервера ВоВа общаются с клиентами по TCP, а не через UDP как в случаях с шутерами.
      • 0
        Я разрабатываю интернет-игру (какую — секрет, предполагаемая нагрузка ~20 человек на сессию). Поскольку в моих целях задержка в полсекунды должна быть приемлема, я тоже решил использовать именно TCP.
      • –1
        Вы уверены, что шутеры работают на UDP? Мне что-то кажется, что контроль и порядок доставки сообщений для них крайне важен.
        • +2
          Сервер Quake 3 по сети шлёт не состояния объектов, а изменения в них. Причём на сервере хранится история изменений и клиенту отсылаются все изменения, которые он ещё не подтвердил. (так и хочется провести аналогию с SVN :)
          Таким образом и порядок доставки не важен, и состояние игры на клиенте не портится.

          trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking
          • 0
            Cпасибо за разъяснения.
        • 0
          Шутеры и другие игры с подобной динамикой работают по UDP, т.к. TCP не обеспечивает необходимую скорость работы. Обычно поверх UPD вешают свои примочки, частично эмулирующие TCP.
    • 0
      А это действительно очень зависит от пингов, и с этим в WoW ничего не поделать. Есть, например, классическая комбинация в дуэли мага и воина: маг начинает кастать 2-секундный sheep, воин видит это, использует отбивалку заклинания, маг в свою очередь видит это и отменяет заклинание, в результате заставив воина потратить отбивалку и сэкономив при этом sheep. Так вот при очень хороших (~20ms) пингах воин может просто включить reflect в самый-рассамый последний момент, когда маг уже не успеет ничего отменить. И тем же русским игрокам такое на западных серверах очень сложно провернуть — пинги не позволят.
      • 0
        Лаг при касте — дело привычное и легкопредсказуемое, и знание о нем помогает значительно увеличить собственную скорость пиу-пиу.

        Но как салочки тряпочек и милишников умудряются корректно выглядеть на обоих клиентах?

        Представим, я стою, и тут в меня влетает воен. Оправившись от стана, попытаюсь отбежать — через 200мс сервер узнает об этом, ещё через 200мс об этом узнает воин и начинает преследовать меня, опять же это должно дойти туда-сюда. По идее, начав убегать, я должен почти сразу выйти из мили-зоны, но на практике этого не происходит, воин будет бежать за мной и лупить. (Вот почему вместо попытки отбежать я просто влеплю ему дескоил, а дальше дело за малым...) Как это работает — я не пойму. То ли мне только кажется, что это происходит так, то ли в определенных ситуациях действительно используется какая-то хитроумная система предугадывания итп.
        • 0
          Опять же, на этот вопрос очень просто ответить, зная, что близы 100% доверяют информации, приходящей с клиента. С точки зрения клиента милишника, в момент, когда он совершает атаку его цель еще никуда не убежала, а значит атаку совершить можно. На сервер уходит команда в стиле «я зафигачиваю вон тому чуваку и да, он у меня в пределах досягаемости.» или как-то так. Более простой вариант — нумеровать команды. Если сервер видит, что команда на атаку была совершена раньше, чем обработана его команда на перемещение противника, то может восстановить состояние на тот момент и убедиться, что атака еще проходит.
  • +4
    Да, статья хорошая, из последней части почерпнул для себя полезные вещи.
    + к списку от dMetrius хотелось бы подробнее раскрыть тему об организации(в частности как раз синхронизации положения игрока) сетевой игры в MMOG играх, там нагрузка всегда большая :)
    Сколько видел «спидхаков» и «воллхаков», и вполне знал как они работают, и какие бывают «лаги», когда много игроков собираются в одном месте(например ЧВ в RFOnline), теперь хотелось бы все-таки увидеть в подробностях как же проектируют их сетевую часть, ибо мои знания в этой области поверхностны =)
  • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Статья шикарная. В свое время читал про приоритеты просчетов клиента и сервера, но в целом картины не видел.
    Огромное спасибо, что собрали все мысли в одной статье!
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Да, мне тоже понравилось, спасибо :-)
  • 0
    система прогнозирования на клиенте была реализована задолго до quake world.
    к примеру в WoW.
    • 0
      черт. надо обновлять вкладку перед тем как писать.
  • +1
    Я если честно мало понимаю в сетях, но меня бесит только одно. Хоть я так же уже почти не играю в игры, но раньше в какомнибуть НФС 3 я просто создавал игру, а друг вводил IP и мы вдвоем гонялись.

    Сейчас какой-то бред, играть только через оф. сервера и еще прочая ахинея. А простых вещей типа я создал и играю только с теми с кем договорился, этого я давно не видел.
    • 0
      ЦА сейчас другая, интернеты стали шире. Это раньше можно было делать игры на подобии Fallout и TES(новый TES уже не торт) в который люди играли играли. Были интересные сюжетные линии и прочее(да даже в NFS:Porche сюжета больше чем в Undercover). Сейчас эра пиратства и школоты. Проще раз в пол года выпускать шлак типа ME который средне-статический школьник проходит через 5 часов.
      ^^^^^^
      это я о том, что оф сервера спасают от пиратства
      .
      Ну и это раньше 2 человека который хотят поиграть всегда находились в одной сети или городе(вспоминаю как в старкрафт по мопеду играл). Да и внешние ip не у всех, а у кого есть те не умеют пробрасывать порты, а UPnP отключал из-за того, что всякая зараза его использует. А так же никто не мешает вам создавать частные «сервера» с паролем для друзей.
  • 0
    >до с трудом играбельной (например, при соединении 28.8Kbps по протоколу SLIP со сжатием)
    Не припомню уже что такое SLIP, но на 28800 v32/v34/v42 с отключённым сжатием вдвоём было просто отлично бегать в DOOM2
    • 0
      Хотя, наверное, уже позабыл. Скорее всего не на 28800, а на 31200 или 33600…
  • 0
    Отличная популярная статья о деталях эволюции всеми используемых технологий.
    Мне всегда было интересно, как это делается, но у меня были только предположения.
    Теперь у меня есть представление, основанное на цитатах первоисточников.
    Спасибо за качественный материал.
    Творческих успехов!
  • 0
    хорошо, толково и понятно описано. жду ещё.
  • 0
    Автор оригинальной статьи обещался выложить вторую часть буквально через неделю после публикации первой части, но к сожалению куда-то пропал, и блог его давно не обновлялся. Тем не менее материал ещё есть, и не только оттуда, так что тема игростроения не пропадёт.
  • +2
    Вот нашел любопытное видео в тему Valve'вской технологии «лагокомпенсации», показывающие разницу в попадании при компенсировании лагов и без
    www.wegame.com/watch/TF2_Hitboxes/

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