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

Найти опытного разработчика, готового заниматься кураторством, можно или в специализированных пабликах по разработке видеоигр в «ВК», или в телеграм-каналах, посвященных той же теме, – например, «Ступени Геймдева». Также никто не мешает вам лично обратиться к уважаемому вами разработчику с просьбой уделить вам время за пару золотых. Кто-то, быть может, согласится и бесплатно, если проект его заинтересует и если вы будете доносить свои просьбы понятно и вежливо.

Основная цель таких консультаций – не критика. Критиковать некомпетентного специалиста нет никакого смысла. В детстве у меня не получалось вырезать снежинки из бумаги: я просто ее мял и гнул, отчаянно вопрошая учительницу, что не так с моими ножницами. Она нервно отвечала мне, что я «неправильно их держу», и на этом замолкала. Помогал ли мне этот ответ резать бумагу? Нет – я продолжал ее мять. Я всё еще понятия не имел, каким именно образом мне нужно держать ножницы. Я был уверен, что это инструменты у меня кривые, бумага сделана из резины, а учительница – дура. Я никоим образом не ставил под сомнение собственные навыки и в итоге, к слову, до сих пор ненавижу что-то вырезать.

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

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

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

Расширение компетенций – это необходимая составляющая в улучшении навыков и приобретении опыта.

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

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

Наблюдательность

Второй способ избавиться от эффекта Даннинга – Крюгера заключается в том, чтобы более внимательно анализировать поведение разработчиков при работе в команде. Я достаточно долго подрабатывал фриланс-художником в различных игровых проектах, но ни один из них так и не увидел свет. У меня заказывали графику на сумму, превышавшую мой тогдашний годовой доход на основной работе. Однако проекты всё равно откладывались авторами в долгий ящик из-за массы ошибок: кому-то в итоге не хватало денег – ошибка планирования давала о себе знать; кто-то, уже оплатив всю графику, понимал, что его проект – это сущее недоразумение и окупиться он никогда не сможет (качественная игра будет хороша и увлекательна даже на заглушках и кубиках, а графика и прочие элементы лишь расширят тот спектр эмоций, которые игрок от нее получит).

Без внимательного анализа того опыта, который я приобрел в ходе работы фрилансером, я едва ли довел бы до ума Reflection of Mine. Я обрастал компетенциями, анализируя последствия решений, принятых игровыми дизайнерами и программистами. Мой низкий уровень вовлеченности в эти проекты помогал смотреть на них гораздо трезвее, чем на продукт, разрабатываемый в собственной команде. Мне было по большому счету всё равно, выстрелит игра или нет, и страсть к этим проектам не затмевала мне глаза – я относился к ним с равнодушием и скепсисом.

Нарабатывая опыт, наибольшее внимание уделяйте расширению своих компетенций. Хороший результат в любом деле всегда достигается комбинацией навыков и знаний. Если вырабатывать только навык, постоянно делая одно и то же и не обращаясь за подсказками к более опытным специалистам, то никакого прогресса вам не видать. Ровно как не видать его и при бездумном накапливании знаний без их дальнейшего использования. Если вы узнали что-то новое в ходе сотрудничества с другими людьми – тут же применяйте это знание, преобразуя его в навык. Но с чего же начать?

Ошибка 3

Брезговать вареньем

Опыт без работодателя

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