Итак, у нас на очереди еще одна лекция, посвященная играм, которую читает Эндрю Уилмот из Maxis о The Sims 2, которая должна стать довольно интересным контрастом по сравнению с предыдущими играми, которые все были шутерами о стрельбе и прочем. Так что идите. Большое спасибо. Это совсем другая игра, и, кроме того, это самая насыщенная по содержанию игра, над которой я когда-либо работал, так что я собираюсь в основном дать широкий обзор всего процесса, и просто попытаться охватить как можно больше различных частей головоломки, а не углубляться во что-то конкретное. Так что в конце я буду рад подробно рассказать о некоторых вещах, но основная тема этого выступления - просто попытаться дать обзор того, как вы собирали то, что на самом деле было довольно массивной игрой.

Итак, почему Sims 2 интересна? Много анимации. Как и в некоторых других играх здесь, много звука, на удивление. Огромное количество людей. У нас было по крайней мере 250, может быть, 300 человек, прикоснувшихся к этому проекту.

Это не все сразу, но все же. Это интересно с той точки зрения, что пользователи являются нашими дизайнерами уровней. Это полностью отличается от обычного процесса FPS, где практически вся суть вашего контента заключается в создании уровней. Так что наши пользователи разрабатывают уровни, а мы просто предоставляем им контент. И наш симулятор интересен тем, что все это управляется визуальным языком сценариев.

Итак, The Sims 2 был долгим проектом. Мы начали в конце 2000 года. Долгое время это была лишь небольшая исследовательская группа, которая постоянно делала демо-версии и постоянно теряла или набирала людей из остальной студии из-за других проектов. Мы находимся в полном производстве около двух или трех лет. В конце, как я уже сказал, было много людей.

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

. . Я буду приводить больше статистических данных по мере продвижения по каждому конкретному разделу, но вот основные из них. Для меня 11 000 отгруженных анимаций - это действительно большая цифра. Много, знаете ли, других данных, которые входят в игру, но 1.

1 миллион строк кода, приведенных в цитате, не содержит пустых строк и комментариев. Я просто быстро пролистаю пару диаграмм, которые вы не обязаны запоминать. Просто примерно покажу, как происходил процесс в Sims 2, чтобы, когда я буду проходить разделы немного позже, у вас было на что повесить свои мысли. В основном это то, как наш процесс создания искусства и сценариев, сценаристов объектов проходил через конвейер и производил в основном либо сценарии, либо 3D или 2D ресурсы. А на другой стороне у нас был код, который собирал эти ресурсы.

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

Итак, начнем с искусства. Во многих отношениях Sims 2 - это... Что мы пытаемся сделать.

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

Вот некоторые данные по искусству. Много моделей, а также анимации. Много эффектов, к которым мы перейдем чуть позже. По сути, просто много данных. Это несколько менее интересный пользовательский интерфейс.

На самом деле, я не собираюсь много говорить о пользовательском интерфейсе, потому что все прошло довольно гладко. Это было... . На данном этапе мы в основном считаем UI проблемой, что довольно сильно контрастирует с некоторыми другими частями игры.

Поэтому у нас было много художников. Наш технический арт-директор любит рассказывать историю о том, что... . . Он пришел из Pixar, работал над первым фильмом "История игрушек", и в первом фильме "История игрушек" было меньше аниматоров, чем в этом проекте.

Так что это дает вам представление о том, на каком этапе находятся игры по сравнению с ранней компьютерной анимацией. Наши художественные инструменты были довольно ванильными. До этой игры Maxis была студией, основанной на Maxis, а Sims 2 стала началом перехода на Maya, и теперь мы в основном работаем на Maya. И во многом потому, что мы считаем ее лучшим инструментом для анимации. По сути, мы купили все анимации из Sims 1, которые были в формате Max, написали сложный конвейер, чтобы как бы управлять перестроенной анимацией в Maya с помощью исходных анимаций, импортированных из Max.

В итоге мы не использовали ничего из этого материала, но он был весьма полезен в качестве начального руководства. Причина, по которой мы не использовали большую часть этого материала, заключается в том, что некоторые анимации были уже неактуальны, а все, что было, было переделано с гораздо более высоким уровнем детализации. Как и некоторые другие предыдущие докладчики, мы часто использовали Null для создания пользовательского интерфейса в Maya, и он отлично справился с этой задачей. Наш конвейер, опять же, достаточно прост. Одна интересная вещь, которую мы сделали примерно на полпути проекта, - добавили поддержку прямого чтения для Photoshop, и это позволило нам заставить художников работать со всеми слоями, скажем, симулятора или модели в одном файле Photoshop, что значительно облегчило их процесс.

Что касается анимации и моделирования, то в основном мы перешли от Maya, использовали внутренний нейтральный формат экспорта платформы EA, а затем у нас был собственный компилятор активов под названием Go Disco, который преобразовывал их в игровые ресурсы. То, как все это работало, было довольно интересно. Художники в основном регистрировались непосредственно в Perforce, и причина, по которой они не забывали регистрироваться в Perforce, заключается в том, что этот шаг состоял из двух частей. Вы регистрировали свою новую анимацию, модель или что-то еще, а затем запускали машину сборки, которая преобразовывала контент в формат игры, и вы получали ответное письмо с сообщением о наличии ошибок или о том, прошел ли процесс гладко. То есть вы не закончили работу, пока не получили ответное письмо, и все было чисто.

