Еще месяц назад я вообще не понимал, как делаются игры.

А сейчас собираю первый прототип на Unity.
Удивительно, но в индустрии почти половина всех проектов — на нем. Он реально простой, и при этом мощный. Даже Pokémon Go сделали на нем.

Если тоже интересно попробовать — вот ссылка на бесплатную онлайн-конференцию. Там с нуля показывают, как стартовать.

А за раннюю регистрацию дают гайд «Как создать своего Ведьмака».

Я не пропал, я тут потихоньку двигаюсь!

Вот например, на конференции у Гришакова посветился, навалил базы про эффективное изучение Unity

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

Статья

#статьи

Упоролся и снова пробую в Shorts

https://www.youtube.com/shorts/RY6YBKw79po

Почитал статью от Deconstruction of Fun про 10 тенденций мобильной игровой индустрии 2025 и немножк.. приуныл?

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

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

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

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

#статьи

💸 Зарубежный клиент готов платить — а как деньги получить?

Делаешь концепт-арт, анимацию, левел-дизайн или даже полноценную мини-игру для студии из Европы или США? Клиент спрашивает куда переводить. А ты — завис на этапе оплаты.

PayPal не работает, SWIFT не дойдет, крипта — рискованно.
Что делать?

EasyStaff Invoice — это сервис получения оплат от зарубежных заказчиков, просто, прозрачно и официально.

Выставляешь инвойс клиенту в EUR или USD — получаешь оплату на баланс сервиса и выводишь на карту или счет в любом банке, в удобной валюте. Для продвинутых - можно и на криптокошелек закинуть.

Идеально подходит для:
🎮 фрилансеров в геймдеве
🎨 художников, 3D-дизайнеров, саунд-дизайнеров
👾 небольших студий и инди-команд

Твоему заказчику тоже понравится, ведь EasyStaff Invoice зарегистрирован в Европе, работает с клиентами официально по B2B договору и предоставляет закрывающие документы.

Сомневаешься? Приходи в Telegram-канал и чат — там реальные отзывы от тех, кто уже получает оплату через EasyStaff Invoice.

А если ты только выходишь на международный рынок — попробуй себя на EasyStaff Connect. Это биржа фриланса с бесплатными тасками и комиссией только за вывод средств.

Регистрируйся и выставляй первый инвойс.
Или найди первый проект: https://clck.ru/3MkRDh

Прошел Superliminal - небольшую инди-игрушку, ломающую мозг

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

Как я и сказал, игра построенна на головоломках через проекции (смотри видео на странице в Steam). Механика интересная, но быстро надоедающая. Очень круто, что разработчики наигрались комбинациями головоломок на паре механик с неожиданными переворотами восприятия и вовремя завершили игру. Я прошел за 3 часа и получил удовольствие, а самое главное - приятное послевкусие.

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

Игра однозначно попадает в список рекомендаций

P.S. Если есть интересные небольшие инди-игры, которые вы считаете важными для прохождения - делитесь ими в комментариях!

#надопоиграть

Сегодня стартовала летняя распродажа в Steam!

Расчехляйте копилки, господа!

P.S. Под последним постом в комментах как раз делились хорошими играми, авось они и скидку получат на распрадаже!

Затрону тему геймдизайна баланса, или то, чем еще приходится заниматься разработчикам игр

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

Технически - всё просто. Особенно, учитывая, что на результат кроме рандома влияет всего лишь один параметр: сила отряда. Ну, вернее два: сила отряда игрока и сила отряда врагов в комнате. И вот тут возникает вся магия математики в играх: как сделать так, чтобы результаты имитации боя были хотя бы отдаленно похожи на результат настоящего боя?

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

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

Поэтому я ввожу градацию сложности: в зависимости от соотношения сил, я выдаю шансы понести потери. Например, если у игрока отряд в два раза слабее вражеского - то он теряет до 80-90% отряда, и если у него кто-то остается, то захват комнаты проходит успешно. Таких градаций несколько, все сводится к тому, что чем меньше сил у игрока - тем больше потерь он понесет, но это еще не значит, что он проиграет. Если в отряде будет достаточно юнитов, что даже при потерях в 99.99% отряда, останется хотя бы один юнит - комната будет захвачена.

Я сделал в итоге 6 отрезков для определения потерь в отряде игрока, в зависимости от соотношения "сила отряда игрока / сила отряда врага". 0-0.5, 0.5-0.75, 0.75-1, 1-1.25, 1.25-1.5, 1.5-2. Минимальное соотношение будет всегда больше 0, т.к. как минимум 1 юнит то в отряде будет, шансы на победу при соотношении сил меньше 0.5 стремятся к 0, потому что потери стремятся к 100% (но никогда не будут 100%, пограничное значение 99.99%). И наоборот, если отряд игрока в 2 и более раз сильнее вражеского, то шансы на победу стремятся к 100%, потому что потери стремятся к 0.

Далее я определяю "корридоры сложности". Например: 0-20% потерь = ваще легко, 20-40% потерь - легко, 40-60% средне и т.д. Это и видит игрок и строит стратегию, готов ли он нести такие потери или нет.

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

___
В крупных компаниях обычно такими задачами занимается отдельный геймдизайнер, он так и называется - геймдизайнер баланса. Такому человеку предстоит много считать, заполнять множество табличек, придумывать множество формул, и чтобы это всё гармонично работало на опыт игроку.

Всем понедельника!

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

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

А здесь будет большая абоба, содержащая все схемки и подсхемки. Кстати, да, имеется ввиду архитектура на MVVM:

https://drive.google.com/file/d/1jFBCFzzhSuKG8rdnW-XEPON1HabQl56O/view?usp=sharing

Еще день, еще схемка! MVVM подъехал

Дисклеймер: схемка расширяет информацию из предыдущего поста

MVP, MVC, MVVM - распространенные архитектурные паттерны в разработке приложений. Многие говорят, что они фигово ложатся на геймдев, и доля правды в этом есть. Нюанс в том, чтобы понять кто такой View, а кто такой ViewModel/Controller/Presenter, кто из них является монобехом и кто кем управляет. Небольшая путанница, я бы сказал.

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

В своем опыте я видел несколько реализации MVVM, из них была плохая только одна: где ViewModel была монобехом. Было жутко неудобно и непонятно зачем так. Самая надежная схема (представлена в скриншоте) - когда модель представлена сервисами и обработчиками данных, вьюмодели могут ссылаться на сервисы, чтобы запрашивать данные или их изенение, а вью, которые представлены баиндерами (монобехами), могут получать данные из вьюмодели (которые доступны только на чтение), подписываться на них и посылать сигналы с запросом на изменение данных (читай Инпут). Вот и всё

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

Как-то так. Остались вопросы - обязательно задавай в комментах!