Postal 3 Technical Postmortem
•Download as PPT, PDF•
2 likes•1,087 views
Технический постмортем игры Postal 3. 14 Мая 2011, КРИ 2011
Recommended
Recommended
More Related Content
Similar to Postal 3 Technical Postmortem
Similar to Postal 3 Technical Postmortem (20)
Postal 3 Technical Postmortem
- 1. История разработки проекта POSTAL III Константин Ефимов программист Акелла aiven@akella.com
- 2. О докладчике Константин Ефимов • Закончил Московский Технический Университет Связи и Информатики • Программист в компании Акелла, где за 7 лет успел поучаствовать в разработке проектов: «Головорезы: корсары XIX века», «Бой с тенью», «Бой с тенью 2», «Меченосец».
- 3. Начало • На дворе был конец 2006-го года • Заканчиваем текущий проект • Нужно думать что делать дальше • Предлагаем Running With Scissors совместно делать Postal 3
- 4. Под что делать? • Произошла смена поколений игровых консолей • Принципиально другое железо, поменялись технологии производства • Отсутствие опыта производства под “next-gen” • Выбор Xbox 360 как основной платформы
- 5. На чем делать? • Развивать дальше существующий движок • Разрабатывать новый с нуля • Купить готовый и не париться
- 6. Выбор движка • Движок за миллион • Небольшие движки • Source Engine
- 7. Первые ощущения от Source • Очень долгая первоначальная загрузка • Programmer Oriented Engine • Клиент-серверная архитектура в однопользовательской игре • В исходниках Source присутствуют сразу все игры Valve • Олдскульный код. Никаких паттернов • BaseEntity.h: 2500+ строк, 1000+ функций у класса
- 8. Проблема: вид от первого лица • На улице планировался вид от третьего лица • В помещениях вид от первого лица • Проблема: предметы и двери выглядят по разному
- 9. Проблема: вид от первого лица (2)
- 10. Проблема: большой открытый мир • Надо динамически подгружать части большого мира • В Source есть подгрузка много чего, но только не уровней • Решение: разбивать мир на много отдельных уровней
- 11. Проблема: большой открытый мир (2)
- 12. Проблема: одноэтажная Америка • В дома можно заходить – много объектов внутри • У домов есть двери и окна – в результате ничего не отсекается • Решение: “заколотить” дома, поставить заборы, разнести области по высоте
- 13. Проблема: одноэтажная Америка (2)
- 14. Проблема: параллельное редактирование уровня • Над уровнем одновременно нужно работать художнику и дизайнеру • Исходник уровня хранится в одном большом файле • Сложно разрешать конфликты • Решение: дизайнер создает все объекты в своей отдельной группе
- 15. Проблема: ролики на движке • В Source нет обычных катсцен, есть интерактивные • Нет удобного редактора, все делается в FacePoser + Hammer • Решение: записывать видео, монтировать и проигрывать как FMV
- 16. Сложно добавлять новые фичи • You can paint it any color, so long as it's black (Henry Ford) • На движке Source можно сделать любую игру, если эта игра – Half Life 2 (TM Studios) • Пример: Player == Камера • Пример: трейс сферы, а не боксов
- 17. Удобный экспортер из Maya
- 18. Скрипты • В Source не было скриптового языка • Может быть он и не нужен? • Для AI точно нужен!
- 19. Скрипты (2) behavior mis_ds_champ { { group Neutral name bh_mexico_citizen patterns inherited bh_citizen { states pt_default { { actions st_init { { Block begin,execute group Neutral IfAttr "npc_startup == 1 CallState ut_startup" patterns TargetPlayer 1 TargetToMem msLEADER { State an_friend pt_default Block end { } actions } { } } TargetEntByName mexico_logic TargetToMem msGP ExecutePattern bh_citizen:st_init_male.pt_default SetAreaGroup AG_DEFAULT:walkable,AG_town } } } }
- 20. Много разных NPC • Есть несколько основных моделей NPC • В модель входит несколько геометрий головы, тела, причесок (бодигруппы) • На все эти геометрии накладываются разные текстурные наборы (скины)
- 21. Много разных NPC (2) • В слоты можно одевать внешние модели: шляпы, часы, сумки и т.п. (болтоны) • Художники сами задают комбинации бодигрупп, скинов и болтонов (префаб) • Пример: #prefab1 = #head1 #body5 #skin2 #glasses1 #watches3 #hair4
- 22. Много разных NPC (3)
- 23. Много разных NPC (4)
- 24. Расчлененка • Для конечности создается рэгдолл с точно такой же моделью • У конечности обнуляются все кости выше места отрыва, чтобы скрыть • У персонажа обнуляются все кости ниже места отрыва • Места отрыва прикрываются моделями мяса и эффектами крови
- 25. Расчлененка (2)
- 26. Прятанье за препятствиями • Динамически определяются места где можно прятаться • Трейсятся 3 бокса на разной высоте и определяется можно ли туда спрятаться • Для NPC пришлось сделать генерацию точек на углах • Анимации за препятствием для левой стороны отзеркалены с правой
- 27. Прятанье за препятствиями (2)
- 28. Жидкости и огонь • Вся логика на сервере, отрисовка – на клиенте • На сервере – ячейки регулярной сетки • На клиенте – декали • Синхронизация сервера и клиента с помощью событий
- 29. Жидкости и огонь (2)
- 30. Еще мы добавили • Сигвеи, танк • Кошек, собак, носорогов, обезьян • Навмеш и расхождение толпы • Поднимание и кидание предметов • Много экзотических видов оружия • Разные разрушаемые объекты • Деревья, гирлянды и т.п. • Ткани (NVIDIA APEX)
- 31. Сервера 1. Основной репозиторий 2. Build, Wiki, BugTracker/TaskTracker, Jabber 3. Backup • На многих машинах запущены клиенты для распределенной компиляции уровней и шейдеров
- 32. Вопросы? aiven@akella.com Скачать слайды @const_int http://akella.com/forum http://postal3.ru http://trashmasters.ru @trashmasterzzz http://bit.ly/mr9Xgr
- 33. Заголовок 1 • Текст 1
- 34. Заголовок 2 Заголовок 2 • Текст 2
Editor's Notes
- Всем доброе утро. Спасибо что пришли в столь ранний час. Я знаю, это было трудно.
- Немножко о себе. Зовут меня Ефимов Константин. Работаю в Акелле уже давно. Участвовал в разработке нескольких проектов. Последние лет сто работаю на проекте Postal 3
- Для начала немножко истории. На дворе был конец 2006 года. Мы заканчивали наш предыдущий проект Swashbucklers (в русской версии Головорезы) под PC и P layStation 2. Там в принципе уже все было понятно, ничего сложного и просто надо было планомерно его доделать. У художников уже заканчивалась работа и надо было их чем-то занять. Ну и надо было уже думать что мы будем делать дальше. Тут мы узнали что ребята из Running With Scissors хотят делать продолжение Postal . Мы предложили им скооперироваться и совместно его делать . У нас с ними были хорошие отношения, Акелла давно с ними сотрудничала: Postal 1, 2 и аддоны в России отлично продавались. RWS на тот момент уже провела какой-то начальный препродакшн и у них было что показать нам. Планы были громадные. Изначально планировалось делать убийцу GTA с открытым миром, кучей заданий, с кучей разного нужного и не нужного оружия и ну и все такое. Короче как GTA 3, только круче. И больше. И круче... Одной из основных фичей игры было то, что там в каждый дом можно было зайти и ходить там. Ну, короче, огромный такой мир, который живет своей собственной жизнью, а мы ходим там и развлекаем себя по всякому. Подписали контракт и стали думать как мы это все будем делать. “ I feel that we can make an ass-kicking game together.”
- Сразу возник вопрос: под что делать. Тогда недавно произошла смена поколений игровых консолей. Понятно было, что следующая игра должна быть уже под эти новые платформы. Опыт разработки под консоли у нас был, но работы с “next-gen” ну или даже под “современный на тот момент” PC не было. Художники умели делать только low-poly, программисты писали однопоточный код под fixed-pipleline. Надо было срочно изучать новые технологии: всякие hi-poly, нормал-мапы, шейдера, “реалистичная физика”. Почти все, конечно, давно интересовались новыми технологиями, но большого опыта работы еще не было ни у кого. PC-рынок во всем мире умирал и особо надеяться на него не стоило. PS3 тогда выглядела очень сложной. Вся мультиплатформа выглядела на Xbox лучше. Так, основной версией стала Xbox-версия, предполагалось ее вылизывать и показывать всем на выставках. Весной 2007 мы выписали себе Xbox-девкиты и тесткиты и начали смотреть с чем их там едят.
- Тогда виделось 3 варианта развития событий: Прокачать существующий движок от Swashbucklers. Разрабатывать новый движок самим с нуля Ну или купить готовый и не париться В Swashbucklers все было сильно завязано на RenderWare. Но в 2004 году Electronic Arts купила авторов движка, Criterion Games, увы, и не хотела никому лицензироваться новый RenderWare 4. Ну и за годы работы старая архитектура надоела, хотелось чего-то новенького. Короче, этот вариант отпал сам собой. Переписать все с нуля всем программистам давно хотелось :) Типа, вот сейчас-то мы сделаем все красиво и правильно, а не так как в прошлый раз. Но разработать новый движок и тулзы было сложно и рискованно, это могло затянуться на месяцы, а в результате ничего хорошего не получиться. Все эти шейдеры, многопоточность, новое железо... Короче, интересно, но слишком стремно. Как можно догадаться, третий вариант -- это вариант, на котором мы и остановились. Хорошо бы было сразу приступить к разработке игры, а не тратить время на разработку движка и тулзов. Ну и программистов давно была тайная мечта -- использовать чужой движок, чтобы сваливать всякие баги и глюки на разработчиков этого движка. Ну типа «Это не мы, это все они». Короче, осталось просто выбрать и купить движок... Но это оказалось не такой уж простой задачей.
- Было отсмотрено несколько движков. Разных. “Движок за миллион” вычеркнули сразу -- не было денег и у RWS был негативный опыт общения с их поддержкой. Ну, точнее, поддержки там почти не было, только форумы. У всех остальных отсмотренных были большие проблемы с отсутствием выпущенных игр. Какие бы замечательные демки у них не были, но хотелось увидеть как это все великолепие будет работать в реальных проектах. Рассматривали даже отечественные. Они были ничего так и у них был огромный плюс в виде русского саппорта, который сидит недалеко, в одной с нами часовой зоне, говорит по-русски, ну и в случае чего сможет оперативно помочь. Третий вариант был движок Source. У него оказалось много плюсов -- многие художники уровней уже имели с ним дело и делали на нем всякие моды и карты. Движок очень распространен -- было много моддеров, которых потом в теории можно было нанять на работу. И еще на нем уже было сделано много отличных игр и куча модов к ним. В том числе и лучшая игра всех времен и народов -- Half Life 2. И еще у него уже была нормальная поддержка Xbox 360 и PlayStation 3, -- то что нам и надо было. Мы скачали и какое-то время поигрались с бесплатным Source SDK. Ну и он нам, в принципе, понравился. В общем, все обнаруженные плюсы и минусы разных движков были представлены начальству, и в итоге выбор пал на Source.
- Очень долго занимал процесс запуска игры. На старте там предзагружалось куча всего -- модели оружия, общие текстуры. Что только ни грузилось. В результате после нажатия кнопки F5 в Visual Studio и до окончания загрузки простенького уровня проходило по пол минуты и больше. Если Debug- версия, то еще больше. Стало понятно, что надо срочно апгрейдить компы тем людям, кто часто запускает игру -- программистам и дизайнерам уровней. Проапгрейдили. Стало полегче. Движок, ориентированный на программиста -- это в Valve, так они сами так называют философию своего движка. Типа можно все очень легко изменять, но для этого нужно быть программистом. В результате, к любому художнику, аниматору или дизайнеру должен был быть приставлен программист. А лучше два. Требовалось писать много инишников, скриптов для компиляции моделей, анимаций и текстур. Документации было мало и часто приходится лезть в исходники для того чтобы узнать что делает та или иная галочка или комманда. Предыдущая наша игра была синглплеерной. Мультиплеер в Postal, конечно же, планировался, но как-нибудь потом. Надо было сначала сделать синглплеер. Опыта разработки мультиплеерных игр ни у кого не было. И по началу дико смотрелось то что надо писать фактически одно и тоже по два раза -- в коде сервера и коде клиента. Много расчетов делается по два раза. Ну научились и привыкли. Еще оказалось, что в исходниках движка Source присутствуют сразу все (на том момент), игры Valve. Ну в смысле, для новой игры они не создавали отдельный бранч, а код новой игры вкорячивалась прямо в существующие исходники ифдефами. В зависимости от набора дефайнов, можно собрать любую их игру. В коде из-за этого было сложно ориентироваться, так как было очень много ненужной информации. И IntelliSence в Visual Studio вообще сходил с ума и становился неюзабельным. Мы, кстати , тоже стали использовать свои похожие ифдефы -- так сразу видно что меняли мы, а что они. И обновлять движок так проще, в смысле мержить новую версию. В предыдущем проекте мы активно использовали паттерны проектирования: синглтон, визитор, фабрика, абстрактная фабрика, прокси. А в Source все делается по старинке – там минимум структур данных, везде фиксированые массивы и глобальные переменные, никаких неймспейсов и даже (о ужас!) goto. Строк почти нигде нет -- везде индексы. Это, безусловно, очень положительно сказывается на производительности кода и его простоте его понимания, но по началу казалось большой дикостью. Но больше всего поверг в шок файл BaseEntity.h -- это базовый класс для всех энтитей. Файл был очень большой и в классе было более 1000 обычных и виртуальных функций на все случаи жизни. Имплементация этого класса размаза по нескольким огромным файлам . Чтобы узнать как что-то работает приходилось скакать по множеству файлов и IntelliSence не работал как надо. Ну ладно, нам с этим как-то надо было жить. Привыкли... По ходу разработки начали возникать разные проблемы. О них далее.
- Изначально планировалось сделать вид как от третьего лица, так и от первого. На улице хорошо подходил вид от третьего лица -- удобно перемещаться по миру с помощью стика и видеть что происходит вокруг крутя камеру -- как в платформерах или рпг. И новые виды рукопашного оружия должны были хорошо смотреться именно от третьего лица. Внутри помещений планировалось переключаться на вид “из глаз” – предполагалось что так будет удобнее ходить по всяким коридорам и комнатам и разглядывать окружение. Короче, на улице вид от третьего лица, а в помещении -- от первого. Это по умолчанию так. Но игрок мог еще сам выбирать как ему удобнее играть. Попробовали сделать. На прототипных уровнях сразу стали видны проблемы -- (сюрприз!) от первого лица многое выглядело совсем не так как от третьего. Основная проблема была с дверями. Они от первого лица были нормальные, а от третьего маленькие и узкие. Ну и наоборот. Как мы не крутили положение камеры и Field of View, так ничего хорошего и не вышло. Можно было сделать какой-то усредненный вариант, но он выглядел отвратно и от первого и от третьего лица. Короче, мы отказались от первого лица. А, ну и еще как бонус отказа -- нам не пришлось моделить и анимировать оружие от первого лица :) В общем, сейчас в игре вид только от третьего лица с огромными такими дверями, чтобы можно было легко в них пролезть. Ну такой эффект можно наблюдать в Oblivion, Fallout 3, Left 4 Dead и других играх где можно переключаться на вид от третьего лица, хотя игра изначально делалась под первое.
- Вот пример двери. Не смог найти более показательное место, но на первых уровнях которые делались было все более заметно. Жалко не смог их найти их исходники…
- От идеи большого непрерывного мира пришлось тоже отказаться. Естественно, весь мир в память не влезет и его надо было как-то разбивать на куски и стримить. Оказалось, что в Source можно стримить практически все... кроме геометрии уровня. Source, как и большинство остальных шутерных движков, был заточен на закрытые пространства: коридоры, комнаты, порталы. Было решено разбить мир на несколько максимально возможных больших частей. Каждая зона -- это отдельный уровень. При переходе из одной зоны в другую происходит загрузка нового уровня. Так было в Postal 2, ну и в Half Life 2. Большие дома, магазины, подземелья тоже делали отдельными уровнями.
- Вот финальный план мира. Каждый квадратик – это отдельный уровень. Не знаю , видно ли что-нибудь.
- На уровнях должно было быть много одноэтажных домов. И в них можно было заходить. Сразу вылезли проблемы с отсечением. Хоть уровни в игре и открытые, но пришлось сделать их максимально коридорными. Одноэтажные домики плохо загораживали друг друга и то что за ними, и в результате почти ничего не отсекалось и рисовалось сразу чуть ли не по пол уровня. В домиках еще были окна и двери, т.е. получалось что они вообще никак ничего не загораживали. Короче от заходов прям во все дома пришлось отказаться. Мы “заколотили” большинство из них. А плоские уровни пришлось делать со всякими горками и заборами, чтобы показывать как можно меньшие зоны и чтобы хоть что-то отсекалось. С закрытыми уровнями проблем не было. Там все хорошо. BSP работает как надо.
- Вот скриншот одного из первых уровней. Улицы тут как коридоры, а области за заборами – как комнаты. Из каждой такой области почти не видно других областей.
- Это еще одна проблема, связанная с созданием уровней. Над уровнем обычно параллельно работают художник и дизайнер. Или два дизайнера делают разные миссии на одном уровне. Уровень хранится в большом текстовом файле. Происходило много сложных конфликтов при мерже. В редакторе Hammer есть возможность объединять объекты в группы -- что-то типа слоев. Решение -- каждый дизайнер создает все свои объекты в одной группе и, таким образом, эта группа занимает одну большую секцию в файле и становится проще мержить. Группы легко копировать и вставлять в другие файлы.
- В Swashbucklers у наc были ролики на движке. В realtime. Был свой редактор роликов в котором они и делались. Можно было удобно редактировать и проигрывать их. Все хорошо загружалось и выгружалось. В Source аналогичных средств не было. Есть FacePoser, но там неудобно делать большие катсцены. И еще очень примитивное управление камерой -- летает по контрольным точкам. Было решено делать маленькие сценки, захватывать их и потом монтировать и постобрабатывать. В игре играются уже финальные видеофайлы. Z-buffer тоже захватывается, т.ч. можно делать всякие эффекты типа Depth of Field .
- Ну да, делать что-то новое всегда сложно. Капитан Очевидность. Но Source постоянно упорно сопротивлялся добавлению новых фичей. Высказывание Генри Форда: Автомобиль может быть любого цвета, если этот цвет – черный. У нас в студии зародилось другое высказывание: На движке Source можно сделать любую игру, если эта игра -- Half Life 2. То что уже есть в Source нельзя пытаться как-то капитально исправить или сделать как-то по-другому. Мы пытались. Честно. Но после многих неудачных попыток, смирились и перестали. Несмотря на хитрые интерфейсы и абстракции, все-равно везде ожидается что это работает внутри именно так, как работает. Движок разбит на модули и из одного модуля сложно обратиться в другой используя только его публичный интерфейс. То, чего нету в Source -- того не существует. Прикрутить что-то новое, бывает порой очень как сложно. Пример: вместо главного персонажа в игре -- камера. Хоть и есть отдельный класс Player, но все-то знают что на самом-то деле все игры Valve от первого лица и используют игрока и камеру как одно и тоже. Например объекты надо фейдить по удальности от игрока, переключались LODы тоже – используется положение игрока, а не камеры. Ну или просишь NPC посмотреть на игрока, а он смотрит прямо в текущую камеру. В общем, когда я делал систему камер мне пришлось много что где менять, чтобы использовалось то что нужно. Еще пример: мы хотели сделать коллижн-сферу для персонажей, но так и не получилось. Все постоянно цепляются углами ббокса за углы и выступы в уровне. В Source можно трейсить только боксы, но не сферы. Ни один программист сломался на этом таске. Пытались делать несколько раз, но так и не смогли осилить. Потому что везде используются боксы и изменить это нельзя! Но новые фичи добавлять все-таки как-то нужно было. Вот что нам удалось впихнуть.
- У Valve был плагин для Maya, но неудобный. Чтобы отэкспорить что-то, надо было каждый раз выбирать File -> Export Selection и устанавливать там каждый раз всякие настройки. Наш технический художник написал нам удобную надстройку над экспортером с графическим интерфейсом, максимально напоминавшую экспортеры от RenderWare. Все довольны. Можно нажатием одной кнопки переэкспортить много всего сразу. Без него было бы жить намного сложнее.
- В Source не было скриптового языка. Все сложное делалось в редакторе уровней Hammer. Создавалось много вспомогательных энтитей с кучей неочевидных связей между ними. Недавно, начиная с Left 4 Dead 2, в Valve наконец прикрутили Squirrel и GameMonkey, но тогда их не было. Первым делом, мы прикрутили LUA. Можно было обращаться к энтитям по имени и вызывать у них методы. Но в начале проекта особой необходимости в скриптовом языке не было и LUA почему-то никто не пользовался. Когда дело дошло до сложного AI, было решено разработать свой язык на основе инишников Source. Сначала был простой язык, а потом превратился в такого монстра с операторами сравнения и всякими сложными конструкциями. Поведение NPC и логика миссий создаются на нем.
- Сложно найти какой-нибудь маленький самодостаточный кусок для иллюстрации. Слева это какая-то логика миссии. Справа один из стейтов собаки.
- В игре должен быть город множеством жителей. Надо сделать их разнообразными. Было решено не городить особо сложную систему для кастомизации персонажей (как во многих RPG), а сделать все проще и на том что есть. Всего есть несколько основных моделей персонажей. В каждой модели есть несколько вариантов геометрии головы, тела, причесок и тому подобного. Называются бодигруппы. Еще есть сменные наборы текстур, скины.
- Плюс можно прицеплять в определенные слоты разные шляпы, часы, значки, сумки и тому подобное. Мы назвали их болтонами. Все модельки, скины или болтоны помечаются тегами и определенный набор этих тегов образует префаб. Конкретный инстанс персонажа собирается как из конструктора. Бодигруппы и скины уже были, а болтоны и префабы -- наше изобретение. На уникальных персонажах таких как игрок и основные герои, тоже эта система используется. В игре, дизайнер ставит точку где рождаются NPC и перечисляет имена префабов которые использовать. Еще пришлось сильно оптимизировать AI, т.к. в Half Life на уровнях было несколько NPC одновременно, а у нас должны быть толпы.
- Вот пример. Здесь все персонажи сделаны на одной модели, но у них разные скины и аксессуары.
- Вот еще пример.
- Когда отрывается конечность мы создаем регдолл с такими же моделью и параметрами как и у персонажа. У тех частей, которые нужно скрыть, их соответствующим костям устанавливается нулевая матрица. Из-за этого они не рисуются, т.к. все вертексы оказываются в нуле. Места отрыва закрываются моделями мяса (такими мясными цветочками) и там играется партикловый эффект крови. Головы могут взрываться.
- Скриншот, так сказать.
- После игры в Gears of War, дизайнерам захотелось и у нас тоже сделать систему перекатов и укрытий. Перекатов у нас нет, но укрытия есть. В Gears of War специально расставлялись энтити за которыми можно прятаться, определенного стандартного размера. У нас к тому времени уже было сделано много уровней, т.ч. было решено их не переделывать их, а динамически находить места где можно. Пришлось делать разные системы для главного игрока и для NPC. У игрока: чтобы определить высоту препятствия, 3 бокса на разной высоте -- это область, поясница и верхняя часть тела. Результат классифицируется, определяется можно ли прятаться за такими объектами. Например, на большим стеклом нельзя прятаться. Или за решетчатой дверью. Если очень низкое препятствие, то оно просто перешагивается (маленький заборчик). Если низкое укрытие или высокое – прилипаем к стене ходим только вдоль нее, поворачиваясь лицом против нормали стены. У краев останавливаемся. Ну все видели Gears of War. Для NPC генерятся специальные ноды на углах. Это сделано для того что бы было меньше дорогостоящих трейсов. Плюс нам пришлось делать очень много анимаций для поведения в прилипшем состоянии для разных видов оружия: айдлы, высовывание, стрельба. Чтобы сократить объем работы, мы сделали мирроринг анимаций персонажей. Оружие перекладывается из одной руки в другую когда мы меняем направление движения персонажа.
- Вот, на скриншоте видны три больших синих бокса для разной высоты. Красный большой бокс проверяет наличие стенки по направлению движения. Если подошли близко к перпендикулярной стене, то на нее автоматически переходится. Еще справа можно увидеть два таких маленьких бокса – они трейсят край препятствия.
- Бензин и огонь – это одна из фишек серии Postal. Пришлось как-то синхронизировать сервер и клиент, т.к. жидкость разливается на сервере, а рисуется на клиенте. На сервере жидкость существует в виде дискретных ячеек на регулярной трехмерной сетке. Ячейка создается когда в этом месте в поверхность врезается струя или капля жидкости. На клиент посылается событие и там обрабатывается. На клиенте, жидкость существует в виде декалей. Сначала был жуткий overdraw. Но с помощью триангуляции Делоне мы теперь располагаем декали так чтобы в одном месте рисовалось меньше декалей. Когда в ячейку попадает спичка или огонь из соседней ячейки – она загорается. Посылается событие на клиент и в этой ячейке рисуется эффект огня. Объекты, находящиеся в горящих ячейках, через некоторое время загораются
- Вот скриншот. Синие кубики – это горящие ячейки, а красные кружки – это декали.
- Я просто перечислю то, про что не успел подробно расказать. Вот в кратце то что мы еще добавили: Сигвеи и танк на которых можно ездить. С танком были сложности из-за того что он большой. Добавили животных. С ними были сложности, потому что они четвероногие у них длинная форма тела и было сложно сделать чтобы они правильно ходили и разворачивались. Особенно большой был носорог. Еще сделали шейдер меха. Взяли и доработали напильником навмеш из Left 4 Dead. Теперь pathfinding делается намного лучше и быстрее. Добавили нормальный стиринг NPC . Многие предметы можно поднимать и использовать как оружие: бутылки, палки, урны. Они бывают как одноручные, так и двуручные. Наделали всякого экзотического оружия. Например, пчелиный улей, лопата, тазер, бензин, барсук Разные разрушаемые объекты: машины, бензоколонки, аквариумы и так далее. Еще сделали специальный тип для множества мелких объектов: можно расстреливать полки магазинов и будет много осколков, и они не будут тормозить. Всякие специальные хитрые объекты окружения: деревья, которые почти не тормозят, гирлянды. Ну и тому подобное. Добавили опциональную поддержку тканей . Плащ у главного героя, ну и там тряпки на уровнях: баннеры, занавески. Еще пытались полностью заменить Havok на PhysX , но не получилось по ряду причин.
- В конце хотел привести какой-нибудь статистики, но что-то ничего не придумал и решил рассказать о наших серверах. Не знаю, может кому интересно будет. Для системы контроля версий был выделен отдельный сервер. Еще есть мощный сервер на котором крутится все остальное Build Server (который собирает новые бинарники и былды), Wiki, Bug Tracker, Task Tracker, Jabber Server, ну и так по мелочи. На Backup все с этих двух серверов бэкапится. Так же в Source можно распределенно считать уровни и компилировать шейдера. Очень ускоряет процесс.
- Ну все. Конец. Спасибо за внимание. У нас еще полно времени и я надеюсь что у вас есть вопросы. Готов на них ответить.