9 июня заканчивается приём заявок на участие в Открытой игровой лаборатории

Участники Game Open Lab создадут собственные игры, а победители разделят призовой фонд в 300 тысяч рублей.

Лаборатория пройдёт в два этапа:
— Онлайн-геймджем 10—17 июня
Команды до 5 человек разработают проекты и разместят их на itch.io.

— Очный финал 6—8 июля
Питч лучших проектов, мастер-классы, лекции представителей игровой индустрии и оглашение победителей.

Регистрация до 9 июня — gameopenlab.ru

#новости

Продюсер на вольных хлебах: Мир постковида

Рассказал про эксперименты, а теперь расскажем про основную деятельность. А точнее как забавно изменился мир. Благодаря тому что в формате фриланса или студии я пробыл с 2017 по 2020 год у меня при выходе в эту деятельность были огромный опыт, куча проектов (хотя много за NDA), несколько брендов. В общем тонна ресурсов. Но всё же до ковида было важное условие. Чаще всего всё равно нужно было проводить много личных встреч.

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

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

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

Уже даже не знаю, как байтить на 🔥, но “The world shall burn” (c) Deathwing. Поэтому не проходим мимо, ставим. А я пока подумаю, о чём ещё может вам рассказать «неизвестный голос из телефона» :)

#приключения

Жизнь и смерть графического программиста
https://www.elopezr.com/life-and-death-of-a-graphics-programmer/?

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

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

Я как-то раз писал под заказ что-то такое на свифте. При том, что я плохо знаю свифт. И там как в анекдоте:
- "А методичка есть?"
- "Есть"
- "Ну ща, докурим, и напишем ваш проект"
Так как по сравнению с задачами, которые периодически встают в геймдеве, в некоторых сферах разработки будто бы просто нужно уметь читать документацию. Думать там необязательно.

#новости

Симуляция птичьих стай в Unity
https://blog.devgenius.io/boids-algorithm-simulating-bird-flocks-in-unity-ec733d529a92

Статья про реализацию алгоритма Boids в Unity для симуляции движения стаи птиц. Дак ещё и с гитхабом, за что спасибо доброму человеку! Статья на медиуме, так что если вы в рф, напоминаю что вам нужен впн :)

Я, как известно, обожаю математику. В целом игровые движки помимо игр являются отличным средством визуализации всяких симуляций. В случае Unity не точных конечно, так как для точности нужен double, а не float в векторах. Но именно в части визуализации, а не расчётов, я не представляю зачем такая точность. А расчёты и так можно написать с даблом.

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

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

#новости

Вообще забавно как прочтеная статья ведёт к дальнейшим рассуждениям.

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

Но в условиях опэн эир феста, где куча народу с телефонами, я бы не доверял радиочастотам. Да и дронов скажем у нас 100 штук. Чем же передавать значения в реальном времени? Оптика и световая панель на земле? Будто бы не гибко и не стабильно. Лучше всего вероятно ультразвук. Хотя там вопрос в расстояниях и ветер будет мешать и ультразвуку. Но цепочка дронов для передачи последовательно может решить. Вопрос в скорости обработки сигнала железом.

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

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

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

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

P.S. Или «за что мне платят» когда обычно покупают консалт :)

#мысли

Ладно, последнее на эту тему. Так как я нашёл кое-что забавное про сов :)

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

Сейчас я конечно дико загружен, но как освобожусь надо будет сдуть пыль с пайчарма, и возможно написать статейку на хабр. Например «не шумите, мы тут сигнал передаем» :)

#мысли

Сглаживание Lerp-ом сломано
https://youtu.be/LSNQuFEDOyQ?si=t11ybI9UkmLVgyHO

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

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

Частой ошибкой новичка будет написать что-то вроде:

olegPos = Mathf.Lerp(olegPos, playerPos, speed);

Вглядеть это будет как плавное приближение, но при разных фреймрейтах у разных игроков будет выглядеть по-разному — что очевидно плохо. Даже в жизни играл в игру, где на это забили — это вуди вудпекер. И на моем компе он был ещё и флешем. Играть было невозможно. Ладно Олег, чё он нам сделает, а вот проджектиль в виде преследующего заклинания — совсем плохо. И именно это имеется ввиду под «Сглаживание Lerp-ом сломано».

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

#новости

Да, на всякий напомню, что я тут личный канал завёл. Если вдруг кому интересно, там теперь постов побольше 🙂
https://news.1rj.ru/str/straylis

Оптимизация звука: Пуллинг AudioSource
https://www.youtube.com/watch?v=BgpqoRFCNOs

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

