Готовый перевод Game Programming Patterns / Паттерны программирования в играх: 0. Introduction

В пятом классе мы с друзьями получили доступ к малоиспользуемому классу, в котором стояла пара сильно убитых TRS-80.

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

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

Поэтому мы предпочитали программы всего из нескольких строк:

10 PRINT "BOBBY IS RADICAL!!!"

20 GOTO 10

Таким трудным способом мы постигали ценность короткого, простого кода.

Тем не менее, этот процесс таил в себе опасность.

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

Если программа не работала (что случалось часто), мы начинали процесс сначала.

В глубине кучи бумаг нас поджидал настоящий монстр:

программа, занимавшая несколько испещренных кодом страниц.

Потребовалось некоторое время перед тем, как мы собрали волю в кулак, чтобы попробовать ввести и запустить ее, но задача оказалась непреодолимой:

заголовок над листингом программы гласил: "Туннели и Тролли".

Мы понятия не имели, что делала программа, но по названию можно было подумать, что это игра, а что может быть круче, чем компьютерная игра, запрограммированная собственноручно?

Через год мы переехали из того класса, так ее ни разу и не запустив.

(Гораздо позже, когда я уже немного знал BASIC, я понял, что это был генератор персонажей для настольной игры, а не сама игра.)

Но жребий был брошен и с этого момента я хотел быть разработчиком компьютерных игр.

Когда я был подростком моя семья заполучила Macintosh с установленным на нем QuickBASIC, а позже был установлен и THINK C.

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

Самостоятельное изучение было медленным и трудным.

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

Когда я уже просто не мог держать все программу в голове целиком, она была обречена.

Немало времени было проведено и в болотах южной Луизианы, где я ловил змей и черепах.

И если на улице не было чудовищно жарко, то выбор вполне мог пасть и на книгу по герпетологии, а не по программированию.

Сначала проблемой было даже вывести что-то на экран.

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

Вместо того, чтобы просто читать "Как программировать на С++", я начал искать книги о том, как организовывать программы.

Через несколько лет новый друг протягивает мне книгу:

Паттерны проектирования:

Элементы объектно-ориентированного программного обеспечения многократного использования.

Наконец-то!

Книга, которую я ищу с детства!

Я прочитал ее от корки до корки за один присест.

Я всё еще боролся со своими программами, но это было такое облегчение - увидеть, что другие тоже боролись и нашли решения.

Я чувствовал, что наконец имею несколько инструментов для использования, а не просто голые руки.

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

Хотелось бы думать, что мои социальные навыки улучшились хотя бы чуть-чуть с того памятного случая.

В 2001 я попал на работу своей мечты:

инженер-программист в Electronic Arts.

Я буду настоящим программистом компьютерных игр!

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

Как они строят такую огромную игру как Madden Football, которая явно не может поместиться в чьей-либо голове?

Какой была архитектура?

Как они разграничили физику и визуализацию?

Как код ИИ взаимодействовал с анимацией?

Как они абстрагировали звук для работы на нескольких платформах?

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

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

У нас были люди, которые знали, как выжать все из процессора для блага игры.

То, что я считал невозможным, эти люди делали до обеда.

Но архитектура, на которую привязывался этот великолепный код, часто была слепленной впоследствии.

Они были так сосредоточены на отдельных функциях, что не уделяли достаточно внимания связям между кусками кода.

Связи между модулями были избыточны.

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

К моему разочарованию, казалось, что многие программисты, если хотя бы начали читать "Паттерны проектирования", то не продвинулись далее паттерна Singleton ("Одиночка").

Конечно, все было не так плохо.

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

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

Они делали все, что могли, и как я постепенно понимал, это "все" часто было очень даже хорошо.

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

К сожалению, слово "спрятанными"

часто было слишком мягким описанием.

В коде были похоронены бриллианты, но много людей топталось прямо на них.

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

Эта книга нацелена на то, чтобы решить данную проблему.

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

Что продается в магазине

