Привлечение и удержание художников в open-source играх

Автор оригинальной статьи — Jetrel. Художник, который активно участвует в проектах Open Source игр. Несколько лет назад он был «арт-директором» игры Battle for Wesnoth. Кроме того, он сделал львиную долю арта для Frogatto and friends и продолжает работать над этой игрой.

Оригинальный текст и перевод лицензированы на условиях CC-BY.

На данный момент, Battle for Wesnoth насчитывает 109 различных художников, так что Jetrel знает о чем говорит.


Источник.

Помимо основного тезиса, в статье еще будут затронуты следующие вопросы:

• Чем нас привлекает программирование?
• В чем опасность графических редакторов для модов?
• Как долго ждут творцы?
• Нужно ли художнику знать программирование?
• Сколько нужно художников по концепт-арту?
• Как найти того единственного?
• Что делать со звездами?

Вряд ли автор будет регистрироваться на хабре самостоятельно. Но если у вас есть вопросы, я могу переадресовать их. Я сам получил согласие на перевод через канал Frogatto в дискорде.

Далее будет изложено от первого лица.

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

В момент написания (2009 год), в open-source игровых проектах стереотипно существовал избыток программистов и болезненная нехватка художников. Следовательно, это негативно отражалось на комьюнити. Многие наши игры стыдно показать публике. Они привлекательны только для небольшого множества игроков, для которых внешний вид не важен.

Open-source и инди комьюнити занимают позицию «зелен виноград». Другими словами, хороший внешний вид считается отличительным признаком плохих коммерческих игр. Иногда это доходит до легкой враждебности к хорошей графике. Эта статья не будет пропагандировать важность графики. Научно доказано, что большинство людей — визуалы, а значит ценят красивую картинку в играх. Если вы не готовы принять это, вы сознательно загоняете себя в маленькое гетто. Я не могу помочь вам с этим — эта статья предполагает, что вы хотите сделать такую игру, которой будет наслаждаться максимально широкая публика.

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

Хорошая новость в том, что у Open Source по умолчанию есть иммунитет к подобным проблемам.

Сама суть open-source значит, что open-source игра станет популярной только если в нее интересно играть. Именно поэтому люди и будут тратить время на арт для интересных игр. Кроме того, Open-source не имеет строгих дедлайнов или бюджета, поэтому они могут позволить себе на досуге переделать все необходимое, чтобы игра стала интересной. Чтобы понравиться художникам и получить новый арт, вы должны беречь существующий арт до завершения рефакторинга и формирования фундамента из интересных игровых механик.

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

Сделайте интересную игру

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

Используйте распространенные форматы файлов

Другой важный фактор в том, чтобы использовать наиболее открытые форматы. Под открытостью я не имею в виду термины open-source, скорее речь о «форматах, с которыми обычно работают люди». Зачастую это одно и то же, но не всегда. Очень важно, чтобы люди могли полностью готовить арт для игры без специальных инструментов и при этом могли зайти в игру и сразу увидеть результат в действии, без дополнительной помощи. Как правило, это подразумевает использование форматов вроде OGG или PNG, а не самопальных форматов, как во многих играх 90х. Если вы напишете свой собственный формат музыки наподобие MOD или свой собственный способ хранения битовых масок, то ни у кого не будет инструментов для создания арта в вашей игре. Им придется продираться через ваш инструментарий. Это отгонит большой процент возможных участников, потому что большинство людей «пробуют воду» в создании арта путем простой возни со своей копией игры.

В дополнение к вышесказанному, большинство творцов, заинтересованных в разработке игры, на самом деле владеют навыками моддинга. Ваш движок должен поддерживать моды. У них должна быть возможность создать свои собственные уровни, существ и персонажей. Творцов очень привлекает та часть игры, которая позволяет рассказать свою собственную историю. Вы можете добиться этого с помощью отличного редактора или доступного формата хранения всего подряд в виде текста. Большинство творцов в геймдеве достаточно хорошо владеют компьютером, чтобы редактировать текстовые файлы с данными. Игровой редактор будет еще лучше, потому что он может быть использован практически всеми, но на его реализацию требуется очень много времени. Особенно для такого контента, который редко меняется. Опасность святого Грааля изготовления GUI «для всего» в том, что некоторые части игры все равно будут требовать программирования, не важно как их представлять. Поэтому их лучше программировать традиционными способами. Если вы попытаетесь сделать для них gui, то придете к графическому языку программирования, но скорее всего вы просто навлечете катастрофу.

Мгновенное удовлетворение это ваш друг

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

