Я недавно писал, что получил исходник игры одного крупного паблишера и смог изучить их архитектуру и безумно впечатлиться. Так вот, меня недавно перевели на новую игру и о,чудо,я получил и ее исходник и это тоже крупный паблишер.считай у меня сейчас в руках два полноценных продукта самых крупных паблишерлв мобильных игр,со всей внутренней инфраструктурой,со всеми тулзами и прочим.А самое главное-они у меня локально😅не на гите,а на моем домашнем компе. Вся бизнес логика,две полноценных игры это просто волшебно.
Так вот,после глубокого изучения я многое понял как работают крупные паблишеры,как они работают в конвейерном режиме быстро меняя игровые механики и тестируя их. Этот подход называется white label.
Суть заключается вот в чем: когда ты делаешь игру,ты под кажду игру пишешь инфраструктуру. Это UI система,аудиосистема,VFX система,аналитика,реклама,стандартные для всех игру инпуты и управление,система окон(настройки и тд),система локализации на разные языки,система билдов под необходимые платформы(webgl,android,iOS),система A/B тестрирования(когда одному игроку игра подгружается с одними характеристиками,другому с другими и смотрят,какая лучше дает метрику удержания),геймдизайн и левелдизайн конфиги. Вся эта инженерия о гигант очень много времени около 80% разработки и всего 20% остается на разработку собственно игры и игровых механик. Некоторые девелоперы вообще лепят все в одну кучу и при малейшем изменении какого либо компонента по п*зде идет вообще вся игра. По этому чистая архитектура где компоненты бизнес логики не знают об игре и все остальное должны жить обязательно ной частью.
А white label это уже готовая инфраструктура всех этих систем разделенная логика,ни каких зависимостей,а самое главное,что весь тот список сверху,который я еще не полностью озвучил у тебя всегда готов те 80% времени свободны и ты посвящаешь их разработке игры.
И я решил написать для себя такую white label платформу. Я начал писать и рассказывать об этом на LinkedIn. Оказалось это боль многих разработчиков и мой продукт вызывал интерес,что побудило меня попробовать построить вообще на этом какой-то реальный продукт для внедрения в небольшие студии,паблишерам и маркетинговым компаниям.
Так вот,после глубокого изучения я многое понял как работают крупные паблишеры,как они работают в конвейерном режиме быстро меняя игровые механики и тестируя их. Этот подход называется white label.
Суть заключается вот в чем: когда ты делаешь игру,ты под кажду игру пишешь инфраструктуру. Это UI система,аудиосистема,VFX система,аналитика,реклама,стандартные для всех игру инпуты и управление,система окон(настройки и тд),система локализации на разные языки,система билдов под необходимые платформы(webgl,android,iOS),система A/B тестрирования(когда одному игроку игра подгружается с одними характеристиками,другому с другими и смотрят,какая лучше дает метрику удержания),геймдизайн и левелдизайн конфиги. Вся эта инженерия о гигант очень много времени около 80% разработки и всего 20% остается на разработку собственно игры и игровых механик. Некоторые девелоперы вообще лепят все в одну кучу и при малейшем изменении какого либо компонента по п*зде идет вообще вся игра. По этому чистая архитектура где компоненты бизнес логики не знают об игре и все остальное должны жить обязательно ной частью.
А white label это уже готовая инфраструктура всех этих систем разделенная логика,ни каких зависимостей,а самое главное,что весь тот список сверху,который я еще не полностью озвучил у тебя всегда готов те 80% времени свободны и ты посвящаешь их разработке игры.
И я решил написать для себя такую white label платформу. Я начал писать и рассказывать об этом на LinkedIn. Оказалось это боль многих разработчиков и мой продукт вызывал интерес,что побудило меня попробовать построить вообще на этом какой-то реальный продукт для внедрения в небольшие студии,паблишерам и маркетинговым компаниям.
🔥2
Многие считают, что геймдев это занятие мечты, что геймдев это создание интересных миров и персонажей с увлекательной историей.
Но…
На самом деле геймдев это самая беспощадная сфера в IT. Насколько она беспощадна настолько и многогранна.
Многие думают,что если ты идешь в геймдев,то ты либо разработчик игровых механик,либо 3d/2d artist,либо гейм/левел дизайнер. Например, если ты умеешь работать в Юнити и программировать это обязательно геймплей разработчик. На самом деле вариантов много и они абсолютно разные.
Как и все продукты в нашем мире, игры требуют маркетинга. Но маркетинг это не только метрики,работа с аудиторией и тд. Для маркетинга тоже должен быть продукт. В играх это чаще всего ролики и так как это игры,ролики геймплейные. Но так как это геймплейные ролики для маркетинга,голый геймплей он не работает каким бы крутым он не был. И вот тут то и нужен человек,который может собрать игровой прототип и адаптировать его под маркетинг. Такой специалист именуется Unity Creative Developer или Creative Developer. Это такой воистину многорукий Шива,который владеет и художественными навыками и понимает психологию рынка/игрока и аналитику знает и может в Юнити собрать игру,сам написать код,собрать все.
Это один из примеров очень ярких на мой взгляд,который для меня порвал шаблон Юнити разработчика. С этого человека не спрашивают чистоту кода,следование архитектуре и паттернам. Его цель сделать абстрактный прототип игры быстро,собрать рекламный креатив на этом прототипе основываясь на нейробиологии и психологии,выкатить на тест,посмотреть метрики,докрутить и снова посмотреть результат. Если результат хороший игру запускают в полную разработку. Чаще всего в играх происходит именно так. Вы видите не рекламу существующей реально игры.
Вы видите идею и именно то как она на вас повлияла в конечном счете влияет на то будет ли игра существовать или канет в небытие.
Для меня все это было большим открытием,так как я хотел попасть в геймдев и разрабатывать игры в какой-то команде,но оказался именно тем человеком,который делает рекламные креативы в Юнити.
Суть моего посыла в том,что граней очень много,дверей на самом деле много через которые можно зайти в индустрию,главное их увидеть и сделать шаг.
#gamedev
Но…
На самом деле геймдев это самая беспощадная сфера в IT. Насколько она беспощадна настолько и многогранна.
Многие думают,что если ты идешь в геймдев,то ты либо разработчик игровых механик,либо 3d/2d artist,либо гейм/левел дизайнер. Например, если ты умеешь работать в Юнити и программировать это обязательно геймплей разработчик. На самом деле вариантов много и они абсолютно разные.
Как и все продукты в нашем мире, игры требуют маркетинга. Но маркетинг это не только метрики,работа с аудиторией и тд. Для маркетинга тоже должен быть продукт. В играх это чаще всего ролики и так как это игры,ролики геймплейные. Но так как это геймплейные ролики для маркетинга,голый геймплей он не работает каким бы крутым он не был. И вот тут то и нужен человек,который может собрать игровой прототип и адаптировать его под маркетинг. Такой специалист именуется Unity Creative Developer или Creative Developer. Это такой воистину многорукий Шива,который владеет и художественными навыками и понимает психологию рынка/игрока и аналитику знает и может в Юнити собрать игру,сам написать код,собрать все.
Это один из примеров очень ярких на мой взгляд,который для меня порвал шаблон Юнити разработчика. С этого человека не спрашивают чистоту кода,следование архитектуре и паттернам. Его цель сделать абстрактный прототип игры быстро,собрать рекламный креатив на этом прототипе основываясь на нейробиологии и психологии,выкатить на тест,посмотреть метрики,докрутить и снова посмотреть результат. Если результат хороший игру запускают в полную разработку. Чаще всего в играх происходит именно так. Вы видите не рекламу существующей реально игры.
Вы видите идею и именно то как она на вас повлияла в конечном счете влияет на то будет ли игра существовать или канет в небытие.
Для меня все это было большим открытием,так как я хотел попасть в геймдев и разрабатывать игры в какой-то команде,но оказался именно тем человеком,который делает рекламные креативы в Юнити.
Суть моего посыла в том,что граней очень много,дверей на самом деле много через которые можно зайти в индустрию,главное их увидеть и сделать шаг.
#gamedev
👍1🔥1
Наверное, пора начать рассказывать про проект, над которым я работаю последние недели.
Я строю игровой движок.
Но не совсем такой, каким обычно представляют движок.
Все началось с простой проблемы.
Каждый новый проект начинался одинаково.
Новая игра — и снова:
— система сохранений;
— UI;
— Object Pool;
— Event Bus;
— загрузка контента;
— аналитика;
— настройки;
— менеджеры всего подряд.
В какой-то момент я поймал себя на мысли:
Я создаю не игры.
Я снова и снова строю одну и ту же инфраструктуру.
Сначала мне казалось, что это только моя проблема.
Но чем больше я изучал тему — форумы, обсуждения разработчиков, истории небольших студий — тем больше понимал, что это системная проблема.
Потом я наткнулся на статью The Hidden Cost of Studio Engineering от Deconstructor of Fun. Та самая статья
Главная мысль была очень простой:
Игровые компании постоянно недооценивают стоимость собственной инфраструктуры.
Пока команда строит внутренние инструменты, она не строит игру.
И тогда я понял одну вещь:
Крупные игровые компании уже решили эту проблему.
У них есть внутренние платформы, которые позволяют создавать новые проекты быстрее.
Но у небольших студий и инди-разработчиков часто нет ресурсов, чтобы годами строить такие системы самостоятельно.
Именно эту проблему я хочу решить.
Я строю Enterprise Engine.
Не очередной Unity Framework.
Не набор разрозненных ассетов.
А платформу разработки игр по модели:
Engine = Console
Game = Cartridge
Движок содержит фундамент:
архитектуру, сервисы, инструменты и производственные системы.
А каждая игра становится отдельным картриджем, который подключается к этой платформе.
Удалил игру — движок остался.
Создал новый проект — тебе не нужно начинать с нуля.
Цель — сделать подход больших игровых компаний доступным для небольших команд.
Платформа должна помогать создавать игры разных жанров и для разных устройств:
WebGL, Android, iOS, Steam и других платформ.
Внутри уже есть фундаментальные системы:
• модульная архитектура на
• Onion Architecture с четким разделением слоев;
• ядро, независимое от Unity API;
• Dependency Injection через VContainer;
• State-driven application flow;
• событийное взаимодействие между системами;
• Object Pool;
• система сохранений с миграциями и защитой от отката;
• экономика, инвентарь и прогрессия;
• аналитическая система;
• Remote Config и настройка баланса;
• интеграции рекламы, лидербордов и платформенных сервисов.
Одна из вещей, которой я особенно горжусь — это подход Creative Mode.
Когда ты создаешь рекламные креативы или записываешь геймплей, тебе не нужно создавать отдельные сцены и вручную отключать интерфейс.
Одна настройка — и игра готова для чистой записи.
Кажется мелочью.
Но именно из таких мелочей складывается производственный процесс.
Самое важное:
Я не строю движок в вакууме.
Первый настоящий «картридж» уже существует.
Это игра в стиле Vampire Survivors, но со своей механикой жадности.
Она стала первым реальным тестом платформы.
Именно настоящая игра показывает, где архитектура удобная, а где ее нужно менять.
Каждая новая проблема превращается в улучшение движка.
Я не знаю, насколько большой получится этот проект.
Но я точно знаю одно:
Разработчики должны тратить больше времени на создание игр, а не на бесконечное восстановление одной и той же инфраструктуры.
Это первый пост из серии.
Дальше я буду рассказывать:
— как устроена архитектура внутри;
— почему выбрана модель «консоль / картридж»;
— какие решения пришлось переделывать;
— как из внутреннего инструмента постепенно рождается продукт.
#unity #gamedev
Я строю игровой движок.
Но не совсем такой, каким обычно представляют движок.
Все началось с простой проблемы.
Каждый новый проект начинался одинаково.
Новая игра — и снова:
— система сохранений;
— UI;
— Object Pool;
— Event Bus;
— загрузка контента;
— аналитика;
— настройки;
— менеджеры всего подряд.
В какой-то момент я поймал себя на мысли:
Я создаю не игры.
Я снова и снова строю одну и ту же инфраструктуру.
Сначала мне казалось, что это только моя проблема.
Но чем больше я изучал тему — форумы, обсуждения разработчиков, истории небольших студий — тем больше понимал, что это системная проблема.
Потом я наткнулся на статью The Hidden Cost of Studio Engineering от Deconstructor of Fun. Та самая статья
Главная мысль была очень простой:
Игровые компании постоянно недооценивают стоимость собственной инфраструктуры.
Пока команда строит внутренние инструменты, она не строит игру.
И тогда я понял одну вещь:
Крупные игровые компании уже решили эту проблему.
У них есть внутренние платформы, которые позволяют создавать новые проекты быстрее.
Но у небольших студий и инди-разработчиков часто нет ресурсов, чтобы годами строить такие системы самостоятельно.
Именно эту проблему я хочу решить.
Я строю Enterprise Engine.
Не очередной Unity Framework.
Не набор разрозненных ассетов.
А платформу разработки игр по модели:
Engine = Console
Game = Cartridge
Движок содержит фундамент:
архитектуру, сервисы, инструменты и производственные системы.
А каждая игра становится отдельным картриджем, который подключается к этой платформе.
Удалил игру — движок остался.
Создал новый проект — тебе не нужно начинать с нуля.
Цель — сделать подход больших игровых компаний доступным для небольших команд.
Платформа должна помогать создавать игры разных жанров и для разных устройств:
WebGL, Android, iOS, Steam и других платформ.
Внутри уже есть фундаментальные системы:
• модульная архитектура на
.asmdef;• Onion Architecture с четким разделением слоев;
• ядро, независимое от Unity API;
• Dependency Injection через VContainer;
• State-driven application flow;
• событийное взаимодействие между системами;
• Object Pool;
• система сохранений с миграциями и защитой от отката;
• экономика, инвентарь и прогрессия;
• аналитическая система;
• Remote Config и настройка баланса;
• интеграции рекламы, лидербордов и платформенных сервисов.
Одна из вещей, которой я особенно горжусь — это подход Creative Mode.
Когда ты создаешь рекламные креативы или записываешь геймплей, тебе не нужно создавать отдельные сцены и вручную отключать интерфейс.
Одна настройка — и игра готова для чистой записи.
Кажется мелочью.
Но именно из таких мелочей складывается производственный процесс.
Самое важное:
Я не строю движок в вакууме.
Первый настоящий «картридж» уже существует.
Это игра в стиле Vampire Survivors, но со своей механикой жадности.
Она стала первым реальным тестом платформы.
Именно настоящая игра показывает, где архитектура удобная, а где ее нужно менять.
Каждая новая проблема превращается в улучшение движка.
Я не знаю, насколько большой получится этот проект.
Но я точно знаю одно:
Разработчики должны тратить больше времени на создание игр, а не на бесконечное восстановление одной и той же инфраструктуры.
Это первый пост из серии.
Дальше я буду рассказывать:
— как устроена архитектура внутри;
— почему выбрана модель «консоль / картридж»;
— какие решения пришлось переделывать;
— как из внутреннего инструмента постепенно рождается продукт.
#unity #gamedev
Deconstructor of Fun
The Hidden Cost of Studio Engineering — Deconstructor of Fun
A build-vs-buy breakdown for game studios, showing why internal engineering builds almost always cost more.
❤1
Почему я строю движок по модели «консоль / картридж»
Когда я начал проектировать Enterprise Engine, передо мной встал главный вопрос:
Что именно должен содержать движок?
И еще важнее:
Что НЕ должно находиться внутри движка?
Потому что самая частая проблема игровых проектов выглядит так:
Создается новая игра. Берется старый проект. Копируются папки.
Удаляется ненужное. Переименовываются менеджеры.
Через несколько недель получается еще один проект, где половина кода принадлежит прошлой игре, а половина — новой.
И через некоторое время уже сложно понять:
Где заканчивается движок и начинается игра?
Я хотел решить эту проблему по-другому.
Поэтому основой Enterprise Engine стала модель:
Движок — это консоль.
Игра — это картридж.
Как это работает?
Консоль содержит все, что нужно для производства игр:
— базовую архитектуру;
— систему сохранений;
— аналитику;
— экономику;
— прогрессию;
— UI-систему;
— управление;
— работу с платформами;
— инструменты разработки;
— интеграции сервисов.
Это фундамент.
То, что не должно переписываться каждый раз.
А картридж — это сама игра.
Ее жанр.
Ее механики.
Ее контент.
Ее уникальные решения.
Картридж можно заменить, удалить или создать новый.
Но консоль остается.
Именно это разделение позволяет строить платформу, а не просто очередной игровой проект.
Почему это важно?
Потому что большие игровые компании давно работают похожим образом.
Они не начинают каждый новый проект с пустого файла Unity.
У них есть внутренние технологии, инструменты и системы, которые помогают выпускать новые игры быстрее.
Проблема в том, что у маленьких студий и инди-разработчиков обычно нет ресурсов создавать такую инфраструктуру самостоятельно.
Именно этот разрыв я хочу сократить.
Но настоящая проверка этой идеи — не архитектурная схема.
А реальные игры.
Поэтому Enterprise Engine не строится в вакууме.
Первым картриджем стала игра в стиле Vampire Survivors, но с собственной механикой:
Вместо того чтобы убегать от толпы врагов, игрок получает награду за риск.
Чем дольше он остается внутри опасности — тем выше ставка.
Эта игра заставила движок пройти настоящие испытания:
— система прогрессии;
— экономика;
— баланс;
— телеметрия;
— удаленная настройка параметров;
— работа с контентом.
Но самое интересное впереди.
Сейчас на Enterprise Engine создается второй картридж.
Другой жанр.
Другой игровой цикл.
Другие задачи.
И именно это станет главным тестом:
Я хочу проверить не то, может ли движок поддерживать одну игру.
Я хочу проверить, может ли одна платформа стать фундаментом для разных игр.
Потому что хороший движок — это не тот, на котором сделана одна игра.
Хороший движок — это тот, на котором можно создавать следующую игру быстрее предыдущей.
Продолжение следует.
#unity #gamedev
Когда я начал проектировать Enterprise Engine, передо мной встал главный вопрос:
Что именно должен содержать движок?
И еще важнее:
Что НЕ должно находиться внутри движка?
Потому что самая частая проблема игровых проектов выглядит так:
Создается новая игра. Берется старый проект. Копируются папки.
Удаляется ненужное. Переименовываются менеджеры.
Через несколько недель получается еще один проект, где половина кода принадлежит прошлой игре, а половина — новой.
И через некоторое время уже сложно понять:
Где заканчивается движок и начинается игра?
Я хотел решить эту проблему по-другому.
Поэтому основой Enterprise Engine стала модель:
Движок — это консоль.
Игра — это картридж.
Как это работает?
Консоль содержит все, что нужно для производства игр:
— базовую архитектуру;
— систему сохранений;
— аналитику;
— экономику;
— прогрессию;
— UI-систему;
— управление;
— работу с платформами;
— инструменты разработки;
— интеграции сервисов.
Это фундамент.
То, что не должно переписываться каждый раз.
А картридж — это сама игра.
Ее жанр.
Ее механики.
Ее контент.
Ее уникальные решения.
Картридж можно заменить, удалить или создать новый.
Но консоль остается.
Именно это разделение позволяет строить платформу, а не просто очередной игровой проект.
Почему это важно?
Потому что большие игровые компании давно работают похожим образом.
Они не начинают каждый новый проект с пустого файла Unity.
У них есть внутренние технологии, инструменты и системы, которые помогают выпускать новые игры быстрее.
Проблема в том, что у маленьких студий и инди-разработчиков обычно нет ресурсов создавать такую инфраструктуру самостоятельно.
Именно этот разрыв я хочу сократить.
Но настоящая проверка этой идеи — не архитектурная схема.
А реальные игры.
Поэтому Enterprise Engine не строится в вакууме.
Первым картриджем стала игра в стиле Vampire Survivors, но с собственной механикой:
Вместо того чтобы убегать от толпы врагов, игрок получает награду за риск.
Чем дольше он остается внутри опасности — тем выше ставка.
Эта игра заставила движок пройти настоящие испытания:
— система прогрессии;
— экономика;
— баланс;
— телеметрия;
— удаленная настройка параметров;
— работа с контентом.
Но самое интересное впереди.
Сейчас на Enterprise Engine создается второй картридж.
Другой жанр.
Другой игровой цикл.
Другие задачи.
И именно это станет главным тестом:
Я хочу проверить не то, может ли движок поддерживать одну игру.
Я хочу проверить, может ли одна платформа стать фундаментом для разных игр.
Потому что хороший движок — это не тот, на котором сделана одна игра.
Хороший движок — это тот, на котором можно создавать следующую игру быстрее предыдущей.
Продолжение следует.
#unity #gamedev
Первый тест Enterprise Engine: одна игра построила фундамент, вторая проверила его
В предыдущем посте я рассказывал про модель Enterprise Engine:
Движок — это консоль.
Игра — это картридж.
Но любая архитектурная идея ничего не стоит без проверки реальной разработкой.
Поэтому я решил проверить главный вопрос:
А это действительно универсальная платформа?
Или я просто построил хороший фундамент под одну конкретную игру?
Первым картриджем стал проект в стиле Vampire Survivors.
И здесь важно быть честным:
Он создавался вместе с движком.
За время разработки было сделано 88 коммитов.
Но это не было ускорение.
Это была стройка.
Каждая проблема игры показывала, чего не хватает платформе:
Нужна прогрессия — появляется система прогрессии.
Нужна экономика — появляется экономика.
Нужна аналитика — появляется телеметрия.
Нужна настройка баланса — появляется система tuning.
Первый картридж не просто использовал движок.
Он помог его построить.
А потом появился второй тест.
Совершенно другой жанр. Match-3 puzzle. И вот здесь стало интересно. Эта игра уже не строила ядро. Она подключалась к существующему фундаменту.
Результат:
1 день разработки.
12 коммитов.
За это время игра получила:
— генератор уровней с обратной генерацией и проверкой решаемости через солвер;
— tutorial funnel;
— бустеры (undo, hammer, shuffle);
— адаптивную сложность с сохранением прогресса;
— настройку баланса через ассеты, без изменения кода;
— звук и game-feel через системы движка.
Самое важное:
Я не писал заново:
— сохранения;
— экономику;
— аналитику;
— Object Pool;
— систему обновления;
— базовую архитектуру.
Я просто использовал их.
Именно ради этого я и начал строить Enterprise Engine.
Конечно, обе игры еще находятся в разработке.
Vampire Survivors prototype сейчас ждет полноценный арт и полировку.
Match-3 проект проходит следующий этап — визуальная часть, UI и финальная настройка игрового опыта.
Но технически они уже доказали главное:
Два совершенно разных жанра работают на одном фундаменте.
И вот здесь проходит граница между framework и foundation.
Framework помогает написать игру.
Foundation позволяет строить следующие игры быстрее.
Продолжение следует.
#unity #gamedev
В предыдущем посте я рассказывал про модель Enterprise Engine:
Движок — это консоль.
Игра — это картридж.
Но любая архитектурная идея ничего не стоит без проверки реальной разработкой.
Поэтому я решил проверить главный вопрос:
А это действительно универсальная платформа?
Или я просто построил хороший фундамент под одну конкретную игру?
Первым картриджем стал проект в стиле Vampire Survivors.
И здесь важно быть честным:
Он создавался вместе с движком.
За время разработки было сделано 88 коммитов.
Но это не было ускорение.
Это была стройка.
Каждая проблема игры показывала, чего не хватает платформе:
Нужна прогрессия — появляется система прогрессии.
Нужна экономика — появляется экономика.
Нужна аналитика — появляется телеметрия.
Нужна настройка баланса — появляется система tuning.
Первый картридж не просто использовал движок.
Он помог его построить.
А потом появился второй тест.
Совершенно другой жанр. Match-3 puzzle. И вот здесь стало интересно. Эта игра уже не строила ядро. Она подключалась к существующему фундаменту.
Результат:
1 день разработки.
12 коммитов.
За это время игра получила:
— генератор уровней с обратной генерацией и проверкой решаемости через солвер;
— tutorial funnel;
— бустеры (undo, hammer, shuffle);
— адаптивную сложность с сохранением прогресса;
— настройку баланса через ассеты, без изменения кода;
— звук и game-feel через системы движка.
Самое важное:
Я не писал заново:
— сохранения;
— экономику;
— аналитику;
— Object Pool;
— систему обновления;
— базовую архитектуру.
Я просто использовал их.
Именно ради этого я и начал строить Enterprise Engine.
Конечно, обе игры еще находятся в разработке.
Vampire Survivors prototype сейчас ждет полноценный арт и полировку.
Match-3 проект проходит следующий этап — визуальная часть, UI и финальная настройка игрового опыта.
Но технически они уже доказали главное:
Два совершенно разных жанра работают на одном фундаменте.
И вот здесь проходит граница между framework и foundation.
Framework помогает написать игру.
Foundation позволяет строить следующие игры быстрее.
Продолжение следует.
#unity #gamedev
❤1
Forwarded from Professor Che (Professor Che)
Сегодня я стал еще на шаг ближе к своей мечте о геймдеве) на протяжении недели полной страданий и радостей я смог придумать персонажа для нашей следующей игры, которая уже будет в 3d, сделать эскиз, потом по нему создать модель, текстурировать ее, сделать риг и закинуть в движок unity, добавить анимации, накосячить в процессе везде где только можно, переделать все 10 раз и в итоге все работает🤯
Кстати наша первая игра “How high" уже полностью готова, но у нас возникли трудности с регистрацией на площадке google, очень надеюсь решить эту проблему в течении августа и если все пойдет по плану, то в сентябре вы уже сможете в нее сыграть
Кстати наша первая игра “How high" уже полностью готова, но у нас возникли трудности с регистрацией на площадке google, очень надеюсь решить эту проблему в течении августа и если все пойдет по плану, то в сентябре вы уже сможете в нее сыграть
👍1🔥1
Я не публиковал обновлений о нашем движке уже некоторое время.
И на то есть причина: сейчас движок тестируется уже на реальных играх.
В данный момент у нас в разработке несколько проектов разных жанров, и мы используем их, чтобы проверять движок в реальных production-условиях.
Сегодня хочу представить одну из этих игр — Blood Rave.
Изначально она создавалась как тестовый проект, но в какой-то момент стала одной из наших главных надежд.
Blood Rave — это bullet heaven, вдохновлённый Vampire Survivors, под жёсткое детройтское техно. Мы не пытаемся изобрести жанр заново. Вместо этого мы делаем большой упор на визуальный стиль, атмосферу и одну ключевую игровую идею — жадность.
В большинстве survival-игр ты стараешься держаться подальше от врагов.
В Blood Rave ты хочешь быть как можно ближе к ним.
Чем глубже ты заходишь в толпу, тем быстрее растёт твой множитель и тем больше денег ты зарабатываешь.
Но есть нюанс.
Чем дольше ты остаёшься, тем опаснее становится. В любой момент ты можешь зафиксировать заработанное —
И на то есть причина: сейчас движок тестируется уже на реальных играх.
В данный момент у нас в разработке несколько проектов разных жанров, и мы используем их, чтобы проверять движок в реальных production-условиях.
Сегодня хочу представить одну из этих игр — Blood Rave.
Изначально она создавалась как тестовый проект, но в какой-то момент стала одной из наших главных надежд.
Blood Rave — это bullet heaven, вдохновлённый Vampire Survivors, под жёсткое детройтское техно. Мы не пытаемся изобрести жанр заново. Вместо этого мы делаем большой упор на визуальный стиль, атмосферу и одну ключевую игровую идею — жадность.
В большинстве survival-игр ты стараешься держаться подальше от врагов.
В Blood Rave ты хочешь быть как можно ближе к ним.
Чем глубже ты заходишь в толпу, тем быстрее растёт твой множитель и тем больше денег ты зарабатываешь.
Но есть нюанс.
Чем дольше ты остаёшься, тем опаснее становится. В любой момент ты можешь зафиксировать заработанное —
🔥1
Игра моей первой команды в которой я был в роли Unity developer обрела страницу в steam. Приятно видеть,что проект начатый на энтузиазме достаточно не маленькой командой,которую собрал очень крутой Алексей Алешин планомерно идет к цели и там есть частичка моей работы.
Добавляйте в вишлисты🫶🏻
Indie dev forever✊🏻
https://store.steampowered.com/app/3220640/Synvector/
Добавляйте в вишлисты🫶🏻
Indie dev forever✊🏻
https://store.steampowered.com/app/3220640/Synvector/
Steampowered
Synvector on Steam
Real-time sci-fi action RPG with tactical pause. Command your mercenary fleet, coordinate squadrons through a command interface, and switch between squadron commanders. Four races, one spiral arm, one unstoppable swarm. Nothing personal. Just contract.
❤2