ООП и современный кризис игровой индустрии

**aradriel** 15 фев 2012, 01:51

Есть ли сейчас какой-то кризис - это, конечно кто как смотрит.

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

Почему? Ведь энтузиасты всегда есть, они никуда не исчезают, но вот вместо интересных и логически сложных продуктов мы получаем либо графических монстров со спинномозговым геймплеем, либо "казуалки". Здесь, конечно вмешиваются и расчеты маркетологов, особенно в крупных проектах - планировать что-то сложное, что возможно будет не понято среднестатистическим потребителем (IQ которого почему-то все предположительно опускают ниже плинтуса) - это просто не выгодно из-за возможных рисков, которые трудно просчитать заранее.

Это понятно. Но ведь энтузиасты то не должны брать в расчет такие вещи, на то они и энтузиасты, что делают именно то, что им самим нравится. Свои задумки воплощают.

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

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

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

И все было просто.

Если тебе нужно сложить 2 числа - ты просто используешь комманду процссора для этого.

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

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

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

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

И все в них было просто и самое главное - очевидно.

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

И уже позднее стали вводится в широкое пользование объектно ориетнированные языки.

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

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

Только недавно я столкнулся с потребностью на самом деле занятся более плотно с# в следствии того, что все движко собственно перешли на него.
Да, крупные проекты, казалось бы в самый раз делать в ООП, потому что он позволяет модульно, то ест независимо друг от друга программистам собирать целую программу из кусков, когда один не знает кода других. Это удобно, казалось бы. Но тут же возникли и проблемы.

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

Второе - представление программы.

Скажите что проще представить себе вложенные друг в друга функции и подпрограммы, или абстрактные объекты наследующие свойства других объектов и тд и тп?

Изначально казалось что проще второе.

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

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

Хорошо, солгашусь. Но ответьте тогда на вопрос.

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

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

И я кажется начал понимать, что от части эта ситуацифя сложилось именно в силу распространенности систем ООП.

Для решение даже простых задач, в ООП требуется довольно сложные подчас формы их записи. Сложные для того чтобы представить и удержать их в голове.

Что же будет если человек попытается из этих абстрактных форм создать что-то на самом деле сложное?

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

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

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

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

Абстракции ООП слишком далеки от качеств самого мышления человека.

Вот и все. И в этом проблема ООП, и соотвественно, причина кризиса в развитии игровой индустрии.

ПС Вообще, на сложности ООП сказывается их всеохватность. Процедурные языки имеют обычно узконаправленный характер. Но это не отменяет вышесказанного. Пусть в системе разработки, в движке используется простой процедурный скриптовый язык. Как например блиц, Хорс и пр. Иначе программмирование загоняет само себя в угол своей чрезмерной сложностью помноженной на абстрактность используемых понятий.

**Golandez** 15 фев 2012, 02:45

Честно говоря больше похоже на крик души.
1. Возьмем ядро, наделенное интерфейсами(Это к мыслям о модульности и трудностях написания). Три программиста реализуют каждый свой интерфейс. И им плевать на то как реализует его сосед свой интерфейс. У них есть входящие и исходящие данные, а как кто из них реализует свой интерфейс друг к другу не имеет абсолютно никакого отношения. Так точно пылесосу наплевать в какую вы розетку его включите в белую или черную, ему лишь нужно получить свои 220В.
2. Вся прелесть абстракции состоит в наследовании и возможности переопределении методов. Банальная задача- на трех десятках обьектов рандомно вызвать разные наборы методов без абстракции выльется вам в ад.
3. Нет ничего лучше и красивее чем хорошо и грамотно структурированного кода. Отладить его намного проще чем при процедурном подходе.
4. При достаточно емком приложении процедурный подход практически не расширяем(В некоторых случаях будет легче заново переписать).
5. ИИ это годы разработок, никто не будет подобный бюджет закладывать в продукт. Сейчас делают коммерческие продукты, а не игры как мы понимали их 15 лет назад.
6. Недостаток сложных поведенческих форм в приложении это не отголоски подхода к программированию, это четко просчитанные маркетинговые ходы.

