Код должен быть в первую очередь эффективен. Поэтому вполне логично использовать другие методы в тех местах, где это принесет лучший эффект.
Начнем с того, что это разные парадигмы, а не методы, это важно. Попытки связать ECS ( я включаю туда и DOD, хотя это не совсем одно и то же, но без него ECS не обладает тем потенциалом, о котором я тут говорю) с ООП вы просто получите bottleneck, который будет вас ограничивать. Вам придется писать какие-то обертки, инжекторы и вообще прыгать вокруг с барабаном. Так что да, код должен быть эффективным, а еще простым в написании и сопровождении.
ООП не главный злодей, он просто не дает такой свободы и простоты, а это значит, что порог вхождения для людей выше. И я не обвинял его в убийстве ( никто пока никого не убил, да и не убьет, скорее всего), я говрил, что он это пытается сделать.
Если вокргу столько инноваций и классных ММО, то почему на ММОзге постоянно пишут статьи о том, что: как-то не видно масштаба, все как-то повторяется, мало новых идей и т.д. Я считаю, что ответ именно где-то в области статистики, результаты которой определяются теми самыми порогом вхождения и сложностью, которые можно было бы сильно снизить.
Вы почему-то пропустили части про виртуальные функции и таблицы, которые вы все еще пиликаете в рантайме, ну да удобно.( я не знаю, может у нас разное понимание ООП, но это как бы основа) Простите, полиморфизм есть полиморфизм, если у вас его нет или практически нет, то это не ООП в чистом виде.
Далее, никакого внимания на упоминание абстракций с нулевой стоимостью.
"«Затрудняет» или «усложняет»" на уровне 100 человек играет в одной сессии с 50к практически статичных объектов. А убивает на уровне ММО. Да, можно очень долго мучиться и выжимать из себя супер круто настроенную архитектуру-гибрид бульдога с носорогом, тратя на это время и деньги, оплачивая какой-нибудь Spatial OS, имея ряд трудностей с сопровождением, отладкой и ведением новых фич, а можно просто взять и добавлять без напряга десятки тысяч динамически изменяющихся сущностей, с полностью индивидуальным набором свойств, которые имеют ограничения только в виде объема вашей RAM, взаимодействующих друг с другом, не требующих практически никакого изменения для распараллеливания обработки и еще кучу всего.
Аналогия так себе, но… Погуглите молекулярную кухню, например)
Да и вообще развитие науки и техники всегда создавало возможности для творцов, расширяло их.
А вообще, мне кажется как-то уже совсем в философствования ударяемся.)
Никто не говорит о количестве, которое переходит в качество. Тут довольно простая математике, точнее статистика. То что чего-то, что вы решили назвать «шлаком», что все же вопрос вкуса, согласитесь, стало больше, не значит апять же, что статистика не работает. Всегда чем больше разнообразие\вариативность, тем болше вероятность, что в этом спектре найдется что-то живучее, это как эволюция, понимаете?
Насчет усилий по поиску… Честно, мне вот например наоборот сам процесс поиска чего-то среди сотен вариантов и параметров нравится больше, чем «выбор» из двух.
*подумал и добавил* со структурами немного загнул, но все же данные даже будучи «упакованы» в кастомные типы все равно примитивные. Ну и естественно ни какого функционала, только данные.
Как именно они могут дать лучшую масштабируемость и простоту работы?
Представьте, что у вас вообще нет иерархий, а добавление нового функционала это буквально написание одной функции, и все. И самое главное это абстракции с нулевой стоимостью.
Вы пишете про то как удобно наследовать, что это надо делать правильно и аккуратно, но наследование и полиморфизм не просто «группируют» функционал, они тащат за собой много того, что вам не нужно. Может что-то из этого сокращает код и упрощает работу здесь и сейчас, но когда процессор будет долго и пичально искать а где же тот виртуальный метод, который от меня хотят, он вам спасибо не скажет. А вот теперь представьте, что у вас есть абсолютно такие же абстракции, вроде объектов, но никакого полиморфизма, наследования и даже создания самих классов и структур для их существования вам не нужно.
Я просто очень не хочу расписывать все тут, давайте я вам пообещаю, что напишу еще одну заметку просто? =)
Понимаете, чем проще что-то создать, тем выше вероятность того, что кто-то это сделает. Чем больше будет тех, кто это сделает, тем выше вероятность того, что это выстрелит и вам понравится.
Из своей практики, например, пиши мы код проекта в стиле ООП ( строго, то есть наследование, полиморфизм, инкапсуляция и все вытекающее) то наши механики с динамически изменяющимся живым миром, в котором существа буквально постоянно анализируют окружающую среду и принимают решения так и остались бы мечтами, т.к. реализовать это «классическими» способами очень сложно, либо получилось бы совсем не то и не в тех масштабах.
Вы просто во все большие абстракции уходите. Я говорил о конкретной парадигме, которая преобладает в софте, о ее недостатках и о том, почему, как я считаю, она сильно ограничивает, если можно так выразиться, полет фантазии, в отличии от альтернатив.
Также хотелось бы реальных примеров, а не иерархий диалогов печати файла и сохранения шаблонов, которые не имеют отношения к играм.
Я к большому сожалению просто куда-то посеял сгенерированную в Doxygen иерархию классов для Unreal, уж больно много места все это занимало.
Что ж, по остальному могу пройтись в след. раз, т.к. я, если честно, не думал, что так много людей тут есть, кто прекрасно бы все понял и «в терминах», так сказать.
Серьезно? Не можете сопоставить 2 события на временной прямой и построить причинноследственную связь?
Г — геймдизайнир
Надеюсь вас и мылору однажды заставять лицензировать ваши поделия как игровые автоматы и мы будем узнавать о них только из рекламмы при просмотре любимых сериалов.
Интересно… То есть это если у меня 16 км^2 тирейн, то на одном инстанс сервере 43,712 человека это уже ММО?) Не то чтоб я против был, но фортнайт тогда ММО х2 ))
А вот и место откуда ноги растут. Кстати, обратите внимание на послдние графики и текст к ним, а главное на то блог какой компании это выкладывает. habr.com/company/mailru/blog/274263/
Начнем с того, что это разные парадигмы, а не методы, это важно. Попытки связать ECS ( я включаю туда и DOD, хотя это не совсем одно и то же, но без него ECS не обладает тем потенциалом, о котором я тут говорю) с ООП вы просто получите bottleneck, который будет вас ограничивать. Вам придется писать какие-то обертки, инжекторы и вообще прыгать вокруг с барабаном. Так что да, код должен быть эффективным, а еще простым в написании и сопровождении.
ООП не главный злодей, он просто не дает такой свободы и простоты, а это значит, что порог вхождения для людей выше. И я не обвинял его в убийстве ( никто пока никого не убил, да и не убьет, скорее всего), я говрил, что он это пытается сделать.
Если вокргу столько инноваций и классных ММО, то почему на ММОзге постоянно пишут статьи о том, что: как-то не видно масштаба, все как-то повторяется, мало новых идей и т.д. Я считаю, что ответ именно где-то в области статистики, результаты которой определяются теми самыми порогом вхождения и сложностью, которые можно было бы сильно снизить.
Далее, никакого внимания на упоминание абстракций с нулевой стоимостью.
"«Затрудняет» или «усложняет»" на уровне 100 человек играет в одной сессии с 50к практически статичных объектов. А убивает на уровне ММО. Да, можно очень долго мучиться и выжимать из себя супер круто настроенную архитектуру-гибрид бульдога с носорогом, тратя на это время и деньги, оплачивая какой-нибудь Spatial OS, имея ряд трудностей с сопровождением, отладкой и ведением новых фич, а можно просто взять и добавлять без напряга десятки тысяч динамически изменяющихся сущностей, с полностью индивидуальным набором свойств, которые имеют ограничения только в виде объема вашей RAM, взаимодействующих друг с другом, не требующих практически никакого изменения для распараллеливания обработки и еще кучу всего.
Ну я не прав и не понимаю, видимо, ничего в ООП.
Да и вообще развитие науки и техники всегда создавало возможности для творцов, расширяло их.
А вообще, мне кажется как-то уже совсем в философствования ударяемся.)
Насчет усилий по поиску… Честно, мне вот например наоборот сам процесс поиска чего-то среди сотен вариантов и параметров нравится больше, чем «выбор» из двух.
Представьте, что у вас вообще нет иерархий, а добавление нового функционала это буквально написание одной функции, и все. И самое главное это абстракции с нулевой стоимостью.
Вы пишете про то как удобно наследовать, что это надо делать правильно и аккуратно, но наследование и полиморфизм не просто «группируют» функционал, они тащат за собой много того, что вам не нужно. Может что-то из этого сокращает код и упрощает работу здесь и сейчас, но когда процессор будет долго и пичально искать а где же тот виртуальный метод, который от меня хотят, он вам спасибо не скажет. А вот теперь представьте, что у вас есть абсолютно такие же абстракции, вроде объектов, но никакого полиморфизма, наследования и даже создания самих классов и структур для их существования вам не нужно.
Я просто очень не хочу расписывать все тут, давайте я вам пообещаю, что напишу еще одну заметку просто? =)
А если очень хочется, то почитайте про DOD и ECS.
Момент
Понимаете, чем проще что-то создать, тем выше вероятность того, что кто-то это сделает. Чем больше будет тех, кто это сделает, тем выше вероятность того, что это выстрелит и вам понравится.
Из своей практики, например, пиши мы код проекта в стиле ООП ( строго, то есть наследование, полиморфизм, инкапсуляция и все вытекающее) то наши механики с динамически изменяющимся живым миром, в котором существа буквально постоянно анализируют окружающую среду и принимают решения так и остались бы мечтами, т.к. реализовать это «классическими» способами очень сложно, либо получилось бы совсем не то и не в тех масштабах.
Вы просто во все большие абстракции уходите. Я говорил о конкретной парадигме, которая преобладает в софте, о ее недостатках и о том, почему, как я считаю, она сильно ограничивает, если можно так выразиться, полет фантазии, в отличии от альтернатив.
Но намекну, что я не просто так упомянул архитектуру процессоров и то как они воспринимают вообще любые иерархии, даже не слишком сложные.
Ах да, я бы не сказал, что кого-то защищаю, как раз даже во многом наоборот.)
Я к большому сожалению просто куда-то посеял сгенерированную в Doxygen иерархию классов для Unreal, уж больно много места все это занимало.
Что ж, по остальному могу пройтись в след. раз, т.к. я, если честно, не думал, что так много людей тут есть, кто прекрасно бы все понял и «в терминах», так сказать.
Г — геймдизайнир
Надеюсь вас и мылору однажды заставять лицензировать ваши поделия как игровые автоматы и мы будем узнавать о них только из рекламмы при просмотре любимых сериалов.
habr.com/company/mailru/blog/274263/