Весь этот процесс также привел к созданию большой веб-страницы, содержащей ссылки на каждый актив в игре. Так что вы могли просматривать этот веб-сайт и добираться до любой конкретной модели и всех игровых событий, которые могут быть в ней, или количества вершин, ну, вы знаете, вы называете это. Скелет Sims 2 значительно усложнился по сравнению с Sims 1X. В Sims 1X действительно была плавная обводка, чему я был удивлен, когда узнал об этом. Много внимания к деталям было уделено морфам лица, именно здесь мы получили много дополнительных эмоций и выразительности.

К сожалению, он немного темноват, поэтому в игре его фактически не видно, я полагаю. Итак, основной скелет имел 64 взвешенные кости, которые на самом деле обрабатывались либо GPU, либо CPU, но сам скелет имел 116. Так что многие из этих дополнительных костей предназначались для захватов, ну, знаете, куда положить очки, куда положить захват шляпы для согласования IK и всяких подобных вещей. И именно из-за всех этих дополнительных слотов и т.д. мы в итоге не зафиксировали скелет. В начале работы над Sims 2 мы уделяли этому большое внимание, а именно: доработали скелет, определили количество костей, расположение и все абсолютно жестко, а затем заблокировали его и забыли о нем.

Но это в принципе не работало, потому что по мере развития дизайна нам нужно было добавлять захваты, удалять захваты, изменять скелет. Поэтому вместо этого мы создали систему, в которой все наши анимации ссылались на один главный файл Maya, содержащий скелет. И у нас была система индексации, которая позволяла достаточно легко добавлять кости или даже удалять их без нарушения всех анимаций. Что касается моделирования, то нам повезло, что многие моделисты из Sims 1 приехали к нам, что очень важно для Sims, потому что, знаете, они разработали определенный внешний вид в Sims 1, который мы пытались улучшить, и у них также был большой опыт в том, как обрабатывать текстуры и моделировать анимированных персонажей, когда у вас, знаете, сотни скинов. Там есть определенный процесс, который должен протекать более гладко, чем при меньшем количестве.

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

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

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

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

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

Это звук. Может быть, это искусство, может быть, это инженерия. У нас было много звука, как и в некоторых предыдущих играх. Меня всегда поражает цифра 43 000 сэмплов Vox. И причина, по которой это поражает воображение, в том, что все наши симы говорят на симлише, так что нам даже не пришлось его локализовать.

Так что если представить, что придется локализовать все эти сэмплы Vox, это будет просто безумие. Множество шагов и просто множество окружающих звуков, срабатывающих от камеры и вызываемых различными объектами и так далее. И звук был всегда, в какой-то момент звук занимал две трети нашего объема данных, используя различные методы сжатия. Мы сократили его до гигабайта. Но это большая часть нашей игры.

Ладно, дизайн. Это было похоже на раннюю версию The Neighborhood, которая, к счастью, была заменена чем-то гораздо более красивым. Дизайн был одной из самых больших проблем в Sims 2. В принципе, это было очень сложно. Вы пытаетесь улучшить Sims 1, которая является одной из самых продаваемых игр всех времен, и привлечь людей, которые не играли в эту игру раньше, вернуть тех, кто играл в нее некоторое время и заскучал, и не потерять всех тех, кто все еще одержим оригиналом или покупает все пакеты расширения.

Кроме того, у нас есть опросы, показывающие, что люди играют в The Sims совершенно по-разному. Это почти равномерное распределение между четырьмя различными стилями игры. Я никогда не могу вспомнить все из них, но это что-то вроде того, что есть люди, которые играют в романтическую игру, ну, знаете, в настоящий симулятор, люди, которые просто строят дома, люди, которым в основном нравится мучить своих симов, это большая часть, и что-то еще. Поэтому мы поставили перед собой цель примерно через два года после выхода игры получить рейтинг Metacritic 90+, потому что в то время это была важная вещь в EA, и я думаю, что это по-прежнему так. Если вы сможете получить такой рейтинг, то ваши продажи вырастут на определенный коэффициент X.

И мы действительно достигли этого. Знаете, мы все еще на 91, я думаю. Так что все это есть. А еще есть давление, которое оказывает громкая игра, что означает постоянное давление в виде демонстраций. Так что я не думаю, что ребята из Oddworld страдают намного сильнее нас в плане постоянных демо-версий и необходимости иметь дело с ними.

. . Поэтому, хотя мы не продаем внешним продюсерам, мы продаем руководителям EA, и нам приходится поддерживать их в согласии с нашими изменениями и так далее. У нас постоянно возникает вопрос: "Знаете, мы вбрасываем новые материалы, пытаясь сделать их привлекательными. Где мы остановимся?

Если мы задерживаемся слишком долго, то нам, по сути, приходится вбрасывать еще больше материала, потому что прошло уже слишком много времени с предыдущей игры. К тому же, в самом начале мы потеряли много людей и много идей из-за расширения Simpson's 1X. Итак, новый геймплей. Мы начали с фильмов как основной идеи, ну знаете, пусть люди занимаются махинациями, созданием видео. Да.

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

Поэтому мы старались подчеркнуть некоторые важные моменты в игровом процессе. Стремления. А вот "Желания и страхи" были практически последними, и это, пожалуй, самый убедительный новый элемент геймплея. Поэтому мы как бы подвели черту под этим. Так что Wants and Fears, в основном, и Aspirations, я думаю, появились после этого промаха.

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

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

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

