Странный заголовок? Что это тут делает? Кто этот странный парень?

Зайдем немного издалека. Не так давно я стал чаще смотреть подкасты ММОзга. Там в последнее время тема самой разработки и того, что с ней связано, стала подниматься крайне часто. Вероятнее всего, причина в том, что многие разработчики стали куда раньше анонсировать свои игры, больше делиться информацией о каких-то внутренних явлениях самого процесса игростроения.

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

Вы спросите, но почему же тут? Есть же Хабр, там же эта тема актуальнее. Однако, есть причины, по которым я считаю, что эта статья должна быть именно тут.

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

Вторая причина состоит в том, что я не профессионал. Это значит не то, что я сам не понимаю, чем я занимаюсь, как бы нескромно это ни звучало, а то, что я не зарабатываю себе этим деньги, хотя, скорее всего, когда-то и буду. И, на мой взгляд, это создает приличную пропасть в понимании между мной и подавляющим большинством разработчиков. (особенно ярко я это почувствовал после анонса Epic Store, но это совсем другая история)

Ну и, конечно, не менее важным фактором публикации этого текста на ММОзге стала сама обстановка в Gamedev-среде. Как я уже написал выше, заметка о геймдизайне произвела на меня определенное впечатление. Пусть я и не удивился той системе в духе игровых автоматов\одноруких бандитов, но известные места активно подгорели.

Итак, краткий ответ на вопрос из заголовка — да, архитектура мешает геймдизайну

Можно было бы на этом закончить, но мы же тут не для этого, правда?

Сложный и развернутый ответ требует некоторого копания в дебрях того, с чем сталкиваются как именитые и опытные ААА разработчики, так и индюшатина, вроде моей любимой команды.

Начнем же копать! А копать мы будем к самой сути, к корням, к тому скелету, на который мы натягиваем нашу игру.

Почти вся современная игровая индустрия, как минимум та, что работает в области мультиплеера и тем более ММО, использует в большинстве случаев парадигму программирования, которую в свое время популяризовал С++ — объектно ориентированное программирование(ООП).

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

Какие же проблемы возникают в этой парадигме программирования и какое же отношение это имеет к геймдизайну?

Иерархии убивают расширяемость.

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

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

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

MMO-индустрия: Представьте себе иерархию, которая в сотни раз больше, чем эта и имеет куда более запутанные связи между объектами.
Представьте себе иерархию, которая в сотни раз больше, чем эта и имеет куда более запутанные связи между объектами.
По ссылке так же можно посмотреть иерархию только небольшой части Unreal Engine 4


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

Работает — не трогай.

Сложная иерархия классов\объектов часто пугает вопросом своего переписывания. Не менее пугающим может стать вопрос велосипедостроения, который предполагает создание решений с нуля. Решений, которые уже где-то когда-то кем-то были созданы и относительно неплохо работают, но могут чем-то не устраивать разработчиков. И тут есть только два варианта. Первый — писать свое, а значит тратить время и силы, а также, возможно, в процессе отказаться от какой-то части механик. И второй — взять то, что тебе не совсем подходит, но зато готово и уже работает. А, как говорится, если работает — не трогай. Ну, и бери в следующий проект, конечно. Бытует мнение, что хороший разработчик не пилит велосипеды, а берет старые велосипеды из старых проектов. И в каком-то смысле это правильно, но лишь до тех пор пока не окажется, что нужен совсем даже не велосипед и даже не транспорт вовсе.

То, что кажется удобным и понятным для нас, для ЭВМ выглядит очень сложным и хаотичным.

Почему же ООП плох в контексте ММО? Ведь так удобно мыслить объектами и классами по аналогии с реальным миром, привычным для нашего понимания. Мы видим структурированные системы в таких иерархиях. Однако то, что кажется удобным и понятным для нас, для ЭВМ выглядит очень сложным и хаотичным. Дело в том, что со времен первых процессоров с современной архитектурой типа i386 прошло почти 35 лет, за это время появилось много новых парадигм и популяризовалось ООП, но, как мы понимаем, сами процессоры кардинально не изменились. И то, что сегодня является мейнстримом для программирования, для архитектуры вычислительных систем что-то новое, непонятное и очень труднообрабатываемое.
И что же, мы в тупике? Пора срочно переделывать все процессоры? Нет, достаточно просто начать понимать, как «думает» ЭВМ, как она работает и какие данные для нее понятнее. И к сожалению для тех, кто испытывает теплые чувства к объектно ориентированной парадигме программирования, она безнадежно провалилась, как минимум в высоконагруженных сложных системах, таких как ММО.

