---

«Разгон» — авторский формат моего ТГК, в котором я НЕ стремлюсь давать исчерпывающие ответы или окончательные выводы. Это способ структурирования собственных мыслей вслух, упорядочивания и поиска живого диалога. Приятного прочтения! ;)

---

Предисловие

Я ненавижу идею соло-разработки. Не просто не люблю презираю как явление, которое почему-то принято романтизировать. Не сами игры, ведь я, как и вы, искренне восхищаюсь такими кейсами, как Animal Well, Stardew Valley, Papers, Please и многие другие. Нам всем нужна путеводная звезда. Но я ненавижу то, как этот путь “одиночки-страдальца” нормализуют и даже стандартизируют, превращая исключение из правил в какой-то достижимый идеал.

И ведь что странно: сколько бы я ни читал историй этих самых “одиночек”, там всегда красной нитью сквозит тема благодарности друзьям, семье, первым тестерам, людям к которым они обращались за помощью. Но мы почему-то переворачивая страницу запоминаем лишь то, что кто-то один, оказывается, страдал.

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

«А какая тогда альтернатива?»

Не бояться открывать рот и говорить простое слово: "помоги"! Не бояться признать свою некомпетентность. Не бояться развивать в себе навык общения и заводить новые знакомства. Я хочу сделать это кристально ясным, вот главный смысл всего этого разгона в одном предложении: УМОЛЯЮ, перестаньте думать, что просить о помощи — это слабость, что команда — это костыль, а настоящий творец должен страдать в одиночестве. ЭТО ЛОЖЬ!

(И сразу ремарка для тех, кто думает, что я сейчас буду полторы тысячи слов обсасывать одну эту мысль: НЕТ. Дальше будут вполне практические выводы, подтверждение которым я и хочу найти вместе с вами.)

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

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

Мастерство — это совсем не производное гения или таланта. Это производное времени и усердия, приложенных к той или иной области знания. — Роберт Грин (с)

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

Вместе мы попытаемся честно ответить на вопросы: как принять в себе тот факт, что ты можешь быть отличным гейм-дизайнером, но ужасным программистом (и наоборот)? Как превратить свою слабость не в комплекс, а в точку для подключения другого человека? И как именно социальный интеллект, а не технические навыки, становится той силой, что позволяет из двух разных взглядов на мир собрать один работающий проект?

Что там за дверью?

Чтобы наш диалог не превратился в абстрактную философию, давайте сразу договоримся о терминах. Любая игра, от инди-жемчужины до ААА-блокбастера, стоит на двух абсолютно равнозначных столпах: Замысел (что и, самое главное, зачем мы делаем) и Воплощение (как именно мы это делаем и для кого). Уберите хотя бы один и вся конструкция неизбежно рухнет.

И когда одна из этих частей отсутствует, мы получаем два классических типа провальных проектов.

• Первый — Замысел без Воплощения. Мы назовём его ”теоретическая игра”.

• Второй — Воплощение без Замысла. Это ”техническое демо”.

“Теоретическая игра” может быть гениальной. Она может быть расписана в диздоке, в питчдоке или презентации, с идеальными циклами и глубоким смыслом. Но для игрока её не существует. Её ценность равна нулю. Это мёртвый проект, который так и не смог родиться.

“Техническое демо”, в свою очередь, может быть безупречным. Работающие механики, оптимизированный код, стабильная работа. Но в него… неинтересно играть. В нём нет цели, нет увлекательного опыта, нет души. Это тоже мёртвый проект, просто он родился зомби — он двигается, но он не живой.

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

«Звучит интересно / выглядит прикольно. Возвращайтесь, когда будет игра».

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

• Ошибка “теоретической игры” — это игнорирование технических ограничений, переусложнение систем на бумаге и полное отсутствие петли обратной связи.

• Ошибка “технического демо” — это отсутствие внятного игрового цикла, игнорирование мотивации игрока и фундаментальное непонимание цели всего проекта.

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

Эта дихотомия “Замысла” и “Воплощения” пронизывает всю индустрию. За первым стоят гейм-дизайнеры, художники, сценаристы. За вторым — программисты, маркетологи, QA-инженеры. Каждый раз, когда эти два лагеря перестают разговаривать, игра начинает гнить изнутри.

Теперь, когда мы согласны с правилами игры, пора посмотреть, как на практике выглядит это самое рукопожатие между гейм-дизайнером и программистом.

Взгляд гейм-дизайнера

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

Именно поэтому жёсткое определение всегда будет ощущаться неполным. Но в ежедневной работе, в беседах с командой и попытках объяснить самому себе, “что ты, чёрт возьми, вообще делаешь?” нужна какая-то опора. Формулировка, которая помогает ежедневно чувствовать почву под ногами звучит примерно так:

