Gamedev LectureСтатьи

Лекция #14. Паттерны revisited. Введение. [Лектор - aruslan] (2 стр)

Автор:

[00:43] <aruslan> "Компиляции"/"Интерпретации".
[00:44] <aruslan> Pipes/filters - создание сети преобразования объектов.
[00:44] <aruslan> Тьфу.  Создание конвейера, вот.
[00:45] <aruslan> У вас есть компоненты, которые что-то делают.  У них есть входы и выходы.
[00:45] <aruslan> В малом - pipes/filters используются часто как средство сборки или реальный конвейер преобразований.
[00:45] <aruslan> В большом - pipes/filters может быть способом обработки игровых сообщений.
[00:46] <aruslan> Жёсткий недостаток - невозможно наладить нормальную обработку ошибок.
[00:46] <aruslan> Можно только сказать, что всё перестало работать и попытаться откатиться.
[00:46] <aruslan> У меня такое ощущение, что мы сейчас за деревьями леса не увидим.
[00:48] <aruslan> Microkernel - способ построения расширяемой системы за счёт определения набора простых механизмов построения и использования интерфейсов.
[00:48] <aruslan> Очень часто используется в ОСах и в серсис-провайдерах.
[00:49] <aruslan> Плагины очень часто - почти правильные расширения microkernel, просто ad hoc реализованные.
[00:50] <aruslan> Иногда через microkernel реализуют "платформонезависимость", но имхо редко удачно.
[00:50] <aruslan> Пример: WindowsNT Executive - microkernel.
[00:50] <aruslan> А Win32 - её (не вполне чистое) расширение.
[00:51] <aruslan> Другой пример: файловая система в движке - часто microkernel.
[00:51] <aruslan> К ней подвязывают совершенно другие интерфейсы, чтобы народ не ломал ноги об тысячи мелких файлов, складывающихся в большие ресурсы.
[00:52] <aruslan> В одном из движков я зачем-то весь namespace сделать через microkernel.
[00:52] <aruslan> Поверх висели все ресурс-менеджеры, отладочные снифферы и т.п.
[00:52] <aruslan> Удобно, но ненужно.
[00:53] <aruslan> -- для справки. я не ударяюсь в подробности.  Подробности можно найти в книжках.
[00:54] <aruslan> -- если лень читать книжки - вот отсюда можно найти большинство - http://www.jcurley.com/software/design-patterns/design-patterns.html
[00:54] <aruslan> Blackboard - жёсткая трава. Никогда не применял живьём, по слухам - на канале есть живые люди, видевшие это in action.
[00:55] <aruslan> В общем и целом - если слои - фактически набор жёстких интерфейсов использования, пайпы - набор жёстких интерфейсов преобразования, а микроядро - набор жёсткизх интерфейсов расширения, то blackboard - набор жёстких интерфейсов взаимодействия.
[00:56] <aruslan> С деревьями первой группы - всё.  Теперь немножко леса.
[00:57] <aruslan> 1. Вам нужно определить ожидаемую частотность изменений в реализации.
[00:57] <aruslan> Самое плохое - если у вас в качестве требования написано "flexibility" и "extensibility" и "хотим портировать на все платформы сразу, PS3 и Nokia 6310i".
[00:58] <aruslan> Типично правильно попытаться найти те блоки, частнотности изменений на границах которых минимально.
[00:58] <aruslan> Так вы сможете хоть как-то обнаружить будущие change hot spots.
[00:59] <aruslan> С самого начала важно проводить политику изоляции проблемных мест.
[00:59] <aruslan> Устойчивые интерфейсы - очевидным образом - идеал.
[00:59] <aruslan> Слои редко удаётся правильно применять, потому что тяжело и трудно и долго.
[01:00] <aruslan> Зато в результате вы либо без проблем измените/замените реализацию слоя, либо просто перепишете пол-приложения.
[01:00] <aruslan> Подсистемы - типичный выбор.
[01:00] <aruslan> Вы готовы пострадать чистотой результата за меньшие риски.  То есть вы заранее ожидаете изменений в интерфейсах и прямого доступа со стороны других подсистем.
[01:01] <aruslan> Фильтры/пайпы - я не видел, чтобы из них делали архитектуру в большом.
[01:01] <aruslan> В малом - очень удобно в комбинации с метаслоями или с натурально интерпретаторами.
[01:01] <aruslan> Тупой пример.
[01:02] <aruslan> Если у вас в материалах есть запись типа "create_normal_map(blabla.max,blabla2.max,666...)"
[01:02] <aruslan> то это типично и будет интерпретироваться как смесь билдер + filters.
[01:03] <aruslan> В пределе - если есть nmake или Jam - набор небольших утилит/микропрограмм своей гибкостью и комбинируемостью зарулит любой плохо продуманный монолит.
[01:04] <aruslan> То есть если в вашем проекте будет финальная сборка или инкрементальная сборка - у вас будут подсистемы с pipes/filters.
[01:12] <aruslan> Насколько я понял по привату, в общем и целом ничего не понятно.
[01:13] <aruslan> И хочется движения к data driven.
[01:13] <aruslan> Итак, кластеризация по частотности изменений и её последствия.
[01:14] <aruslan> Самая большая ошибка - недооценка или переоценка масштаба.
[01:14] <aruslan> Люди, изменения, расширяемость, время, качество, поддержка.
[01:15] <aruslan> Пример - делать сериализацию в C++ или в тулсете.  Или делать загрузчик руками или централизованно.
[01:16] <aruslan> Или, того хуже, скрипты или C++.
[01:16] <aruslan> Всё это - проблемы масштаба.  Проблемы людей, проблемы частотности.
[01:16] <aruslan> На самом деле, я видел отличные архитектуры, в которых всё повернуто на 90 градусов или вообще сделано задом наперед.
[01:17] <aruslan> Потому что народ трезво оценил, где и как и, главное, зачем они это делают.
[01:18] <aruslan> Консольные решения отличаются от типично писишных (хотя, практика показывает, что консольные радикальнее идут на писи).
[01:18] <aruslan> Если вас один человек - обширный data driven не просто не нужен, а противопоказан.
[01:19] <aruslan> Потому что смысл data driven - введение новых специальностей.  Причём типично - не программистских.
[01:19] <aruslan> Причём это не уменьшает стоимость, а увеличивает.  И экономию можно получить только ценой масштаба.
[01:20] <aruslan> Если тупо в цифрах - программисты, поддерживающие datadriven будут стоить ДОРОГО.
[01:20] <aruslan> И окупить их можно только толпой data wizard/game designer/data wrangler.
[01:20] <aruslan> То же самое - pull vs push модель.
[01:21] <aruslan> Pull модель легко и приятно реализовывать.  Потому что реализовывать там нечего.
[01:21] <aruslan> Push модель - дорогая, коварная, труднорасширяемая штука.
[01:21] <aruslan> -- что такое push/pull
[01:22] <aruslan> Pull модель - набор архитектурных решений, направленный на упрощение получение данных, обновлений, конфигурации и т.п.
[01:23] <aruslan> Пример - считывание настроек в стиле game::get_setting<string>("blabla")
[01:23] <aruslan> Пример - считывание 3D модели через render::load3dmodel("balbalb.xxx").
[01:24] <aruslan> Все загрузки, всё определение конфигурации и т.п. - размазано по коду и делается ad hoc.
[01:24] <aruslan> Pull == тянуть == вам надо, вы и мучаетесь.
[01:24] <aruslan> Push model - то же самое, ровно наоборот.
[01:25] <aruslan> Вам приходит callback/event/change propagation "blabla setting changed [old] [new]".
[01:25] <aruslan> Вам говорят - объект XXX сдох.
[01:25] <aruslan> Вам говорят - все ассоциированные модели загружены, начинай работу.
[01:25] <aruslan> Все загрузки, конфигурации, управление ресурсами - вынесено наружу, делается более-менее централизованно.
[01:26] <aruslan> Вы регистрируетесь где попало и реагируете на обновления.
[01:26] <aruslan> Зато система _БЕЗ ВАС_ знает, где как и что искать.
[01:27] <aruslan> Лакмусовая бумажка на push/pull: в push нельзя писать for(int i=10;--i>=0;) load_blabla("xxx%d.tga",i);
[01:27] <aruslan> -- сериализация - то же самое:
[01:28] <aruslan> В дешёвом варианте - boost::serialisation или руками os << i.a << i.b << i.c
[01:28] <aruslan> в капельку чуть более дорогом - макросы в описании класса
[01:28] <aruslan>    SERIALIZABLE_FIELD( int, foo )
[01:28] <aruslan>    SERIALIZABLE_FIELD( vector<int>, bar ) etc
[01:29] <aruslan> В радикально дорогом (БОЛЬШОМ) - либо автоматическая инспекция кода либо генерация ваших хидеров по метаописанию.
[01:29] <aruslan> Причина - частотность изменений и их распределенность.
[01:29] <aruslan> Сериализация в одном вашем hpp - это хорошо, дешево и нетрудно реализовать.
[01:30] <aruslan> Но типично толпы геймдизайнеров и художников и data wranglerов не видят ваш hpp и работают в редакторе, который вообще не вами написан.
[01:31] <aruslan> Промежуточная стадия в виде hpp -> DLL, все юзают DLL - хороша только возможностью отработать изменение на всех тулзах.
[01:31] <aruslan> Но теряется смысл вообще держать сериализацию в hpp, потому что hpp после трех-четырех версий прочесть будет нереально.
[01:31] <aruslan> Тяжело программистам - тяжело всем, непонятно зачем.
[01:31] <aruslan> -- скрипты
[01:32] <aruslan> Самая больная проблема.  Программисты делают НЕправильные скриптосистемы.
[01:32] <aruslan> Они ориентируют её на программистов, в результате только программисты и могут её использовать.
[01:32] <aruslan> скрипты делаются для упрощения и удешевления продукта и для удешевления и оптимизации процесса создания/модификации контента.
[01:33] <aruslan> есть только три способа сделать продукт дешевле: меньше людей, меньше зарплаты и меньше сроки.
[01:34] <aruslan> есть только один способ сделать игру интереснее: дать возможность "двигать ползунки" тем, кто в этом понимает.
[01:34] <aruslan> (типично это не программисты вовсе.)

Страницы: 1 2 3 4 5 Следующая »

19 февраля 2006

Комментарии [5]