Мгновенное удовлетворение важно для поддержки мотивации творцов. Если творец начинает готовить шедевр для вас, очень важно чтобы результат работы попал в мастер как можно быстрее. Захватывающе видеть, что твоя работа была признана и включена в официальный билд игры. Точно так же и наоборот, убийственно знать, что твоя работа никому не нужна. Творцы редко понимают как трудно программирование, а значит посчитают, что вы не используете их работу потому что не рады ей. Это равнозначно для арта и кода, творцы не могут читать ваши мысли. Если вы запланировали посмотреть это через несколько недель, то никто об этом не узнает. Если вы немедленно не займетесь работой с предложенным кодом, артом или музыкой, то они больше не будут вам что-либо делать. Это не проблема для разового багфикса. Но это дурной знак для тех, кто присылает вам первый образец и готов наполнить вашу игру моделями и графикой. Вам нужно следовать за ними, вы должны работать с ними и поддерживать их заинтересованность. Почти все участники, способные наполнить вашу игру, будут потеряны, если вы не вернетесь к ним через неделю или пару дней. Это один из аргументов в пользу политики RERO (release early, release often).

Художники не компилируют

Возможно это неочевидно, но художники не могут компилировать вашу игру. Если официальные релизы реже чем раз в месяц или два, вам следует обеспечить их релизами. Им нельзя застревать в гетто устаревших версий, потому что они выпадут из потока новшеств в вашей игре. Они тоже часть команды и им важно видеть, как их работа сочетается с новыми изменениями. Также очень важно выпускать релизы для их платформы. Я знаю, что у Linux-программистов не всегда есть возможность скомпилировать под Mac (например). Но если кто-то предлагает шедевр, нужно обеспечить ему релиз. Потому что если они не могут играть в твою игру, то они и не заинтересованы в помощи тебе. На практике, вам нужна общедоступная готовая сборка под Mac и под Windows. Точка. Если у вас такой не будет, то 99% пользователей компьютера не будут играть в вашу игру, а значит не будут заинтересованы в создании шедевров для нее. Mac в отношении художников и музыкантов особенно важен, потому что их там непропорционально много.

Докажи, что игра успешна

Творцы категорически не одобряют планов в духе «бесконечность не предел». Подобных прожектов пруд пруди. Большинство видеоигр (как open-source, так и коммерческих) это недобитые неудачники, и большинство творцов, заинтересованных в создании арта для видеоигры, уже пробовали участвовать минимум в одном проекте и тяжело переживали его падение. Вся их работа пропала. Проблема в том, что у творцов нет возможности оценить навыки разработчиков. Вот другие разработчики могут глянуть наискосок на код и решить, надежен он или ужасен, однако у большинства творцов есть только сарафанное радио. Они понятия не имеют, есть ли у вас то, что нужно. Чтобы показать серьезность своих намерений, вам нужно закончить базовый геймплей. Как в «Возвращении джедая», Звезда смерти не должна быть завершена, но обязана быть «полностью функциональна».

В целом это хорошая практика геймдизайна. Сначала вы делаете быстрый прототип и как можно скорее формируете основные функциональные элементы игры. Стоит упомянуть, что я видел бесчисленное количество игровых проектов, которые позиционируются как стартовая площадка для Архитектурных Астронавтов. Если вы хотите сфокусироваться только на разработке ИИ и вам нет дела до завершения игры, то не приманивайте потенциальных участников своими заявлениями о «разработке игры». Не сможешь ответить за свои слова, в надежде что все получится само собой? Гори в аду. Люди, которые создают шедевры — действительно серьезны, иначе они бы тратили время на свое портфолио на галереях вроде DeviantArt. Заявляй о том, что делаешь игру только если твоя первичная цель — завершение качественной и безупречной игры.
Don’t Let Architecture Astronauts Scare You
[прим.перев. В оригинале была эта ссылка, оставляю как есть]

Художникам нужны полномочия на графику

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

Поиск художника для игрового проекта похож на поиск невесты. Как и в семейной жизни, хочется избежать женитьбы (или замужества) на художнике, который делает что-то ненавистное вам. Если вы создаете видеоигру и к вам пришел художник, который предлагает работу в таком стиле, который вам абсолютно не по вкусу (например аниме), возможно вам нужно отказать ему. Лучше всего сделать это заранее. Последнее, что вам нужно — бомба замедленного действия. Это тяжелый выбор. Возможно у вас не будет арта, если вы откажете этому человеку, но лучше быть верным себе и решить этот вопрос. Может быть вам стоит потерпеть стиль, который вас незначительно бесит.

Вам нужен ведущий художник

Одна из очевидных проблем может возникнуть когда несколько художников в команде тянут воз в разные стороны. Что делать в этом случае? Ровно то же самое, что и с кодом. Выберите того, кто делает наилучшую работу (и имеет серьезные намерения довести проект до конца) и позвольте ему быть диктатором. Если он действительно делает львиную долю работы, то вам не страшно отпугнуть людей, которые не согласны с ним. Таким образом, все желающие поучаствовать, будут приносить вам аккуратные шедевры единого стиля и качества. Другими словами, вам нужно прикинуться коммерческой игрой. Доверие власти и полномочий кому-то также позитивно влияет на мотивацию этого творца. Обычно они будут работать усерднее и оправдывать ваше доверие по части графики.

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

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

