А пока тема с ECS греется расскажу вам про рандом.

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

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

Разрабам это дико упрощает жизнь в нескольких вещах:

🔹 Реплеи: Игра не записывает видео, она просто сохраняет сид и порядок нажатых игроком кнопок. При воспроизведении движок заново просчитывает всё по той же схеме, и мир получается идентичным.

🔹 Процедурная генерация: В условном Майнкрафте не нужно хранить триллионы блоков на диске. Достаточно знать сид, и мир соберется сам прямо на ходу.

🔹 Синхрон в онлайне: В стратегиях или файтингах достаточно передать сид обоим игрокам, чтобы у них на экранах всё происходило одинаково без передачи лишних данных.

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

Привет!

Привет друзья! Нас уже больше 20, я в шоке! Мы уже превращаемся в комьюнити! ⚡️

Спасибо за поддержку, постараюсь вас не разочаровать и с каждым разом повышать планку контента!

Кстати о нем: любой инди-разработчик знает, что первые 20 человек — это самые важные люди. Это те, кто видит проект еще «скелетом», без красивой обертки.

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

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

Делать всё планирую через DOTween. Чуть позже напишу отдельный пост, почему выбрал именно его и как он упрощает жизнь.

Ну и раз нас стало больше, давайте знакомиться! Кто из вас сам что-то пилит, а кто просто зашел посмотреть на внутреннюю кухню?

Хотел я вам рассказать про DOTween как и обещал, но понял, что надо сначала копнуть глубже. Поэтому разделим тему на 2 части.

И так, фундамент. Как работает время в играх:

Прежде чем учиться двигать объекты, нужно понять, как «думает» Unity. Все, что вы видите на экране — это быстрая смена статичных картинок (кадров). Существует бесконечный геймлуп — цикл, который каждый кадр вызывает код в Update. Если у вас 60 FPS, то код прогоняется 60 раз в секунду.

Проблема: Если в коде написать «перемести объект на 5 метров», он окажется там в следующем же кадре. Мгновенно. Для игрока это будет выглядеть как телепортация, а не движение.

Как сделать плавно? Нам нужно разбить эти 5 метров на маленькие отрезки и проходить их каждый кадр. Инструмент для этого — Корутины (Coroutines).

Это особый вид функций, которые могут встать на паузу в определенном месте (yield return), отдать управление движку, а на следующем кадре (или через секунду) продолжить работу ровно с той же точки.

Чтобы объект затрясся, нам нужно в течение нескольких кадров быстро смещать его в случайные стороны. В корутине это выглядит так:

🔹 Создаем цикл например на 10 повторений.

🔹 Берем рандомное направление (в Unity это часто Random.insideUnitCircle) и прибавляем его к позиции объекта.

🔹 Ставим паузу до следующего кадра через yield return null. Это ключевой момент — без него объект переместится 10 раз за один миг, и вы ничего не заметите. Пауза заставляет Unity «показать» каждое смещение игроку покадрово.

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

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

Чтобы не изобретать велосипед каждый раз, разработчики используют мощные библиотеки. Лидер среди них — DOTween, и о нем с примерами мы поговорим в следующем посте.

Сегодня не до разработки. Сегодня апгрейд базы.

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

Креслу, кстати, больше всех обрадовался кот.
Занял его сразу, как будто так и было задумано.

И заодно приехали книги:

🔹 «Игровой баланс» — Ян Шрайбер, Бренда Ромеро
🔹 «Геймдизайн» — Тайман Сильвестр

Обе не про «как сделать хит», а про мышление.
Почему одни механики цепляют, а другие нет.
Почему баланс это не только цифры.
И почему игрок почти никогда не играет так, как ты задумал.

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

Практика будет.
Просто хочется, чтобы под ней был нормальный фундамент.

Продолжаем тему.
Прошлый раз разобрали корутины, теперь — DOTween.

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

Как это работает на практике Вместо создания отдельной функции и контроля кадров, вы просто вызываете команду у объекта. Например, перемещение на 5 метров за 2 секунды выглядит так: transform.DOMoveX(5, 2f);