Гейм-дизайн — это проектирование системы взаимосвязанных правил и механик, которая создаёт для игрока пространство осмысленного выбора и, как следствие, уникальный интерактивный опыт.

Давать такие формулировки дело необлагодарное и даже пошлое. Любое определение неизбежно сужает и упрощает. Но чтобы вы поняли, как именно гейм-дизайнер смотрит на игру, и чем этот взгляд отличается от взгляда программиста, нам нужна эта отправная точка.

Давайте проведём мысленный эксперимент. Представьте, что мне как гейм-дизайнеру не нужно думать о том, как игра будет выглядеть, как она будет звучать и будет ли она вообще оптимизирована. (Ни в коем случае не делайте так в реальной жизни, это вредно для здоровья проекта!) Так что останется сухом остатке? Каков тот самый скелет, который я проектирую?

В этом ядре останется непрерывный диалог между Игроком и Системой. Это и есть моя отправная точка. Я не думаю о них по отдельности. Создавая в своей голове ментальный образ игры, я обязан представить, как эти две сущности будут взаимодействовать, отвечать друг другу и менять друг друга в процессе. Кто этот человек по ту сторону экрана? Зачем он вообще запустил нашу игру, какую цель он преследует? И как наша система правил и механик будет реагировать на каждое его действие, чтобы подталкивать его дальше?

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

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

Теперь перейдём к сути. Мы с Женей по очереди ответим на три вопроса, которые лежат в основе нашего взаимодействия.

Какую "правду" я отстаиваю в проекте?

Моя правда — это игрок.

Моя задача дать игроку не то, что он просит, а то чего он действительно хочет, даже если он сам ещё не может этого сформулировать. Быть защитником игрока значит быть главным адвокатом его опыта внутри нашего проекта. Я тот человек в команде, который постоянно задает неудобные вопросы: “А игроку будет это понятно?”, “А зачем ему это делать?”, “А какой кайф он от этого получит?”.

Отсюда и берется “игровой опыт” как понятие, которое, к слову, можно разложить на три составляющие:

• Читаемость. Игрок должен понимать правила мира, в котором он находиться. Ему не нужно читать диздок, чтобы понять, что лава — обжигает, а высокая стенка — непреодолима. Моя задача следить, чтобы моя работа через призму работы всей команды, от художников до программистов, складывалась в единую, понятную для игрока систему фидбека.

• Осмысленность. Любое действие игрока должно иметь значение. Выбор становиться осмысленным только тогда, когда у него есть цена и последствия. Придержать карту для ключевой комбинации или разыграть её сейчас? Улучшить текущее снаряжение или копить ресурсы на что-то принципиально новое? Каждый такой выбор — это маленький кирпичик, из которого игрок строит свою уникальную историю.

• Ценность. Система должна честно реагировать на действия игрока. Если он принял умное решение — он должен почувствовать себя умным. Если он совершил ошибку — он должен понять, почему потерпел неудачу. Этот основной механизм за которым я и слежу.

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

Как моя работа упрощает жизнь остальной команде?

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

Для этого существует такой инструмент как документация.

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

Каждый раз, когда ключевые решения принимаются в устном разговоре и нигде не фиксируются, вы закладываете мину замедленного действия, которая обязательно взорвётся спорами о том, “кто и что говорил” или вы просто забудете, что хотели сделать и где зарыта проблема.

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

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

Вместе с этим неотрывно идёт предоставление контекста. Нам нужно переводить дизайнерскую идею на язык наших друзей. Поэтому задача в документации никогда не выглядит как “сделай механику X”. Для программиста она будет дополнена описанием необходимой логики, а для художника её функциональным и визуальным назначением. Когда команда понимает не только что нужно сделать и зачем это игроку, но и видит задачу, сформулированную с учетом их экспертизы, они могут предложить более элегантные и эффективные решения, чем я мог себе представить.

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

Итого: я беру на себя полную ответственность за “что” и “зачем”, чтобы полностью освободить команду для поиска решений в области “как”.

Где заканчивается моя экспертиза и начинается зона ответственности другого?

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

При этом специфика геймдева вынуждает каждого из нас иметь базовые компетенции в смежных областях. Мы создаём один цельный продукт, работая на одном “холсте”. Мой прошлый опыт в коде, арте или звуке существует для того, чтобы полнее понимать общую картину и выстраивать общий язык с командой. Это нормальная часть проф-пригодности, не обязательная, но желательная. Важно просто держать в голове, что мастерства можно добиться, только полностью погрузившись в одну дисциплину.