Изменения в дизайне очень дорого стоят, и все посмертные статьи, которые я читал об этом проекте, в основном говорили о том, как трудно было иметь дело с постоянными изменениями. Нас также затянуло в материнскую компанию EA Redwood Shores в начале 2004 года, после того как мы соскочили. Я думаю, они хотели присматривать за нами. И это привело к различным негативным последствиям. Так что у нас есть очень большой стимул научиться делать такие вещи лучше.

Итак, проектирование объектов. Возможно, не менее важная, чем искусство, это ребята, которые в основном делают весь геймплей в The Sims. Итак, принцип работы The Sims заключается в том, что в симуляторе запускается куча объектов, ну вы знаете, объектов на различных плитках, и каждый объект имеет целую серию связанных с ним скриптов, а также отвечает за последовательность всех анимаций, в которых участвует этот объект. Так что в основном все продолжало работать хорошо. Я имею в виду, что симулятор - это достаточно приятный процесс.

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

Таким образом, художники в основном предоставляют все исходные анимации, а затем роль инженера по объектам заключается в том, чтобы соединить их вместе для получения конечного результата анимации. Таким образом, возникает очевидная проблема синхронизации, особенно если инженеры по объектам не сидят рядом с аниматорами, как это было в нашей ситуации. Поэтому, по крайней мере, в начале работы, инженеры по объектам постоянно возвращались к аниматорам, пытаясь заставить их прогнать, показать им в Maya, где происходят определенные события, пытаясь понять, чего им не хватает. Это была большая технологическая проблема. В результате этого один из OE, в рамках проекта Skunkworks, создал небольшой инструмент под названием Clockwork, который, по сути, всасывал всю анимацию, считывал все теги и предоставлял небольшой браузер, который позволял очень легко понять, что делает анимация и где находятся все временные события.

Итак, Эдит - это визуальный язык сценариев, который управляет всем этим. И на самом деле, один из главных уроков The Sims 2, и, вероятно, предыдущих пакетов расширения, заключается в том, что в этой ситуации визуальный скриптинг просто не очень хорошо работает. Вы отказываетесь от многого ради красивого визуального языка сценариев. В Perforce нет истории ревизий, нет хорошего поиска и замены, все виды вещей, которые вы считаете само собой разумеющимися при использовании скриптов, текстовых скриптовых языков, вы теряете. И это становится довольно неприятным.

Поэтому я провел небольшой опрос в конце проекта, и практически все OE хотели уйти от него. Единственное, что хорошо в визуальном скриптовом языке, это то, что он практически принуждает иметь хороший отладчик, хотя, как я понял, большую часть времени он был сломан. Так что мы даже попытались немного использовать Эдит в Sim City 4, из всех вещей, что совсем не сработало. Так что теперь наша студия может сказать следующее: мы собираемся отказаться от Edith и попытаться использовать Lua в том же качестве. Инженерия.

На пике у нас было около 28 инженеров, а начиналось все с 5 или 10 в первые несколько лет. Как я уже говорил, 1. 1 миллион строк кода. У нас в Maxis довольно много общего кода. У нас есть общий код фреймворка, который, как я полагаю, начался с SimCopter и с тех пор используется во всех видах игр.

SimCity 3000, SimCity 4, Sims Online, оригинальная Sims, весь код пользовательского интерфейса был взят из этого фреймворка. Кроме того, у нас было много инженерных скриптов, в основном материалы, а также такие вещи, как камеры, каталог и настройка света. У нас был один инженер, который занимался тем, что мы называем WorldDB, то есть представлением мира, поездов и так далее. И это было нашим главным связующим звеном между геймплеем и движком. На ранних этапах создания Sims 2 было много разговоров о том, чтобы отойти от системы, основанной на плитках, на которых она держится.

Честно говоря, мы проходим через это с каждой новой игрой, и то же самое происходит с SimCity. Все наши игры основаны на плитках. С эстетической точки зрения, вы хотели бы отойти от этого. Причина, по которой мы остаемся с системами на основе плиток, заключается в пользовательском интерфейсе и геймплее. Нам пришлось бы кардинально переписать симулятор, чтобы отойти от этого.

Впоследствии это создало нам проблему, потому что у нас был хороший обобщенный код WorldDB, и было довольно сложно сделать его эффективным с точки зрения структуры, основанной на плитках. Маршрутизация была одной из самых больших жалоб на Sims 1. У вас был синдром вечеринки, когда у вас было 20 человек в партии, все пытались попасть куда-то в определенное время, и, по сути, складывались в кучу. В самом начале мы заключили контракт с компанией на написание замены для роутера Sims 1, но результаты не были такими уж фантастическими. И даже если бы это было так, все равно оставалась проблема в том, что маршрутизатор действительно необходим для игрового процесса в The Sims.

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

Анимация, довольно стандартная. Смешанная анимация, двухкостная IK, и куча дополнительных функций для обработки некоторых вещей. Стандартная досягаемость, вероятно, самая большая. У нас явно есть проблема, когда симы ходят вокруг и должны поднимать чашки, класть вещи в микроволновку и все остальное. У нас также есть система эффектов, которая начиналась как система частиц в SimCity 4, а теперь превратилась в систему прототипирования монстров, так что все это основано на скриптах, загружается в горячем режиме и имеет иерархическую структуру.

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

