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

[gnoblin]

Книгу Гаммы я пока не осилил...

Думаю, что кто-то шарящий мог бы запостить пару примеров использования паттернов с игровым\около игровым кодом.
И БЫЛО БЫ КРУТО!

Вот один очень простой паттерн .
http://en.wikipedia.org/wiki/Adapter_pattern
(Там снизу есть список еще из нескольких чтобы окинуть взглядом)

[gnoblin]

Хорошим туториалом был бы "пакман нафаршированный паттернами" .

[Neodrop]

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

[gnoblin]

Китайские программисты скорее всего не знают что это такое .

[mvladlin]

Не только китайские, но и наши зачастую не знают паттернов, но это специфика работы над ПО у нас, лень/недостаток финансирования/незнание не дает заниматься проектированием, а потом судорожно правим код (цена исправления ошибки с каждой итерацией возрастает в тысячи раз)
У меня были попытки ввести проектирование в разработку игр, но дальше общей схемы пока дело не движется http://unity3d.ru/distribution/viewtopic.php?f=11&t=1427
А здесь хорошая статья про паттерны, не только "банды четырех" но и GRASP http://zeus.sai.msu.ru:7000/SE/project/pattern/index.shtml#toc

[Neodrop]

Я говорю, что паттерны не иконы, а вы мне заявляете, что, мол "плохо ещё молимся".

[sp00n]

Паттерны знать нужно как для общего развития, так и для того, чтоб не изобретать велосипед при проектирование больших и сложных систем. а вот
для геймдева даже не знаю, что может пригодиться.
Все нижесказанное есть ИМХО:
1) при написании движка - имхо нужны абстрактные интерфейсы, фабрики, возможно, синглтоны - но так как мы используем юнити, то движок нам писать не надобно:) ;
2) при написании игровой логики универсального назначения - имхо нужны обсерверы, но в юнити и так уже внутренности реализованы на 5+, значит, надобность в них (обсерверах) отпадает - мы(точнее юнити) их используем, не зная об этом:) ;
3) при написании серверов (для тех же убер ММОРПГ) - вот тут да, тут проектирование - самое главное и паттерны реально нужны. Но... есть уже куча готовых решений, так что разве что нужно для понимания того, как они работают;
4) ИИ - здесь все посложней и зависит каждый раз от поставленной задачи.

Для казуалок, шутеров, платформеров, хекэндслэшеров - в юнити они не нужны.

Мой вывод: знать полезно, но не обязательно для программиста. Для архитектора знать обязательно, но использовать только в случае острой необходимости, ибо время, затраченное на реализацию, а затем поддержку и обучение новых людей премудростям уже написаного кода имхо будет потрачено зря. Юнити - прекрасный инструмент, спроектированный умными людьми не без помощи паттернов;) , которые старались облегчить максимально жизнь разработчикам, и поэтому моя мысль - чем меньше кода в проекте - тем лучше.

[Neodrop]

Совершенно согласен.

[nuran]

Паттерны нужны, не везде и вся, но нужны, по-необходимости. ИМХО.

чем меньше кода в проекте - тем лучше.

Бред

[sp00n]

Бред

Аргументация?

напоминаю - речь идет о юнити

[Sef]

Я ещё учусь, но пока для Юнити и геймдева мне понравился паттерн MVC (model view controller) – создаётся три класс и каждый получает инфу по схеме на картинке:

1.JPG

И если я правильно понимаю, то:
model - обрабатывает действия.
view - получает данные из model и выводит\двигает графику.
controller - посылает данные управления (мыши, клавиатуры и т.п.) всем блокам.
Ну и каждый может ещё получать определенные параметры друг из друга.

[sp00n]

Я ещё учусь, но пока для Юнити и геймдева мне понравился паттерн MVC (model view controller)

Это вообще-то основной паттерн для реализации/использования ГУИ(возможно и не только) в макоси и айфоне, насколько я помню. Очень красиво выглядит в ObjectC Но... как бэ в юнити он уже реализован приблизительно так, как Вы сказали, причем в более расширенном варианте имхо.
Вот грубый пример - у меня есть префаб Модель (игрок) - в нем есть меш, привязана камера. Есть скрипты движения и камеры - это можно назвать Контроллером, в роли ж View выступает сам рендер юнити, обработка инпута в Юнити, аудио движок Юнити и т.д. Как бы получается, что я, даже не подозревая об этом, использую данный паттерн, но... я ведь его не реализовывал средствами какого-нибудь языка, я просто использую то, что мне максимально удобно использовать в данном движке. И, чтобы использовать это, мне абсолютно не нужно знать, что это за паттерн и существует ли он вообще В данном случае моего кода всего да ничего - скрипт движения игрока и скрипт камеры. Взаимодействие между Model, View, Controller мне тут писать не надо практически - весь механизм уже реализован в самом движке, и использую его(паттерн) я интуитивно, как программист.
А вот что будет, если я начну реализовывать этот паттерн сам? Да ничего хорошего - куча ненужного кода, в котором нужно будет еще выловить баги, проблемы синхронизации между разными обьектами... в итоге - фактически зря потраченное время, которое дало мне только опыт в реализации данного паттерна и изучении граблей, что, имхо, абсолютно не нужно программисту на юнити.
з.ы. много букафф, конечно, но, думаю, смысл удалось передать

[Sef]

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

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

[sp00n]

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

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

вешать кучу скриптов на кучу объектов

или ручками или же программно

[Sef]

или ручками или же программно

Я же говорю что практики нет, но мне показалось удобно разбивать код, если делать программно, именно по MVC