Движок сам понимает, на сколько пикселей сдвинуть объект в каждом конкретном кадре, чтобы движение завершилось ровно через 2 секунды.

Что это дает кроме сокращения кода:

🔹 Типы плавности (Easings). Можно одной командой .SetEase(Ease.OutBack) добавить объекту инерцию или эффект отскока. Писать такие кривые скорости вручную долго и сложно.

🔹 Последовательности (Sequences). Позволяют группировать анимации. Можно задать очередь: сначала объект увеличивается, потом меняет цвет, потом улетает в сторону.

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

Резюме.
Корутины стоит оставить для системных вещей: загрузки уровней или ожидания ответа от сервера. Для любого движения, работы с интерфейсом и визуальных эффектов проще и надежнее использовать DOTween.

Так как у нас в планах 2D карточный рогалик, то анимаций у нас будет огого сколько, и как раз дотвин нам поможет справится с этим объемом.

А вам нравится когда все летает, свистит и кряхтит?

Настало время потихоньку вскрывать карты. 🃏

Весь следующий год мы будем плотно работать над проектом, который сами для себя называем «гремучей смесью» трех мощнейших референсов. Если вам когда-нибудь хотелось увидеть их в одном флаконе, то вот они:

🔹 Balatro. За азарт, безумные множители и кайф от того, как цифры улетают в стратосферу.
🔹 Герои III. За дух старой доброй стратегии, эстетику фракций и масштабность.
🔹 Darkest Dungeon. За атмосферу подготовки и вдумчивые закупки в магазине.

Что это будет за зверь? В основе Core-механики лежит «симулятор подсчета». Вы выбираете Полководца, собираете армию из карт-юнитов и обвешиваете их модификаторами.

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

Но самое важное - мы хотим делать эту игру вместе с вами. Я буду делиться внутрянкой почти каждый день, и это не просто «дневник разработчика». Вы вольны напрямую влиять на то, какой станет игра: предлагать свои идеи для юнитов, придумывать безумные свойства Джокеров или критиковать механики. Самые сочные предложения вполне могут оказаться в финальном билде.

Пока это всё, что я готов рассказать. Впереди много интересного.

Как вам такой набор референсов? Пишите в комментах, что бы вы добавили в такую игру в первую очередь! 👇

Ну что, ребят, вот я и поймал свой первый «кранч» 🦀

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

Я много читал о том, что разработка не обходится без переработок, но не думал, что столкнусь с этим так скоро.

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

Говорят, ни одна игра не бывает готова на 100%. Всегда есть механики, которые хочется докрутить, и баги, которые хочется поправить. Видимо, пора просто смириться с этим фактом. В какой-то момент нужно нажать на тормоза и сказать: «Всё, на сегодня этого достаточно».

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

А как вы справляетесь с дедлайнами: доделываете всё в последнюю ночь или умеете вовремя остановиться?

Геймдизайнер — это инженер эмоций.

«Зачем люди играют?» вопрос, с которого Тайнан Сильвестр начинает свою книгу.
Ответ предельно честен: за эмоциями.

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

Моя работа это не просто заставить кнопку «Выбрать» нажиматься. Моя задача в том, чтобы в этот момент у игрока на долю секунды замерло сердце: «А вдруг я ошибся?».

Если эмоция случилась, то игра состоялась. Если нет, то это просто софт.

А за что вы любите игры?

Слушайте, есть одна мысль... но я пока сомневаюсь 🤨

Вижу сейчас в сети много челленджей в духе «100 дней кода» или «100 дней чего-нибудь еще». Люди просто прыгают в тему с головой и фигачат контент каждый день.

Подумал, может мне тоже попробовать что-то такое в Unity? Например, каждый день учить по одной новой механике и выкладывать короткий ролик с тем, что получилось.

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

Хватит ли меня на это? Не надоест ли вам смотреть на мои бесконечные тесты прыжков и открывания дверей?

В общем, пока просто прикидываю. Как считаете, такой формат вообще интересен или это уже пройденный этап и сейчас всех только раздражает?

Стоит ли в это ввязываться или лучше спокойно учиться в своем темпе, без этого публичного самоистязания?

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