Мы пытались сделать его более похожим на песочницу в Sims 2, как и участок. Поэтому самой сложной технической проблемой было динамическое создание самозванцев на лету. Когда вы выходите с участка, мы создаем маленькую самозванку, которая примерно отображает его внешний вид, а также импортируем все наши ландшафты из SimCity, что позволило довольно легко создавать различные районы. Нет ничего лучше, чем если одна из ваших других игр предоставляет довольно сложный производственный инструмент, чтобы ускорить процесс. Я уже говорил о системе освещения и о том, как она должна была работать с динамическим окружением.

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

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

Таким образом, практически каждый объект должен иметь тень. Рельеф и дом на самом деле не были сделаны с использованием традиционной графики, проективного текстурирования теней. Имелся быстрый алгоритм на стороне процессора, который давал нам небольшую карту, которую мы могли просматривать для любого места в мире, вы знаете, есть ли тень в зависимости от местности или дома, что подходило для нашего целевого оборудования. Наше целевое оборудование было очень похоже на уровень DX7, поэтому нам пришлось сохранить большинство наших графических трюков довольно простыми. Еще одна вещь, которую мы использовали, это GUOBs, что означает Generic Under Object Blobs.

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

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

Я бы сказал, что такие вещи действительно должны быть в вашем художественном конвейере, потому что просто накладные расходы и дополнительная сложность в работе с графом сцены, вы знаете, фактически в коде геймплея, были достаточны, чтобы я думаю, что это снизило производительность программистов реальной игры довольно сильно. Поэтому, как вы можете себе представить, у нас были проблемы с графической производительностью, а также с количеством пакетов. То есть мы рендерим партию с целой кучей, ну вы знаете, сотнями, двумя сотнями различных объектов, и у каждого объекта могут быть различные подмножества, плюс у вас есть стены, крыша и все остальное. Так что это было проблемой для нас в самом начале, и в конечном итоге решение, к которому мы обратились, было очень старым и избитым. Итак, SimCity использует Dirty Rex.

В основном динамические объекты перерисовываются за кадр, а все, что мы знаем как статичное, мы просто сохраняем с предыдущего кадра. Я думал, что SimCity станет последней игрой, в которой будет использована эта технология, но так оно и вышло. У нас был первоначальный прототип системы для работы на низкоуровневом оборудовании, система Dirty Rex, которая в итоге за несколько месяцев превратилась в полноценную двухслойную систему в стиле SimCity 4, и это создало нам множество проблем, просто потому что она была модернизирована. Там были всевозможные подсистемы, которые в основном нуждались в большом количестве дополнительного кода, чтобы мы могли определить, когда что-то изменилось и где это изменилось. Некоторые из этих проблем возникли просто потому, что наши целевые платформы были настолько широкими и минимально необходимыми.

Итак, мы пытались поддерживать фактическое не-TNL оборудование Intel, ну, вы знаете, 815, 845, и, в основном, широкий спектр карт, которые мы пытались поддерживать, или машин, которые мы пытались поддерживать, были машины с картами уровня DX7. В материалах есть целая куча дополнительных слайдов и комментариев, которые я советую вам прочитать, если вам это интересно, но учитывая, что многое из этого не представляет интереса в будущем, я решил, что лучше пропустить это. Помимо этого слайда, конфигурация игры - это настоящая головная боль, когда речь идет о таком количестве целевых платформ. У нас была достаточно сложная система в SimCity для обработки всех возможных конфигураций, ошибок драйверов и всего остального, и мы увеличили ее примерно в два раза, я думаю. Так что наш опыт был таков, и я уверен, что и в других странах он такой же, что полагаться на биты или любой другой вид, полагаться на то, что карта скажет вам, что она может сделать или нет, просто не работает.

В основном, мы встраиваем много логики в скрипты, которые говорят нам, какие карты могут поддерживать и где установить различные параметры уровня детализации. Работа с памятью, это игра для ПК, поэтому, как обычно, мы довольно быстро и свободно обращаемся с памятью. Много STL, очень похоже на описание Чарльзом того, что они использовали в Oddworld, почти все векторы, не всегда эффективные, но мы обычно можем обнаружить случаи, когда это неэффективно с помощью профилировщиков, и наша главная одержимость во многих из этих вещей - просто предотвращение утечек. Поскольку нам нужно масштабировать игру на несколько платформ, гораздо сложнее попасть в цель, мы не можем просто попасть в определенную цель по памяти, мы, вероятно, попали в четыре или пять, в зависимости от различных платформ, на которые мы нацелены, от того, сколько памяти у системы, работает ли карта, которая потребует подкрепления из системной памяти, или от всего остального. Мы также часто используем подсчет ссылок, интерфейсы и аналогичные умные указатели, auto ref count - это, по сути, тот же тип умного указателя, о котором говорил Чарльз.

А для всего, что действительно нуждается в эффективном распределении, у нас есть пользовательские распределители для создания, ну вы знаете, подобных пулов и тому подобных вещей. У нас есть несколько интересных наблюдений за последней парой игр, которые мы поставляли. В основном, в наши дни довольно легко отследить утечки. Мы провели ряд проверок кода и как бы суммировали процентные доли тех мест, где мы находили проблемы, и если вы хотите найти утечку памяти, просто найдите new или delete в игре Так что в результате у нас почти нет, мы избегаем этого. Раньше у нас было много ручного подсчета ошибок, мы заменили все это, потому что это еще одна горячая точка.