Уже есть дюжины книг, посвященных программированию компьютерных игр.

Зачем тогда писать еще одну книгу?

Большинство книг по программированию игр, которые я видел, попадают в одну из двух категорий:

Предметно-ориентированные книги.

Эти узконаправленные книги дают вам глубокое погружение в определенный аспект игровой разработки.

Они научат вас трехмерной графике, визуализации в реальном времени, симуляции физических эффектов, искусственному интеллекту или работе со звуком.

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

Книги об игровом движке.

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

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

Мне нравятся обе категории книг, но они оставляют некоторые пробелы.

Предметно-ориентированные книги редко говорят, как кусок кода взаимодействует с другими частями игры.

Вы можете быть гуру в физике и визуализации, но знаете ли вы, как изящно связать их вместе?

Вторая категория охватывает эти вопросы, но часто данные книги слишком монолитные и жанрозависимые.

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

Мы более не клонируем Quake.

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

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

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

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

Другой пример подхода "à la carte" служит популярная серия "Бриллианты программирования игр".

Как это связано с "Паттернами проектирования"

Каждая книга по программированию с "Паттернами"

в названии явно имеет связь с олдскульной книгой "Паттерны проектирования:

Элементы объектно-ориентированного программного обеспечения многократного использования" (авторы: Эрих Гамма, Ричард Хелм, Ральф Джонсон и Джон Влиссидс, зловеще называемые "Бандой четырех").

Предыдущая книга, в свою очередь, послужила источником вдохновения для книги "Паттерны проектирования".

Идея создания языка паттернов для описания открытых решений задач идет из книги "Язык паттернов" (автор Кристофер Александер совместно с Сарой Исикавой и Мюрреем Сильверштейном).

Их книга была об архитектуре (то есть, о настоящей архитектуре со зданиями, стенами и прочим)

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

"Паттерны проектирования" - это попытка "Банды четырех" использовать такую структуру для программных продуктов.

Назвав эту книгу "Паттерны программирования в играх", я отнюдь не хочу заявить, что книга "Банды четырех" не применима к играм.

Напротив:

вторая часть данной книги возвращает нас ко многим из паттернов, которые были впервые описаны в книге "Паттерны проектирования", но с особым акцентом на том, как они могут применяться в программировании игр.

С другой стороны, по моему мнению, данная книга также может найти применение в неигровом программном обеспечении.

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

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

Вместо того, чтобы попытаться поспорить с "Паттернами проектирования", я рассматриваю данную книгу, как ее дополнение.

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

Время и последовательность часто являются основой игровой архитектуры.

Все должно происходить в правильном порядке, в нужное время.

Циклы разработки сильно сжаты, и узкому кругу программистов нужно быстро собрать игру и провести итерацию, затронув функционал с различным поведением, не отдавив друг другу ноги и не наследив по всей кодовой базе.

После того как все подверженные изменению поведенческие функции определены, начинается взаимодействие.

Монстры кусают героя, позиции перемешиваются, бомбы взрывают как врагов, так и друзей.

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

И последнее: в играх критична производительность.

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

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

Как читать эту книгу

Книга разбита на три обширных раздела.

Первый раздел - это введение и оглавление книги.

Он включает в себя главу, которую вы читаете сейчас, а также следующую главу.

Второй раздел ("Возвращение к паттернам проектирования")

освещает несколько паттернов из книги "Банды четырех".

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

Наконец, в последнем разделе содержится настоящая "соль" книги.

Он знакомит читателя с тринадцатью новыми паттернами проектирования, которые я нашел в играх.

Новые паттерны объединены в четыре группы:

последовательности, поведения, декомпозиции и оптимизации.

Каждый паттерн описан с помощью одной и той же структуры пунктов, поэтому вы можете использовать книгу в качестве справочника и быстро найти то, что вам нужно:

Пункт "Цель" представляет краткое описание паттерна в терминах задачи, которую он решает.

Пункт расположен в списке первым, чтобы вы могли быстро найти в книге паттерн, который поможет вам в текущей работе.

