Архитектура мешает геймдизайну?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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