По видео предложен концепт который позволяет не плодить миллионы источников для проджектилей. По сути такой подход позволяет не париться при их дестрое и так далее. Звук не пропадёт, так как источники в отдельном пуле. Чему я удивился, так это то, что звук проигрываемый через PlayOneShot на 5-ти источниках и на 15 — отличается. Надо будет поизучать почему. Пуллинг хороший, обычный, объектные пуллы это хорошо. Правда для совсем уж красоты его бы дописать для задач пространственного звука. Скажем поведение которое я не тестировал и даже не знаю что будет.

Мы перемещаем аудиосорс, вызываем в следующем кадре PlayOneShot, а потом перемещаем аудиосорс снова пока звук через PlayOneShot играется. Звук доиграется в той точке где был вызван метод или будет следовать за аудиосорсом? Я подозреваю что второе, и это как бы верное поведение. Но тогда с учётом кучи потенциальных звуковых эффектов по своей сути (типа шипения проджектиля электрического заряда) В таких пуллах надо уметь локать аудиосорсы к источнику по позиции и так далее.

В общем классное видео. Let's make sounds great again! И не будем забывать, что звук это штука важная, которая во многом отвечает за погружение игрока в игру.

#новости

Давно не было опросов. Сижу я утром, ковыряю проект, и у меня есть в беклоге баг - чёрные полосы ракурса камеры на ультрашироких дисплеях. Игра 2д. Понятно что нужно менять стартовый размер ортографической камеры. Но это же ща надо математику искать, давайте выведем зависимость эмперически. Тыкаем разрешения широкие, меняем размер камеры и ищем есть ли какая-то система в этих изменениях. Находим, прикидываем, и вуаля наша формула работает и It's Alive!

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

Как сделать интерактинвый ковёр
https://80.lv/articles/learn-how-to-make-interactive-rug-with-unity-s-shader-graph/

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

Технический художник Unity Хосе Ортигоса Рамос поделился видеоуроком по созданию аккуратного интерактивного коврика, который деформируется, когда под него помещают объект с помощью Shader Graph от Unity. Он же недавно показывал эффект желешки.

#новости

Оптимизация трассировки лучей методом BVH
https://www.youtube.com/watch?v=C1H4zIiCOaI

Видео про трассировку лучшей и про метор BVH ( bounding volume hierarchy) или иерархии ограничивающих объёмов. Реймаршинг, рейтрейсинг в реалтайме одни из самых любопытных тем в графике. Ведь всем хочется чтобы в реалтайме можно делать так же круто, как в 3д софте. Потому что сейчас рендер от реальности иногда даже бывает сложно отличить.

И опять в оптимизации у нас деревья. Я ещё помню что любил технику BSP (Binary Space Partition или как-то так) В общем как мне нравились всегда деревья и графы, так и остаётся это чуть ли не любимым разделом в математике. А видео интересное, рекомендую глянуть. Даже если не применять все эти оптимизации, такие штуки помогают разбираться в некоторых принципах используемых в разработке можно сказать "на примерах".

#новости

Забавный баг с сорстри на макбуке

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

/Users/nox7atra/.ssh/config line 23: keyword hostname extra arguments at end of line
/Users/nox7atra/.ssh/config line 26: keyword identityfile extra arguments at end of line
/Users/nox7atra/.ssh/config: terminating, 2 bad configuration options

Чтож, сразу идём в гугл и не находим ответа. Ну читать я пока умею, так что давайте тогда опустимся до того, чтобы посмотреть что написано в файле config. Заходим и видим сгенерированное что-то от сорстри. Читаем файл. И чтож, мы находим баг.

Пробелы. В сгенерированной конфигурации от сорстри аргумменты не заключены в кавычки 🙂 А у меня там откуда-то в названии пробелы (хотя как опытный пользователь я никогда в путях не использую пробелы и кирилицу, зная что много кто клал на обработку этого случая, но сам Gitlab Enterprise в конфигурации написан через пробел).

Ставим кавычки, всё работает. Но забавно, что из-за сгенерированной сорстри конфигурации у меня сломался в целом механизм подключения по ssh. Так что если у кого-то выскочит, найти нужные линии, поискать нет ли пробела в пути и поставить аргументы в кавычки. Раз такое не гуглится так просто - надо написать. Хотя разобраться не сложно, но для этого надо хоть немного Unix знать.

#интересное

Particle Plexus
https://mirzabeig.substack.com/p/unity-tutorial-particle-plexus-part-3

Классный туториал по красивому визуальному эффекту. Люблю такой визуально простой, но при этом эффектный VFX.

#новости

Открытость IT, а точнее разработки

Давно ничего не писал. Но и дел много + я ща в походных условиях осваиваюсь. А сейчас раз уж появилась мысль — стоит написать.

На пост меня навело то что ко мне пришли с рекламой закрытого канала. Я такое рекламировать не хочу, так как для меня реклама погоды в моих доходах не создаёт. При огромной цене поста относительно CPV в 10 рублей за просмотр. То есть около 10к рублей за пост. У меня час консалта стоит как бы столько же (хотя я уже думаю сделать дороже). Не беря основной бизнес — доходов с проектов. Ладно, речь не об этом.

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

