Лекция #14. Паттерны revisited. Введение. [Лектор - aruslan]
Автор: Арсений Капулкин
Disclaimer: лог почищен, суффиксы ников убраны, обсуждение про max выкинуто. полный лог
[00:02] <aruslan> сегодняшняя лекция имеет громкое название "Паттерны revisited."
[00:02] <aruslan> Это, конечно же, неправда. Потому как уместить 1500 страниц описаний паттернов в software в 1 час - нереально совсем.
[00:02] <aruslan> и, главное, ненужно.
[00:03] <aruslan> мы будем говорить сегодня о том, как появляются и проявляют себя паттерны при разработке игр.
[00:03] <aruslan> основной акцент - дата дривен.
[00:03] <aruslan> я постараюсь обойтись без жёсткого дзена и быть довольно конкретным. настолько, насколько позволяет сама тема.
[00:03] <aruslan> маленькая просьба.
[00:04] <aruslan> у меня сейчас открылось восемь прайветов в мирке. я буду тормозить и не сразу отвечать - не обессудьте.
[00:04] <aruslan> *десять
[00:04] <aruslan> *двенадцать
[00:04] <aruslan> итак, о чём мы НЕ будем говорить.
[00:04] <aruslan> поступили просьбы рассказать о Визиторе, Адаптере и ГУИ.
[00:05] <aruslan> О визиторе будет, по всей видимости, отдельная лекция. Потому как много желающих послушать.
[00:05] <aruslan> Не очень понятно, правда, о чём. Потому конкретные вопросы приветствуются.
[00:06] <aruslan> Адаптор - это очень просто и не думаю, что имеет смысл о нём говорить.
[00:06] <aruslan> ГУИ частично всплывёт сегодня как часть дзена.
[00:06] <aruslan> Но начнём мы с самого главного.
[00:06] <aruslan> С контекста, в котором применяются паттерны и с вашей роли как проектировщика.
[00:06] <aruslan> . Контекст.
[00:07] <aruslan> Основной смысл деятельности проектировщика - в выборе решения.
[00:07] <aruslan> Слово выбор - ключевое. Иными словами - это в первую очередь поиск компромисса.
[00:08] <aruslan> Компромисс невозможен на луче (плохо; хорошо).
[00:08] <aruslan> Поиск компромисса на этом луче - это такой дзен-даунизм. Потому что если умеешь сделать хорошо - сделай.
[00:08] <aruslan> Компромисс требует нескольких осей и противодействующих или содействующих сил.
[00:08] <aruslan> В любом описании паттерна вы встретите "силы".
[00:09] <aruslan> Иногда их описывают прямо в начале книги.
[00:10] <aruslan> ПОловина GoFа посвящена, например, design for change - инкапсуляция для устойчивости при изменениях.
[00:10] <aruslan> Есть более глобальные силы.
[00:10] <aruslan> Часто они находятся вне собственно предмета программирования.
[00:10] <aruslan> Например - разделение обязанностей разработчиков, распределение труда.
[00:11] <aruslan> Другой пример - обеспечение сопровождаемости кода, его соответствие неким мифическим метрикам.
[00:11] <aruslan> Компромисс не предполагает единственно правильного решения.
[00:12] <aruslan> (Сорри за трюизмы, я просто хочу быть уверенным что это было сказано)
[00:12] <aruslan> Потому вопросы типа "какая архитектура ГУИ лучше всего" и т.п. - это неправильные вопросы.
[00:12] <aruslan> Классика жанра - cohesion и coupling.
[00:12] <aruslan> Или "универсальный движок".
[00:13] <aruslan> Если вы видите "универсальный движок" объёмом исходников меньше 100 мегабайт, можете смело идти мимо.
[00:13] <aruslan> Потому что там будет всё настолько универально, что писать код придётся вам, а не разработчику движка.
[00:14] <aruslan> Cohesion и coupling - я взъелся на чисто "связность", потому что должно быть ДВЕ силы, а не одна.
[00:14] <aruslan> На одной не бывает компромиссов.
[00:14] <aruslan> Итак, вы - архитектор (проектировщик, программист).
[00:14] <aruslan> Начинаем дизайнить игру.
[00:14] <aruslan> . Паттерны нулевого порядка.
[00:15] <aruslan> Вопреки распространённому убеждению, игра не дизайнится сверху вниз или снизу вверх или из середины.
[00:15] <aruslan> Потому что направление дизайна - э
[00:16] <aruslan> - это как раз одно из первых решений, которое вам предстоит принять.
[00:16] <aruslan> Точно так же "игры должны быть data driven" - это не аксиома.
[00:16] <aruslan> Хотя бы потому, что "data driven" - слишком широкое понятие, и ВАМ предстоит принять решение, в какой мере и как оно data driven.
[00:16] <aruslan> Чтобы это сказать, нужно в первую очередь понять "зачем".
[00:17] <aruslan> То есть какие _реальные_ проблемы перед вами стоят.
[00:17] <aruslan> В реальной жизни ничего не начнётся как в сказке.
[00:17] <aruslan> Вам не дадут красивые данные от маркетинга, в которых сразу понятно, что нужно делать.
[00:17] <aruslan> "Игры для девочек" и т.п.
[00:18] <aruslan> Равно как вам не дадут сразу 10+ миллионов долларов подъёмных.
[00:18] <aruslan> И найти 15 программистов - это не так быстро, как кажется.
[00:18] <aruslan> А самое главное - первым пяти нужно дать задачи, которые позволят вам двигаться к результату, нанимая остальных.
[00:18] <aruslan> Отсюда возникают первые ваши _реальные_ проблемы.
[00:19] <aruslan> 1. Кто что будет делать.
[00:19] <aruslan> 2. Какие специализации у вас возникнут, когда вы взлетите.
[00:20] <aruslan> 3. Что важнее - время, качество кода, масштабируемость процесса, средние специалисты (которых легко нанять) и т.п.
[00:20] <aruslan> То есть первые ваши проблемы - это всегда организационно-архитектурные проблемы.
[00:21] <aruslan> Принятые решения - самые страшные и самые сильные.
[00:22] <aruslan> Разделение на подсистемы (и соответствующая специализация персонала), выбор системы на основе микроядра и т.п. - это всё первые, архитектурные паттерны.
[00:22] <aruslan> Будет ли система распределенной, будет ли игра просто игрой или это будет здоровый тулсет для её разработки и т.п.
[00:22] <aruslan> Первые решения потребуют от вас первого простого дзена - оценка масштаба проекта.
[00:23] <aruslan> Петпрожекты не требуют мощных сложных комплексов паттернов. Это будет для них overkill.
[00:24] <aruslan> Реальные игровые проекты - это не только и не столько программирование. И программирование там сильно разное. Масштаб другой.
[00:24] <aruslan> Поступило предложение перечислить эти первые паттерны.
[00:24] <aruslan> Перечисляю на память.
[00:25] <aruslan> Layers/metalayers/subsystems, pipes/filters, blackboard, microkernel.
[00:25] <aruslan> Push/pull, bottom-up/top-down/constant refactoring.
[00:26] <aruslan> Resource/asset management/acquisition/pooling/caching.
[00:26] <aruslan> И, самое главное, framework/libraries.
[00:27] <aruslan> Уверен, половину из этого вы слышали.
[00:28] <aruslan> Выбор из этих паттернов сформирует большую половину картины.
[00:28] <aruslan> Поступило предложение аккуратно и быстро пробежаться по ним.
[00:29] <aruslan> Первая пачка паттернов - общая организация кодовой базы.
[00:29] <aruslan> К этому моменту вы уже знаете масштаб работ - чисто EXE с игрой или таки полный тулсет (включая редакторы, плагины, сборщики и т.п.)
[00:30] <aruslan> Основной смысл - управление сложностью, распространением изменений и разделением труда.
[00:31] <aruslan> Layers/metalayers - классический слоёный пирог. Слои располагаются строго один над другим, каждый слой использует только сервисы нижележащего.
[00:31] <aruslan> Типично присутствует расслабляющий "utilities", который доступен всем слоям.
[00:32] <aruslan> Примеры - API. Вы знаете OpenGL, он вас - нет.
[00:32] <aruslan> Layers рассматривает в чистом виде интерфейсы. На границах слоев постоянно есть только фасады.
[00:33] <aruslan> Основной задачей потом будет собственно эти интерфейсы определить и реализовать.
[00:33] <aruslan> Хорошо - можно разных людей засадить за разное. Плохо - они друг о друге ничего не знают и будут принимать неверные решения.
[00:33] <aruslan> Типично неверные решения означает локальные оптимизации.ю
[00:35] <aruslan> Обычно проще всего отделить в слои то, что явным образом не требует интеракции.
[00:36] <aruslan> То есть файловые системы, загрузчики и т.п.
[00:36] <aruslan> Subsystems - очень часто путают со слоями.
[00:36] <aruslan> Разделение на подсистемы.
[00:37] <aruslan> Layers и subsystems очень близки по идее, но отличаются по последствиям.
[00:37] <aruslan> Подсистема не так закрыта, как слой.
[00:37] <aruslan> На границах подсистем типично идёт мощная возня, объекты передаются из подсистемы в подсистему.
[00:38] <aruslan> Как правило слои образуют стройную вертикаль.
[00:38] <aruslan> Подсистемы - кучу окружностей со стрелочками :)
[00:38] <aruslan> Слои предполагают некоторое направление и образование виртуальных каналов.
[00:38] <aruslan> (Пример: сетевая игра поверх TCP/IP - слои)
[00:39] <aruslan> (Виртуальный канал - есть "протокол" у сетевой игры.)
[00:39] <aruslan> Пример подсистем: рендер, звуковая подсистема, стриминг, централизованные менеджеры ресурсов.
[00:40] <aruslan> Подсистемы могут знать друг о друге, слои типично знакомы только вниз.
[00:40] <aruslan> Да, напомнили, что я забыл про metalayers.
[00:41] <aruslan> Metalayers - те же слои, что и layers, только отношение между слоями не "использует сервисы фасада", а
[00:41] <aruslan> "интерпретирует в низлежащий (объемлемый) слой".
[00:42] <aruslan> Metalayers - это среднее между layers и pipes.
[00:43] <aruslan> То есть слой над OpenGL технически не просто использует OpenGL, но и выражает свои намерения на языке OpenGL.
[00:43] <aruslan> Метаслой - то же самое, только явным образом, поэтому мы начинаем говорить о протоколе преобразований.
19 февраля 2006
Комментарии [5]