Моя экспертиза находит своё конкретное выражение в гейм-дизайн документе. Это зафиксированное видение замысла. Когда реализация расходится с этим видением, я прихожу с формулировкой “у нас проблема”. Это точка, где заканчивается моя единоличная работа и начинается диалог. Мы садимся и вместе ищем решение этой общей проблемы, у которой нет конкретного виновника, а есть лишь недопонимание или техническое ограничение.

В этом диалоге я никогда не полезу в код и не стану указывать, как его писать. Мои вопросы всегда направлены на результат: как реализованная механика ощущается, решает ли она поставленную задачу, понятна ли она игроку? Точно так же я ожидаю от программиста вопросов к моему дизайну: достаточно ли чётко описана логика, учтены ли все пограничные случаи? Взгляд каждого из нас должен быть направлен на конечный результат, а не на защиту своей территории.

На этом моя часть заканчивается. Я постарался максимально честно очертить свою позицию и свой взгляд на процесс. А теперь я передаю слово моему другу Жене. Возможно, он выскажется с менее изящным слогом, но честно и откровенно ответит на те же три вопроса со своей колокольни “Воплощения”.

Взгляд программиста

О себе немного. Я Женя. И я тот самый человек, которому кладут руку на плечо и тихо шепчут на ухо:

‭«Мы хотим эту механику‭!»

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

Что значит “думать” для программиста? В первую очередь, это переводить “хотелку” команды на язык движка и логики. В моём случае, весь этот процесс строится на трех простых, но нерушимых правилах.

Вот они:

• Текст — единственный источник правды.

• Если чувствуешь, что на механику уйдёт полгода — обсуждай.

• Сделал не так, как задумывалось — слушай.

Какую "правду" я отстаиваю в проекте?

Моя правда — это долгосрочное здоровье проекта. Я человек, который борется с техническим долгом до того, как он начнёт пожирать время и нервы.

Это означает продумать архитектуру, которая не треснет по швам, когда кто-то придумает новую механику, персонажа, перерисует ассет или добавит новую строчку диалога. Держать, по возможности, код в чистоте и поддерживать актуальность всей системы в целом. Только я отвечаю за чистоту и формирование логики, систем и стабильности. Я стараюсь сделать, чтобы всё работало не “на авось”. Игроку всё равно, насколько элегантен мой код, но ему не всё равно, когда игра вылетает.

Вся эта инженерная честность — это не какая-то высокая философия, это тупой прагматизм. Конечная цель одна — скорость итераций. Когда фундамент прочный, команда может сказать "а давай попробуем вот так", и мы это пробуем, а не похороним идею, потому что "код не позволяет". Никто, кроме меня, в этом коде разбираться не будет, так что я отвечаю за то, чтобы он не превратился в помойку.

Простая причинно-следственная связь. Чистый и предсказуемый код — это быстрые и дешёвые итерации. Запутанный код — это потраченное впустую время, сорванные сроки и похороненные идеи. Мой выбор очевиден.

Как моя работа упрощает жизнь остальной команде?

В любой команде все дороги ведут к программисту. Любая идея, любой ассет, любой звук в конечном итоге проходит через код. Я должен перевести идеи в работающий код, но так, чтобы этот код потом не требовал моего постоянного присутствия. Если команда ждёт меня, чтобы внести простейшее изменение, мы не делаем игру.

Практика простая: всё, что не является ядром логики, должно настраиваться без программиста. Урон, здоровье, скорость, цвета, звуки — всё это должно лежать в таблицах или компонентах, где кто угодно, но не я, может сам это менять. Если для того, чтобы поменять урон с 3 на 4, нужно дёргать меня, я считаю, что провалил свою задачу. Это значит, что я создал не гибкую архитектуру, а зависимость от себя. Я строю среду, в которой каждый может максимально эффективно раскрывать свою роль.

Например: “Как интегрировать карточную систему?”. Добавляем класс карточек, её параметры и готово. “Нам нужно больше гибкости”. Без проблем, проходим новую итерацию переработки, добавляем динамические параметры. “У НАС БУДЕТ N ЭФФЕКТОВ И 400 КАРТ”. Не-про-бле-ма. Согласовываем все эффекты, их взаимодействия и параметры. Новая итерация задачи, дробим на большее количество компонентов и снова дописываем механику. И так далее. Этот процесс повторяем до тех пор, пока результат нас не будет устраивать.

Я обеспечиваю команде уверенность. Когда что-то работает стабильно, предсказуемо и прозрачно, это снижает стресс, делает планирование реальным, а работу осмысленной. Надёжный код — это как прочный пол под ногами: ты не думаешь о нём каждую секунду, но именно он позволяет двигаться вперёд уверенно.

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

Где заканчивается моя экспертиза и начинается зона ответственности другого?

