С другой стороны часть правды в этом есть.
Программисты пишут любые программы — и в общем не сильно важно банковский это продукт игровой или вообще система по учету наркотрафика для ребят из криминала. Кирпичи везде почти одинаковые.
Так что игры в определенном смысле все таки создают геймдизайнеры и постановщики задач. А вот дальше уже начинается техника.
Вы почему-то пропустили части про виртуальные функции и таблицы, которые вы все еще пиликаете в рантайме, ну да удобно.( я не знаю, может у нас разное понимание ООП, но это как бы основа) Простите, полиморфизм есть полиморфизм, если у вас его нет или практически нет, то это не ООП в чистом виде.
Далее, никакого внимания на упоминание абстракций с нулевой стоимостью.
"«Затрудняет» или «усложняет»" на уровне 100 человек играет в одной сессии с 50к практически статичных объектов. А убивает на уровне ММО. Да, можно очень долго мучиться и выжимать из себя супер круто настроенную архитектуру-гибрид бульдога с носорогом, тратя на это время и деньги, оплачивая какой-нибудь Spatial OS, имея ряд трудностей с сопровождением, отладкой и ведением новых фич, а можно просто взять и добавлять без напряга десятки тысяч динамически изменяющихся сущностей, с полностью индивидуальным набором свойств, которые имеют ограничения только в виде объема вашей RAM, взаимодействующих друг с другом, не требующих практически никакого изменения для распараллеливания обработки и еще кучу всего.
Вы пишете про то как удобно наследовать, что это надо делать правильно и аккуратно, но наследование и полиморфизм не просто «группируют» функционал, они тащат за собой много того, что вам не нужно.
Дык в том то и дело, что нужно группировать так, чтоб ненужный мусор не тащился. Я уже перечислил в первом комментарии — low coupling/high cohesion структура, использование компонентов, контейнеров и т.д.
ООП языки позволяют писать хороший, «бодрый» код. Да и совсем не обязательно всегда использовать объекты. Здесь уже упоминали structs.
Я погуглил DoD. Собственно, начиная с Unity 2018, если я правильно понимаю, идет адаптация ECS/DoD:
Я взялся за Unity поздней осенью и все еще учу Unity 2017, поэтому руками не щупал, не скажу ничего.
Боттом лайн, это все вопрос оптимизации и производительности, а не экзистенциальный кризис какой-то. Ваш изначальный посыл с использованием слова «убивает» просто не соответствует действительности. «Затрудняет» или «усложняет» — может быть. Но не более.
Сказать такое — всё равно, что заявить, будто дома строят не строители. А строители просто ставят кирпичи. Игры создают все — и программисты, и геймдизайнеры, и тестировщики, и даже игроки. Не нужно преуменьшать ценность кого-то из них.
Аналогия так себе, но… Погуглите молекулярную кухню, например)
Да и вообще развитие науки и техники всегда создавало возможности для творцов, расширяло их.
А вообще, мне кажется как-то уже совсем в философствования ударяемся.)
Никто не говорит о количестве, которое переходит в качество. Тут довольно простая математике, точнее статистика. То что чего-то, что вы решили назвать «шлаком», что все же вопрос вкуса, согласитесь, стало больше, не значит апять же, что статистика не работает. Всегда чем больше разнообразие\вариативность, тем болше вероятность, что в этом спектре найдется что-то живучее, это как эволюция, понимаете?
Насчет усилий по поиску… Честно, мне вот например наоборот сам процесс поиска чего-то среди сотен вариантов и параметров нравится больше, чем «выбор» из двух.
Утверждать, будто программисты делают игры — всё равно что считать, будто еду готовят производители посуды. Да, в современном мире еда обычно находится в какой-то посуде (упаковке, обёртке), однако ценность-то не в посуде, а в том, что туда налито/насыпано. И повару совершенно до лампочки проблемы производителя сковородок, который всё никак не подберёт оптимальный способ закалки металла или напыления каких-нибудь супер-покрытий. На процесс готовки всё это влияет не так уж сильно, чтоб прям случился прорыв в поварском искусстве из-за новой формы кастрюли.
Боюсь, в геймдеве количество не переходит в качество. Да, развитие инструментов (тех же движков) приводит к тому, что игр выходит всё больше и больше. Однако же, шедевров больше не становится. Становится больше середнячков, на пару недель игры, и сильно-сильно больше шлака, за счёт которого и идёт основной прирост.
Мне, как потребителю, от этого наоборот хуже, потому что я вынужден прилагать больше времени и сил, чтоб найти в этом океане мусора хоть что-то стоящее.
*подумал и добавил* со структурами немного загнул, но все же данные даже будучи «упакованы» в кастомные типы все равно примитивные. Ну и естественно ни какого функционала, только данные.
Как именно они могут дать лучшую масштабируемость и простоту работы?
Представьте, что у вас вообще нет иерархий, а добавление нового функционала это буквально написание одной функции, и все. И самое главное это абстракции с нулевой стоимостью.
Вы пишете про то как удобно наследовать, что это надо делать правильно и аккуратно, но наследование и полиморфизм не просто «группируют» функционал, они тащат за собой много того, что вам не нужно. Может что-то из этого сокращает код и упрощает работу здесь и сейчас, но когда процессор будет долго и пичально искать а где же тот виртуальный метод, который от меня хотят, он вам спасибо не скажет. А вот теперь представьте, что у вас есть абсолютно такие же абстракции, вроде объектов, но никакого полиморфизма, наследования и даже создания самих классов и структур для их существования вам не нужно.
Я просто очень не хочу расписывать все тут, давайте я вам пообещаю, что напишу еще одну заметку просто? =)
Ну, давайте тогда начнем с конкретных фраз, по порядку.
Иерархии убивают расширяемость.
— наследование убивает расширяемость системы. Не пугайтесь, это не попытка вас запутать или глупо пошутить. Все дело в том, что эти самые сложные иерархии не могут увеличивать свою сложность до бесконечности по многим причинам, как просто из-за того, что с таким кодом становится очень сложно работать, так и из-за того, что сам код начинает работать хуже. И тут речь уже о масштабируемости системы, то есть возможность выдержать большие нагрузки.
Иерархии это лишь способ группировать данные/функционал. Для удобства восприятия и работы с ними. Чем лучше сгруппируешь, тем меньше будет конечного кода. Наследование и полиморфизм — тоже способы уменьшить ненужное дублирование, сократить/упростить код, уменьшить работу. Это, в купе с модульностью, и есть шаги к улучшению масштабируемости системы. Плюс, к упрощению одновременной работы над ней множеству людей. Т.е. абсолютно противоположное тому, о чем говорите вы.
Стоит сказать, что я кроме как ООП языками не владею, кроме, разве что, BASIC, которым я последний раз пользовался… м… лет так двадцать назад, будучи школьником. Поэтому никаких контрпримеров с использованием других парадигм я привести не могу. Как именно они могут дать лучшую масштабируемость и простоту работы?
Правила ДнД тоже своего рода код, разве нет? И применять его можно не только к конкретному миру, и использовать не только конкретные арты/фигурки/прочее…
Понимаете, чем проще что-то создать, тем выше вероятность того, что кто-то это сделает. Чем больше будет тех, кто это сделает, тем выше вероятность того, что это выстрелит и вам понравится.
Из своей практики, например, пиши мы код проекта в стиле ООП ( строго, то есть наследование, полиморфизм, инкапсуляция и все вытекающее) то наши механики с динамически изменяющимся живым миром, в котором существа буквально постоянно анализируют окружающую среду и принимают решения так и остались бы мечтами, т.к. реализовать это «классическими» способами очень сложно, либо получилось бы совсем не то и не в тех масштабах.
Игры создают не программисты. Поэтому совершенно плевать, какой такой парадигмой они пользуются. Программисты создают движок и инструментарий, и только лишь. Но не игру.
На самом деле игры вообще начали создаваться задолго до эпохи PC, вспомнить хоть D&D или WH40K. Программисты лишь дали ещё один инструмент для этого создания, не более.
Фантазию всегда что-то где-то ограничивает. Когда ООП только-только внедрялся, по поводу его эффективности было не меньше сомнений, классический подход казался гораздо более надежным и, главное, понятным.
Суть не в абстракции. Суть в механизмах взаимодействия. Современное поколение программистов в большей степени само стремится использовать уже имеющиеся наработки, а не создавать свои. Зачем делать что-то новое, когда кто-то уже сделал аналогичное. Я не в курсе системы работы в крупных компаниях, но сдается мне, что очень значительная часть программистов там работает именно по принципу «не будем изобретать велосипед». При этом они даже не представляют себе как работает «звездочка» на заднем колесе: Есть цепь, есть звездочка, есть колесо, есть педальный привод. Усилие на колесо меньше, чем усилие на звездочку, но скорость колеса больше — вот все, что они знают. А что там внутри звездочки и педального привода — их не колышет совершенно, хорошо если знают по какому принципу усилие повышается. Они получают конкретную задачу — изменяют конкретный модуль. Изменить можно что угодно и как угодно. Даже в уже готовом движке. И ООП в принципе позволяет делать любой модуль совершенно независимо от других модулей.
Проблема в общем видении системы. и, как уже заметил товарищ, в требованиях тех, кто дает деньги. Увидеть всю систему, оптимизировать ее, найти способ внедрения нового — все это задача не программиста, а гейм-дизайнера, который вообще может не понимать как работают отдельные модули, но прекрасно должен понимать как они взаимодействуют. И ООП позволяет в этом случае делать главное — идти сверху вниз, от общего к частному, уточняя детали по мере развития проекта. И делать это усилиями совершенно разных людей, один из которых видит всю картину, а второй умеет сделать отдельный мазок. Проблема не в ООП, который прекрасно подходит для этого. Проблема в видении общего. В желании изменять отдельные готовые модули. В финансировании и отведенном времени, в конце-концов.
В общем и целом понятно, что вы стремитесь донести. Однако брюзжание «ООП не дает простора творчеству» длятся уже больше 10 лет. Точно также, как и споры о лучшем языке программирования, и еще много чего. И это ни к чему не приводит, хотя «убийц ООП» предложено было уже не один десяток, дай бог памяти. «ООП устарел» — это что-то из разряда мифов типа «В Ворде верстать нельзя», «Линукс лучше Виндовс», «Старые игры были лучше». Все об этом знают, а те, кто не знает, делают шедевры.
Разве многопоточный код со struct-ами на чистом С или даже ассемблере выглядит проще и понятнее?
Да, значительно проще в том случае, когда применяется DOD или семейство CO/ES парадигм.
DOD (Data Oriented Design) напрямую дает поточную изоляцию памяти, что выливается как в неблокирующие операции, так и в т.н. positive sharing (положительную работу предсказателя и постоянную актуальность данных в L1).
Семейство CO (Component Oriented) и ES (Entity System) парадигм предлагает набор решений для широкого ряда проблем, в том числе и описанных в данной статье.
Вы просто во все большие абстракции уходите. Я говорил о конкретной парадигме, которая преобладает в софте, о ее недостатках и о том, почему, как я считаю, она сильно ограничивает, если можно так выразиться, полет фантазии, в отличии от альтернатив.
Программисты пишут любые программы — и в общем не сильно важно банковский это продукт игровой или вообще система по учету наркотрафика для ребят из криминала. Кирпичи везде почти одинаковые.
Так что игры в определенном смысле все таки создают геймдизайнеры и постановщики задач. А вот дальше уже начинается техника.
Далее, никакого внимания на упоминание абстракций с нулевой стоимостью.
"«Затрудняет» или «усложняет»" на уровне 100 человек играет в одной сессии с 50к практически статичных объектов. А убивает на уровне ММО. Да, можно очень долго мучиться и выжимать из себя супер круто настроенную архитектуру-гибрид бульдога с носорогом, тратя на это время и деньги, оплачивая какой-нибудь Spatial OS, имея ряд трудностей с сопровождением, отладкой и ведением новых фич, а можно просто взять и добавлять без напряга десятки тысяч динамически изменяющихся сущностей, с полностью индивидуальным набором свойств, которые имеют ограничения только в виде объема вашей RAM, взаимодействующих друг с другом, не требующих практически никакого изменения для распараллеливания обработки и еще кучу всего.
Ну я не прав и не понимаю, видимо, ничего в ООП.
ООП языки позволяют писать хороший, «бодрый» код. Да и совсем не обязательно всегда использовать объекты. Здесь уже упоминали structs.
Я погуглил DoD. Собственно, начиная с Unity 2018, если я правильно понимаю, идет адаптация ECS/DoD:
unity.com/unity/features/job-system-ECS
Я взялся за Unity поздней осенью и все еще учу Unity 2017, поэтому руками не щупал, не скажу ничего.
Боттом лайн, это все вопрос оптимизации и производительности, а не экзистенциальный кризис какой-то. Ваш изначальный посыл с использованием слова «убивает» просто не соответствует действительности. «Затрудняет» или «усложняет» — может быть. Но не более.
Да и вообще развитие науки и техники всегда создавало возможности для творцов, расширяло их.
А вообще, мне кажется как-то уже совсем в философствования ударяемся.)
Насчет усилий по поиску… Честно, мне вот например наоборот сам процесс поиска чего-то среди сотен вариантов и параметров нравится больше, чем «выбор» из двух.
Мне, как потребителю, от этого наоборот хуже, потому что я вынужден прилагать больше времени и сил, чтоб найти в этом океане мусора хоть что-то стоящее.
Представьте, что у вас вообще нет иерархий, а добавление нового функционала это буквально написание одной функции, и все. И самое главное это абстракции с нулевой стоимостью.
Вы пишете про то как удобно наследовать, что это надо делать правильно и аккуратно, но наследование и полиморфизм не просто «группируют» функционал, они тащат за собой много того, что вам не нужно. Может что-то из этого сокращает код и упрощает работу здесь и сейчас, но когда процессор будет долго и пичально искать а где же тот виртуальный метод, который от меня хотят, он вам спасибо не скажет. А вот теперь представьте, что у вас есть абсолютно такие же абстракции, вроде объектов, но никакого полиморфизма, наследования и даже создания самих классов и структур для их существования вам не нужно.
Я просто очень не хочу расписывать все тут, давайте я вам пообещаю, что напишу еще одну заметку просто? =)
А если очень хочется, то почитайте про DOD и ECS.
Иерархии это лишь способ группировать данные/функционал. Для удобства восприятия и работы с ними. Чем лучше сгруппируешь, тем меньше будет конечного кода. Наследование и полиморфизм — тоже способы уменьшить ненужное дублирование, сократить/упростить код, уменьшить работу. Это, в купе с модульностью, и есть шаги к улучшению масштабируемости системы. Плюс, к упрощению одновременной работы над ней множеству людей. Т.е. абсолютно противоположное тому, о чем говорите вы.
Стоит сказать, что я кроме как ООП языками не владею, кроме, разве что, BASIC, которым я последний раз пользовался… м… лет так двадцать назад, будучи школьником. Поэтому никаких контрпримеров с использованием других парадигм я привести не могу. Как именно они могут дать лучшую масштабируемость и простоту работы?
Момент
Понимаете, чем проще что-то создать, тем выше вероятность того, что кто-то это сделает. Чем больше будет тех, кто это сделает, тем выше вероятность того, что это выстрелит и вам понравится.
Из своей практики, например, пиши мы код проекта в стиле ООП ( строго, то есть наследование, полиморфизм, инкапсуляция и все вытекающее) то наши механики с динамически изменяющимся живым миром, в котором существа буквально постоянно анализируют окружающую среду и принимают решения так и остались бы мечтами, т.к. реализовать это «классическими» способами очень сложно, либо получилось бы совсем не то и не в тех масштабах.
На самом деле игры вообще начали создаваться задолго до эпохи PC, вспомнить хоть D&D или WH40K. Программисты лишь дали ещё один инструмент для этого создания, не более.
Суть не в абстракции. Суть в механизмах взаимодействия. Современное поколение программистов в большей степени само стремится использовать уже имеющиеся наработки, а не создавать свои. Зачем делать что-то новое, когда кто-то уже сделал аналогичное. Я не в курсе системы работы в крупных компаниях, но сдается мне, что очень значительная часть программистов там работает именно по принципу «не будем изобретать велосипед». При этом они даже не представляют себе как работает «звездочка» на заднем колесе: Есть цепь, есть звездочка, есть колесо, есть педальный привод. Усилие на колесо меньше, чем усилие на звездочку, но скорость колеса больше — вот все, что они знают. А что там внутри звездочки и педального привода — их не колышет совершенно, хорошо если знают по какому принципу усилие повышается. Они получают конкретную задачу — изменяют конкретный модуль. Изменить можно что угодно и как угодно. Даже в уже готовом движке. И ООП в принципе позволяет делать любой модуль совершенно независимо от других модулей.
Проблема в общем видении системы. и, как уже заметил товарищ, в требованиях тех, кто дает деньги. Увидеть всю систему, оптимизировать ее, найти способ внедрения нового — все это задача не программиста, а гейм-дизайнера, который вообще может не понимать как работают отдельные модули, но прекрасно должен понимать как они взаимодействуют. И ООП позволяет в этом случае делать главное — идти сверху вниз, от общего к частному, уточняя детали по мере развития проекта. И делать это усилиями совершенно разных людей, один из которых видит всю картину, а второй умеет сделать отдельный мазок. Проблема не в ООП, который прекрасно подходит для этого. Проблема в видении общего. В желании изменять отдельные готовые модули. В финансировании и отведенном времени, в конце-концов.
В общем и целом понятно, что вы стремитесь донести. Однако брюзжание «ООП не дает простора творчеству» длятся уже больше 10 лет. Точно также, как и споры о лучшем языке программирования, и еще много чего. И это ни к чему не приводит, хотя «убийц ООП» предложено было уже не один десяток, дай бог памяти. «ООП устарел» — это что-то из разряда мифов типа «В Ворде верстать нельзя», «Линукс лучше Виндовс», «Старые игры были лучше». Все об этом знают, а те, кто не знает, делают шедевры.
DOD (Data Oriented Design) напрямую дает поточную изоляцию памяти, что выливается как в неблокирующие операции, так и в т.н. positive sharing (положительную работу предсказателя и постоянную актуальность данных в L1).
Семейство CO (Component Oriented) и ES (Entity System) парадигм предлагает набор решений для широкого ряда проблем, в том числе и описанных в данной статье.
Вы просто во все большие абстракции уходите. Я говорил о конкретной парадигме, которая преобладает в софте, о ее недостатках и о том, почему, как я считаю, она сильно ограничивает, если можно так выразиться, полет фантазии, в отличии от альтернатив.