Что может быть надежнее проверенного велосипеда?

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

Для понимания масштаба трагедии, могу с уверенностью заявить, что все это не только проблемы тех, кто, например, пишет свой движок с нуля. Может даже наоборот — инди-разработчикам в такой ситуации несколько проще маневрировать. А вот такие гиганты как Unreal Engine, Unity, CryEngine страдают от своих ООП реализаций больше, чем игры на собственных движках.

Так в нашей команде мы очень долго мучили себя и UE4, копаясь в исходных кодах, занимаясь попытками понять последовательности действий при исполнении программы и различить все связи в сложной многоуровневой иерархии. Мы пытались переписать\адаптировать какие-то отдельные части движка под свои нужды, что попросту съело наше бесценное время. В конечном счете, к чему же мы пришли? Ну, что же, наш проект мы просто переписали, точнее даже написали заново, используя кардинально отличающуюся парадигму. Возможно, если кого-то это заинтересует, я смогу перевести и адаптировать статьи об этой технологии.

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

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

Спасибо за внимание!

Автор: Эрг

Indie Game-Dev, никакого AAA, только хардкор!)
( Unreal > Blender > C++ )

35
  • Спасибо за вашу оценку!
    Узнайте, на что она влияет.

Поддержите ММОзговед через Patreon

Поддержать

$236 из $250 в месяц

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

Поддержать

Читайте также

37 комментариев

avatar
Спасибо за правки, как-то больше внимания уделял тому, чтобы не скатиться в кучу сложной терминологии, а про какие-то простые вещи даже не подумал.)
Комментарий отредактирован 2018-12-25 08:51:56 пользователем William_Godwin
  • 0
avatar
Сгенерировал более наглядный пример архитектуры. В даном случае это базовый класс UE4 для создания игровых объектов и его наследники.
  • +2
avatar
Ссылка ведет на сайт ВК?) Просто он заблокирован и я не могу посмотреть.
  • 0
avatar
Я согласен лишь только с одним тезисом — масштабируемость — проблема, требующая серьезного внимания и затрат. В остальном — не согласен. Статья, с неоправданно длинным и self-centered вступлением, похожа на попытку вступиться за коллег (что я лично сам очень даже понимаю, been there, done that), манипулируя «магическими» словами, малопонятными для неподготовленного читателя, в попытке обосновать свой тезис.

Несмотря на все это, автор приходит к правильным выводам:

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

ООП лишь принцип. Как его применять — отдельная тема. Знание основ Software Engineering для гейм-дизайнера важно (и обязательно в случае с независимыми разработчиками, которые носят множество шляп одновременно). Можно делать плохие системы, а можно и хорошие, регулируя количество внутренних и внешних связей, используя контейнеры и компоненты, и т.д.. Это, в буквальном смысле, целая наука. Требующая профессионального подхода.

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

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

PS: начинающий независимый гейм дизайнер/софт инженер, адепт C#/Unity
Комментарий отредактирован 2018-12-25 11:59:08 пользователем L0ckAndL0ad
  • +7
avatar
ООП лишь принцип
Это «лишь» таит в себе очень многое, как написал чуть ниже, наверное стоит раскрыть тему еще подробнее.

Но намекну, что я не просто так упомянул архитектуру процессоров и то как они воспринимают вообще любые иерархии, даже не слишком сложные.

Ах да, я бы не сказал, что кого-то защищаю, как раз даже во многом наоборот.)
Комментарий отредактирован 2018-12-25 13:18:18 пользователем William_Godwin
  • +1
avatar
Я не понимаю, к чему вы клоните.

Повторю свою ключевую мысль. Вопросы производительности важны, но они решаемы, причем даже в одно-два лица/разработчика, при мизерном бюджете (см кейс Haven & Hearth). В случае хорошей команды и бюджета побольше они решаемы с очень крутым результатом (см кейс EVE-Online). Поэтому я не вижу особого смысла рассуждать о технической стороне вопроса.

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