У вас может быть более одного ведущего художника. В случае, если арт делится на очевидные категории, которые требуют различного набора навыков, то художники естественным образом поделятся на группы по способностям. Множество искусных иллюстраторов совершенно некомпетентны в 3D-моделировании (и наоборот).

Вам не нужны художники по концепт-арту

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

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

Художники развиваются в атмосфере технической критики

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

How Art Can Be Good
[прим.перев. В оригинале была эта ссылка, оставляю как есть]

Даже лучшие из художников могут допускать технические ошибки в своих работах. Например конечности из неожиданных мест; странные и неестественные позы (потому что в реальности они были бы невозможны или утомительны); перспектива, от которой Эшер вертелся бы в гробу. Эти моменты не зависят от изобразительного стиля или «глубоких мыслей» художника. Промахи случаются потому что исполнитель облажался. Изображение с подобными ошибками выглядит глупо даже для автора, как только он осознает свою ошибку. Люди должны держать при себе свое мнение о стиле, но здоровая критика настоящих ошибок пойдет на пользу всем. Такая атмосфера сделает ваш арт лучше. Это позволит вашим артистам расти. У творцов сложится впечатление, что к ним относятся справедливо. Это поощряет здоровый диалог о создании арта для вашего проекта и намного лучше, чем однострочные неестественные комментарии «отличная работа» при обсуждении свежих предложений.

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

Q&A

Почему бы не сделать графику переключаемой? Тогда он не будет видеть стиль, который не нравится.

В общем, при разработке Battle for Wesnoth мы придерживались принципа «выбор — зло». Каждая опция в программе это дополнительная ветвь кода, которую вам нужно поддерживать. Общее количество ветвей кода растет по законам комбинаторики. Как следствие, увеличивается сложность тестирования и «невидимая стоимость» разработки.
Так что вы на самом деле не хотите принимать множество направлений арта и делать для каждого из них флаг отключения в опциях.
Выбор — зло не только потому что он увеличивает стоимость поддержки софта. Выбор помешает достичь вам единого и последовательного стиля арта в вашем проекте, потому что ваш посыл новым контрибуторам будет «зашумлен».
В конечном итоге, если в вашей игре готова только часть арта, то само ее существование лучше всего донесет мысль «мне нужна помощь», чтобы получить дополнительный арт. Но важная часть просьбы о помощи в том, чтобы детально описать что именно вам нужно для соответствия общему стилю игры.

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

Другая интерпретация. Возможно вы предлагаете сценарий, когда у вас появился участник, способный взять на себя всю работу с артом, но при этом вы, как автор, будете прятать этот арт от себя.
Возможно я покажусь невежливым, но это безумие.
Да и на самом деле это почти невозможно — вы будете тратить огромные силы для того, чтобы обеспечить корректное отображение этого самого арта как в начале, так и в течение всей жизни проекта.
Такое уже случалось в «dwarf fortress» и в нескольких других проектах. В конечном счете, «внешним художникам» пришлось вкладывать огромные усилия в программирование для того, чтобы добиться их работу вообще можно было увидеть.
Моды на Dwarf fortress работают с прямым доступом к оперативной памяти работающего процесса. Там нет прямого API для моддинга или чего-то подобного Но даже если бы он был, кому то все равно пришлось бы написать код для обеспечения работы слоя отображения графики. Сложность такой задачи сопоставима с разработкой собственной игры.
… Я имею в виду, что не нужно равняться на игры, где такой подход «выиграл в лотерею». Это очень опасный пример, потому что он успешен не за счет «хороших практик разработки», а за счет невероятной удачи.
Смотреть на практики разработки популярных и успешных игр — в целом плохая идея. Даже термин есть — «ошибка выжившего». Вместо того, чтобы говорить «ничего себе, они смогли выжить несмотря на плохие решения» — люди говорят «они добились успеха ПОТОМУ ЧТО сделали такие решения».
Ну например в dwarf fortress не используется система контроля версий. Ни git, ни svn, ни даже cvs. Они просто копируют папку в директории.

Что бы там ни было, я лично считаю, что работать с художником, стиль которого вам не нравится, это противоестественное неуважение к себе. Можно «притворяться», быть вежливым и принимать арт, даже если он вам не нравится, но вам будет намного проще отказаться и быть честным с собой.
Это очень напоминает женитьбу/замужество.

P.S. Если вы нашли опечатки или ошибки в тексте, пожалуйста, сообщите мне. Это можно сделать выделив часть текста и нажав «Ctrl / ⌘ + Enter», если у вас есть Ctrl / ⌘, либо через личные сообщения. Если же оба варианта недоступны, напишите об ошибках в комментариях. Спасибо!