Просчитать расстояние и не зависнуть: с какими проблемами сталкивались создатели C&C: Tiberian Sun
У истоков геймдизайна стратегий в реальном времени.
Command & Conquer: Tiberian Sun вышла в 1999 году, и уже тогда игрок в ней управлял сотнями юнитов одновременно. Естественно, это не обошлось без нужды оптимизировать код: просчитывание даже такой простой операции, как пройти из одной точки в другую, требовало колоссальных вычислительных мощностей.
YouTube-канал издания Ars Technica опубликовал разговор с сооснователем студии Westwood Луисом Каслом — разработчик рассказал, как команда в своё время решала проблемы создания Command & Conquer. Сейчас многие из приёмов могут показаться очевидными, но тогда это было настоящим прорывом.
Технологии сжатия
Tiberian Sun использовала CD-ROM — настоящую инновацию того времени. Вместо десятков дискет игру можно было загрузить на диски — это экономило время установки. К тому же, формат CD позволял хранить полноценные аудио- и видеозаписи.
Если бы Tiberian Sun записывали старым методом, то она бы заняла 1050 дискет. Вместо них игра использовала два диска.
Tiberian Sun славилась качеством внутриигровых роликов — в катсценах снялись даже такие актёры, как Майкл Бин («Терминатор») или Джеймс Эрл Джонс («Звёздные войны»). Но внедрение CD обернулось для студии большой проблемой — диски слишком медленно передавали информацию для таких объёмов данных.
В те времена почти не было технологий, которые могли бы считывать подобные ролики со стандартной скоростью CD-ROM. К тому же, не существовало нужных кодеков — потому программы по обработке и сжатию видео Westwood пришлось писать самостоятельно.
Мы брали видео, делили его на множество маленьких блоков — каждый из них преобразовывался в скалярную величину. Все они помещались в многомерное облако и уже оттуда собирались обратно в такой набор блоков, который наиболее точно изображал оригинал.
Перемещение юнитов
В Tiberian Sun одной из ключевых особенностей было строительство. Разработчики не могли просчитать все возможные пути перемещения юнитов заранее — внутриигровая карта постоянно менялась. Пришлось найти нестандартные варианты решения проблемы.
Самый простой способ решить эту проблему — это пойти по принципу лабиринта. Вы можете просто постоянно поворачивать направо, пока не наткнётесь на тупик — со временем вы найдёте выход. Предположим, я беру в игре юнит, говорю ему идти в такое-то место, и дальше он просто кружит от одного края карты к другому — это попросту нелепо.
В C&C игроку были доступны несколько типов юнитов, и у каждого из них перемещение работало по-своему. Пеший солдат не мог двигаться как вертолёт, потому что он не может облететь препятствия по воздуху. По словам Касла, необходимость просчитывать пути одновременно сотен юнитов «опускала на колени любой процессор того времени».
Так что разработчики прибегнули к ряду уловок. Так, каждый юнит при перемещении будто бы не замечал все дружественные динамические объекты. Если стену или любое другое препятствие он обычно обходил, то в случае с союзными юнитами просто шёл «напролом» — без необходимости обрабатывать их поведение.
Естественно, в таком случае пришлось решать проблему коллизии — особенно в случае, когда военных единиц становилось слишком много. В таком случае те юниты, которые стояли у других на пути, просто слегка двигались на момент в сторону.
Так выглядела ситуация, когда сотням юнитов пехоты приходилось переходить через один-единственный мост. Солдаты продолжали «дрожать», пока наконец не пересекали узкий проход.
В комментариях к ролику на Kotaku другие разработчики из Westwood дополнили слова Касла. Так, если множество юнитов одного типа передвигались вместе, то путь просчитывался лишь у условного «лидера» — все остальные шли группой по той же дороге, что и он. Это снизило нагрузку на процессор до минимума.
А если в тот момент, когда группа передвигалась через мост, он разрушился, то юниты просто делились на две разные группы.
Другой приём касался обработки самого пути. Если отослать юнита в другой конец локации, то игра не будет просчитывать дорогу пиксель за пикселем. Вместо этого карта представлялась в виде множества сеток разной детализации — с разметкой вплоть до одного юнита. Большая сетка лишь условно показывала путь, в то время как сетка меньшего масштаба, к примеру, рассчитывала его с учётом возникших препятствий.
Так сделали для того, чтобы просчитанная дорога адаптировалась под изменения обстановки на экране. Как только юнит проходил площадь сетки меньшего масштаба, генерировалась новая сетка — и так далее.
Это блестящая стратегия потому, что зачем тратить время на просчитывание сразу всей дороги, если: а) игрок может изменить решение на полпути, б) что-то может случиться в сетках (например, появятся постройки или разрушения), в) юнит может встретить врагов.
Игра просто не делала ненужную работу — как, например, Baldur's Gate, которая в те времена «фризила» почти каждый раз, когда игрок перемещал партию на огромные расстояния. Путь просчитывался не полностью, а лишь частично — и он постоянно подстраивался под все изменения на карте.
У игры помимо роликов, крепкого сюжета был оочень большой плюс - саундтрек.
Возможно, не самое крутое творение Клепаки, но точно самое атмосферное.
Комментарий недоступен
3. Path-Finding хоть и стал лучше, но в целом остался идиотийным. Фиг знает, что они там просчитывали, но по сравнению с играми Близзард - это был стыд и срам. Или фишка)
Чегооооо? Сами близы отмечали что фиксили поиск пути в ремастере старкарфта. О чем ты?
Справедливости ради, в C&C не было ограничений на количество юнитов и выделение групп.
Path-Finding хоть и стал лучше, но в целом остался идиотийным.Вы видимо в орду не играли. Вот там всё очень плохо. В C&C солдатики хотя бы стопроцентно до цели доберутся.