«здесь каждый третий — геймдизайнер; заводы в стране стоят»
(c) Тангар Игроглаз
Продолжаю дискуссию в комментах к прошлому видосу, хочу коснуться этой темы:
Val:
Гейм дизайнер важнее программистов. Программисты это простые строители, а гейм дизайнер это архитектор.
Ну во-первых, не строители, а инженеры..
Во-вторых, я подобные рассуждения комментировал неоднократно, но видимо надо замутить отдельное видео на тему (поэтому, спасибо Валу за наводку). В паре слов, можно описать битву «программист vs геймдизайнер» такой аналогией:
Представим себе, что геймдизайн — это математика; а сами игры — ее прикладное применение (которое создают инженеры-программисты). Так вот, математика, как наука ушла вперед на десятки (сотни?) лет, по сравнению со своей прикладной реализацией (это уже вне аналогии — это ситуация в реальном мире).
Соответственно, когда математики (геймдизайнеры) обсуждают какую-то офигенно интересную механику (геймплея или там объекты неевклидовой метрики, без разницы) — это не значит, что ее смогут реализовать программисты или там инженеры на заводе. Эти две области познания — геймдизайн и программирование — находятся в разных измерениях, в разных качествах.
Обсуждение этой проблемы усложняется еще тем, что каждый третий школьник — гениальный геймдизайнер (ему так кажется по крайней мере). Хотя излишне самоуверенных кодеров тоже хватает.
Это и приводит нас к тому, что мы имеем в жанре MMORPG.
Прочитайте вот это https://queue.acm.org/detail.cfm?id=971590
Очень заметна всеобщая тенденция к созданию сложностей на пустом месте. Стандартом является имитация бурной деятельности для удобного освоения бюджетов выделенных для реализации искусственно переусложнённых проектов. Это называется работа ради работы. Экстенсивный путь. А таланты, способные к упрощению, изобретениям, созданию нетривиальных решений, генерации уникальных алгоритмических идей — вытесняются на второй план. Талантливые интроверты часто вообще затаптываются. Программист стал восприниматься как бездушный зомби-исполнитель, винтик в системе игровой индустрии управляемой маркетологами. Поэтому пришёл застой. Здравый смысл и тяга к настоящему развитию (а не показушному) остались в андерграунде.
Обратите внимание на дату публикации статьи — 2004. Это год последних гастролей инженерного олдскула. В статье даже пытались сравнивать с тем как было раньше, просто тогда 15 лет назад ещё помнили времена инженеров. А сейчас в мейнстриме подобные вопросы даже не обсуждаются.
А на самом деле пообсуждать ещё есть чего, в качестве примера приведу одно из выживших направлений инженерного андерграунда — демосцену, симбиоз программирования и искусства.
Здесь вы можете наблюдать результат работы программы размером 4 килобайта:
https://www.youtube.com/watch?v=jB0vBmiTr6o
Это не шутка. Вот это всё, включая процедурную генерацию фотореалистичного ландшафта, текстур и качественной музыки занимает всего лишь 4 тысячи символов. Реализовано с использованием алгоритма шума перлина и рейтрейсинга.
Данный экстремальный пример «разворачивания вселенной» из нескольких формул интересен в качестве демонстрации нижней границы возможностей по упрощению решений, если изначально использовать инженерный подход.
Более свежий пример размером в 8 килобайт (продолжение предыдущей темы):
youtube.com/watch?v=rZI6MQmmTYY
А вот «танчики» размером в 8 килобайт:
youtube.com/watch?v=RNxY0SuwuEA
Слабо зажравшимся паблишерам приблизиться хоть на миллиметр к данному виду инженерного искусства?
Здесь кроме ландшафта с текстурами вы ещё заметите множество объектов и трёхмерные эффекты, которые каким-то чудом вместились в такой крошечный объём памяти. Всё это достигается благодаря алгоритмам, которыми владеют инженеры-программисты. Смысл в том, что процедурная генерация — это не просто хитрый способ упаковки, это ещё и способ свободно манипулировать сгенерированным результатом, потому что по сути всё состоит из формул, параметры которых можно произвольным образом изменять. Таким образом достигается и простота и максимальная гибкость одновременно.
Например, заметьте, как в первом примере (Elevated), на второй минуте снег плавно превращается в зелёную траву. Это делается всего лишь с помощью изменения нескольких аргументов функций. А теперь представьте себе, что точно такие же фокусы можно использовать и в алгоритмах геймплея. Представляете насколько богаче станет экспириенс игрока? Насколько это будет выглядеть принципиально по иному в сравнении с тысячами однотипных игр с картонными декорациями сделанных на юнити. Подобных прецедентов пока крайне мало.
Вот в чём состоит роль инженера-программиста — оживлять геймплей. Геймдизайнер на такое не способен. Геймдизайнер в современном понимании — это теоретик, очень далёкий от практической реализации, его роль представляет намного меньше ценности чем сам кодинг.
к такому комментарию и добавить ничего не хочется. спасибо за видео. Размер имеет значение и данном случае чем он меньше, тем лучше
Ещё мне понравилось как Тангар недавно описал суть программирования в своём стриме TomeNET (про перемешанные нитки): https://youtu.be/E4pPDifrf-A?t=6972
На этом же акцентировали внимание и олдскульные инженеры:
«Управление сложностью — квинтэссенция программирования» B. Kernighan
«Простота — ключ к надежности» E. Dijkstra
«Стоимость добавления нового функционала, это не только затраты на написание кода. Цена также включает в себя препятствия для дальнейшего расширения… Трюк в том, что следует подбирать функции, которые не конфликтуют друг с другом.» John Carmack