перфекционизм длиннопост

У кого-то слишком много свободного времени

Когда сисадмины перфекционисты.

Как сделать игру и не выгореть? Нужно ли для этого продавать машину? В чём секрет инди-хитов и самых успешных разработчиков?

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

В предыдущем выпуске мы подробно разобрали стадию Подготовки: научились генерировать идеи, определились с тем, что мы хотим явить миру и под каким соусом. Дело за малым - разработать игру, продать миллионными тиражами и купаться в лучах славы!

Разработка

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

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). И это прекрасно!

Послесловие

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

“На самом деле Кодекс не свод правил… скорее, список рекомендаций.”

Всем добра и мирного неба над головой!

Ковыряние в снимках, опубликованных NT и посте, опубликованном Кокой

Предисловие (в целом, можно пропустить)

Считаю нужным уточнить некоторые моменты относительно моих мировоззренческих позиций. Будучи жителем России считаю, что "специальная операция" ни с финансовой, ни с геополитической, ни с этической точки зрения не является рациональной. Также я не испытываю доверия ни к СМИ своей страны, ни к СМИ Украины - любая пропаганда является инструментом воздействия на умы граждан, которому свойственно скрывать истину в пользу общего блага, определяемого действующей властью. Плохо, когда средства пропаганды высказывают мнения вместо изложения фактов, но еще хуже тогда, когда излагаются подтасованные факты. Люди, воспринимающие новостные источники как беспрекословную истину, кажутся мне заблудшими (дурачками).

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

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

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

Переходя к теме поста

Я не считаю себя экспертом в OSINT и GEOINT, ровно как и не считаю экспертом в этой области одного уважаемого администратора. Собственно это - главная причина, по которой я решил немного поковыряться в картах, желая получить отличные значения, но к моему разочарованию, в конечном счете получил нечто отвратительное (спойлер). Тем не менее, я потратил на это не 2 часа, а приблизительно 8, и из-за непрекращающихся позывов внутреннего перфекционизма мне хочется закончить свой дилетантский труд полностью.

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

Источники и инструменты, использованные в моем диванном анализе:

Источники:

1 Пост Коки: http://polit.reactor.cc/post/5154680

2 Видеоролик с проездом по Яблонской: 

3 Вид на измеряемый столб, панорама: https://www.google.ru/maps/@50.5420119,30.23069,3a,75y,169.09h,93.55t/data=!3m6!1e1!3m4!1sZ1rzQ-dDLT_Wvez-cJHJ-Q!2e0!7i13312!8i6656!5m1!1e4

4 Вид на измеряемый столб, карта: https://www.google.ru/maps/@50.5420971,30.23047,312m/data=!3m1!1e3!5m1!1e4

5 Более наглядная карта 2012 года от Яндекса: https://yandex.ru/maps/24883/irpin/?from=tabbar&l=sat%2Cskl&ll=30.232122%2C50.542305&source=serp_navig&z=18

6 SunCalc.org с нужным адресом: https://www.suncalc.org/#/50.542,30.2307,19/2022.03.07/11:17/1/3

7 Для рисования проекций и измерений был использован paint.net: https://www.getpaint.net/

8 Для измерения углов был использован этот транспортир: https://www.ginifab.com/feeds/angle_measurement/online_protractor.ru.php

Нахождение перекрестка:

Слева - Яндекс Карты, справа - снимок из поста Коки (фото из NT)

Ссылка на на перекресток ещё раз: https://yandex.ru/maps/24883/irpin/?from=tabbar&l=sat%2Cskl&ll=30.233148%2C50.542234&source=serp_navig&z=17

(Заметьте, по ссылке Яндекса отображается как часть Ирпеня)

Погрешности и неточности

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

Изображение из Google Maps, соотношение - 100/32 = 3.125

Изображение из видеоролика, соотношение - 195/74 = 2.635

Места изображены те же, но значения различаются на 18.6%. Стоит отметить, что на этом участке улицы проводились ремонтные работы, так он выглядел на снимках Google раньше:

Изображение из Google Maps, обратите внимание на бордюр