**Order** 15 фев 2012, 03:41

В ООП нет ничего сложного, сложность как раз в написании алгоритмов модулей, математике, геометрии , физики и тп. Ну и конечно придумать что то оригинальное.
На счет ИИ и прочего, да хоть нейронную сеть программируйте, или распознание объектов...

ООП это инструмент, а как его применить решать программисту.

Кризис только в коммерческом подходе к играм.. в менеджерах с ограниченной фантазией и экономии на геймплее.(сталкивался лично).

**Sef** 15 фев 2012, 11:27

Спасибо, было интересно

В том числе потому что сам испытал взрыв мозга когда с блитц переходил на ООП. ) Тогда мне казалось что всё через чур мудрёно, да и сейчас с некоторыми вещами тоже, но сейчас отношусь к этому уже спокойнее. Наверно потому что почувствовал реальное ускорение по времени в наших проектах (хотя в этом ещё заслуга юнити).
А корень кризиса всеобщего упрощения и ускорения - капитализм и общество потребления, или даже построения общества инстинкта $-)

**artk** 15 фев 2012, 14:20

ооп - это только дополнительный инструмент. Конечно, манки-кодеры :(|)

, будь то ооп'эшники или процедуршники, будут писать одинаково хреновый код. И имхо, игры дожны быть гибкие в процессе разработки, они не должны зависеть от диздока и структуры ваших классов. Экстремальное программирование - это круто.®

**Belfegnar_** 15 фев 2012, 19:20

aradriel писал(а):С появлением современных мощностей можно было ожидать всплеск разработок искуственного интеллекта, в том числе в играх. Где он? Ведь это же одна из наиинтереснейших тем компьютерной техники - симуляция интелектуальных способностей самого человека, поведенческие особенности, и так далее. Где это все? Этого просто нет.

Вот это да. Конечно, если следить за разработками искуственного интеллекта по игровой индустрии, можно опечалиться. Однако логическая связь "кризис игровой индустрии <-> нет разработок" для меня не очевидна :-??

А системы распознавания образов/голоса? А экспертные системы? А мультиагентные системы, управляющие предприятиями?
Почему все эти наработки еще не прикручены интузиастами? Да потому, что сложные алгоритмы и системы требуют серьезных знаний, подчас даже в нескольких науках одновременно. Времена простых if-else давно прошли. Разрабатываются они кафедрами, институтами (которые правда сами иногда выдают что-нибудь типа nero, но это как-то слабо заметно в индустрии, не прада ли?). А чтоб собрать все эти наработки в систему, да еще играбельную... Какие тут энтузиасты, профессионалов бы чему-нибудь научить)) Но с ними дела обстоят так, как описали выше: а стоит ли оно затраченных сил? Им кажется, что не стоит. Наверно они в этом правы. Есть наука физика, а есть физические движки))
Я тут недавно прочитал на aigamedev, что goap "умер". КАК УМЕР??? Да очень просто: ни одна из ведущих компаний в том году не использовала его в своих разработках, вот он и умер для индустрии))

aradriel писал(а):Есть ли сейчас какой-то кризис - это, конечно кто как смотрит.

А кино? А музыка? Да все идет по пути упрощения сейчас, так что наверное дело тут все-таки не в ООП.

**aradriel** 15 фев 2012, 20:08

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

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

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

И в связи с этим, я как раз и подумал, что было бы не так плохо движку Юнити обладать в добавок еще и не ООП скриптовой системой, ведь цель скрипта в игровом движке, по крайней мере для меня, зачастую сводится к написанию игровой логики, логики поведения персонажей, игровых моментов, каких-то оборотов. И вот честно, мне лично было бы на много проще представить себе схему поведения персонажа, если она сложная и многоступенчатая, не в абстракциях ООП, опять же, а обычной последовательностью инструкций. Это, конечно, очень субъктивно.