Моя экспертиза — это превращать текст в работающий код. Зона ответственности другого начинается, когда текст (ТЗ) — говно. У меня для этого три красных флага.

1. Что-то не понятно. Если я читаю задачу и не понимаю, как это должно работать — я останавливаюсь. Я не додумываю. Даже маленькая деталь, будь это переменная скорости перемещения или подсчет для статистики, может в будущем взаимодействовать с другой механикой, а та, в свою очередь, с другой и т.д до бесконечности в квадрате. В этом случае нужно поставить задачу на стоп и смело идти обсуждать всплывший вопросик. Это быстрее и дешевле, чем потом всё переписывать.

2. Я сделаю, но через полгода. Если для вас полгода срок допустимый, вопросов к вам нет. Если же все-таки время имеет ценность — надо обсуждать. Но не сразу, сначала стоит прикинуть, разбить на компоненты и попробовать **понять, где основной затык, чтобы обсуждение было более продуктивным. В такие моменты я задаю главный вопрос, который должен задавать любой программист: "То, что мы получим в итоге, действительно стоит этих затрат?". Иногда ответ “да”. Чаще — мы находим решение в десять раз проще.

3. Вы просили, я сделал. Я сделал всё по букве ТЗ. Показываю результат. А коллега говорит: "что-то не то". И это "что-то не то" — может пустить гниль на весь проект. Моя экспертиза в том, чтобы система работала. Его — в том, чтобы она ощущалась правильно. Я не спорю с "ощущениями". Я прошу показать, что именно не так, и мы вместе ищем, какую "крутилку" в коде нужно подправить, чтобы это исправить. Потому что в итоге, только он один держит в голове весь этот адский механизм.

Короче, обсуждайте. Это единственное, что работает. И не стройте иллюзий: крутые игры делают не гении-одиночки, а команды, где люди умеют разговаривать.

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

Итог: Игры строятся не в одиночку, а вместе.

Прежде всего, я хочу сказать спасибо нашему программисту — Жене. За то, что согласился на этот эксперимент, потратил время и честно сформулировал свою позицию. И да, чтобы быть до конца откровенным: я помог ему причесать его мысли, но каждое слово и каждая идея в его части — это его позиция, которую он сам утверждал. Мне важно говорить как есть.

Изначально этот разгон задумывался как текст о социальном интеллекте в работе гейм-дизайнера. О том, как нам важно развивать эмпатию, уметь смотреть на мир глазами игрока, программиста, художника. Но в процессе я понял, что замыкаться на своей профессии — это снова строить стену. Потому что “социальный интеллект” — это не скилл гейм-дизайнера. Это клей всего геймдева. Да что там, любого сложного коллективного творчества.

Я много читаю. Аудиокниги, статьи, постмортемы, да всё, что связано с нашей индустрией. И я, как и вы, сотни раз слышал избитые фразы о важности команды. Но иногда банальность — это просто истина, подтверждённая столько раз, что она набила оскомину. На этом принципе в Valve строятся команды “Т-образных” людей. Об этом говорит Кодзима, когда говорит, что создаёт игры не со “своим видением”, а с “нашим видением” — видением команды. И Сид Мейер который сформулировал эту идею, как мне кажется, лучше всех:

«Разница между талантом другого человека и вашим собственным — это повод для радости, потому что чем дальше вы друг от друга, тем больше вы можете предложить друг другу».

Да господи, выйдите за пределы геймдева, и вы услышите то же самое. Стив Джобс говорил:

«Великие вещи в бизнесе никогда не делаются одним человеком. Они делаются командой»

А Джон Рокфеллер и вовсе считал:

«Умение общаться с людьми — это товар, и я заплачу за него больше, чем за что-либо другое на свете»

ВСЕ говорят нам об этом.

А что делаем мы? Я искренне восхищаюсь каждым, кто в одиночку смог дотащить свою ношу от идеи до релиза. Но я никогда не променяю опыт общих побед и поражений, споров и озарений в команде на тишину и мнимую свободу одиночной разработки. И вам не советую.

Если вы, дочитав до этого момента, горите мечтой о создании своей игры или просто хотите стать частью геймдева, вам придётся быть честным с самим собой. Задайте себе вопрос:

Что из всего этого — ваше?

Проектирование игры на бумаге? Написание кода? Создание арта, звука, истории? Что именно вы готовы изучать и делать годами, чтобы стать в этом мастером? А теперь задайте второй, ещё более сложный вопрос:

А что — не ваше?

Где вы объективно слабы? Где вам неинтересно? Где вы будете тратить в десять раз больше сил, чтобы получить в десять раз худший результат, чем специалист? Признать это — не слабость. Это отправная точка профессионального роста.

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

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

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

И увидимся там, где секретов больше → t.me/slepokNT ?