Автор оригинальной статьи — Jetrel. Художник, который активно участвует в проектах Open Source игр. Несколько лет назад он был «арт-директором» игры Battle for Wesnoth. Кроме того, он сделал львиную долю арта для Frogatto and friends и продолжает работать над этой игрой.
Оригинальный текст и перевод лицензированы на условиях CC-BY.
На данный момент, Battle for Wesnoth насчитывает 109 различных художников, так что Jetrel знает о чем говорит.
![image](https://habrastorage.org/r/w780q1/getpro/habr/post_images/8cc/8cf/e60/8cc8cfe60c2e6a1741f8840c36e4e040.jpg)
Источник.
Помимо основного тезиса, в статье еще будут затронуты следующие вопросы:
Вряд ли автор будет регистрироваться на хабре самостоятельно. Но если у вас есть вопросы, я могу переадресовать их. Я сам получил согласие на перевод через канал 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
[прим.перев. В оригинале была эта ссылка, оставляю как есть]
Даже лучшие из художников могут допускать технические ошибки в своих работах. Например конечности из неожиданных мест; странные и неестественные позы (потому что в реальности они были бы невозможны или утомительны); перспектива, от которой Эшер вертелся бы в гробу. Эти моменты не зависят от изобразительного стиля или «глубоких мыслей» художника. Промахи случаются потому что исполнитель облажался. Изображение с подобными ошибками выглядит глупо даже для автора, как только он осознает свою ошибку. Люди должны держать при себе свое мнение о стиле, но здоровая критика настоящих ошибок пойдет на пользу всем. Такая атмосфера сделает ваш арт лучше. Это позволит вашим артистам расти. У творцов сложится впечатление, что к ним относятся справедливо. Это поощряет здоровый диалог о создании арта для вашего проекта и намного лучше, чем однострочные неестественные комментарии «отличная работа» при обсуждении свежих предложений.
Суммируя все вышесказанное, относитесь к творцам (как художникам, так и композиторам) как к вашим равным партнерам на поприще разработки игр и однажды вы найдете такого же маньяка, как и вы сами. Чтобы успешно найти его, вам нужно понимать откуда он может прийти и вложить свой труд, чтобы обеспечить ему доступную среду. Помните, если человек предложил вашей игре несколько человеко-лет труда, то она будет настолько же «его», насколько она «ваша».
В общем, при разработке Battle for Wesnoth мы придерживались принципа «выбор — зло». Каждая опция в программе это дополнительная ветвь кода, которую вам нужно поддерживать. Общее количество ветвей кода растет по законам комбинаторики. Как следствие, увеличивается сложность тестирования и «невидимая стоимость» разработки.
Так что вы на самом деле не хотите принимать множество направлений арта и делать для каждого из них флаг отключения в опциях.
Выбор — зло не только потому что он увеличивает стоимость поддержки софта. Выбор помешает достичь вам единого и последовательного стиля арта в вашем проекте, потому что ваш посыл новым контрибуторам будет «зашумлен».
В конечном итоге, если в вашей игре готова только часть арта, то само ее существование лучше всего донесет мысль «мне нужна помощь», чтобы получить дополнительный арт. Но важная часть просьбы о помощи в том, чтобы детально описать что именно вам нужно для соответствия общему стилю игры.
Штука в том, что одного только существования достаточно. «Одна картинка стоит тысячи слов». Если у вас есть множество примеров, то вам не придется тратить кучу времени на объяснение вашего видения с помощью текста. Но если эти примеры противоречат друг другу, то вы будете страдать. Существование двух радикально отличающихся стилей арта помешает вам объяснить какой из стилей вы сами хотели бы получить в итоге.
В обычной ситуации вам не нужно вмешиваться в развитие визуального стиля. Арт будет говорить сам за себя. Но если дать возможность выбора, то вам внезапно придется заниматься микроменеджментом и самостоятельно направлять каждого участника.
Другая интерпретация. Возможно вы предлагаете сценарий, когда у вас появился участник, способный взять на себя всю работу с артом, но при этом вы, как автор, будете прятать этот арт от себя.
Возможно я покажусь невежливым, но это безумие.
Да и на самом деле это почти невозможно — вы будете тратить огромные силы для того, чтобы обеспечить корректное отображение этого самого арта как в начале, так и в течение всей жизни проекта.
Такое уже случалось в «dwarf fortress» и в нескольких других проектах. В конечном счете, «внешним художникам» пришлось вкладывать огромные усилия в программирование для того, чтобы добиться их работу вообще можно было увидеть.
Моды на Dwarf fortress работают с прямым доступом к оперативной памяти работающего процесса. Там нет прямого API для моддинга или чего-то подобного Но даже если бы он был, кому то все равно пришлось бы написать код для обеспечения работы слоя отображения графики. Сложность такой задачи сопоставима с разработкой собственной игры.
… Я имею в виду, что не нужно равняться на игры, где такой подход «выиграл в лотерею». Это очень опасный пример, потому что он успешен не за счет «хороших практик разработки», а за счет невероятной удачи.
Смотреть на практики разработки популярных и успешных игр — в целом плохая идея. Даже термин есть — «ошибка выжившего». Вместо того, чтобы говорить «ничего себе, они смогли выжить несмотря на плохие решения» — люди говорят «они добились успеха ПОТОМУ ЧТО сделали такие решения».
Ну например в dwarf fortress не используется система контроля версий. Ни git, ни svn, ни даже cvs. Они просто копируют папку в директории.
Что бы там ни было, я лично считаю, что работать с художником, стиль которого вам не нравится, это противоестественное неуважение к себе. Можно «притворяться», быть вежливым и принимать арт, даже если он вам не нравится, но вам будет намного проще отказаться и быть честным с собой.
Это очень напоминает женитьбу/замужество.
P.S. Если вы нашли опечатки или ошибки в тексте, пожалуйста, сообщите мне. Это можно сделать выделив часть текста и нажав «Ctrl / ⌘ + Enter», если у вас есть Ctrl / ⌘, либо через личные сообщения. Если же оба варианта недоступны, напишите об ошибках в комментариях. Спасибо!
Оригинальный текст и перевод лицензированы на условиях CC-BY.
На данный момент, Battle for Wesnoth насчитывает 109 различных художников, так что Jetrel знает о чем говорит.
![image](https://habrastorage.org/getpro/habr/post_images/8cc/8cf/e60/8cc8cfe60c2e6a1741f8840c36e4e040.jpg)
Источник.
Помимо основного тезиса, в статье еще будут затронуты следующие вопросы:
- Чем нас привлекает программирование?
- В чем опасность графических редакторов для модов?
- Как долго ждут творцы?
- Нужно ли художнику знать программирование?
- Сколько нужно художников по концепт-арту?
- Как найти того единственного?
- Что делать со звездами?
Вряд ли автор будет регистрироваться на хабре самостоятельно. Но если у вас есть вопросы, я могу переадресовать их. Я сам получил согласие на перевод через канал 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
Почему бы не сделать графику переключаемой? Тогда он не будет видеть стиль, который не нравится.
Оригинальный текст
In general, a major software-development principle we held when working on Wesnoth (and which I think is generally pretty smart) was: «options are bad».
Every option in a software program is another code path you have to support, and the combinatorial complexity of multiple code paths, when it comes to testing and all sorts of similar «hidden costs» of doing development, really adds up.
So you don't want to accept multiple kinds of art, and gate each kind of art behind an option flag which users (or the author) can turn off.
It's bad because not only does it increase the support costs of the software, but it also makes it harder to achieve the goal of having a single, coherent art set for the project you're on, because it severely «confuses» your messaging to new contributors.
Ultimately if you've got a game that only has a portion of the art done, your game's mere existence is the best «help wanted» ad for getting additional art. But a critical part of asking for this additional art is a detailed description of what you need to do to match the game's current style.
The thing is — just existing is usually enough. «A picture is worth a thousand words». You don't need to waste a huge amount of time explaining what you want if you've got a large body of examples.
But — if these examples severely contradict themselves, then you're in for a lot of pain. If you've got two radically different visual styles, it's very difficult to explain to new contributors «which style» you'd like the game to actually be in.
All of a sudden you go from a hands-off, «no work for the project lead» matter of just letting the art speak for itself, to having to be deeply, personally involved in steering people.
— Alternate interpretation: It's possible you're suggesting a scenario in which someone's offering to make art for the game in a single, coherent style, and this is a situation where the entire game would get art, but you, the developer, would hide the art from yourself.
At the risk of being impolite, this is absolutely insane.
Which is to say it's «impossible» — there's an enormous time-cost and ongoing maintenance cost of time you'll have to spend getting the graphics to display correctly, and making sure they continue to display correctly as development continues and features get added and removed.
In almost all cases where this has happened (dwarf fortress being a key example), these external «artists» essentially did an enormous amount of programming to make their work viable.
Dwarf fortress mods operate by literally doing direct memory access and looking at the RAM state of the app as it runs, since there's no mod API or anything, but even if you did have a mod API — somebody has to pay the enormous cost of writing the code to get the entire graphics-drawing layer working correctly, and the complexity of doing this is usually equivalent to writing an entire game of its own.
… I mean — any game where this succeeds has essentially «won the lottery», and is an extremely dangerous target to imitate the habits of, because it succeeded not due to «good developer practices» but because it got insanely lucky.
A dangerous thing when looking at the dev practices of other games, especially «popular, successful» games, is a phenomenon called «survivor bias».
Survivor bias is when someone looks at the behavior of a very successful thing, and instead of thinking «oh, they were really successful, so they were able to survive even though they made a bad choice» — instead, one assumes «oh, they succeeded BECAUSE they made this choice».
For example — dwarf fortress doesn't use source control. :ohno:
Not git, not svn, not cvs. They just have old copies of the code in folders.
Anyways, when it comes to art — I honestly personally believe you're going to be entering a really toxic/awkward relationship if you're working with an artist who's producing a style you really don't like.
You can try to «fake» it by being nice, and accepting the art even though you don't like it, but you're far better off just living without and being honest.
It's a lot like getting married. :neutral_face:
Every option in a software program is another code path you have to support, and the combinatorial complexity of multiple code paths, when it comes to testing and all sorts of similar «hidden costs» of doing development, really adds up.
So you don't want to accept multiple kinds of art, and gate each kind of art behind an option flag which users (or the author) can turn off.
It's bad because not only does it increase the support costs of the software, but it also makes it harder to achieve the goal of having a single, coherent art set for the project you're on, because it severely «confuses» your messaging to new contributors.
Ultimately if you've got a game that only has a portion of the art done, your game's mere existence is the best «help wanted» ad for getting additional art. But a critical part of asking for this additional art is a detailed description of what you need to do to match the game's current style.
The thing is — just existing is usually enough. «A picture is worth a thousand words». You don't need to waste a huge amount of time explaining what you want if you've got a large body of examples.
But — if these examples severely contradict themselves, then you're in for a lot of pain. If you've got two radically different visual styles, it's very difficult to explain to new contributors «which style» you'd like the game to actually be in.
All of a sudden you go from a hands-off, «no work for the project lead» matter of just letting the art speak for itself, to having to be deeply, personally involved in steering people.
— Alternate interpretation: It's possible you're suggesting a scenario in which someone's offering to make art for the game in a single, coherent style, and this is a situation where the entire game would get art, but you, the developer, would hide the art from yourself.
At the risk of being impolite, this is absolutely insane.
Which is to say it's «impossible» — there's an enormous time-cost and ongoing maintenance cost of time you'll have to spend getting the graphics to display correctly, and making sure they continue to display correctly as development continues and features get added and removed.
In almost all cases where this has happened (dwarf fortress being a key example), these external «artists» essentially did an enormous amount of programming to make their work viable.
Dwarf fortress mods operate by literally doing direct memory access and looking at the RAM state of the app as it runs, since there's no mod API or anything, but even if you did have a mod API — somebody has to pay the enormous cost of writing the code to get the entire graphics-drawing layer working correctly, and the complexity of doing this is usually equivalent to writing an entire game of its own.
… I mean — any game where this succeeds has essentially «won the lottery», and is an extremely dangerous target to imitate the habits of, because it succeeded not due to «good developer practices» but because it got insanely lucky.
A dangerous thing when looking at the dev practices of other games, especially «popular, successful» games, is a phenomenon called «survivor bias».
Survivor bias is when someone looks at the behavior of a very successful thing, and instead of thinking «oh, they were really successful, so they were able to survive even though they made a bad choice» — instead, one assumes «oh, they succeeded BECAUSE they made this choice».
For example — dwarf fortress doesn't use source control. :ohno:
Not git, not svn, not cvs. They just have old copies of the code in folders.
Anyways, when it comes to art — I honestly personally believe you're going to be entering a really toxic/awkward relationship if you're working with an artist who's producing a style you really don't like.
You can try to «fake» it by being nice, and accepting the art even though you don't like it, but you're far better off just living without and being honest.
It's a lot like getting married. :neutral_face:
В общем, при разработке Battle for Wesnoth мы придерживались принципа «выбор — зло». Каждая опция в программе это дополнительная ветвь кода, которую вам нужно поддерживать. Общее количество ветвей кода растет по законам комбинаторики. Как следствие, увеличивается сложность тестирования и «невидимая стоимость» разработки.
Так что вы на самом деле не хотите принимать множество направлений арта и делать для каждого из них флаг отключения в опциях.
Выбор — зло не только потому что он увеличивает стоимость поддержки софта. Выбор помешает достичь вам единого и последовательного стиля арта в вашем проекте, потому что ваш посыл новым контрибуторам будет «зашумлен».
В конечном итоге, если в вашей игре готова только часть арта, то само ее существование лучше всего донесет мысль «мне нужна помощь», чтобы получить дополнительный арт. Но важная часть просьбы о помощи в том, чтобы детально описать что именно вам нужно для соответствия общему стилю игры.
Штука в том, что одного только существования достаточно. «Одна картинка стоит тысячи слов». Если у вас есть множество примеров, то вам не придется тратить кучу времени на объяснение вашего видения с помощью текста. Но если эти примеры противоречат друг другу, то вы будете страдать. Существование двух радикально отличающихся стилей арта помешает вам объяснить какой из стилей вы сами хотели бы получить в итоге.
В обычной ситуации вам не нужно вмешиваться в развитие визуального стиля. Арт будет говорить сам за себя. Но если дать возможность выбора, то вам внезапно придется заниматься микроменеджментом и самостоятельно направлять каждого участника.
Другая интерпретация. Возможно вы предлагаете сценарий, когда у вас появился участник, способный взять на себя всю работу с артом, но при этом вы, как автор, будете прятать этот арт от себя.
Возможно я покажусь невежливым, но это безумие.
Да и на самом деле это почти невозможно — вы будете тратить огромные силы для того, чтобы обеспечить корректное отображение этого самого арта как в начале, так и в течение всей жизни проекта.
Такое уже случалось в «dwarf fortress» и в нескольких других проектах. В конечном счете, «внешним художникам» пришлось вкладывать огромные усилия в программирование для того, чтобы добиться их работу вообще можно было увидеть.
Моды на Dwarf fortress работают с прямым доступом к оперативной памяти работающего процесса. Там нет прямого API для моддинга или чего-то подобного Но даже если бы он был, кому то все равно пришлось бы написать код для обеспечения работы слоя отображения графики. Сложность такой задачи сопоставима с разработкой собственной игры.
… Я имею в виду, что не нужно равняться на игры, где такой подход «выиграл в лотерею». Это очень опасный пример, потому что он успешен не за счет «хороших практик разработки», а за счет невероятной удачи.
Смотреть на практики разработки популярных и успешных игр — в целом плохая идея. Даже термин есть — «ошибка выжившего». Вместо того, чтобы говорить «ничего себе, они смогли выжить несмотря на плохие решения» — люди говорят «они добились успеха ПОТОМУ ЧТО сделали такие решения».
Ну например в dwarf fortress не используется система контроля версий. Ни git, ни svn, ни даже cvs. Они просто копируют папку в директории.
Что бы там ни было, я лично считаю, что работать с художником, стиль которого вам не нравится, это противоестественное неуважение к себе. Можно «притворяться», быть вежливым и принимать арт, даже если он вам не нравится, но вам будет намного проще отказаться и быть честным с собой.
Это очень напоминает женитьбу/замужество.
P.S. Если вы нашли опечатки или ошибки в тексте, пожалуйста, сообщите мне. Это можно сделать выделив часть текста и нажав «Ctrl / ⌘ + Enter», если у вас есть Ctrl / ⌘, либо через личные сообщения. Если же оба варианта недоступны, напишите об ошибках в комментариях. Спасибо!
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Как вам качество перевода?
29.27% А это перевод?12
58.54% Хорошо24
7.32% Гуглопереводчик3
4.88% Гуглопереводчик был бы лучше2
Проголосовал 41 пользователь. Воздержались 14 пользователей.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Приходилось ли вам участвовать в open-source проектах?
11.63% Я мейнтейнер крупного проекта5
16.28% Я сам себе мейнтейнер7
37.21% Я только предлагал коммиты16
34.88% Я только пользуюсь15
Проголосовали 43 пользователя. Воздержались 15 пользователей.