Не совсем так плохо, но проблема с ручным подсчетом ссылок в том, что он имеет тенденцию быть очень хрупким, поэтому мы придем позже, добавим код и сломаем существующую рабочую систему. И, наконец, мы избегаем циклов подсчета ссылок, имея очень надежные подходы к инициированию и выключению. Поэтому, в основном, обязательно инициируйте и выключайте все классы, и это абсолютное требование, чтобы при выключении освобождались все автоуказатели членов. Я подумал, что это будет интересно. Если говорить о самой большой утечке, которую мы обнаружили во время доработки SimCity 4, то на самом деле это была сборка мусора в Lua, что кажется мне довольно ироничным.

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

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

И у нас много оттока средств, и в результате много пространства, которое мы затронули, а затем снова освободили. Итак, управление ресурсами. Я не собираюсь говорить об этом слишком много, потому что думаю, что это уже было достаточно подробно рассмотрено в предыдущих выступлениях. У нас есть достаточно консервативная система на основе ключей, которую мы используем в Maxis. Единственная реальная проблема, которая возникла здесь, заключается в том, что первоначальная команда разработчиков Sims 2, простите, не была знакома с ней, и, во-первых, переборщила с ресурсами, а во-вторых, попыталась сделать альтернативную систему, основанную на именах, и в итоге превратила строки в 32-битные UID.

Теперь вы можете избежать этого, и мы избегаем этого, скажем, в консольных играх Maxis, где у вас небольшое количество ресурсов, 5,000, 10,000 или что-то в этом роде. Но с нашим количеством ресурсов вы просто обязаны получить столкновения, что мы и сделали. Кроме того, у нас была обычная головная боль с пользовательским контентом: кто-то в Индии создает скин, кто-то в Англии создает скин, а затем они загружают свои скины, а кто-то в Америке скачивает их оба, и нужно быть осторожным с коллизиями ресурсов. Так что мы в основном решили обе эти проблемы методом перебора. Изменение ID экземпляра на 64 бита, в основном это решение появилось только потому, что мы загнали себя в угол, и при любом количестве простого и прямолинейного планирования в начале проекта мы могли бы избежать этой ситуации, но мы очень поздно столкнулись с этими коллизиями, и в конце концов сделать такое изменение методом грубой силы было проще всего.

Управление конфигурацией. Мы начинаем собирать довольно большую команду по управлению конфигурацией. Это похоже на то, о чем Крис говорил ранее в Bungie. В нашей команде по управлению конфигурацией было от шести до восьми инженеров, которые были разделены между Sims 2 и несколькими другими проектами. У нас в Maxis есть система, при которой мы тестируем игру, выполняя команды через командную консоль, что оказалось очень эффективным.

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

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

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

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

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

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

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

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

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

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

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

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

У нас было много чрезмерной инженерии, и я привожу здесь совершенно безумный пример, но есть и другие почти такие же безумные примеры. Итак, концепция формата пикселя, вы знаете, ARGB, 5651, простите, 5551, все остальное. Что-то, что вы обычно представляете перечислением. Ну, у нас было пять интерфейсов, я думаю, и 2200 строк кода, просто чтобы представить эту концепцию. У нас были люди, очень увлеченные C++ и COM, и это привело к тому, что я называю синдромом пузырчатой пленки, когда у вас есть достаточно простая основная концепция игры или движка, которой вы хотите иметь возможность манипулировать, но на нее наложено так много наслоений, что кажется, что вы просто не можете пробиться и сделать это напрямую.

В Maxis мы постепенно переходим на renderware, и пока что он мне нравится гораздо больше, потому что в нем есть концепция инструментария, когда вы берете куски кода и используете их напрямую. Чарльз говорил, что не стоит презирать C++, но есть некоторые области C++, которые вам просто необходимы. Так, наша математическая библиотека была написана с использованием метапрограммирования шаблонов, которое было в моде несколько лет назад. Это была обычная проблема в The Sims 2 с инженерной точки зрения: если люди внедряют новые подходы, то они должны всегда описывать их и показывать, что они на самом деле лучше. К сожалению, никто так и не сделал этого, и оказалось, что даже с этой идеей метапрограммирования шаблонов, которая заключается в том, что в итоге вы получаете более эффективный код, потому что вы бросаете все математические инструкции компилятору, чтобы он делал то, что хочет, мы получили снижение производительности по сравнению с обычной стандартной математической библиотекой, потому что мы, по сути, взрываем мозг компилятору.

Любой компилятор сдается после определенного количества глубины инлайна. На самом деле проблема не в этом. Проблема с этим подходом, который приводит к одной из таких неочевидных вещей, с которыми нужно быть осторожным, заключается в его влиянии на скорость отладки. Такой подход к библиотеке математических векторов значительно увеличивает количество вызовов функций в любой конкретной математической операции. Так, если я правильно помню, сложение vec4 в отладке превращалось в 20 вызовов функций.

Это при выключенных ассертах. При включенных ассертах это было около 40 или 50. Поэтому, когда мы сделали обратное исправление и попытались смягчить некоторые из этих проблем, мы обнаружили, что общее влияние на скорость отладки составило около 75% для наших основных процедур движка. Так что это говорит о том, что на ранних стадиях проекта нужно быть осторожным и иметь опытных и практичных людей, потому что то, что они делают, очень сильно повлияет на последующих программистов. Другой проблемой была текучка API.

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

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

