Теплый кисель: Профессионал или непрофессионал - вот в чем вопрос

На Мотыльке была заметка про статью Атрона на ММОзге, которая является ответом на статьи появившегося недавно на ММОзге William_Godwin (инди-разработчик игор), который появился после того как Атрон разнес статью другого автора, то же разработчика игр (гейм-дизайнера). Такая «сантабарбара».

Я решил тоже присоединиться к этому межпроектному процессу.



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

Начинаем с первой заметки: Архитектура мешает геймдизайну?

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

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

Кроме всего прочего, я считаю важным упомянуть, что сегодня, в век многоядерных систем, ООП либо делает почти невозможным распараллеливание большинства задач в игре, либо делает это настолько сложным, что встает вопрос о целесообразности такой мультипоточности.
Я не очень знаком с ООП, предпочитаю функциональное программирование, даже в том числе в средах, которые ООП (ну, например, Delphi). Нет, при вызове WinAPI или что-то типа form1.show конечно я обращаюсь к объекту и к его свойствам.

Тем не менее, на пальцах это выглядит так:
Возьмем персонажа Pers (правильнее Pers[0], Pers[1] и тд, но мы не будем углубляться) — это объект. Он будет относиться к классу Players. Может еще и к классу BlueTeam/RedTeam.
У персонажа есть оружие Pers[0].Weapon[0]=Deagle (индексы объектов уберу из текста, чтобы не плодить лишний текст). У оружия есть параметры. Pers.Weapon.Dmg=100, Pers.Weapon.Spd=60, Pers.Weapon.Accuracy=50. Также можно для оружия сделать функции Pers.Weapon.Shoot, Pers.Weapon.Reload, Pers.Weapon.Destroy.

Если структура программы и объектов примерно такая, что очень удобно обращаться к таким объектам, а еще лучше — использовать наследственность. Вместо Pers[0].Weapon[1].Dmg=100 можно просто завести объект Deagle, у которого будут параметры Deagle.Name=«Desert eagle», Deagle.Dmg=100, Deagle.Spd=60 и тд. Тогда для Pers[0].Weapon[1]=Deagle все параметры названия, урона, скорострельности, точности и тд будут наследоваться. И для Pers[100500].Weapon[1].Deagle будет то же самое.

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

Работа с объектами при ООП в целом похоже на работу с объектами в реальном мире. У вас есть несколько объектов под рукой — камень, яблоко и бутылка кефира. Вы все можете бросить эти объекты в Атрона (ну а куда еще?), а можете съесть.

Если вы бросаете, то вам не важно красное это яблоко или зеленое, кефир 1% или 3% жирности. Вам нужно знать только массу объекта, его центр тяжести, форму и тд. Если же вы будете его есть, то нужно знать съедобный ли это объект. Получается, что для определенных действий нужны определенные характеристики, но в ООП и в целом в реальной жизни яблоко будет иметь цвет, форму, размер и тд, а также длину веточки. В играх механика упрощенная, так что яблоко при расчетах будет выглядеть как обычный шар определенной массы и с определенной моделью (стандартной). И вот ваши игроки уже кидают этими яблоками друг в друга.

В функциональном программировании процедура другая. Вы просто напишите:
bulletmodel='apple.mdl'
bulletmass=300
startshootingspd=10
playerX=1
pklayerY=2
playerZ=3
targetX=100
targetY=200
targetZ=300

for i=0 to ...
Дальше будет код, который в соответствии с используемым на сервере ускорением свободного падения по параболе бросит снаряд с моделькой яблока в направлении цели.

Если заменять работу с объектами на простые переменные/массивы, то можно привести код проекта в Спагетти код, где никто уже ничего не поймет.

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

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

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

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

Есть такая игруха (ну как есть, в бета-тесте вечном) — .kkrieger. Это игра размером в 96кб. Девяносто шесть килобайт. Это трехмерный шутер в стиле Quake3. Размером в 3 раза меньше, чем приложенный сверху черно-белый скриншот из «Берегись автомобиля».

Вот как описал процесс разработки программист Фабиан Гизен:
К тому моменту, когда работа была завершена, мы настолько выбились из сил, что понадобилось 8 месяцев перерыва, прежде чем мы всерьёз занялись другими проектами. Конечно, в итоге мы добились признания (особенно вне демосцены), но я по-прежнему не уверен, стоило ли это того. У нас остались довольно плохие воспоминания, связанные с разработкой игры.
Но непрофессионал Вильям знает лучше:
Все дело в том, что эти самые сложные иерархии не могут увеличивать свою сложность до бесконечности по многим причинам, как просто из-за того, что с таким кодом становится очень сложно работать, так и из-за того, что сам код начинает работать хуже. И тут речь уже о масштабируемости системы, то есть возможность выдержать большие нагрузки.
GOTO — очень быстрый механизм. К черту ООП. К черту UE4. Берем и пишем свой движок, ведь UE4 слишком много требует наследования и разветвления.

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

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