Понятное дело, что софт не создается путем бросания денег в монитор. Но, как и со всем остальными предприятиями в жизни, это вопрос знаний, навыков, профессионализма, управления, эффективности, которые и определяют успех.
  • +1
avatar
Вопросы производительности важны, но они решаемы

Вы просто во все большие абстракции уходите. Я говорил о конкретной парадигме, которая преобладает в софте, о ее недостатках и о том, почему, как я считаю, она сильно ограничивает, если можно так выразиться, полет фантазии, в отличии от альтернатив.
  • 0
avatar
Фантазию всегда что-то где-то ограничивает. Когда ООП только-только внедрялся, по поводу его эффективности было не меньше сомнений, классический подход казался гораздо более надежным и, главное, понятным.
Суть не в абстракции. Суть в механизмах взаимодействия. Современное поколение программистов в большей степени само стремится использовать уже имеющиеся наработки, а не создавать свои. Зачем делать что-то новое, когда кто-то уже сделал аналогичное. Я не в курсе системы работы в крупных компаниях, но сдается мне, что очень значительная часть программистов там работает именно по принципу «не будем изобретать велосипед». При этом они даже не представляют себе как работает «звездочка» на заднем колесе: Есть цепь, есть звездочка, есть колесо, есть педальный привод. Усилие на колесо меньше, чем усилие на звездочку, но скорость колеса больше — вот все, что они знают. А что там внутри звездочки и педального привода — их не колышет совершенно, хорошо если знают по какому принципу усилие повышается. Они получают конкретную задачу — изменяют конкретный модуль. Изменить можно что угодно и как угодно. Даже в уже готовом движке. И ООП в принципе позволяет делать любой модуль совершенно независимо от других модулей.
Проблема в общем видении системы. и, как уже заметил товарищ, в требованиях тех, кто дает деньги. Увидеть всю систему, оптимизировать ее, найти способ внедрения нового — все это задача не программиста, а гейм-дизайнера, который вообще может не понимать как работают отдельные модули, но прекрасно должен понимать как они взаимодействуют. И ООП позволяет в этом случае делать главное — идти сверху вниз, от общего к частному, уточняя детали по мере развития проекта. И делать это усилиями совершенно разных людей, один из которых видит всю картину, а второй умеет сделать отдельный мазок. Проблема не в ООП, который прекрасно подходит для этого. Проблема в видении общего. В желании изменять отдельные готовые модули. В финансировании и отведенном времени, в конце-концов.
В общем и целом понятно, что вы стремитесь донести. Однако брюзжание «ООП не дает простора творчеству» длятся уже больше 10 лет. Точно также, как и споры о лучшем языке программирования, и еще много чего. И это ни к чему не приводит, хотя «убийц ООП» предложено было уже не один десяток, дай бог памяти. «ООП устарел» — это что-то из разряда мифов типа «В Ворде верстать нельзя», «Линукс лучше Виндовс», «Старые игры были лучше». Все об этом знают, а те, кто не знает, делают шедевры.
  • +5
avatar
Ну, давайте тогда начнем с конкретных фраз, по порядку.
Иерархии убивают расширяемость.
— наследование убивает расширяемость системы. Не пугайтесь, это не попытка вас запутать или глупо пошутить. Все дело в том, что эти самые сложные иерархии не могут увеличивать свою сложность до бесконечности по многим причинам, как просто из-за того, что с таким кодом становится очень сложно работать, так и из-за того, что сам код начинает работать хуже. И тут речь уже о масштабируемости системы, то есть возможность выдержать большие нагрузки.
Иерархии это лишь способ группировать данные/функционал. Для удобства восприятия и работы с ними. Чем лучше сгруппируешь, тем меньше будет конечного кода. Наследование и полиморфизм — тоже способы уменьшить ненужное дублирование, сократить/упростить код, уменьшить работу. Это, в купе с модульностью, и есть шаги к улучшению масштабируемости системы. Плюс, к упрощению одновременной работы над ней множеству людей. Т.е. абсолютно противоположное тому, о чем говорите вы.