Так что некоторые из этих вещей - это то, что я имею в виду, когда говорю, что мы отправили, потому что иногда меня удивляет, что мы это сделали. Так что это и есть извлеченные уроки, то есть то, как мы на самом деле, что мы собираемся изменить в том, что мы делаем. Как я уже говорил, одной из наших самых больших проблем был отток дизайна, поэтому мы изучаем предпроизводственную подготовку. Это то, чему другие подразделения EA уделяют достаточно большое внимание, но мы никогда не занимались этим в Maxis, просто потому что мы не были на этой арене до, скажем, Sims 2 или, может быть, The Sims Online, где у вас есть огромные команды и, по сути, чтобы все прошло через колбасную фабрику и вышло с другой стороны, вам действительно нужно делать это в порядке. Поэтому вся цель предпроизводственной подготовки заключается в том, чтобы вы провели все свои исследования, создали прототипы, приняли как можно больше дизайнерских решений, которые будут верными, потому что каждое из них снижает риск в дальнейшем.

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

Потому что, в конце концов, ранняя команда исследователей Sims 2 была примерно 5-10, 20-10, она как бы менялась в зависимости от того, какой другой проект шел в то время. По сути, у нас просто не было правильного мышления. Мы относились к ней как к исследовательской команде, и большая часть этих исследований уходила на изучение графики или очень ограниченное изучение новых идей, которые на самом деле не были реализованы и протестированы. Так что главное - не просто принимать дизайнерские решения, но и создавать их прототипы, делать прототипы игр, играть и смотреть, будет ли это работать. Что касается некоторых проблем с коммуникацией, то эти проблемы не связаны с чем-то конкретным в Maxis, это просто проблема наличия таких больших команд и передачи информации из одного места в другое.

Мы действительно должны изменить методы работы. Поэтому мы пробуем такой стиль работы, как "стручок", где мы гораздо больше приближаемся к подходу спецназа, который мы использовали в прошлом. Цель состоит в том, чтобы создать такие небольшие группы, в которых время выполнения итераций будет очень быстрым, и не будет большого количества межпроцессных накладных расходов, замедляющих работу людей. Это небольшой пример того, что произошло в The Sims 2. Так, для первоначального срока сдачи корабля в январе 2004 года мы фактически сократили плавательные бассейны, потому что у нас ничего из этого не было готово, и это будет довольно много работы, что было почти невероятно.

Бассейны являются неотъемлемой частью игры The Sims из-за того, как вы убиваете симов. То есть, вы бросаете их в бассейн, убираете лестницу, и они умирают. Поэтому для их спасения мы собрали команду "skunkworks", которой руководил продюсер, и все это совершенно вне обычных правил процесса. Самые простые вещи, которые мы могли сделать, в основном просто доставить что-то туда и заставить это работать, небольшое количество людей, и я думаю, что мы проделали действительно хорошую работу, чтобы доставить все это туда и заставить это работать. Это был своего рода урок в плане того, насколько эффективным может быть выход за рамки большого процесса мясорубки и просто работа небольшой группы спецназа над конкретной функцией.

И, конечно же, мы добавили к этому еще кое-что, как только спустились на землю. Так что мы уже делаем много предварительных работ над играми следующего поколения и другими играми. Мы даже нанимаем концепт-художников для создания эскизов, чтобы попытаться понять, каким будет наш внешний вид, и, по сути, просто исследовать пространство внешнего вида. Оказывается, гораздо быстрее поручить это художнику, чем делать целую кучу рендеров в Maya или, что еще хуже, запускать игровой движок и заниматься подобными вещами. Большим успехом Sims 2 в художественном плане, вероятно, была автоматическая сборка контента.

Как только система была запущена, она работала очень гладко, и, учитывая огромное количество моделей и анимации, которые проходили через эту систему, я думаю, что она проделала хорошую работу по доставке всего в нужное место в нужное время. Инженерия, в общем, урок - будьте проще. Мы переборщили со сложностью в Sims 2, и это было довольно, фактически, локализовано в этой команде. У меня был опыт работы в других командах Maxis, и они были гораздо более практичными и гораздо более сфокусированными. Так что, чем проще вы можете сохранить базовый уровень, тем больше сложности вы можете создать на его основе.

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

Мы используем ее довольно часто в текущих системах предварительного производства, чтобы прикинуть, как будет выглядеть то или иное произведение. Как я уже говорил, мы все больше переходим на текстовые сценарии. В Sims 2 у нас была база данных игровых объектов, но она была как бы перенесена из Sims 1, и была не самой лучшей. Поэтому у нас есть команда, которая работает над созданием надлежащей производственной аппаратной системы. Вот, собственно, и все. Вот некоторые из людей в Maxis, которые помогали мне советами, статистикой и всем остальным.

Хорошо, спасибо. Спасибо. Спасибо. Спасибо. Спасибо.

Спасибо. Спасибо. Спасибо. Спасибо. Итак, у кого есть вопросы?

Хорошо. Начинайте, а я принесу микрофон. Итак, у меня к вам пара вопросов, Эндрю. Поскольку у вас такое огромное количество подписчиков, ваша тема становится еще более масштабной. Я думаю, что вам тоже нужно быть в новостях.

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

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

Правильно. Вам не нужно вводить его в игру для предварительного просмотра паутины через порталы и порталы в центре. Да. Создание контента - то же самое. Да.

Тот же код. Вначале было много разговоров о важности технического руководителя и о том, что он должен проверять решения. Мне интересно, как была создана эта система общения, как были созданы ваши шаблоны и все эти вещи, как они продержались в разработке больше недели или двух. Да, здесь я должен быть несколько тактичным. У вас должны быть хорошие технические руководители.

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

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

