Как сделать игру и не выгореть? Нужно ли для этого продавать машину? В чём секрет инди-хитов и самых успешных разработчиков?
На последний вопрос у меня нет ответа, так как я пока не выпустил ни одного хита. А вот с остальным мы попробуем разобраться!
В предыдущем выпуске мы подробно разобрали стадию Подготовки: научились генерировать идеи, определились с тем, что мы хотим явить миру и под каким соусом. Дело за малым - разработать игру, продать миллионными тиражами и купаться в лучах славы! Разработка
При должном уровне умений, хороший прототип вполне может собрать один человек. Максимум - пара из программиста и гейм-дизайнера. Когда же вы определились с тем, что именно предстоит делать, курс намечен - без команды вам уже не обойтись (если, конечно, вы не соло-разработчик, на все руки мастер). Подключаются художники, программисты вспоминают, как писать нормальный код, гейм-дизайнеры - как шить одежду для считать баланс/писать квесты.
MVP
Первый этап Разработки - это создание Minimum Viable Product (MVP), или Минимально Жизнеспособного Продукта.
В классической формулировке MVP это игра, в которой есть всё, но по минимуму: один персонаж, один уровень, одна пушка, один противник. Можно делать всё, что и в полной версии, просто почти нет контента.
Однако по моему мнению, MVP очень индивидуальная сущность, которая зависит как от игры, так и от ваших личных критериев. Я считаю, что главная задача этой сборки - формирование правильного впечатления от будущей игры. Используя актуальный сленг, MVP должна передавать вайб игры.
Этапы разработки на примере кабанчиков.
Поэтому каждый создатель сам определяет количество контента и продолжительность своего MVP. Обычно это от 3 до 15 минут игрового процесса, без учёта репитативного геймплея (рогалики, процедурные головоломки).
Princess Hunter - игра, над которой мы сейчас работаем - сейчас находится на этом этапе. Я очень сильно задрал планку MVP, по сути приравняв его к демо или прологу. Мне хочется собрать 4 полноценных игровых уровня, реализовать 5-7 врагов со своими колодами, 4 вариативных квеста, двух персонажей для построения отношений и даже финального босса. Это неправильный подход - так лучше не делать. Далее станет понятно, почему. Советы на этот этап:
- Лучше всего начать этап MVP с написания ГДД (гейм-дизайн Документации). Как её писать - тема для отдельного поста и холиваров, но продолжайте следовать принципу “от общего - к частному”. Вместо огромного дока на 400 страниц делайте отдельные мини-доки на каждую фичу или механику, сосредоточьтесь на самом основном.
- ГДД поможет лучше понять вам и команде что делать, а программисту ещё и как.
-Обсудите ГДД с командой и составьте хотя бы примерный роадмап. Он даст понимание сроков, в идеале - дедлайна. Кроме того, это позволит отрезать слишком тяжёлые для этого этапа фичи.
- Не переживайте, что в процессе создания MVP роадмап будет корректироваться, и не забывайте это делать. Определение темпов разработки каждого спеца и команды целиком - одна из важных задач этапа.
- Продумывайте архитектуру вашего проекта. Лучше всего делать его модульным: даже если сейчас вы какие-то механики реализуете костыльно/не оптимально, в дальнейшем их можно будет отрефакторить или переписать.
- На этапе создания MVP допускается локальный говнокод, но сам подход, по сравнению с прототипированием, становится фундаментально иным: теперь вы пишите то, с чем в будущем предстоит работать. В перфекционизм впадать тоже не стоит: время все ещё приоритетнее, чем качество. Ищите компромиссы - это приходит с опытом.
- Это же справедливо и для остального: не старайтесь сделать идеальный баланс или вылизанный арт. Успеется.
- Жизненно важно начать комментировать код, а то и вести минимальную техническую документацию. Может показаться, что сейчас это не нужно и просто трата времени - но в будущем это позволит сэкономить месяцы, а то и вообще спасти проект.
- Организуйте хранилище ресурсов для проекта с возможностью пошарить доступ на членов команды. Например, на гугл-диске. Чем логичнее и структурированнее будет система папок, тем проще будет в будущем. Ни в коем случае не превращайте хранилище в файлопомойку.
- Храните не только финальный арт, но и скетчи, промежуточные варианты. В будущем они могут вам пригодиться. Например, для написания такой статьи.
- Не пренебрегайте бэкапами!
Сбор фидбека
Итак, у вас готов Минимально Жизнеспособный Продукт - маленькая, но всамделишная игра! Это настоящая веха и отличный повод отпраздновать, но расслабляться ещё рано. По сути, всё только начинается…
Обычно те, кто планирует найти издателя, уже на этом этапе начинают рассылать архив с игрой. Это продиктовано как нетерпением, так и усталостью. Однако я советую повременить и перед любыми следующими шагами, будь то поиск партнёра, масштабирование или суицид, провести сбор фидбека.
Покажите игру незнакомым людям. Не маме, трём друзьям и жене/мужу, а совершенно сторонней целевой аудитории, которая не побоится сказать правду в глаза. Это может быть тематический форум, чат или даже закупка покупка рекламы. Соберите отзывы хотя бы нескольких десятков игроков и проанализируйте их.
Сбор фидбека очень важен, потому что позволяет понять, в нужном ли направлении вы двигаетесь, и будет ли игра нужна кому-то ещё, кроме вас и команды. Нет, если проект вы видите исключительно как сублимацию и авторское видение - можете смело пропускать этот этап. Однако я лично считаю, что игра без игрока, как и театр без зрителя, не имеет смысла. Не нужно менять курс целиком, но внести в него коррективы, пока не поздно, бывает крайне полезно.
… в которую вложил душу, 2 год жизни и вырученные с продажи почки деньги.
Не воспринимайте фидбек близко к сердцу и смотрите не на один отзыв, а на впечатление группы людей в целом. Если одному человеку механика не нравится, а девять даже не упоминают её, проблема скорее всего, не в механике, а в человеке. Если одной половине участников плейтеста идея по вкусу, а второй - нет, это тоже не причина все перекраивать. Однако когда в каждом отзыве люди жалуются на ваше концептуальное управление при помощи крутилки громкости на колонках - повод задуматься...
Помимо основной задачи - выявить самые очевидные проблемы пока ещё не поздно внести серьёзные - у плейтестов MVP есть и другая, не менее важная. Команда в целом и вы в частности должны получить обратную связь, позитивную подпитку и осознание: то, что вы делаете кому-то нужно и интересно. Чем дольше вы работаете над игрой, тем сильнее она начинает казаться вам каким-то чудовищным нагромождением бездарно реализованных механик. Квесты и диалоги после сотого прочтения не вызывают ничего, кроме омерзения, игровой процесс видится скучным, безыдейным и слишком простым. Это совершенно нормальное выгорание и замыливание взгляда, которое неизбежно приходит к любому разработчику, делающего игру более полугода. Эти мысли посещали и создателя Stardew Valley, и разработчиков Ведьмака, и автора этих строк. Единственный способ справиться с этим - получить позитивный, непредвзятый взгляд со стороны.
Но нужно быть готовым к тому, что фидбек этот будет не абсолютно восторженным.
Корректура
Как и любые творцы, игроделы очень болезненно относятся к критике. Не факт, что явив MVP миру, вы получите в ответ только лучи добра и чистую радугу обожания. В лучшем из наиболее вероятных исходов отзывы будут сдержанно-позитивные: в целом неплохо, но вот это так себе, это как-то странно работает, а вот это я не понял. Может быть и пожестче: пресновато, скучновато, зачем оно нужно, когда есть [Title_Name]?
В этом случае у вас два варианта действий: заплакать как эмо-девочка и больше никогда не заниматься этой неблагодарной работой, или проглотить подступающую к горлу обидку, вычленить из фидбека рациональное зерно, сформулировать гипотезы, внести правки в проект и показать его снова, желательно уже другим людям. Это действительно сложный, в первую очередь эмоционально, процесс, чем-то напоминающий знаменитую сцену из Большого Лебовски.
Разраб снова и снова получает фидбек от пользователя.
Однако если вы найдёте в себе силы и ресурсы не только стоически выносить мнение от игроков, но и стараться сделать игру лучше, это действительно пойдёт ей на пользу.Советы:
- Слушайте игроков, но не идите у них на поводу. Вам важны симптомы, а не их диагноз. “Игра слишком короткая” - симптом. “Добавьте босса в конце а ещё противников побольше, и чтобы корованы” - диагноз диванного эксперта.
- Стройте гипотезы и проверяйте их, а не стреляйте наобум. Помните, что никто не знает вашу игру так же хорошо, как вы.
- Старайтесь вычленять из фидбека важное и отбрасывать второстепенное. Ищите закономерности. Представьте, что вы - механик, который по звуку работы двигателя пытается определить, нет ли внутри поломок.
- Старайтесь вычленять из фидбека важное и отбрасывать второстепенное. Ищите закономерности. Представьте, что вы - механик, который по звуку работы двигателя пытается определить, нет ли внутри поломок.
- Определите, какого именно фидбека вы хотите добиться,чтобы понять, когда можно будет остановится и двинуться дальше. Помните: лучшее - враг хорошего.
Маркетинг
Окей, у вас на руках MVP, в который приятно играть и не стыдно показывать. Кроме того, вы уже лучше представляете, сколько времени требуется на отрисовку, программирование, диалоги, квесты и всё остальное. Что дальше?
Вариант первый: посчитав трудозатраты на создание игры, вы понимаете, что в свободное время и на энтузиазме будете пилить её лет 5-7, если не случится форс-мажор. И/или трезво оцениваете свои нулевые способности в маркетинге и понимаете, что даже если хватит сил довести игру до конца, про неё никто не узнает, ведь выпуск проекта без плана по продвижению сейчас равносилен торжественному спуску кирпича на воду. Ко дну он пойдёт сразу же, как покинет заботливые руки создателя.
Забавный факт: бетонные суда реально существуют. Хороший пример того, что при умении поплывёт что угодно!
Вывод - вам нужен инвестор/издатель. Не будем сейчас вдаваться в тонкости различия между ними, благо что есть много классных команд, которые помогут и с деньгами, и с продвижением… если проект многообещающий и классный.
Именно поэтому выше я советовал заняться отладкой MVP, а не сразу рассылать его всем издателям из гугла. Как говорят мудрые волки из пацанских пабликов, первое впечатление можно оставить только первый раз. А если оно будет не очень, то второе, скорее всего, и не случится.
Советы по налаживанию контакта с издателем:
- Будьте настойчивыми, но не навязчивыми. Загруженность у многих крупных издателей такова, что ваше письмо может запросто затеряться среди сотен других, ежедневно падающих им на почту. Однако если вы получили отказ, не стоит писать снова или сталкерить сотрудников на конференциях.
- Если у вас за плечами нет нескольких успешных проектов, а в паспорте не написано “Кодзима”, на стадии идеи с вами никто общаться не будет, какой бы гениальной она ни казалась. Но играбельный MVP - уже очень весомый аргумент в пользу того, чтобы на вас обратили внимание.
- Де-юро опытные издатели могут рассмотреть алмаз неогранённый даже в самом грубом прототипе. Де-факто, чем более отполированную версию вы пришлёте, тем выше будут ваши шансы на успех. Однако помните, “отполированную” - не значит длинную!
- Из предыдущего пункта можно сделать неверный вывод, что в идеале издателю нужно прислать уже готовую игру. На самом деле нет: продвижение игр занимает много времени и обычно начинается за год до релиза. К тому же издатель с высоты своего опыта может дать очень ценные советы по разработке, реализовать которые на поздних стадиях будет невозможно.
- Заранее подготовьте ответы на следующие вопросы: описание целевой аудитории, успешные недавние похожие проекты (или убедительные доказательства того, что игра создаст/возродит свою нишу), примерный роадмап разработки, бюджет на разработку, который вам требуется и производный от него бёрнрейт команды (сколько стоит разработка в месяц, включая зарплаты, софт, аренд офиса, если он есть и т.д.).
- Старайтесь искать издателя, у которого есть похожие проекты и успешные кампании. Маловероятно, что специализирующийся на спортивных симуляторах издатель добьётся больших успехов, взявшись за JRPG.
Вариант второй: оценка ресурсов команды показывает, что вы вполне потянете производство самостоятельно. К тому же, у вас есть какие-то веские основания полагать, что игра выстрелит и без помощи издателя: например, вы сами успешный блогер-летсплейщик с огромной аудиторией, которая только и ждёт вашу игру. Или ваш дед застолбил рекламный щит на горе Рашмор
Однако даже если вы решили взять на себя не только разработку, но и продвижение игры, начинать стоит как можно раньше, но не позднее MVP. Формирование комьюнити вокруг игры и сбор вишлистов - процесс очень долгий, но очень критичный. К сожалению, здесь мне нечем особо поделиться в плане опыта, этот путь мы только начали осваивать. Но даже осознание его важности уже даст вам преимущество.
Сложность маркетинга ещё и в том, что он идёт параллельно процессу разработки, поэтому если вы планируете заниматься им самостоятельно - вы отжираете значительную часть времени от создания самого проекта. В среднем это занимает от 20 до 50% времени выполняющего функции маркетолога/комьюнити менеджера и художника, но в отдельные моменты с порывами до 146%. Не думайте, что можете отделаться 10 минутами в неделю!
Однако вернёмся к разработке. Так или иначе, с издателем или без, после минимально жизнеспособной версии вы переходите к самой долгому этапу - Масштабированию.
Масштабирование
Теперь ваша задача - нарастить на скелете MVP мясо контента. Сделать из пробника полноценную игру. Вы уже понимаете, как она будет выглядеть, играться, осталось просто нарисовать, написать и озвучить это дело.
Этот этап - самый рискованный в плане выгорания, потому что долгий и относительно рутинный. К тому же, архитектура уже заложена, и теперь вы сильнее ограничены в создании новых механик и выборе технических решений. Многие классные задумки, которые придут вам на этом этапе, будет придётся отложить до лучших времён или другого проекта.
Однако если на прошлых шагах вы все сделали правильно, у вас есть читабельный и прокомментированный код (у нас, например, с этим проблемы), чёткая цель впереди и дорожная карта, которая поможет до неё добраться. А если удалось ангажировать издателя - то ещё и деньги на разработку.
Перед тем, как начать масштабирование, очень полезно формализовать все требования к проекту: технические ограничения, целевое железо, на котором должна нормально идти игра, формат и разрешение графических ассетов, звуков и музыки. Это позволит вам:
- Оптимизировать ресурсы, сделать разработку более предсказуемой. Художнику не придётся ресайзить сто раз свои картинки, а верстальщик не вскроется от того, что у всех предметов в инвентаре размер +-20 пикселей.
- Поставить производство контента на поток без постоянного поиска в логах и просмотра свойств изображения в проекте.
- Избежать недопонимания между соратниками и сократить количество поводов для конфликта.
- Быстро расширить команду, если появятся возможность и потребность. Не отвлекать ради этого надолго других участников. Чтобы ввести человека в курс дела, достаточно будет скинуть ему док и несколько референсов для примера.
- Не менее быстро найти замену тому, кто отвалился по какой-то причине.
Гейм-дизанер, наконец-таки, может приступать к созданию подробной ГДД, из которой в процессе родятся отдельные ТЗ. Приоритезируйте фичи и составьте план, по которому разработка не будет стопориться из-за отставания кода, арта или гейм-дизайна.
Единого универсального формата ГДД не существует - хороший гейм-дизайнер выстраивает его в зависимости от проекта и команды. Но есть несколько универсальных советов.
Не постесняюсь повторить - задача ГД не написать много, а написать понятно. Меньше всего художники и программисты хотят читать километровые простыни. Пишите ёмко, коротко, используйте кросс-ссылки в духе википедии. Не забывайте, что создаёте технический, а не художественный текст! Избегайте подробных повторов: если элемент работает аналогично уже реализованному или описанному выше, не стоит копипастить. Достаточно упомянуть это и сослаться на нужный кусок текста, при надобности сопроводив списком отличий.
Не бойтесь фичекатить (то есть, отказываться от каких-то задумок) в пользу ускорения процесса разработки или производства более важных штук. Лучше хорошая выпущенная игра без возможности менять причёску главному герою, чем идеальный, но не выпущенный симулятор парикмахера.
Обязательно нужно формализовать разработку, разбить её на задачи, расставить им приоритеты. В идеале это лучше сделать ещё на этапе прототипирования, но если MVP за счёт малого количества контента ещё можно собрать спонтанно, то полноценный проект уже очень трудно. И от масштаба проекта проблемы будут расти кратно.
Это нудно, но очень важно, потому что иначе вы утоните в хаосе и запутаетесь в том, что было сделано, что предстоит, а от чего давно отказались. Чем больше людей в команде, тем животрепещущей вопрос менеджерской работы, но таск-трекингом пользуются даже опытные соло-разработчики.
Кто бы ни взял на себя продвижение - вы, сын маминой подруги или какой-нибудь HypeTrain - заложите в разработку время и на создание промо-материалов. Даже если это будет компиляция будущего игрового контента, её всё равно нужно собрать, сверстать, подогнать под формат и т.д. Не стоит полностью перетягивать одеяло с разработки на маркетинг, но минимум 3 часа в неделю кто-то в команде будет этим заниматься.
Релиз
Итак, месяцы или даже годы разработки позади. Вам и самим не верится, но игра, в целом, готова. Нет, в ней всё ещё есть, что допилить или улучшить, да и четвёртую локацию хотелось бы добавить, но… вы же помните, да? Лучшее - враг хорошего. В какой-то момент необходимо остановиться и явить игру людям.
Естественно, лучше так не делать, если в игре есть известные критические баги. То, что пойдёт в релиз, должно быть оттестировано: нужно быть уверенным, что большинство пользователей сможет дойти до конца без проблем.
Не стремитесь закрыть все существующие баги, особенно если они носят чисто забавный характер (это может даже завирусить игру*) или являются глитчами, то есть дают игроку какое-то неожиданное преимущество. Ни один человек не жаловался на то, что из-за странного бага в битве с финальным боссом отхилил не 100, а 1000 хп, и победил - а вот обратная ситуация может привести к возгоранию кресла!
--
*У многих возникает вопрос - а не стоит ли специально добавлять подобные баги в игру? Что ж, это каждый решает для себя сам. Это паттерн на грани тёмного, но всё зависит от того, насколько часто и в лоб вы это делаете. Чаще всего баг настоящий, разработчики про него знают, но решили не исправлять, а оставить. Яркий пример - ограбление торговца в скайриме путём надевания ему на голову ведра.
Пример из Princess Hunter: из-за неправильных настроек анимации перемещения герой, вместо того, чтобы бегать по полянкам, превратился в Тасманского Дьявола. Я её уже показывал до этого.
В итоге, как и советовали реакторчане, мы решили сделать из этого бага фичу - если герой переусердствует с зельями, то будет крутится как волчок :)
Когда вы подойдёте к релизу, у вас должна быть сформирована фан-база, пропорциональная вашим ожиданиям. Если вы релизитесь в Steam, перед запуском игры у вас должно быть 7-9 000 вишлистов, иначе игра почти наверняка потонет в потоке новинок и не будет видна никому. Помимо того, что вишлисты - это потенциальные покупатели (хотя не стоит рассчитывать на конверсию более 10-15%), их количество на релизе влияет, насколько сам Steam будет показывать игру прочим пользователем.
Поэтому, если вы хотите поддержать разработчика, но при этом не планируете покупать игру (вы принципиальный пират или просто жанр не ваш) - всё равно добавляйте игру в виши, это даст буст проекту на старте. Вам это ничего не стоит, а человеку - реальная помощь. Например, нашу игру! Именно поэтому, как я говорил ранее, страницу в Steam желательно завести примерно за год до релиза - и планомерно собирать виши, работая с аудиторией. Ну, или делегировав это кому-то.Перед тем, как нажать кнопку “опубликовать”, выспитесь, запаситесь энергетиками и убедитесь, что все ключевые члены команды, особенно программисты, на связи. Первые сутки после релиза вам предстоит постоянно мониторить отзывы и статистику на предмет багов и крашей. Нужно быть готовым пересобрать, супер-быстро протестировать и перезалить билд игры, пнуть саппорт, если проблема на их стороне. Это - самое напряжное и стрессовое, но и самое важное время, потому что второго релиза у вас уже не будет. Согласитесь, очень обидно потратить пару лет на разработку и словить на старте дикий хейт из-за того, что игра не запускается… или даже не качается из-за локального сбоя серверов стима.
Будьте сильными. Дежурьте посменно. Если в первые сутки игроки не столкнулись с какими-то фундаментальными проблемами, можно слегка выдохнуть. Но расслабляться рано: первую неделю после релиза за игрой нужен глаз да глаз, потому что критичный баг может оказаться в конце игры. Возможно, засада будет крыться не в коде, а в цифрах: уровень, который ваши тестеры проходят с закрытыми глазами, не могут осилить 99% игроков. В этом случае нужно быть готовыми выпускать и быстрые баланс-патчи. Однако не спешите с выводами и собирайте достаточно статистики, чтобы принимать такие решения: самые громкие игроки могут создать впечатление, что их большинство, но это не всегда соответствует истине.
Ваше состояние через 12-14 часов релиза.
Обязательно стримьте свою же игру в первую неделю (или дольше) прямо на Steam - это поднимает шансы на успех и привлекает внимание.
Помните, в самом начале я писал, что у меня нет рецепта 100% хита? Это так, но напоследок я хотел бы поделиться несколькими соображениями, которые, на мой взгляд, увеличивают шансы игры на успех.
- Картинка важна. Исследования показывают, что у пользователя два ключевых фактора, определяющих желание купить: арт и цена. Классный сюжет и офигенные механики он сможет заценить только как поиграет. Это не значит, что на них не стоит делать упор, но не пренебрегайте визуальной составляющей. Она не обязательно должна быть фантастической, но как минимум - приятной, в идеале - выделяющейся.
- Вытекающий из прошлого пункта вывод - не скупитесь на трейлер. Это видео должно быть не просто “мхвм мы тута игру сдмделали вот короче”, а быть максимально крутым и драйвовым. Это концентрация всего самого офигенного, что есть в вашей игре! Найдите того, кто умеет такое, предложите ему денег, шантажируйте, умоляйте, но сделайте своей игре достойное промо-видео!
- Подумайте, насколько игра виральна. Интересно ли смотреть за тем, как кто-то в неё играет? Или играть с друзьями? Хочется ли рассказывать об этой игре? Если на все эти вопросы ответ “нет”, возможно, стоит внести некоторую корректуру в гейм-дизайн. Я не агитирую делать игры специально под стримеров или киберспорт, но иногда смещение акцентов буквально на пару градусов позволит игре выстрелить на твиче или ютубе.
- Редактор может сделать игру бессмертной. Дайте игрокам возможность самостоятельно делать контент - и его поток не иссякнет. HMM III и WarCraft 3 - самые яркие примеры, однако далеко не единственные. Есть множество других, менее известных, но годами поддерживающихся комьюнити проектов. Дело в том, что даже самая крутая игра рано или поздно наскучит, приестся. Через год-два после релиза (скорее всего - намного раньше) её если и будут вспоминать, то просто как пример. Можно подогревать к ней интерес дополнениями, но куда лучше делегировать это самим игрокам. Вполне возможно, что какие-то обретут даже большую популярность, чем оригинал (вспомните историю Dota). И это прекрасно!
Послесловие
Спасибо всем, кто дочитал этот лонгрид, а особенно - оба поста. Ещё раз отмечу, что всё написанное - просто моё частное мнение, дистиллят своего и чужого опыта через призму мировоззрения. Не используйте её как дословную инструкцию. Помните слова Барбароссы:
“На самом деле Кодекс не свод правил… скорее, список рекомендаций.”
Всем добра и мирного неба над головой!
![,*v • 1*
rv*' •!
ft l i?"]
* гшшт JpTTT*,человейник,архитектура,architecture, архитектура, здание, дом, архитектурный памятник,,небоскребы,Китай,страны,длиннопост](https://img2.joyreactor.cc/pics/post/full/человейник-архитектура-небоскребы-8575179.jpeg "человейник,архитектура,architecture, архитектура, здание, дом, архитектурный памятник,,небоскребы,Китай,страны,длиннопост")
![Mavki im
MABH
<v.j
AI Mawasi
As-Siafa
Yad Mordehai Ñetiv HaAsara
s.
'.V
^ . ^3 E/e? Crossing
Bert Lahia --^N _____
QD
Bror Hayil
Even Shrrv
Ahuz
Jabalia
r
✓
Ibim
^^J^Sderot
Wahsh
Gaza
AI Zahra
NuseiratCamp 7
x-
/
/
o
Mefalsim Qm ar Aza
Ruhama
Tkuma QT]
Klahim](https://img2.joyreactor.cc/pics/post/full/политика-Израиль-страны-8142787.jpeg "политика,политические новости, шутки и мемы,Израиль,страны,арабы против Израиля,ХАМАС,длиннопост,Сектор Газа")
![
Шт* ».
\ 111
” 1 Л1
-тИ
11
1 j a],Япония,страны,путешествие,длинопост,попытка переезда №1,Hoshinigata](https://img2.joyreactor.cc/pics/post/full/Япония-страны-путешествие-8178030.png "Япония,страны,путешествие,длинопост,попытка переезда №1,Hoshinigata")
![ л / / 1 1 1 ,/r- JHÏ V, / уташ/Ш'^^vax- - д1 4
f( 1 к Вк '.1к ii а se> / Л^Шш 4 L '\ л\ \ ^
■2 — lit]
, ^ ?'¿ 1/ к Ж/ I нр . , пй
VyWBK * ',борщевик,длиннопост,неснятые фильмы,андрей тарковский,подборка,MidJourney,нейронные сети,нейрофильмы,крипота](https://img2.joyreactor.cc/pics/post/full/борщевик-длиннопост-неснятые-фильмы-7884739.jpeg "борщевик,длиннопост,неснятые фильмы,андрей тарковский,подборка,MidJourney,нейронные сети,нейрофильмы,крипота")
![/ / «I'/ s'isfÊ* \ *_■€*** j i л A <1 " - »i Щ1Т^/ BAÿ -js ív 9? ¿-fe J?-; . rT - M( - . -^ y<^g]l 1*3R¿ t ^i; ?-v ^ .С ' " ' ■vOs4- ^ *' / *^шГ LvA^y Г .< У wSE^ '. *> 'x-Vri^ • • —/ У • f* ‘ у, • » W.
w » _, í 1 У Ж1 w' TJf Jf J '/Л flbv ■ ' Oi . > Jv • • *ЯЯИ ss8 -s& Mfríz*](https://img2.joyreactor.cc/pics/post/full/Реактор-познавательный-динозавры-Палеонтология-6205415.jpeg "Реактор познавательный,динозавры,Палеонтология,длиннопост,Палеоарт")
Отличный комментарий!