Стоит сказать, что я кроме как ООП языками не владею, кроме, разве что, BASIC, которым я последний раз пользовался… м… лет так двадцать назад, будучи школьником. Поэтому никаких контрпримеров с использованием других парадигм я привести не могу. Как именно они могут дать лучшую масштабируемость и простоту работы?
  • 0
avatar
Как именно они могут дать лучшую масштабируемость и простоту работы?


Представьте, что у вас вообще нет иерархий, а добавление нового функционала это буквально написание одной функции, и все. И самое главное это абстракции с нулевой стоимостью.

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

Я просто очень не хочу расписывать все тут, давайте я вам пообещаю, что напишу еще одну заметку просто? =)

А если очень хочется, то почитайте про DOD и ECS.
  • +3
avatar
*подумал и добавил* со структурами немного загнул, но все же данные даже будучи «упакованы» в кастомные типы все равно примитивные. Ну и естественно ни какого функционала, только данные.
  • 0
avatar
Вы пишете про то как удобно наследовать, что это надо делать правильно и аккуратно, но наследование и полиморфизм не просто «группируют» функционал, они тащат за собой много того, что вам не нужно.
Дык в том то и дело, что нужно группировать так, чтоб ненужный мусор не тащился. Я уже перечислил в первом комментарии — low coupling/high cohesion структура, использование компонентов, контейнеров и т.д.

ООП языки позволяют писать хороший, «бодрый» код. Да и совсем не обязательно всегда использовать объекты. Здесь уже упоминали structs.

Я погуглил DoD. Собственно, начиная с Unity 2018, если я правильно понимаю, идет адаптация ECS/DoD:

unity.com/unity/features/job-system-ECS

Я взялся за Unity поздней осенью и все еще учу Unity 2017, поэтому руками не щупал, не скажу ничего.

Боттом лайн, это все вопрос оптимизации и производительности, а не экзистенциальный кризис какой-то. Ваш изначальный посыл с использованием слова «убивает» просто не соответствует действительности. «Затрудняет» или «усложняет» — может быть. Но не более.
  • +3
avatar
Вы почему-то пропустили части про виртуальные функции и таблицы, которые вы все еще пиликаете в рантайме, ну да удобно.( я не знаю, может у нас разное понимание ООП, но это как бы основа) Простите, полиморфизм есть полиморфизм, если у вас его нет или практически нет, то это не ООП в чистом виде.

Далее, никакого внимания на упоминание абстракций с нулевой стоимостью.

"«Затрудняет» или «усложняет»" на уровне 100 человек играет в одной сессии с 50к практически статичных объектов. А убивает на уровне ММО. Да, можно очень долго мучиться и выжимать из себя супер круто настроенную архитектуру-гибрид бульдога с носорогом, тратя на это время и деньги, оплачивая какой-нибудь Spatial OS, имея ряд трудностей с сопровождением, отладкой и ведением новых фич, а можно просто взять и добавлять без напряга десятки тысяч динамически изменяющихся сущностей, с полностью индивидуальным набором свойств, которые имеют ограничения только в виде объема вашей RAM, взаимодействующих друг с другом, не требующих практически никакого изменения для распараллеливания обработки и еще кучу всего.

Ну я не прав и не понимаю, видимо, ничего в ООП.
Комментарий отредактирован 2018-12-25 23:50:01 пользователем William_Godwin
  • 0
avatar
Вы почему-то пропустили части про виртуальные функции и таблицы, которые вы все еще пиликаете в рантайме, ну да удобно.( я не знаю, может у нас разное понимание ООП, но это как бы основа) Простите, полиморфизм есть полиморфизм, если у вас его нет или практически нет, то это не ООП в чистом виде.

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

Когда вы говорите про ООП, у меня складывается ощущение, что вы имеете ввиду, что весь код, от и до, должен состоять из его атрибутов, и манипулировать только ими. Что все должно упираться в иерархии классов и объекты. Я правильно вас понимаю?

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

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


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

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

Если вокргу столько инноваций и классных ММО, то почему на ММОзге постоянно пишут статьи о том, что: как-то не видно масштаба, все как-то повторяется, мало новых идей и т.д. Я считаю, что ответ именно где-то в области статистики, результаты которой определяются теми самыми порогом вхождения и сложностью, которые можно было бы сильно снизить.
  • 0