Первое предположение - так как дорога реставрировалась, то бордюр возможно переложен. Если это так, ширина дороги должна измениться и сравнивать снимки из NT и Google некорректно, отсюда же возникает разность в соотношениях пространств. 

Второе предположение - бордюр не перекладывался. Данная гипотеза опирается на фотографии этих участков:

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

Общее состояние бордюра говорит о том, что его не меняли, но делать какие-либо выводы по фрагментам видеоролика очень сложно из-за плохого качества. Это утверждение оспариваемо, однако в последствии всегда можно будет сделать поправку на изменение ширины проезжей части. Разность в соотношениях пространств объясняется различным расположением камер на момент съемки. При наложении линий перспективы друг на друга видно, что они не совпадают:

Наложение линий забора и бордюра со снимка Google и c кадра из видео

Расчёты

На спутниковых снимках, опубликованных NT, дорога находится под небольшим углом. Для нахождения даты и времени, в которые были сделаны снимки, необходимо знать длину тени и угол ее наклона. 

Перпендикуляр и линия, параллельная дороге на снимках NT, далее левая линия будет называться опорной

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

Существуют ли другие методы измерения, кроме транспортира?

Здесь видно тень от столба

Здесь тень закрыта указателем - голубой линией шириной 1 px

На лицо проблема: указатель так или иначе полностью закрывает тень от столба в диапазоне +-1 градус, это накладывает погрешность в 2 градуса, что при значении отклонения тени в 12 составляет 16.7%. Это очень плохо.

Теперь у нас есть значения отклонения указателя, их следует вырезать и импортировать в изображение из SunCalc:

В точке x должно находиться Солнце

Как видно, дорога на карте прямая, следовательно, можно использовать значение отклонения тени в 12 градусов. 

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

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

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

Камера находится почти напротив середины места падения тени

Тень находится под углом в 12 градусов к голубой линии, найти ее длину можно так: 

l = 145/cos12/97 = 1.53 

Остается внести эти данные SunCalc:

Это точно не 1 апреля - не совпадает положение тени и ее длина

Данные Коки под мои вычисления не подходят 

Мои данные верны только для 7 марта, чуть раньше 11:30

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

P.S Возможно, следовало рисовать линии, параллельные краям дороги и уже по ним определять границу тени. Похоже, это как азартные игры, сложно бросить и все время хочется отыграться... Особенно, если твоя дата не совпадает вообще ни с одной другой. Тем более на сайте Maxar есть график пролетов спутников, по их данным 7 апреля спутника над Бучей не было: https://discover.digitalglobe.com/

Здравствуйте, уважаемые жители реактора.

Парад даунгрейда продолжается и сегодня я хочу представить вам ноутбук 1989 года, попавший в мои лапки. Это SHARP PC-4602 оснащенный 80188 совместимым процессором.

Сей чудесный экземпляр продавался в 89 году за сущие копейки

Данная модификация не оснащалась жестким диском, зато имеет два дисковода 720кб.

Более полные спецификации можно посмотреть ниже.

На удивление ноутбук в рабочем состоянии, хоть и пролежал без малого 30 лет на шкафу.

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

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

Плата питания и регулировки яркости/контраста дисплея

Материнка

Разбираю дисплей 

Петли с палец толщиной

Обратная сторона матрицы дисплея

Плата клавиатуры, никаких мембран 

Дисководы

Немного поближе посмотрим на материнку

Сам процессор NEC V40, 80188 совместимый

ПЗУ БИОСа

Оперативка

Аккумулятор в ноутбуке используется обычный свинцовый

Он прячется под крышкой в задней части

Еще из интересного - ручка для переноски

Собрал уже отмытого и отбеленного

Берем загрузочную дискету и вперед

CHEKIT

BIOS

И пробуем во что-нибудь поиграть

Надо понимать, что игры должны поддерживать CGA режим и влезать на дискету 720кб.

Принц запустился

Но намертво зависает при запуске 1 уровня

WOF без нареканий

Xonix работает

И стрип-покер, на который без слез не взглянешь

Думал что бы еще попробовать запустить, но фантазия кончилась.