Геймдизайнер VS программист

«здесь каждый третий — геймдизайнер; заводы в стране стоят»
(c) Тангар Игроглаз

Продолжаю дискуссию в комментах к прошлому видосу, хочу коснуться этой темы:

Val:
Гейм дизайнер важнее программистов. Программисты это простые строители, а гейм дизайнер это архитектор.

Ну во-первых, не строители, а инженеры..

Во-вторых, я подобные рассуждения комментировал неоднократно, но видимо надо замутить отдельное видео на тему (поэтому, спасибо Валу за наводку). В паре слов, можно описать битву «программист vs геймдизайнер» такой аналогией:

Представим себе, что геймдизайн — это математика; а сами игры — ее прикладное применение (которое создают инженеры-программисты). Так вот, математика, как наука ушла вперед на десятки (сотни?) лет, по сравнению со своей прикладной реализацией (это уже вне аналогии — это ситуация в реальном мире).

Соответственно, когда математики (геймдизайнеры) обсуждают какую-то офигенно интересную механику (геймплея или там объекты неевклидовой метрики, без разницы) — это не значит, что ее смогут реализовать программисты или там инженеры на заводе. Эти две области познания — геймдизайн и программирование — находятся в разных измерениях, в разных качествах.

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

Это и приводит нас к тому, что мы имеем в жанре MMORPG.

Запись опубликована в рубрике Аналитика онлайн игр. Добавьте в закладки постоянную ссылку.

4 комментария на «Геймдизайнер VS программист»

  1. Val говорит:

    Прочитайте вот это https://queue.acm.org/detail.cfm?id=971590

    • Witcher говорит:

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

      Обратите внимание на дату публикации статьи — 2004. Это год последних гастролей инженерного олдскула. В статье даже пытались сравнивать с тем как было раньше, просто тогда 15 лет назад ещё помнили времена инженеров. А сейчас в мейнстриме подобные вопросы даже не обсуждаются.

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

      Здесь вы можете наблюдать результат работы программы размером 4 килобайта:

      https://www.youtube.com/watch?v=jB0vBmiTr6o

      Это не шутка. Вот это всё, включая процедурную генерацию фотореалистичного ландшафта, текстур и качественной музыки занимает всего лишь 4 тысячи символов. Реализовано с использованием алгоритма шума перлина и рейтрейсинга.

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

      Более свежий пример размером в 8 килобайт (продолжение предыдущей темы):
      youtube.com/watch?v=rZI6MQmmTYY

      А вот «танчики» размером в 8 килобайт:
      youtube.com/watch?v=RNxY0SuwuEA

      Слабо зажравшимся паблишерам приблизиться хоть на миллиметр к данному виду инженерного искусства?

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

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

      Вот в чём состоит роль инженера-программиста — оживлять геймплей. Геймдизайнер на такое не способен. Геймдизайнер в современном понимании — это теоретик, очень далёкий от практической реализации, его роль представляет намного меньше ценности чем сам кодинг.

      • repeat говорит:

        к такому комментарию и добавить ничего не хочется. спасибо за видео. Размер имеет значение и данном случае чем он меньше, тем лучше

  2. Witcher говорит:

    Ещё мне понравилось как Тангар недавно описал суть программирования в своём стриме TomeNET (про перемешанные нитки): https://youtu.be/E4pPDifrf-A?t=6972

    На этом же акцентировали внимание и олдскульные инженеры:

    «Управление сложностью — квинтэссенция программирования» B. Kernighan

    «Простота — ключ к надежности» E. Dijkstra

    «Стоимость добавления нового функционала, это не только затраты на написание кода. Цена также включает в себя препятствия для дальнейшего расширения… Трюк в том, что следует подбирать функции, которые не конфликтуют друг с другом.» John Carmack

Добавить комментарий

🇬🇧 Attention! Comments with URLs/email are not allowed.
🇷🇺 Комментарии со ссылками/email удаляются автоматически.