Это не единственный фактор. Нам пришлось бы делать что-то еще на машинах низкого класса, потому что мы определенно упирались в количество партий, но есть ряд других вещей, которые мы могли бы там сделать. Накопление объектов, ну, A, лучший LOD, и B, накопление объектов в несколько буферов, и всевозможные вещи. Этот вопрос может быть неактуальным, поэтому, пожалуйста, не стесняйтесь на него отвечать, но вы дважды упоминали, что подход с использованием инструментария, знаете, вы считали чем-то действительно хорошим. Что именно это такое?

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

Ожидали ли вы, что после того, как произошел сбой, вы повысите цель, к которой вы стремились, вместо платформы DX7 до платформы DX8? Ведь вы отставали примерно на семь-восемь месяцев. Да. Нет. И я думаю, что причина этого в том, что сначала мы отставали всего на пять или шесть месяцев, а потом снова отстали.

Но это не промах, если об этом никто не слышит. Да, но на самом деле давление не было оказано в тот момент, потому что в то время, когда мы действительно могли что-то сделать с этим, и я отмечу, что мы поставляли игру с DX9-путем. Причина, по которой мы сократили путь DX8, заключалась в том, что наша система была слишком неэффективна для обработки огромного количества шейдеров - вам нужно генерировать множество различных шейдеров при таком пути, о чем Крис говорил ранее, и это нас убило. Но в то время было не так уж много игр, которые бы хорошо использовали карты DX8 на ПК. Был ли какой-то человек, вся работа которого заключалась в создании пути DX8, а потом его сократили, или что-то в этом роде?

Это была не вся его работа. На самом деле, ближе к концу - скажем, в течение последнего года - у нас был парень, который занимался исключительно написанием сценариев. До этого момента этим занимались я и еще один человек. Так что да, это, вероятно, была большая часть его работы, потому что все эти вещи должны были быть написаны на Asm, и множество различных случаев для обработки всех различных - для упаковки вещей. Интересно, что объектом с самым большим количеством костей была кровать, которая состояла из 180 костей и, очевидно, должна была быть разделена для аппаратного обеспечения.

Это просто потому, что есть много разных способов забраться в кровать, одеяла должны взъерошиться и все остальное. Никогда не бывает так, что объекты, которые вы ожидаете, оказываются самыми сложными. Итак, я закончу с Кеном, и теперь мы будем открыты для дальнейших вопросов, а также если у вас есть заявления или вы хотите рассказать что-нибудь о своем собственном процессе разработки, мы передадим микрофон. Я хотел бы спросить вас о структуре инженерной команды и о том, как работала иерархия. Был ли кто-то, кто как бы руководил планированием, помимо, возможно, нескольких руководителей программирования?

Как все это было реализовано? Одна из наших проблем заключалась в том, что он часто менялся. Возможно, это была проблема, которую я не затронул в "Simstude" на протяжении всего процесса. Я имею в виду, что до последней пары лет мы постоянно меняли продюсера или того, кто управлял командой, поскольку их отсасывали, чтобы бросить на последний огонь в других проектах. Так что в последние пару лет у нас был директор по развитию, а инженерный состав под его началом, она непосредственно управляла инженерной командой, как и большая часть инженерной команды, а затем руководители были как бы здесь.

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

Как и в предыдущей игре, Simstude 4, у нас был один человек, который был практически главным технологом, он был очень компетентен, и все практически работало. Сколько было ведущих? В Simstude? Да. Это зависит от того, как вы его классифицируете.

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

Я в замешательстве. Я открыт для вопросов. Сколько наших людей заинтересовано? У нас есть доска, если вы хотите это сделать. Мы понимаем, если вы не хотите, но, вы знаете.

Значит, вам нужна инженерная структура? Да. Да. Хорошо. Значит, ближе к концу... Немного по времени ближе к концу, так?

Хорошо. Итак, в первый момент, ближе к концу, это были в основном DD, графика, анимация и, типа, другие ведущие. Директор по развитию. Директор по развитию. Да.

Другая проблема, с которой мы столкнулись тогда, заключалась в том, что наш директор по развитию, поскольку мы впервые занимались массовым внедрением CM, все внимание было переключено на CM и управление ежедневной сборкой. Поэтому не всегда оставалось много внимания для инженерного процесса. Поэтому DD привел к тому, что проблема в том, что все было перепутано. Я могу нарисовать картину на одном этапе, когда большинство инженеров подчинялись третьему руководителю. Где мы?

Графика, анимация, моделирование. Так что, я думаю, это было до того, как произошел сбой. После срыва, вы знаете, было очевидно, что DD был перегружен, поэтому у нас было больше, три инженерных менеджера, которые пришли и, по сути, каждый взял на себя часть команды. А потом, к сожалению, мы потеряли одного из них шесть месяцев спустя. Люди как бы мигрировали к руководителям по графике и анимации?

Действительно ли эти люди справились с задачей? Или они просто переносили свои собственные вещи? Итак, есть управление, а есть распределение задач. Да. Так что в основном... Я не думаю, что задаю этот вопрос.

Итак, распределение задач - это, по сути, разговор этих парней с DD в некоторых случаях, скажем, по конкретным графическим задачам. То есть, обычное распределение, знаете, этот парень разговаривал с DD, а затем назначал задания младшим программистам, и, скажем, этот парень затем просил посмотреть, например, спецификацию интерфейса или что-то в этом роде. Анимация была очень хорошо разделена, на самом деле. По сути, причина, по которой у руководителя анимации было не так много прямых подчиненных, заключается в том, что ему удавалось поддерживать эту систему практически на всем ее протяжении в тесном сотрудничестве с техническим арт-директором, и только в конце ему приходилось работать с другим инженером, чтобы реализовать сжатие анимации и всевозможные подобные вещи. Так что я думаю, что многие люди, работавшие под руководством симулятора, на самом деле были переданы директором по разработке?