Сложная иерархия классов\объектов часто пугает вопросом своего переписывания. Не менее пугающим может стать вопрос велосипедостроения, который предполагает создание решений с нуля. Решений, которые уже где-то когда-то кем-то были созданы и относительно неплохо работают, но могут чем-то не устраивать разработчиков. И тут есть только два варианта. Первый — писать свое, а значит тратить время и силы, а также, возможно, в процессе отказаться от какой-то части механик. И второй — взять то, что тебе не совсем подходит, но зато готово и уже работает. А, как говорится, если работает — не трогай. Ну, и бери в следующий проект, конечно. Бытует мнение, что хороший разработчик не пилит велосипеды, а берет старые велосипеды из старых проектов. И в каком-то смысле это правильно, но лишь до тех пор пока не окажется, что нужен совсем даже не велосипед и даже не транспорт вовсе.
Я не очень хороший программист, но для меня очевидно, что для правильной работы код нужно писать по принципу 1 функция = 1 функционал. Да, удобно вкатить огромную процедуру, в которой будет куча IF/Case и которая будет помимо физики полета яблока будет еще и графику отрабатывать, но на деле ты вызовешь несколько функций по-очереди, либо одну внутри другой. И, ЧСХ, полет фаерболла и яблока можно в части физики полета описать одной функцией/процедурой. Вообще любая разработка (хоть ММО, хоть велосипеда) требует унификации элементов и процессов и отсутствия повторных процессов. Любая разработка заключается в разделении задач на небольшие подзадачи.

Если тебе нужен в WoW полеты на космических кораблях из EVE — ты берешь и внедряешь эти корабли. Заводишь классы, объекты, указываешь свойства и пишешь физику. Почему это должно быть велосипедостроением я не понимаю.

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

В этом и проблема горе-разработчиков на Unity (низкий порог вхождения в разработку => крайне-плохая оптимизация из-за непонимания основ) и того же UE. Когда Близзард делали первый Warcraft, то они переписывали стек IPX протокола. Когда Valve делали Half-Life, то на движке от первой кваки они реализовывали скелетную анимацию (впервые в играх). Это происходило когда никто не понимал как что делать, когда движок от другой конторы ты выпрашивал через знакомых у гениальных программистов типа Джона Кармака (погуглите на Хабре статьи на тему анализа кода его движков). И уж тем более никто не имел полноценных мануалов, гитхабов, стэковерфлоу и тд.

Unreal Engine 4 используется в такой популярной игре как Fortnite. Игра меня никак не привлекла, но созданный на том же движке PUBG жесточайше лагает как на сетевом уровне, так и сыпет кучей багов визуальных. Проблема ли это Epic Games или все-таки криворуких разработчиков PUBG?

— Василий Иванович, а ты на рояле играть умеешь?
— Да
— А на гитаре?
— Да
— А на саксофоне?
— Нет, карты соскальзывают


UE4 не самый плохой движок в целом. Стоит от относительно недорого, нижняя планка так вообще бесплатная. Да, он многофункциональный комбайн, но если ты не DICE или NCSoft какой-нибудь, а обычный инди-разработчик, то бери его и делай на нем игру. Разберись в нем, изучи его, почитай плюсы и минусы, посмотри оптимизацию на примерах, узнай как движок работает с тысячами одновременных подключений. Если движок не подходит по ММО, если требуется много чего переписать — НЕ ДЕЛАЙ ММО, УМОЛЯЮ. Сделай квест, сделай аркаду, сделай сингл-РПГ. Сделай кооперативную игру, на худой конец. Не нужно идти и делать ММОРПГ с оптимизацией в виде «минимальные требования — 32ГБ DDR5, 8-ядерный проц i7, 128Gb свободного места на SSD». Люди играют не только в ММО.

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

Romulas
с Фортнайт и ПУБГ может быть такая же история, как и Half-life 2 и Vampire Masquerade. У одних разработчики движка сидят за дверью, а у других — в другом городе/стране.
0
Комментарий отредактирован: 25 января 2019, 17:41
Jolly
Я понимаю прекрасно что когда тебе движок допиливают под твои хотелки коллеги через стенку, то можно делать лучше. Но если одни смогли допилить до ума и сделать игру без жутких багов, а вторые до сих пор не могут из догнать, хотя стартанули раньше — вопрос не в соседней двери
0
Romulas
ПУБГ собирался из говна и палок (готовых ассетов), явно не рассчитывали на такую популярность. А потом уже и хер забили, это правда.
1
eupraxia
Все хочется посмотреть портфолио этих «экспертов-разработчиков» с ММОЗГа)
1
Romulas
Ага, назвался груздем, полезай в кузов.
0
Eley
Так они специально не светятся. Как говорил Франк вчера на Горячем чае, раньше он хлебнул реакции игроков на публичность, и теперь скрывается. И вспоминая историю Шона Мюррея с No Man's Sky, я его понимаю. Но Франк объясняет, что и почему, а когда спрашиваешь Вильяма — всё заканчивается фразами типа: «Я не хочу вам рассказывать весь дизайн игры» или «Если вам не нравится моё отношение к ПвП, то вы — не моя аудитория».