avatar
Начнем с того, что это разные парадигмы, а не методы, это важно.
Верно, я говорю про методики, принципы, а не про конкретно ООП методы (as in method vs function).

вы просто получите bottleneck, который будет вас ограничивать
Вот. Вы сами подобрали более подходящее слово. Именно ограничениями, или затруднениями, как я уже сказал комментарием выше. Но никак не «убийством». А с ограничениями мы сталкиваемся в любом случае. Какими именно уже зависит от эффективности составленного кода (т.е. возможностей инструментария и навыков пишущего).

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

Когда мне, например, достаточно производительности Unity для реализации задуманного, то это осознанный выбор инструмента, способного дать возможность реализовать все, что я хочу. Когда пара студентов взяла Java и стала работать над H&H, у них получилось реализовать кучу интересных механик, при том, что они не гнались за созданием огромного мира с тысячами игроков. Когда у CCP Games была необходимость делать единый сервер для большого мира, они стали использовать Stackless Python, который удовлетворял их нуждам. При чем здесь ограничения ООП, когда их никто ни на кого не накладывает? Люди пользуются методиками и инструментами в рамках поставленной задачи. Да, цена входа разная, конечно, но она соответствует уровню сложности задачи, что вполне закономерно. Хотя, опять же, технологии не стоят на месте, и тренд идет лишь в сторону снижения цены (как в примере введения обозначенных вами технологий в Unity 2018).
  • +1
avatar
Ну, в принципе мне нечего возразить.)

Посмотрим на технологии. ^_^
Комментарий отредактирован 2018-12-26 13:01:09 пользователем William_Godwin
  • +2
avatar
ООП не главный злодей, он просто не дает такой свободы и простоты, а это значит, что порог вхождения для людей выше. И я не обвинял его в убийстве ( никто пока никого не убил, да и не убьет, скорее всего), я говрил, что он это пытается сделать.
Ну, по-крайней мере заметка так воспринимается.

Если вокргу столько инноваций и классных ММО, то почему на ММОзге постоянно пишут статьи о том, что: как-то не видно масштаба, все как-то повторяется, мало новых идей и т.д. Я считаю, что ответ именно где-то в области статистики, результаты которой определяются теми самыми порогом вхождения и сложностью, которые можно было бы сильно снизить.
Могу говорить только за себя. Я в принципе считаю ММО сомнительным жанром, в плане эффективности создания сетевых экспириенсов. Вопросы масштаба меня не сильно заботят, по этой же причине. А ограничение инноваций, как в вашей же заметке и сказано, лишь следствие недостатка инвесторов, которые готовы в них вкладываться.
  • 0
avatar
Большое спасибо за статью! Пишите еще, очень интересно, к чему же вы пришли в итоге.
  • 0
avatar
Приветствую нового автора!

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

Не соглашусь с объявлением ООП виновником всех бед. Если сталкиваетесь с проблемами в иерархиях, то не нужно делать такие длинные и развесистые иерархии, а лучше использовать композицию. Я хоть и не игру делаю, но у меня обычно трейт или абстрактный класс, который расширяет библиотечный класс, и у него пара наследников. Всё.

Писать многопоточный код намного сложнее, чем однопоточный, но причём здесь ООП? Разве многопоточный код со struct-ами на чистом С или даже ассемблере выглядит проще и понятнее? В любом случае нужно или куча синхронизаций при работе с shared mutable state, или неизменяемые объекты и функциональный подход (всё равно объекты, как ни крути). Или пересылать сообщения в очередях.

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

Работает — не трогай
Этот принцип подходит далеко не всегда, а только для тех частей программы, которые Не нужно развивать. Например, ланчер или окошко настроек. Их один раз написали, и больше новых функций от них не потребуется. А вот для основного кода, который всё время развивается, лучше другой принцип — постоянный рефакторинг. Тогда и будет нормальный код, который не придётся полностью переписывать, а только частично поменять при добавлении новой механики.
Комментарий отредактирован 2018-12-25 12:40:53 пользователем Eley
  • +4