**Fredo** 15 фев 2012, 20:24

Ну в unity используется компонентный подход к программированию, по моему ничего проще не существует, ИМХО самый приятный подход к программированию.

**gnoblin** 15 фев 2012, 20:27

aradriel писал(а): И вот честно, мне лично было бы на много проще представить себе схему поведения персонажа, если она сложная и многоступенчатая, не в абстракциях ООП, опять же, а обычной последовательностью инструкций. Это, конечно, очень субъктивно.

кто-то мешает так писать код в юнити? нет.

**DbIMok** 15 фев 2012, 21:12

aradriel писал(а):цель скрипта в игровом движке

... отлаживать без перекомпиляции. при необходимости сделать такое в юнити не сложно. непонятна цель автора... потроллить?

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

**Fredo** 15 фев 2012, 21:48

DbIMok писал(а):
aradriel писал(а):цель скрипта в игровом движке

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

Не знаю, а мне мысль понравилась, она конечно скорее всего далека от истины. Все дело в том что игростой из хобби любителей перерос в огромный бизнес. Просто это одно из размышлений почему в прекрасные 80-90 года, на функциональных языках писали интересные игры. А сейчас при всем обилии технологий игры стали скучными и однообразными)

**Acrobat** 16 фев 2012, 08:51

aradriel писал(а):И знаете почему? Да потому что поведение самого челвоека - оно как раз по сути является аналогом процедурного программирования. Человек привык мыслить в категориях процедурного программирования. ООП же предлагает естественные для логики человека вещи заменить на абстракции, и это и вызывает сбой в создании программ с помощью этих абстракций.

Здесь наверно все зарыто. Человек именно привык мыслить в своих рамках. Изменение очень мучительны, но они должны быть. Это проявление эволюции в чистом виде. Может конечно эта ветвь эволюции зайдет не туда, но на данном этапе развития программирования- ООП лучший вариант для проектов. Ведь для многих из нас разработка игр является местом работы. Чем больше мы можем применять уже существуюего кода, тем легче наша жизнь. Если хотите процедурного программирования то попробуйте Torque. Без ООП, это иногда АД.

И вот еще в догонку:
http://www.helloworld.ru/texts/comp/other/oop/ch07.htm
Пункт 7.8 и 7.9. Есть фраза что ООП "лучше воспринимается человеческим сознанием."

**artk** 16 фев 2012, 16:32

Тщетъ, только сейчас понял что уже давно во всю использую парадигму ооп. :-ss

Путал надстройки c# и ооп. И как-то трудновато не использовать ооп в юнити.
PS А использование скриптовых языков с кодом как называется и к чему относится?

**Neodrop** 16 фев 2012, 22:04

Хм.. А вот [vizio]

Universe это ООП или Процедуры ? /:)

**Syberex** 18 фев 2012, 00:37

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

Абстракции ООП слишком далеки от качеств самого мышления человека.

Ну вообще то мыслим мы образами, а не процедурами, слава Богу!

И логика у нас не булева...
Не может наше мышление быть "аналогом процедурного программирования".

Да вероятно с первого взгляда ООП кажется сложен. А многие считают наоборот. Сейчас вот только закончил читать Джоэла Спольски, так он пишет, что сейчас из ВУЗов выходят "тупоголовые" программисты, знающие ООП, но не знающие рекурсию, не знающие указателей и тд. А вы говорите сложно? И я не скажу, что легко. Я постигал азы ООП вместе с Java, и на ООП мне сейчас строить программу проще

Чего и вам желаю!
А еще времена меняются! Приходят новые технологии вместе с новыми инструментами. Инет все объединяющий, заставляет придумывать стандарты, а потом их поддерживать. Новые форматы вытесняют старые (XML, JSON вместо TXT и DBF, хотя чем они плохи?). Но они тоже к ООП ближе, чем к процедурам. Дак не потому ли, что оно ближе к нашему мышлению на самом деле? :-?