Комментарии 9
Интересно, кто вы выбирает нет, ему нужны неинтересные статьи?
А ведь можно копнуть еще глубже: http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/.
Если честно, я не понял, о чём эта статья. Глянул название: «Магия data-driven design»; ага, значит и автор сам не понял, раз это для него магия. Выглядит как набор советов, сводящихся к «не используйте хардкод, выносите данные в конфигурационные файлы». Мысль прекрасная и полезная, но очевидная любому, кто занимался оплачиваемой разработкой больше месяца.
Теперь по пунктам.
Боюсь, подобные советы и описывающее ими действие приводит к переработкам, космической архитектуре, и срыву всех сроков. Это не подойдёт никому кроме, пожалуй, Valve и Blizzard, но они могут себе это позволить, потому что в начале писали быстро, с костылями и хардкодом.
Про сценарии: проще всего использовать систему триггер-действие: если происходит событие, то запускается сценарий, который состоит из шагов. Программистам нужно будет написать сами триггеры и шаги, а всем остальным смогут заняться геймдизайнеры и сценаристы. Совет дня: лучшим сценарием является тот, который может выступать в качестве шага.
Наследование: проблемы начинаются с множественного наследования. Что если у вас есть гоблин-стрелок и защитная башня, имеющие общее поведение стрелка. Сделаете базовый класс «ShootingEntity»? А если гоблин ещё и лечит союзников? Лучше определять каждую сущность, как имеющую какое-либо поведение, в этом примере гоблин обладает MovingBehaviour, ShootingBehaviour, UnitBehaviour, HealingBehaviour; башня только ShootingBehaviiour и BuildingBehaviour. В общем, структура Entity-Behaviour в целом куда гибче, чем обычное наследование.
Теперь по пунктам.
Напишите свою игру, которая может поддерживать любое количество экранов со своей логикой для каждой камеры.
Боюсь, подобные советы и описывающее ими действие приводит к переработкам, космической архитектуре, и срыву всех сроков. Это не подойдёт никому кроме, пожалуй, Valve и Blizzard, но они могут себе это позволить, потому что в начале писали быстро, с костылями и хардкодом.
Про сценарии: проще всего использовать систему триггер-действие: если происходит событие, то запускается сценарий, который состоит из шагов. Программистам нужно будет написать сами триггеры и шаги, а всем остальным смогут заняться геймдизайнеры и сценаристы. Совет дня: лучшим сценарием является тот, который может выступать в качестве шага.
Наследование: проблемы начинаются с множественного наследования. Что если у вас есть гоблин-стрелок и защитная башня, имеющие общее поведение стрелка. Сделаете базовый класс «ShootingEntity»? А если гоблин ещё и лечит союзников? Лучше определять каждую сущность, как имеющую какое-либо поведение, в этом примере гоблин обладает MovingBehaviour, ShootingBehaviour, UnitBehaviour, HealingBehaviour; башня только ShootingBehaviiour и BuildingBehaviour. В общем, структура Entity-Behaviour в целом куда гибче, чем обычное наследование.
В свободное время пишу sandbox, тоже пришел к выводу что система Entity-Behaviour наиболее гибкая из всего, до чего я додумывался.
«… выносите данные в конфигурационные файлы». Мысль прекрасная и полезная, но очевидная любому, кто занимался оплачиваемой разработкой больше месяца.
А если бы он позанимался оной разработкой ещё хотя бы месяц, мысль перестала бы казаться такой уж очевидной. Вынося данные в конфиг, программист теряет над ними контроль, и теряет статическую проверку компилятором. Если данные записаны в синтаксисе языка, то они заведомо не будут содержать неправильный разделитель целой и дробной части, «минус −» вместо «программистского минуса -», киррилическую букву «с» вместо латинской «c» в каком-нибудь идентификаторе-enum'е. Целый ряд ошибок, которые раньше ловились при компиляции, теперь могут всплыть в любое время в рантайме и повлечь гневные багрепорты от активных пользователей, разнёсших конфигурацию в хлам своими правками.
Конфигурирование в коде — strongly typed.
Конфигурирование в текстовых файлах — stringly typed.
Я не имел в виду правки конечных пользователей. В статье и моём комментарии говорится прежде всего о правках в конфигурационных файлах, которыми занимаются профессионалы не-программисты. Если конечный пользователь меняет данные, то ответственность лежит на нём. Делаем кнопу «Reset to default», спим спокойно.
Если ошибается геймдизайнер, то это тоже поправимо: единый парсер для всех файлов, который обучен разным разделителям или генерирует исключение для каждого подозрительного символа. Опять же, потеря контроля над сырыми данными это копеечная цена за экономию времени программистов и создание удобного инструмента для ГД.
Если ошибается геймдизайнер, то это тоже поправимо: единый парсер для всех файлов, который обучен разным разделителям или генерирует исключение для каждого подозрительного символа. Опять же, потеря контроля над сырыми данными это копеечная цена за экономию времени программистов и создание удобного инструмента для ГД.
Для мобильной разработки под iOS не очень подходит. Нет внешних текстовых файлов, легко редактируемых пользователем.
Статья предназначенна для молодых разработчков. Все описано примитивно но понятно. У нас использовался xml, никаких сценариев не создавалось, создавать второй язык программирования плохая затея. Вместо этого, система проектировалась так, что все моменты можно было указать декларативно, соотвествено данные не были похожи на сценарии. При добавлении сложного функционала, он приобретал вид экшена или валидатора и добавлялся в фабрику, после чего его можно было использовать в декларативном описании чего либо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Магия data-driven design