Да. Хорошо. И так... Некоторое время. Кто... Ответ на этот вопрос неприменим, но, знаете, кто внедрял стандарты политики в команде? Стандарты политики кодекса или... Стандарты политики кодекса.

Изначально, когда команда была меньше, это делали ведущий по графике и ведущий по симуляции. Когда команда стала больше и стало очевидно, что некоторые из этих вещей были плохими идеями, все стало гораздо более свободным. Я не уверен, что могу вдаваться в подробности. У меня это есть здесь. Пока я жду микрофон сверху, это как бы по касательной, но мы пробуем кое-что под названием "Командный программный процесс".

Институт программной инженерии Карнеги-Меллона занимается этим. Я не знаю, слышал ли кто-нибудь об этом, но мы столкнулись с проектом - он не был таким большим, как Sims, но он был сумасшедшим и вышел из-под контроля. И после этого мы захотели понять, как мы можем сделать это лучше? И мы попробовали эту штуку под названием Team Software Process, где вроде как все члены команды отвечают за составление расписания сами, и они отвечают за отслеживание своего времени, и есть время, отведенное на обзоры и все такое, и есть много межкомандного общения, что, казалось, помогло справиться со многими из этих областей, где вы не знаете, кто за что отвечает, и вы не знаете, идет ли общение между членами команды или обратно, или что-то в этом роде. Я не знаю.

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

В конце SimCity у нас было около 22 инженеров, в то время как в Sims 2 их было около 28, где у нас был просто очень компетентный тип - мы называли их DD, но на тот момент это было похоже на Maxis DD, который был скорее менеджером по инженерным вопросам. Итак, у нас был технический руководитель, а затем, по сути, все инженеры управлялись техническим руководителем и получали большое количество технических указаний от технических руководителей, но не слишком много. Я думаю, что одной из проблем Sims 2 было то, что в ней было слишком много технических указаний. Было слишком много. Да, слишком много процесса - вот что я пытаюсь сказать.

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

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

Другие на симуляторе маршрутизации. Я просто не могу дать очень четкий ответ по общей структуре только потому, что она часто менялась в последнее время. Два вроде бы глупых вопроса, я полагаю. Не стесняйтесь их игнорировать. Первый: не могли бы вы количественно определить, почему продукт просел на одном уровне более детальной детализации?

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

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

Игра вышла и побила прогноз. Правда, произошел сбой, что стоило денег. Но вроде как проект испортился, а продано больше единиц, чем прогнозировалось. Так где же...

. И это своего рода мета-вопрос. Когда процесс на самом деле заканчивается тем, что мы оказываемся в проигрыше? Потому что в данном случае это обошлось EA на 20 миллионов долларов дороже, но игра все равно заработает 700 миллионов долларов или что-то безумное в этом роде. Точно.

На одном из своих слайдов я в какой-то момент сделал пометку: "Не слушайте это неправильно". Потому что один из уроков Sims 2 - это то, что вы можете облажаться и выжить. И я не думаю, что мы можем облажаться до такой степени и продолжать выживать. Поэтому я также говорю, что мы должны улучшить наш процесс. Я просто хотел сказать, одна из вещей, которые вы упомянули, и здесь был вопрос о том, когда вы проседаете, заставили ли они вас задуматься о других видеокартах?

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

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

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

Я просто думаю, что совершенно ясно, что во многих случаях процесс, когда игры долго не выходят и тому подобное, на самом деле не вредит, потому что нет достаточной конкуренции в играх, которые выходят, чтобы это действительно вредило вам. То есть, если такая игра, как The Sims 2, задерживается на год или два, это не имеет значения, потому что нет конкурентов, которые приходят и агрессивно продают на этом рынке, отнимая его. Я имею в виду, что обычно компании терпят крах из-за процесса. Потому что кто-то приходит и, знаете, использует это в своих интересах. Так что я с этим немного не согласен.

Я думаю, что по мере того, как эти игры становятся все больше и больше, стоимость увеличивается по ряду причин. Одна из них - маркетинг. Мы потеряли много денег, не уложившись в срок, просто потому, что у нас уже была заказана реклама на телевидении, ну, вы знаете, различные вещи в этом роде. Другая причина - скорость сгорания. Знаете, скорость сгорания при срыве сроков на два года просто феноменальна для такого большого проекта.

Я хотел задать вопрос, который может привести к более общей дискуссии, а именно: можете ли вы рассказать о том, какой опыт был у ваших объектных инженеров? Например, вы называете их объектными инженерами, что, я полагаю, означает, что они имеют инженерное образование, но в то же время они используют исключительно визуальные инструменты и расстраиваются из-за этого, потому что им больше нравится использовать текстовые инструменты командной строки. Итак, каков их опыт? Были ли они инженерами и дизайнерами? Вы бы предпочли, чтобы это были инженеры?

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

То есть, они берут активы, знаете, есть движок, который поставляют инженеры, и вместе с продюсерами соединяют все это вместе, чтобы сделать из этого игру. В такой игре, как The Sims, где, знаете ли, геймплей хорошо разделен, они являются своего рода комбинированным дизайнером уровней. Да. Да, в основном. Хорошо, спасибо, Эндрю.