avatar
Также хотелось бы реальных примеров, а не иерархий диалогов печати файла и сохранения шаблонов, которые не имеют отношения к играм.


Я к большому сожалению просто куда-то посеял сгенерированную в Doxygen иерархию классов для Unreal, уж больно много места все это занимало.

Что ж, по остальному могу пройтись в след. раз, т.к. я, если честно, не думал, что так много людей тут есть, кто прекрасно бы все понял и «в терминах», так сказать.
  • 0
avatar
Разве многопоточный код со struct-ами на чистом С или даже ассемблере выглядит проще и понятнее?
Да, значительно проще в том случае, когда применяется DOD или семейство CO/ES парадигм.
DOD (Data Oriented Design) напрямую дает поточную изоляцию памяти, что выливается как в неблокирующие операции, так и в т.н. positive sharing (положительную работу предсказателя и постоянную актуальность данных в L1).
Семейство CO (Component Oriented) и ES (Entity System) парадигм предлагает набор решений для широкого ряда проблем, в том числе и описанных в данной статье.
Комментарий отредактирован 2018-12-25 17:18:32 пользователем FrankStein
  • +1
avatar
Игры создают не программисты. Поэтому совершенно плевать, какой такой парадигмой они пользуются. Программисты создают движок и инструментарий, и только лишь. Но не игру.
На самом деле игры вообще начали создаваться задолго до эпохи PC, вспомнить хоть D&D или WH40K. Программисты лишь дали ещё один инструмент для этого создания, не более.
  • 0
avatar
Кхм, на такое можно и обидеться))

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

Из своей практики, например, пиши мы код проекта в стиле ООП ( строго, то есть наследование, полиморфизм, инкапсуляция и все вытекающее) то наши механики с динамически изменяющимся живым миром, в котором существа буквально постоянно анализируют окружающую среду и принимают решения так и остались бы мечтами, т.к. реализовать это «классическими» способами очень сложно, либо получилось бы совсем не то и не в тех масштабах.
  • +3
avatar
Боюсь, в геймдеве количество не переходит в качество. Да, развитие инструментов (тех же движков) приводит к тому, что игр выходит всё больше и больше. Однако же, шедевров больше не становится. Становится больше середнячков, на пару недель игры, и сильно-сильно больше шлака, за счёт которого и идёт основной прирост.
Мне, как потребителю, от этого наоборот хуже, потому что я вынужден прилагать больше времени и сил, чтоб найти в этом океане мусора хоть что-то стоящее.
  • 0
avatar
Никто не говорит о количестве, которое переходит в качество. Тут довольно простая математике, точнее статистика. То что чего-то, что вы решили назвать «шлаком», что все же вопрос вкуса, согласитесь, стало больше, не значит апять же, что статистика не работает. Всегда чем больше разнообразие\вариативность, тем болше вероятность, что в этом спектре найдется что-то живучее, это как эволюция, понимаете?

Насчет усилий по поиску… Честно, мне вот например наоборот сам процесс поиска чего-то среди сотен вариантов и параметров нравится больше, чем «выбор» из двух.
  • +6
avatar
Правила ДнД тоже своего рода код, разве нет? И применять его можно не только к конкретному миру, и использовать не только конкретные арты/фигурки/прочее…
  • 0
avatar
Утверждать, будто программисты делают игры — всё равно что считать, будто еду готовят производители посуды. Да, в современном мире еда обычно находится в какой-то посуде (упаковке, обёртке), однако ценность-то не в посуде, а в том, что туда налито/насыпано. И повару совершенно до лампочки проблемы производителя сковородок, который всё никак не подберёт оптимальный способ закалки металла или напыления каких-нибудь супер-покрытий. На процесс готовки всё это влияет не так уж сильно, чтоб прям случился прорыв в поварском искусстве из-за новой формы кастрюли.
  • 0
avatar
Аналогия так себе, но… Погуглите молекулярную кухню, например)
Да и вообще развитие науки и техники всегда создавало возможности для творцов, расширяло их.

А вообще, мне кажется как-то уже совсем в философствования ударяемся.)
  • +1