Теперь у нашего канала появилась англоязычная копия. Хочу, чтобы крутой контент был доступен каждому, независимо от страны. Рад каждому из вас! Давайте создавать по-настоящему мощное и открытое комьюнити вместе.

Почему идеи ничего не стоят без реализации?

«У меня есть идея игры, где можно грабить корованы...» 🐫

Знаете, какой самый частый вопрос слышит геймдизайнер? «А что, если сделать игру про [вставить любое сочетание слов]?». Кажется, что крутая идея это 90% успеха.

На самом деле, идея это бесплатно. Реализация это дорого, больно и долго.

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

А у вас была «та самая» идея игры, которую вы боитесь рассказывать, чтобы её не украли?

Признавайтесь в комментах! 👇

Следующая остановка — диалоги 🗣

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

Казалось бы, просто текст на экране, но в геймдеве это целая технология.

Как это можно реализовать?

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

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

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

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

Нажимаю всё подряд, чтобы завести эту машину, но она пока отказывается ехать. Я сейчас про Sequencing и Timeline в Unity.

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

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

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

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

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

Спустя 10 часов возня с таймлайнами наконец закончилась!

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

Всего у меня вышло 4 таймлайна и 4 блока диалогов между катсценами.

Что в итоге удалось выжать из этого инструмента: Таймлайн по сути стал дирижером моего маленького оркестра. Один поток отвечает за перемещение камеры (Cinemachine), другой вовремя подсовывает анимации персонажам, а третий дергает скрипты, чтобы на экране вовремя всплывал нужный текст. Когда эти дорожки синхронизируются, статичная сцена превращается в кино. Да, под капотом там сейчас «спагетти» из связей, но на экране всё выглядит так, как я и задумывал.

Для первой попытки результатом доволен. Насколько хорошо это получилось на самом деле решите вы уже завтра.

Работы еще хватает. Мне осталось добавить озвучку и звуковые эффекты, чтобы картинка окончательно «ожила». Так что сегодня снова допоздна.

Задача с диалогами закрыта!

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

Помимо самих текстов я использовал таймлайны, о которых писал раньше. Результат того, что получилось, уже можно посмотреть в закрепе.

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

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

О том, какими способами можно реализовать переходы, расскажу уже завтра, а сейчас пора наконец-то выдохнуть и отдохнуть.

Как вам моя поделка? Жду ваше мнение в комментариях!

Магия бесшовности или как обмануть игрока при смене сцен 🎬

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

Весь секрет кроется в парных анимациях. Я создаю анимацию выхода в конце первой сцены. Она замирает ровно на том же моменте, с которого стартует анимация входа во второй сцене.

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

Но как передать ту самую карту между сценами?

Если я хочу, чтобы в анимации перехода отобразилась конкретная карта, мне нужно передать её номер из одной системы в другую. Скриптбл обджекты для такого рандома подходят плохо. Проще использовать объект, который не уничтожается при загрузке через метод DontDestroyOnLoad, либо передать нужный номер через статику: DataHolder.CardID = randomID;.

В новой сцене я просто считываю это значение и подставляю нужный спрайт в шейдер или аниматор. В итоге карта успешно переживает переезд.

За неделю попробую реализовать нечто подобное.

Как думаете, какой эффект перехода сейчас самый сочный в инди играх?

Сегодня иду играть в бильярд, поэтому давайте разберем его через призму геймдизайна 🎱

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

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

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

Вечер планирую провести за изучением этих физических систем на практике. Хороший повод отвлечься от монитора и посмотреть на геймдизайн в реальном мире.

Тот случай, когда шары в лузах оказались не самым главным 🎱

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

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

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

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

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

Почему в одних играх мир кажется декорацией, а в других живой экосистемой? 🌍

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

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

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

В геймдизайне это работает точно так же. Тайнан Сильвестр в своей книге объясняет, что нам не нужно программировать каждую случайную встречу. Достаточно прописать базовые свойства объектов. Например, если мы создадим правило, что хищники хотят есть, а трава растет быстрее после дождя, то в игре сама собой возникнет симуляция миграции животных. Разработчик просто наблюдает со стороны за тем, как его «муравьи» создают уникальные истории.

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

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