Не, там конечно будет как в той же доте) Первое время тебя будут гнобить. Нужно будет перетерпеть саркастические ответы на новичковые вопросы и тому подобное. Но в разработке все всегда были готовы помочь друг-другу. Причём без оплаты. Даже взяв за пример мой консалт. Он платный: 1) для бизнеса 2) при конкретном коммерческом запросе.

Когда меня в чатах спрашивают или разработчики спрашивают и ответ можно сформулировать в нескольких предложениях, а не в документе на 100 страниц я не буду говорить: «плоти» :) Типа «Гриш, а ты работал с этим, как там всё?» я безусловно отвечу. Собственно с этой концепцией я писал и надеюсь буду писать статьи на хабр, пишу в этот блог. Я в целом за открытость и некоторое совместное развитие.

Курсы — норм, так как это структурирование информации, для тех кто хочет ускориться и не хочет сам заниматься. Но всё же комьюнити разработчиков, общение в айти и т.п. должно оставаться открытым. А то скоро как у юристов будет сайт «программист ру», где за 100 рублей будут отвечать где в блоке с кодом «;» пропущена :)

#мысли

Загадка Order in Layer

Unity иногда поражает своими решениями. Особенно их очевидностью. Вот вы знаете какое максимальное значение у sortingOrder в SpriteRenderer? Ну наверное если работаете с 2д много то знаете. Но вот почему так - загадка. А давайте попробуем угадать?

Сначала сходим в документацию. Там ничего не сказано. Ну ладно, документация нужна только трусам. У нас же есть код, а код лучшая документация. Посмотрим тип sortingOrder в коде. Ну вроде бы int. Следовательно по идее значение должно быть равно int.MaxValue - 2 147 483 647? Ведь так Unity? Так? *тут должна быть ухмылка Энакина, но в текст в телеграме нельзя вставить картинку*

Не, опять не угадал. Максимальное значение равно - 32767. То есть short.MaxValue. Почему при этом sortingOrder у нас типа int, а не short? Ну видимо во славу сатаны. А я потратил 5 минут лишних на задачу и ещё на пост чутка времени, чтобы узнать почему при драге sortingOrder = int.MaxValue ставит -1 в значение порядка сортировки объекта. Я считаю и обработка больших значений божественная, и документация идеальная, и код очень логичный. Уже за 12 лет работы с этим движком удивлять он всё так же не перестаёт.

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

#оработе

Продюсер на вольных хлебах: Об ошибках

Я рассказал о работе, а теперь поговорим об ошибках. Их было много за 6 лет, но хочется выделить какие-то самые важные. Хотя в первую очередь я поговорю почему ошибаться нормально.

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

1. "Победителей не судят" - это ошибка

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

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

Отстаивать свою позицию важно и нужно, но как и во всём - нужен баланс.

2. "Мы же делаем для вас лучше"

Я всегда очень сильно вовлекаюсь в проект. И это во многом скорее плюс. Но я часто спорил с клиентами, причём в мясо, по не столь существенным вопросам, когда я знаю что лучше сделать по-другому. И вывод мой - так не нужно делать всегда. Объяснить как лучше и почему я так считаю - обязан. Биться и доказывать с пеной у рта, когда у меня просто заказали разработку проекта - не за чем. Во-первых, у клиента может быть больше контекста и клиент может банально больше знать. А вот во-вторых, если с точки зрения бюджетирования разницы нет, то всегда проще сделать как хочет клиент акцентировав внимание на том, что ты не совсем согласен с его позицией. Как говорится "хозяин барин". Все же в моей работе оплата идёт за реализацию. Поэтому я всё чаще что-либо рекомендую вообще только когда меня об этом спрашивают.

3. "Все сам"

Это вообще топ-1 ошибка. Я уже не помню сколько раз я в проектах не делегировал разработку когда надо было. Я умею работать с супер скоростью. Некоторые проекты я целиком с нуля разрабатывал за 2-3 дня. Потому что за 90 проектов мне нужно просто сесть и написать. Чтобы сделать тот же раннер или ещё какую-то игровую механику мне даже задумываться не надо. Просто попечатать пару часов строчки кода. Так как для меня в Unity всё ключевое понятно.

Но очень часто было такое что я был загружен и не отдавал кому-то другому проект. А потом когда до дедлайна остаётся пара дней "ну мы уже ни с кем не договоримся" и я в огне всё делаю сам. Обычно прохлебав какие-то переговоры или какой-то контракт. Да либо просто устраивая себе весёлые ночи без сна. Лучше заранее и сразу грамотно планировать ресурсы и своё время. И по сути этому я более менее (и то не до конца) учусь сейчас.

4. "Излишняя принципиальность"

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