Пункт "Мотивация" описывает образцовую задачу, к которой мы будем применять паттерн.

В отличие от конкретных алгоритмов паттерн обычно не обретает форму, пока не применяется к какой-то определенной задаче.

Учить паттернам, не имея пример перед глазами - то же, что и преподавать кулинарию, не учитывая состав теста.

Данный пункт - это тесто, из которого в следующих пунктах выйдет отличная выпечка.

В пункте "Паттерн" мы выжимаем эссенцию из паттерна, используя предыдущий пример.

Если вам нужно сухое описание паттерна, как в учебнике, то этот пункт для вас.

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

До сих пор паттерн пояснялся на основе единственного примера.

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

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

Пункт "Имейте в виду" указывает на последствия, которые имеет использование паттерна в вашей программе.

Паттерн - это шаблон для решения.

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

В следующем пункте ("Проектные решения") освещены различные способы реализации абстрактного паттерна в живом коде.

До этого момента было много презентаций, а самого кода - не очень.

Пункт "Примеры кода" исправляет эту недоработку, предоставляя одну или две образцовые реализации.

Если, как и мне, вам нужны конкретные примеры, чтобы вникнуть в тему, этот пункт для вас.

В качестве завершения пункт "См. также" показывает, как данный паттерн связан с другими как в этой книге, так и в "Паттернах проектирования".

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

Как оформлена книга

У каждого паттерна есть набор составляющих - ингредиентов в его рецепте.

Каждая реализация включают эти части, поэтому важно учитывать их все.

При первом упоминании составляющая будет выделена жирным шрифтом.

Кроме того, дополнительная информация и мои глупые шутки будут помещены в специальные поля (такие, как это).

При желании можете их пропустить.

Примеры кода выделены моноширинным шрифтом.

Каждый следующий паттерн, упоминающийся в книге, будет напечатан прописными буквами.

А далее будет номер страницы, где описан данный паттерн, по типу объектного пула.

Паттерны, описанные "Бандой четырех" в книге "Паттерны проектирования", также будут напечатаны прописными буквами, но вместо указания номера страницы будут выделены так:

Decorator (Декоратор).

О пункте "Примеры кода"

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

Любой объектно-ориентированный язык программирования справится на отлично.

Я выбрал C++ по нескольким причинам.

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

Это язык общего назначения, широко распространенный в данной индустрии.

К тому же, синтаксис языка C, на котором основан C++, также является базой для языков Java, C# и многих других.

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

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

Ищите в примерах кода выраженную в них идею, не заостряя внимания на самом коде.

В частности, код написан не в современном

стиле C++11 или более новом стандарте.

Он не использует стандартную библиотеку и только изредка использует шаблоны.

Это приводит к "плохому"

C++ коду, но я надеюсь, что будучи максимально упрощенным, он будет более доступен для людей, которые пришли из C, Objective-C, Java и других языков программирования.

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

На месте пропущенного кода в примере будет ставиться многоточие.

Представьте себе функцию, которая что-то делает и затем возвращает значение.

Разбор шаблона строится на значении что вернет функция, а не на том какую работу она выполняет.

В этом случае пример кода будет выглядеть как-то так:

bool update()

{

// Тут что-то происходит...

return isDone();

}

Что делать после прочтения данной книги

Паттерны - постоянно изменяющаяся и расширяющаяся часть разработки ПО.

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

Вы - ядро этого процесса.

Как только вы разрабатываете собственные паттерны и подробно разбираете (или опровергаете!)

существующие паттерны, то тем самым вносите вклад в сообщество программистов.

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

Внимание! Этот перевод, возможно, ещё не готов.
Его статус: идёт перевод

Переведено на Нотабеноиде
http://notabenoid.org/book/51192/215206

Переводчики: IngaJolly, ZaEzzz, Vladislav86, alshi

MrSmith33, r0me, marapper, kamillxiii

deveel, Deo, GromHoll