Я допускаю вероятность того, что он знает что-то особенное, но пока доказательств этому не вижу. А вижу раздутые бездоказательные фразы типа «ООП умерло».
1
Coven
Не светиться потому, что хлебнул реакции игроков и больше не хочется — причина понятная, да. Здесь некоторые тоже не светятся, это нормально.

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

А иногда Франк тоже начинает глупо надуваться — как тут:

mmozg.net/mmo/2018/12/28/arhitektura-ne-meshaet-geymdizaynu.html#comment191879

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

А иногда он просто несет какую-то чушь — как здесь про баги:

mmozg.net/hah/2019/01/19/korol-umer-da-zdravstvuet-korol_2.html#comment191707

«Баг — это конкретный подвид ошибки, используйте термины правильно» — лол. Это ерунда. Баг / дефект / ошибка — это разные названия одного и того же понятия. Основное определение понятие — поведение, которое не соответствует спецификации / ожиданиям. (Именно так, потому что проблема может быть и в спецификации, тогда дефекта в ее реализации нет, хотя все равно надо все править.) Никто не разделяет дефекты на «баги» и «не баги». Я работал в нескольких компаниях, крупных и интернациональных, а уж *со* сколькими компаниями я работал и не сосчитать. Нигде разделения дефектов на «баги» и «не баги» не было, Франк несет ерунду. (А ммозг плюсует потому что вот, эксперт рассказал как и что, хотя он ввел всех в заблуждение.)

Не впечатляет.
2
Комментарий отредактирован: 26 января 2019, 15:25
Eley
В функциональном программировании процедура другая. Вы просто напишите:
Джолли, тот код, что ты написал — это обычное процедурное программирование. В ООП такой код бы выглядел примерно так:

Player player = ...
List<Hit> incomingHits = findIncomingHits(player)
for(int i = 0; i < incomingHits.size(); i++) {
  Hit hit = incomingHits[i]
  if (!hit.blocked) {
    players.health -= calculateDamage(hit.value, player.getDamageModifiers())
  }
}
Отличительная черта функционального программирования — что фукнции передаются в функции. Там, как правило, нет циклов for, while, а вместо них фукнции, что принимают фукнции и лямбды, типа map, reduce:

Player player = ...
List<Hit> incomingHits = findIncomingHits(player)
int hitSum = incomingHits.findAll {
  !it.blocked
}.sum(0) {
  calculateDamage(it.value, player.getDamageModifiers())
}
player.health -= hitSum
То есть, вместо цикла for и обработки каждого удара по отдельности мы обрабатываем список ударов как одно целое — сначала ищем все удары, которые не заблокированы щитом, а потом считаем сумму, а потом уже только применяем к игроку. За счёт этого упрощается код, так как теперь мы состредотачиваемся не на циклах, а на том, что реально происходит с ударами.
1
Комментарий отредактирован: 26 января 2019, 14:28 (5 раз)
Jolly
Да, я не поправил просто, уже после заметил. Там 2 раза «функциональное», а дальше уже «процедурное». Но не суть, я о том, что без ООП будет просто колбаса текста, с кучей переменных, массивов и тд, тогда как в современном движке игры как раз за счет ООП получается легко связывать свойства, графику и действия, привязывая это к объекту, а не говоря о том, что ООП дает слишком много избыточных заморочек, поэтому нужно все переделывать.

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

Почему же меня бомбит? Потому как Вильям упоминает логику работу процессоров, причем кичиться этими знаниями, пусть не в особо явной форме. Ну типа «эти ваши ООП плохо работают с многоядерными процессорами, даже не буду рассказывать почему, это всем понятно».
0
XsevenBeta
Закончилось вполне закономерно и в духе ммозга. Фрэнк, всё время читавший нашу дискуссию вчера ночью ВНЕЗАПНО решил веерно меня заминусовать, но не хватило силёнок на то, чтобы загнать меня в минус. Народ в этот раз решил не поддаваться стадному чувству, так как не было одобрительного кивка. Минуса зазнайке Вильяму, впрочем тоже никто не поставил. Меж тем вспомнилась одна поговорка, которую я переделал к реалиям мозга:

«Минус — последнее прибежище негодяя»
0
Coven
Выше я писал, что Франкштейн как-то не сильно впечатляет с точки зрения знаний и опыта. Ранее многие выражали желание посмотреть, что же он такое пишет вообще. У меня тоже возникало такое желание, и, кажется, сегодня мы приблизимся к разгадке.

Отчет черных вертолетов.

Франкштейна я никогда специально не вычислял. Не настолько было интересно. Но сегодня Атрон запостил следующее — "… у нашего замечательного специального гостя дедлайн, что лишний раз подтверждает его высокий статус разработчика". Ну, я поржал (что подтверждает-то, что он трудоустроен? лол, действительно высокий статус), но потом подумал — елки, ну речь же про игру наверное, хочется посмотреть что за игра.

Кликнул на профиль Франкштейна на ммозге — там «Евгений, 1985, Санкт-Петербург». Ну ок.

Пошел смотреть Евгениев из Санкт-Петербурга которые еще и программируют. На третьем клике CV:

moikrug.ru/evgeniyshatunov

Почему же это Франкштейн? Ну то есть, профиль подходит под разговоры, но мало ли. Да легко — взгляните как он назвался на Github: FrankStain. Молодец. Желающие могут посмотреть законтрибученный код (я пока не смотрел, но посмотрю, я любопытный).

Где же он работает? Да тоже легко — скролль ниже. Saber Interactive. Питер, ну да.

Вот их сайт:

saber3d.com/

Пишут игры для фейсбучиков и прочего. Пример: «PLAY SLOTOTERRA ON FACEBOOK! Get ready to play High Rollers! The hit social casino SlotoTerra is finally coming to Facebook! The game contains more than 60 slots with a new one released every couple of weeks. All slots are based on original math models...»

(Вау, высокие технологии. И наверное игры исключительно честные. Атрону бы понравились.)

Скоро, видимо, выйдет очередная их нетленка, там и будет понятно над чем Франкштейн работал.
2
Coven
А, ну и вот игра с предыдущего места работы:

warspear-online.com/en/

Довольно стандартная штука, Free + IAP, Андроид / IOS, есть ветка в стиме:

store.steampowered.com/app/326360/Warspear_Online/

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

Короче, все понятно. Еще один программист. Ничего плохого, но никаких особенных звезд ждать не нужно, их там нет. Днем пишет безыскусный пейтувин, вечером рассказывает что вся индустрия дерьмо на ммозге. Пока другие пишут иначе и двигаются вперед.
0
Комментарий отредактирован: 8 февраля 2019, 16:06
Romulas
А ты ожидал звезду? Серьезно?

Программисты обычные люди, ничего особенного. А Франк еще и денег хочет, зачем его ругать?
1
Комментарий отредактирован: 8 февраля 2019, 16:32
Coven
Не ругаю, ругать не за что, хвалить тоже не за что, просто удовлетворил любопытство. Он просто много раз фигурировал как «серьезный разработчик, важный гость» и ведет он себя на ммозге как охрененный авторитет, отсюда и интерес насколько он авторитет. Нинасколько.
0
Комментарий отредактирован: 8 февраля 2019, 16:38 (2 раза)
Coven
Я, наверное, плохо написал — «Еще один программист» — прозвучало уничижительно. Я имел в виду — «Обычный программист, без каких-либо особенных достижений.» Я не то, чтобы прямо ожидал, но процентов на 30 думал, что он может быть какой-то крутой инди или там, полуглавный дизайнер в Playrix или WG (WoT). То есть, еще раз — ничего плохого в том, что он обычный нет. Просто некоторые сообщения на ммозге теперь читать смешно, там такие глубины опыта прямо подразумеваются, а их нет по факту.
0
Комментарий отредактирован: 8 февраля 2019, 16:59 (2 раза)
Coven
В интересах справедливости.

У сабер3д есть свой game engine, оказывается. Я пропустил. В Питере делают только часть, и скорее всего далеко не основную, но все равно. Если Франк работает над частью этого game engine, пусть и не основной, пусть не главным, пусть только год, это уже хотя бы что-то.

Посмотрим, что выйдет быстрее — новая игра на мобилки или какая-то штука с engine'ом.

Все, черные вертолеты летят на стоянку.
0
XsevenBeta
Ты в videogames зайди на сайте:

Saber has a more diverse skillset than almost any game developer on the planet. We work on massive AAA first person shooters – most notably under the Halo and Quake banners – but we also create sports, fighting, mobile titles and more. Notably, we also have a specialty in casino games for mobile, online, and real-world Vegas style machines.

Там WORLD WAR Z, THE WITCHER 3: WILD HUNT 4K, Armored warfare и.т.п.

Ну вот, например: saber3d.com/portfolio_page/world-war-z/
0
Coven
Это я видел, вот тут тоже список: en.wikipedia.org/wiki/Saber_Interactive
0