avatar
Сказать такое — всё равно, что заявить, будто дома строят не строители. А строители просто ставят кирпичи. Игры создают все — и программисты, и геймдизайнеры, и тестировщики, и даже игроки. Не нужно преуменьшать ценность кого-то из них.
Комментарий отредактирован 2018-12-25 22:29:07 пользователем Eley
  • +6
avatar
С другой стороны часть правды в этом есть.
Программисты пишут любые программы — и в общем не сильно важно банковский это продукт игровой или вообще система по учету наркотрафика для ребят из криминала. Кирпичи везде почти одинаковые.
Так что игры в определенном смысле все таки создают геймдизайнеры и постановщики задач. А вот дальше уже начинается техника.
  • 0
avatar
Игры создают не программисты.… Программисты создают движок и инструментарий, и только лишь. Но не игру.
На самом деле это «немного» не так.

Не так давно, еще где-то в районе 1995 года, игровому дизайнеру Рафу Костеру потребовалось сперва изучить неизвестный ему язык скриптов (для которого на тот момент и машины виртуальной еще не существовало), затем набить на этом языке дизайн механик и квестов, а после завершения создания виртуальной машины — переписать все заново.

Квесты, предметы, монстры, расположение и поведение НПЦ, навыки и даже связи между локациями в игре Ragnarok Online создаются средствами специального языка для виртуальной машины сервера eAthena.

Я могу очень много таких примеров привести, но не в них суть.

Существует подход под названием DDP (Data-Driven Programming). В рамках этого подхода программа разбивается на уровни ответственности. Чем ниже — тем ближе к кремнию. Чем выше — тем ближе к человеку. Ответственность растет от человека, где она минимальна, в сторону кремния, где ответственность максимально высокая.
Код с высоким уровнем ответственности создается в виде разрозненных и атомарных блоков логики. На среднем уровне задаются правила объединения блоков кода с низкого уровня. А на верхнем уровне правила среднего уровня используются как операторы для написания конкретной бизнес-логики.
При этом, начиная со среднего уровня код программы перестает быть исключительно текстовым: в код включаются машины состояний, графы переходов, деревья поведений, разного рода таблицы с данными, включая даже изображения карт многомерных распределений или карт шумов.
Комментарий отредактирован 2018-12-26 09:54:47 пользователем FrankStein
  • +6
avatar
Существует подход под названием DDP (Data-Driven Programming). В рамках этого подхода программа разбивается на уровни ответственности.
Есть подозрение что это вообще хороший тон при написании больших программ.

Ответственность растет от человека, где она минимальна, в сторону кремния, где ответственность максимально высокая.
Не уверен. На постановщиках и архитекторах намного больше отвественности. Их ошибка может запороть работу кодеров намного сильнее чем наоборот.
Код с высоким уровнем ответственности создается в виде разрозненных и атомарных блоков логики.
Есть подозрение что ТЗ стоит тоже включить в эту иерархию и тогда код с высоким уровнем пишется вообще на естественном бюрократическом или экономическом языке.
  • +1
avatar
А для игрового дизайна создать такую структуру нельзя что ли?
  • 0
avatar
Попробую изложить свои мысли и провести аналогию, которая сложилась у меня в голове после прочтения статьи. (как у человека, далекого от программирования и компьютеров)

Игра — это прежде всего произведение искусство. А движок и программный код — лишь рабочий инструмент для создания произведения.

Если ты хочешь написать картину, ты можешь взять краски и кисть. (т.е. уже готовые инструменты)
Но если ты задумал в своей картине нечто особое? Например написать картину песком, на ходу изменяя ее? Или линии рисунка должны блестеть металлическим цветом, и быть начертанными углем? Но в магазинах только краски и кисть…

У тебя есть выбор: либо ты рисуешь готовыми красками и кистью. (отказываясь от некоторых идей)
Либо сам создаешь для себя нужные инструмент (перебираешь разные варианты угля для начертания, подбираешь песок нужного цвета с определенным размером песчинок, сам изготавливаешь нужные краски и т.д.) Это может потребовать даже больших сил, чем на создание самого произведения.

С играми то же самое. Готовые инструменты казалось бы дают нам возможность: «бери да твори». Но в то же время ограничивают творцов и не всегда подходят для реализации задуманного…
  • +3
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.