Тестирую, насколько концепция "Write once, run anywhere" работает на практике. Цель - один jar с 3D-игрой, который работает на 4х-платформах - J2ME, Windows, Linux, OS X. Кроме того, демку можно будет запустить на первых Android-смартфонах в мире (в Android dex вместо обычного jvm-байткода, поэтому не перечислил в списке основных платформ) и если у меня появится BlackBerry с GLES по типу 8900 - то и на нем. Само собой о разработке демки будет статья.
Как защитить игровой сюжет?
Игра — это сложный мультимедийный объект.
Дизайн коробки, игрового поля, программный код, видеоролики, музыка, шрифты и тексты, которые поясняют правила, — все это может защищаться свидетельствами и патентами.
Как это выглядит на практике?
Авторские права действуют на сюжетную сценарную линию и на персонажей, которые обладают уникальными характеристиками. Последних, кстати, можно зарегистрировать также в качестве товарных знаков.
Смежные права на игру возникают у всех создателей (например, тех, кто «подарил» героям свои движения и голос).
Если в игре используются неочевидные схемы взаимодействия между пользователями, то в этом случае разрешается оформить патент на изобретение. Аналогично следует действовать, если создатели придумали какой-нибудь интересный интерфейс (его можно зарегистрировать как промышленный образец или патент на дизайн).
Я создал интересную (и свою) сюжетную линию, а кто-то ее скопировал. Как мне защищаться?
Только в суде, соблюдая обязательный досудебный претензионный порядок.
В любом случае предстоит доказывать, что сценарные повороты, придуманные вами и заимствованные нарушителем, идентичны (а не прямо пародийны). Если правоприменитель установит, что использована была лишь идея, то в этом случае санкций не последует.
Учитывайте, что не всякое копирование идеи разрешено. Если конкурент взял концепт без серьезной модификации, сдублировал полностью размеры игрового поля, движение (и цвета) фигур, визуальные подсказки, то в этом случае (даже если придумка была выражена при помощи других технических решений) — разработчика признают виновным в нарушении авторских прав. Но то за рубежом.
Онлайн Патент ранее констатировал, что российская практика не имеет широко известных примеров разбирательств такого формата. Если в РФ споры и возникают, то могут решаться в досудебном порядке.
Как наиболее удобный вариант можно зарегистрировать игру как программу для ЭВМ в Роспатенте и даже внести ее в Реестр отечественного ПО. В последнем случае Вы сможете претендовать на существенные налоговые льготы.
Книги для разработчиков игр
Хочу прочитать что-то из индустрии разработки игр. Что бы вы посоветовали? Какие книги вдохновили вас или помогли лучше понять процесс создания игр?
Поделитесь в комментариях, что сами планируете прочесть или уже прочли. Давайте вместе соберем полезную подборку книг, которые точно стоит изучить.
Проект Minecraft 2 в разработке — создатель оригинала Нотч анонсировал продолжение любимой игры. Рабочее название — Adventureland. Сейчас разработчик выбирает сеттинг будущей игры: это будет космическое приключение или игра в стимпанк стиле.
Хронология:
В сентябре прошлого года Notch поделился ранним геймплеем своей новой игры, которая похожа на что‑то между Dungeons & Dragons и Super Hot — dungeon crawler с элементами rogue‑like.
1 января разработчик устроил опрос, где спросил, чего бы от него ждали больше — Minecraft 2 или другую новую игру. Minecraft выиграл с отрывом.
3 января Notch написал, что «по сути, анонсировал Minecraft 2», так как, во‑первых, этого от него и ждут и во‑вторых — его новая игра похожа на Minecraft.
«Мои намерения — быть ясным и честным по этому поводу, говоря, что духовные преемники обычно как‑то... знаете... выброшены на ветер. Трагично. Я боюсь, что моя следующая игра будет [выброшена на ветер], и стараюсь избегать этого. Так почему бы мне не сделать [духовного наследника Minecraft], чего люди действительно хотят и за что готовы дать мне, каким‑то образом, даже больше денег», — пояснил Notch.
Неоднозначный MVC: причины и следствия
Уровень материала: 🐥 #middle
Ранее я писал, что прохожу обучение на курсе от Unity Architect. Недавно была тема, посвященная MVC. И упор был сделан не на очередной разбор очередной реализации, а на выяснение причин, почему существует такое разнообразие трактовок. Из этого вытекают и некоторые следствия, о которых не часто рассказывают, но которые находят место в практике.
Про разнообразие подходов 🛠️ :
Причина такого раздрая — «так исторически сложилось». Когда по принципу «глухого телефона» революционный много десятилетий назад подход дошёл до наших современных дней.
Подробнее с этим можно ознакомиться в длинном исследовательском материале из двух частей на Хабре: #1 и #2. Текст объёмный и сложный. Но увлекательный. Для вдумчивого чтения (а иначе смысла нет) стоит заложить на обе статьи где-то 1 час.
А один из примеров реализации в геймдеве я шарил в этом посте.
Следствие 1️⃣:
MVC — это изначально история про взаимодействие с пользователем. Т. е. про UI. Соответственно, попытки затащить это в геймплей сделают из MVC не MVC (и даже не обязательно какой-то MVx). Т. к. для удобства использования в геймплее эту штуку приходится адаптировать.
Следствие 2️⃣:
Как бы ни был «приготовлен» MVC, кто-то обязательно скажет, что это неправильно. Или это не MVC, а какой-нибудь другой MVx. Это бесконечные бессмысленные споры, стоящие на противоречивых источниках.
Чтобы не маячить красным платком перед «искушённой» публикой, можно отойти от общеизвестного нейминга. Соблюсти идею разделения визуала и бизнес-логики, но назвать это иначе. Особенно легко это делается в геймплее.
Ведь задача — спроектировать всё хорошо, а не сдать экзамен по «эталонному соответствию канонам». Тогда на нападки в виде «но в MVx же...» можно отвечать «а это не MVx».
Следствие 3️⃣:
Эталонно View и Controller находятся на одном слое взаимодействия с пользователем. И в современных системах, где нет низкоуровневого кода по непосредственно рендерингу и обработке ввода, контроллер как-таковой не шибко нужен. Поэтому достаточно использовать только Model и View.
В качестве Model можно подготовить специальную прослойку, типа Facade, Adapter или Mediator, которая будет агрегировать внутри всю коммуникацию с необходимыми игровыми моделями и сервисами.
Например, нажалась кнопочка, медиатор из WalletModel снял монетки, в StorageModel положил конфетки, а у AdService запросил показ InterstitialAd.
В свою очередь View будет отвечать за всю логику представления (кнопочки, формочки, генерация карточек, анимации прокрутки, заполнение прогресс-баров и пр.) и передачу событий в Mediator.
Связку из View и Mediator я и в своей команде использую уже очень давно — это отлично себя показывает в проектах разных масштабов.
На каком-то из стримов K-Syndicate оговаривались, что используют двухуровневый шаблон и связующий слой тоже называют Mediator. Не нашёл, на каком именно, но у них был большой классный стрим по MVx в целом.
————————————
#unity #gamedev #development #architecture #mvc #mvx #геймдев #разработка #архитектура #рекомендация #статья #видео
📼 Видео-заметка про пользовательские соглашения в Web-играх 📼
Решил попробовать использовать ранее выпущенную заметку про пользовательские соглашения в Web-играх в качестве сценария и записать видео. Свои мысли по этому опыту оставил ниже.
Заниматься этим, конечно, вообще было некогда. Поэтому почти месяц по чайной ложке в «свободное время» я практиковался в моушн-дизайне и учился монтировать и компенсировать отсутствие пригодного для записи роликов оборудования. В сравнении с прошлым роликом, на мой взгляд, звук уже накрутил получше.
Предыдущее видео снималось в полной импровизации без какого-либо сценария. Поэтому много времени ушло на нарезку и аккуратную склейку. Сейчас этой проблемы не было, но уже много времени ушло на поиск и реализацию визуальных эффектов.
⬇️ Какие выводы я сделал за два снятых ролика:
Лучше заранее потратить время на сценарий.
Лучше на записи обеспечить интересный визуальный ряд (хотя бы трансляцией экрана), чем заниматься этим на пост-продакшене.
Видео-блоггинг в соло требует колоссального кол-ва времени и навыков, никак не связанных с разработкой. Без команды качественно заниматься этим можно только в ущерб разработке и повышению компетенций (если не трогать семью, хобби, здоровье и пр. важные вещи).
Снимать видео я буду редко – лучше почаще на конференции поезжу 😂
—————————————
#gamedev #development #gdpr #privacy #web #webgl #конфиденциальность #соглашения #защитаданных #юридическое #веб #разработка #геймдев #игры #aks2dio #видео
👣 Инсайт про Unity AI Navigation 🧭
Уровень материала: 🐣 #junior
Unity выпустили серию роликов о своей системе AI Navigation. Вышло три видео (#1, #2, #3). В целом, очень полезный для знакомства с системой контент — Unity вообще радуют последние годы в этом плане. Но меня во время просмотра посетила любопытная мысль 💡
AI Navigation — это новое название пакета NavMesh. И у старых версий была неприятная особенность: строил навигацию он только на плоскости XZ. И неприятность в том, что для 2D-игр Unity использует плоскость XY 👾
Соответственно, 2D-игры ради навигации были вынуждены или искать/изобретать другие решения (пример), или использовать костыль: "разворачивать" свои спрайты так, чтобы они лежали на плоскости XZ. Были даже отдельные решения, основанные на этом ухищрении 🩼
[Форум с обсуждением]
Т.к. уже давно не работал с 2D-проектами, не придавал этому значения. И сейчас смотрю на видео и вижу, как настраивается навигация на вертикальной стене, на плоскости XY. Похоже, Unity теперь умеет полноценно в навигацию для 2D. Кто в 2D уже пробовал и может подтвердить или опровергнуть ❓
—————————————
#unity #gamedev #development #pathfinding #navigation #insight #разработка #геймдев #навигация #поискпути #рекомендация #видео
⏯️ Про создание реплеев для игр ⏺️
Уровень материала: 🐥 #middle
Хочу поделиться свежим полезным видео с реализацией системы реплеев. И дополнить своими комментариями. Однажды такая фича может потребоваться, и было бы здорово знать, в какую сторону начинать думать.
🔎 Суть реплея:
Чтобы иметь возможность когда-то потом восстановить игровой процесс, необходимо во время этого игрового процесса записывать минимальный набор данных, необходимый для восстановления игровой сессии в конкретный момент времени. Всегда.
Чем меньше данных, тем более легковесным получится файл реплея. А это важно, ведь его надо хранить (ROM), читать (CPU), загружать (RAM) и возможно даже передавать по сети (Network).
Например, если поворот персонажа полностью восстанавливается из его направления движения, то достаточно записать только направление движения. И записывать его только тогда, когда оно изменится, а не просто каждые N сек. И т.д. Всё, как при синхронизации данных в мультиплеере.
Лучший вариант, когда игра детерминирована (т.е. при одинаковых вводных будет происходить всегда одно и то же). Тогда достаточно только записывать инпут от игрока с отметками времени и во время реплея его применять. Минимум данных, но детерминированность имеется (или хотя бы вообще возможна) не во всех проектах. Особенно в Unity с её недетерминированной физикой.
📐 Зачем нужен:
Помимо понятной для игрока функции «посмотреть, как эффектно я пробежал этот уровень» или возможности разрешить спорные моменты в соревновательных играх, эта механика может быть полезна в не пользовательских сценариях.
В сервисных играх реплей полезен для отправки сессии на валидацию сервером, чтобы уличить мошенника в нечестных манипуляциях.
Реплей может помочь с отладкой игры. Или с воспроизведением бага, который нашёл QA или какой-то игрок.
Реплеи, собираемые с игроков, можно анализировать и в результате совершенствовать пользовательский опыт (или монетизационные подходы).
По реплеям можно тестировать игровой баланс и прорабатывать его детальнее.
Реплеи можно использовать для создания маркетинговых материалов, т.к. на таком пост-продакшене можно усилить эффектность геймплея через иную настройку камеры, редактирование окружения, добавление всяческих эффектов и пр.
Т.е. отсутствие возможности реплея в самой игре как механики ещё не гарантирует её отсутствия как части проекта. И это стоит учитывать при проектировании очередного проекта.
————————————
#gamedev #development #feature #tool #replay #геймдев #разработка #механика #рекомендация #видео
Мы 12 лет делали текстовую Zero Player MMORPG на русском языке, иногда я писал об этом на Хабре (1, 2, 3, 4).
Теперь мы открываем лор игры под лицензией CC BY 4.0.
Сайт с лором: https://the-tale.notion.site/
Что мы шарим:
195 художественных описаний монстров;
403 художественных описания артефактов;
177 описаний дополнительных существ (спутники героев);
85 художественных текстов о разных аспектах жизни во вселенной игры;
25 текстов с описанием логики мира, частично художественных, частично технических;
Pixelart sprite sheets для карты и некоторые иконки.
Лицензия CC BY 4.0 значит, что вы можете почти всё: копировать и распространять, изменять и перерабатывать — даже в коммерческих целях. При условии, что указываете лицензию, оригинальных авторов и внесённые изменения.
Мы с друзьями надеемся, что наши наработки окажутся полезными начинающим разработчикам и авторам.
P.S. За всё время в игру активно играло 39 000 человек, игроки написали больше 1 000 фанфиков, создали огромное количество фанарта, несколько текстовых квестов по миру игры, и оставили больше 270 000 сообщений на форуме. Поэтому, пусть лор и не уровня ААА игр, есть основания предполагать, что он достаточно увлекательный.
Обещанная статья о том как я примазался к самой успешной игровой студии в Мире и создал логотип для сообщества. В конце галерея уродов от нейросети с моими комментариями:
https://vk.com/@orkstargames-kak-ya-primazalsya-k-samoi-uspeshnoi-videoigrovoi-studii-v-m
📝 Заметка про собеседования 📝
Уровень материала: 🦉 #management
На днях выходила статья по собеседованиям на Unity. Вышла уже аж вторая редакция. Первая содержала «контент не для слабонервных». Жаль, что его по итогу вырезали — это был очень полезный опыт из реальной корпоративной практики. Тем не менее, всё полезное для широкого круга читателей осталось. В т. ч. отличные советы, под которыми я ставлю свои «+».
Процессы проведения собеседований — очень индивидуальная штука, и везде всё устроено по-разному. Есть вводные у кандидата, у команды, у проектов, у бюджета и т. д. Между ними приходится как-то балансировать и искать наиболее равновесную точку. Общего рецепта, как это сделать, нет. Только разве что «нормально делай — нормально будет». Поделюсь коротенько тем, как это делаю я.
1️⃣ Я стараюсь проводить собеседования наименее ресурсозатратно и для себя, и для кандидата. Мои целевые показатели — 30 мин на интервью, 30 мин на подготовку (но реальные медианные будут побольше 👺). Подготовка — это осмотр резюме, изучение информации о кандидате и прошлых местах работы в сети, знакомство с проектами и кодом.
2️⃣ Для меня код (если нужен программист) — ключевой и самый говорящий фактор. ТЗ я давать не люблю: стараюсь обходиться петами кандидатов. Но если посмотреть нечего или нет проектов с релевантными технологиями, то выдаю ТЗ на какие-то отдельные конкретные моменты, которые бы мне хотелось прояснить. Или посмотреть, насколько хорошо удастся разобраться с новой технологией.
Правда, если кандидатов много, то всё приходится усреднять и ставить на поток. Иначе основной рабочий процесс будет саботирован. Главное, чтобы на ТЗ уходило минимальное количество времени. В конце концов, и мне же это потом смотреть. Поэтому с каждой новой волной найма я стараюсь оптимизировать коллекцию заданий.
3️⃣ Интервью — самый дорогой этап с точки зрения времени и организации, поэтому он обычно остаётся на самый конец (чтобы оставалась возможность до него не дойти). Но если попадается интересное резюме, то могу сразу и перейти к нему, пропустив или отложив этап «кода».
Я перестал открыто гонять кандидатов по техническим вопросам. Более эффективным нахожу обычное общение про опыт, компетенции, практические кейсы и т. д. И в процессе, если натыкаюсь на что-то значимое и шаткое, начинаю копать глубже.
❗Причём я считаю очень важным давать свои комментарии на темы, в которых кандидат не смог достаточно раскрыться. Пусть он уйдёт, если без оффера, то хотя бы с новыми знаниями.
Из-за специфики разработки мне часто важно, чтобы новые члены команды были заинтересованы в продолжительном сотрудничестве. Поэтому на интервью я стараюсь определить ценности, мотивацию и цели кандидата. Что он понимает, куда и почему собеседуется, а не пытается просто запрыгнуть хоть куда-нибудь на какое-то время. И, со своей стороны, искренне даю все вводные. Для взаимовыгодного и плодотворного сотрудничества нужна обоюдная совместимость 🤝
————————————
#gamedev #development #hiring #interview #геймдев #разработка #найм #собеседование #рекомендация #статья
🏗️ Темы по архитектуре для инженеров ПО💪
Уровень материала: 🐓 #senior
Разгребая бэклог, добрался до поста канала S0ER с «темами по архитектуре, которые должны входить в архитектурный минимум каждого инженера». Структуризация, возможно, спорная, но это авторское видение, и если «душность» оставить за скобками, то ещё и очень хорошая система тегов для профессионального развития.
✍ По схеме у меня есть ряд пробелов, которые я планирую заполнить. Но с большей частью за свою карьеру я в том или ином виде успел повзаимодействовать.
☝ Пользуясь случаем, напомню, что игры — это тоже ПО. А разработка ПО — инженерная дисциплина. У игр, несомненно, есть своя специфика, но она никак не отменяет всего остального инженерного бэкграунда. Особенно, когда работаешь не только на клиентской части.
🤓 Скорее всего, вся эта «техническая канитель» не нужна людям, которые идут в геймдев ради творчества и самореализации через инди-проекты в инди-командах. Но если ты осознаёшь себя программистом, осознаёшь геймдев своей специализацией, хочешь уметь разрабатывать более сложные продукты, развиваться как профессионал, расширять зону ответственности, приносить больше ценности для своей команды и, как следствие, в какой-то форме для себя, то (-записывайся на курс-) держи бесплатную верхнеуровневую роудмапу для расширения своих компетенций. Корреляция с игровыми проектами произойдёт сама собой по мере получения большего опыта в сфере.
🎥 Можно ещё побродить по YouTube-каналу S0ER'а. Видео не выходили давно, но контента там уже накопилось много. Например, я недавно пересматривал видео по KISS, чтобы освежить в памяти некоторые красноречивые пункты.
🕸 Схема в текстовом виде:
Архитектура:
|- Требования:
|---- Функциональные
|---- Нефункциональные
|---- Производные
|---- Пользовательские истории
|- Принципы:
|---- Границы: толстые, тонкие
|---- YAGNI
|---- KISS
|---- DRY
|- Подходы:
|---- Проектные
|---- Продуктовые
|- Методология:
|---- DDD: тактика, стратегия
|---- Agile: SCRUM, экстремальное программирование
|---- Waterfall: сверху вниз, снизу вверх
|- Процессы:
|---- Документирование: BPMN, UML
|---- Проектирование: ADR, C4
|---- Выпуск: версионирование, CI/CD
|- Уровень предприятия:
|---- ITIL
|---- PRINCE2
|- Облачная архитектура
|- Проектирование и разработка:
|---- Уровень кода:
|------- Шаблоны проектирования (GoF)
|------- Парадигмы:
|---------- ООП: SOLID, GRASP, DI
|---------- ФП
|---- Уровень приложения:
|------- Концепции:
|---------- Реактивная архитектура
|---------- Чистая архитектура
|---------- Порты и адаптеры
|---------- Feature Sliced
|------- Структура:
|---------- Монолит
|---------- Сервис
|---------- Микросервис
|---------- Микроядро/плагин
|------- Данные:
|---------- Потоки данных: CQRS, Конвейер/pipe, pub/sub, SAGA
|---------- Целостность: BASE, ACID
|---- Системный уровень:
|------- Данные: Data Lake, Data Mesh
————————————
#gamedev #development #architecture #roadmap #software #геймдев #разработка #архитектура #по #рекомендация
🏗️ Cell-Based Architecture и EventBus 🚌
Уровень материала: 🐥 #middle
Сейчас будет немного спорный контент: так и не смог ёмко и лаконично выразить мысль, а раздувать статью из этого не хочется. Но всё же. Просматривал небольшую обзорную статью про Cell-Based Architecture из своего бэклога. И глаз зацепился об одну занятную мелочь.
Эта мелочь — EventBus. Про него можно посмотреть, например, тут и тут. Что я хотел отметить: обрати внимание на положение EventBus'а на схеме. Сейчас маленько «сову на глобус», но замени клетки на отдельные логические модули из своего игрового проекта — у них, как и у клеток, тоже должен быть высокий Cohesion (и низкий Coupling по GRASP'у). Это могут быть, например, CoreGame и MetaGame или Presentation-слой и Business-слой. И посмотри на положение EventBus'а ещё раз.
EventBus — это один из способов коммуникации между модулями. Он «связывает» большие самодостаточные модули между собой, обеспечивая им низкий Coupling, что позволяет им быть отдельными переиспользуемыми образованиями, а не одним большим неразрывным «куском кода».
Он не находится внутри модуля. У модуля есть только тычка Events для общения с EventBus. А внутри модуля коммуникация производится более явно. В т.ч. через «классические» события, которые не требуют дополнительных слоёв абстракций, как в EventBus.
Почему-то так сложилось, и почему-то преимущественно в геймдеве (в других сферах, по крайней мере, я не встречал), что на его основе пытаются стряпать проекты прям «от и до». Пример: тык. Даже на дорогостоящих курсах про это рассказывают.
Но EventBus — не для того, чтобы в проекте всё подряд сделать несвязанным. Если всё не связано — значит, связано всё, только неявно, что ещё хуже.
Чтобы убедиться, достаточно самостоятельно «сунуть пальцы в розетку». Вот инструкция:
сделать проект на >5000 строк собственного кода на основе EventBus,
запланировать масштабную геймплейную фичу,
забыть о проекте на две недельки,
вернуться в проект и сделать эту фичу,
оценить пережитый опыт от 0 до 10 по шкале «спасибо, до свидания».
EventBus — это не плохо, если использовать по назначению. Это инструмент для связи того, что быть связанным напрямую не должно. И чем такого будет меньше, тем лучше. Поэтому подход неплохо приживается на более верхних слоях, где элементов взаимодействия меньше. Но на более низких — часто превращает проект в очень запутанную и сложно контролируемую историю.
Есть исключения. Не всё так просто. Бывают кейсы, где и игровую логику удобно сделать на EventBus. Только название у этого будет более контекстное, а область использования — ограничена этой игровой логикой. Т.е. это будет не совсем EventBus, а иная структура, по реализации похожая на EventBus.
————————————
#gamedev #development #architecture #eventbus #геймдев #разработка #архитектура #рекомендация #статья
♾️ Рекомендация видео по старту в CI/CD ♾️
Уровень материала: 🐓 #senior
У Артёма Шумейко ещё не очень давно вышло два видео, посвящённых CI/CD. Одно теоретическое, другое — практическое. И вот второе мне очень даже понравилось — хочется им поделиться. К тому же ранее я уже рекомендовал его видео по деплою приложений, а CI/CD можно рассматривать как автоматизацию этого процесса.
🤔 При чём тут геймдев:
Указанный уровень материала очень условный. Вопросы CI/CD "официально" не входят в область GameDev-специальности, а уж тем более middle-уровня. Но навык это незатейливый и очень полезный на любом уровне специализации. Полезный и для корпоративной жизни, и для личной — навести автоматизацию на своих петах тоже удобно. А достопочтенному senior'у как-будто бы даже зазорно не уметь в такое хотя бы на уровне теории.
В больших компашках на 100+ человек обычно есть выделенные devops-человечки. И обычно они постоянно заняты, т.к. обязанностей у них предостаточно. Оперативно решить вопросики с CI\CD малого масштаба можно самостоятельно — тут и поможет накопленная экспертиза.
Или можно угодить в коллектив поменьше или того страшнее — собрать его самому. Тогда автоматизируешь рутину и повысишь эффективность команды или ты, или никто.
Запустить автотесты, собрать билд, собрать бандлы, задеплоить бандлы, опубликовать приложение во внутреннее тестирование — как часто это приходится делать и как много это времени занимает, если делать всё вручную. А если ещё есть какие-то зависимые сервера и прочая инфраструктура, то всё становится в разы увлекательнее. В какой-то момент становится выгоднее посидеть денёк другой и всё разочек автоматизировать, чем продолжать тратить время на эту рутину.
☝️ Что хорошего в видео:
Этот ролик — пока самое лучшее из того, что я видел вводного по теме. Он короткий, он по делу, он ёмкий и понятный, он легко и интересно смотрится, он наглядный и качественно сделанный.
Показан весь путь автоматизации: от самого процесса выбора, аренды и настройки сервера до непосредственного автоматизированного деплоя приложения. Хоть тут же повторяй, даже если понятия не имеешь, где и как брать сервера.
И сам пример хорошо демонстрирует для чего нужен CI/CD, для чего нужны тесты, почему важно это всё автоматизировать и почаще гонять.
Gitlab, возможно, не самое популярное решение в геймдеве: я обычно встречаю Jenkins и TeamCity (и изредка Unity Build Automation). И т.к. сборка игрового проекта занятие продолжительное и тяжеловесное, то и сборки делаются не так часто, как об этом пишут применительно к другим сферам. Особенно если проектов много, а машинок для сборки — чуть-чуть или вообще одна. Но на уровне идеи это всё не имеет значения: процессы примерно одинаковые во всех системах и для разной природы проектов. А как выглядит дашборд и какие цифры ставить в настройках — дело наживное.
—————————————
#gamedev #development #backend #infrastructure #devops #cicd #геймдев #разработка #бэкенд #девопс #инфраструктура #автоматизация #рекомендация #видео
🧠 Инсайты про применение LLM 🧠
Уровень материала: 🦉 #management
Пока в столице гремел РЭД, я на выходных посещал другую локальную конференцию — KD Conf. Помимо приятного чувства, что на конференцию не надо никуда лететь/ехать, подхватил два интересных инсайта про внедрение LLM-моделей в процессы:
📃 Можно валидировать ГДД:
Проверить документ на противоречивость информации.
Проверить документ на достаточность информации.
Отформатировать документ под конкретный отдел. Т.е. переоформить так, чтобы с доком было удобно работать программистам, художникам и т.д.
🏷️ Можно валидировать описания для задач:
Проверить, что описание соответствует шаблону.
Проверить, что информация релевантная, а не ради удовлетворения шаблона.
Проверить, что предоставленной информации достаточно для выполнения задачи.
Делать это можно вручную, по необходимости, или автоматизированно через API.
Нужно только подобрать подходящий для команды набор промтов и следить, чтобы нейронка не нагаллюционировала лишнего 🤩
В этой схеме есть две явные проблемы — это конфиденциальность🛡️ и стоимость запросов 💵
Решается это развёртыванием внутренней корпоративной LLM. На конференции я чаще всего слышал про Llama от Meta. И мы в команде тоже как раз смотрим в сторону этого решения.
Мероприятие было «не геймдевное» — весь этот опыт исходил от энтерпрайза, банкинга и прочего бигтеха. Поэтому интересно, пробовали ли кто уже в геймдеве вводить в процессы подобные инструменты❓
————————————
#gamedev #development #llm #ai #pipeline #геймдев #разработка #процессы #управление #ии #вопрос
🗞️ Свежая стажировка в геймдеве 🗞️
✍️ Коллеги из Unigine опубликовали объявление на новую стажировку. В этот раз для технических писателей. Про то, кто это такой и зачем, можно почитать ещё свежую статью на Хабре, уже старенький доклад от самих же Unigine и информацию в самом объявлении.
💡 Это хорошая возможность запустить свою карьеру в индустрии и поработать над реальным, крупным, глобальным и сложным проектом. У ребят частые, мощные и интересные стажировки. И сами они скилловые, дружелюбные и открытые — в этом просто убедиться, лично пообщавшись с ними на игровых конференциях.
—————————————
#development #gamedev #intern #engine #techwriter #news #разработка #стажировка #геймдев #рекомендация #новости
⏱ Природа DeltaTime ⏱
Уровень материала: 🐣 #junior
Интересная коротенькая статья про то, как устроено deltaTime в игровых движках. Никакого откровения нет, если внимательно прочитать само определение параметра в документации к движку (например, Unity). Но всё равно найдутся те, для кого это может оказаться неожиданностью.
А не зная, как работает инструмент, можно получить неожиданное поведение при использовании.
Рекомендую также заглянуть в Appendix — там есть ссылки на более углубленные статьи: про нюансы отрисовки, общение между CPU и GPU, способы определения deltaTime, влияние параметра maxQueuedFrames и особенности работы при vSync.
Это контент посложнее, но, если заинтересует, уже будет понятно, в какую сторону рулить поисковые запросы и промпты для чат-ботов.
p.s. может потребоваться VPN.
—————————————
#gamedev #development #graphics #gpu #cpu #render #разработка #геймдев #статья #рекомендация
📅 MidUp #4 📅
🎄 Последняя в этом году подборка GameDev и IT мероприятий, которые встретил в чатах, группах и просто в сети. Митапы, конференции, фестивали, джемы, конкурсы и другое.
>> предыдущая подборка <<
🔹🔹 Декабрь: 🔹🔹
🧑💻🎤🎫 2 и 3 декабря. Мск [Offline] [Online] HighLoad++ 2024. "Сколково". Билеты от 41 000 ₽.
🧑💻🎤🆓 3 декабря. Екатеринбург [Offline] Frontend Meetup. Технохаб Сбера. Бесплатно.
🧑💻🎤🆓 5 декабря. Вологда. [Offline] Sber IT Talk. Картинная галерея. Бесплатно.
🧑💻🎤🆓 5 декабря. Мск [Offline] [Online] OS DevConf. Бесплатно.
🧑💻🎤🎫 6—7 декабря. Спб [Offline] [Online] Питерский промпт. Airportcity Plaza. Билеты от 4 900 ₽.
🧑💻🎤🎫 6 декабря Мск. [Offline] RustCon. Holiday Inn. Билеты от 20 000 ₽.
🧑💻🎤🎫 6 декабря Мск. [Offline] [Online] Conversations 2024. Radisson Blu Olympiyskiy Hotel. Билеты от 34 900 ₽.
👾🏆🆓 5-8 декабря [Online] GamePush Profit Jam. Бесплатно.
👾🎤🆓 7 декабря. Спб. [Offline] [Online] Митап геймдев изнутри. Точка Кипения. Бесплатно.
👾🎤🆓 8 декабря. Мск. [Online] Индикатор Шрёдингера. Библиотека для молодёжи. Бесплатно.
👾🎤🆓 8 декабря. Мск. [Offline] Лекция по Level Art. Artplay. Бесплатно.
👾🎤🆓 11 декабря. Спб. [Offline] [Online] Selectel GameDev Meetup. Цветочная, 19. Бесплатно.
🧑💻🎤🆓 11-13 декабря. Мск [Offline] [Online] AI Journey. Офис Сбербанк. Бесплатно.
🧑💻🎤🆓 12 декабря. Мск [Offline] Киберсъезд. Кибердом. Бесплатно.
🧑💻🎤🆓 14 декабря. Мск [Offline] [Online] DevRel Conf. T-Space. Бесплатно.
🧑💻🎤🆓 14 декабря. Мск [Offline] Ночь опенсорс библиотек. Библиотека иностранной литературы. Бесплатно.
👾🍻🆓 14 декабря. Екатеринбург [Offline] Ural Game Night. Бесплатно.
👾🏆🆓 17 декабря. Калининград [Offline] ART GameJam. Резаниум. Бесплатно.
👾🍻🆓 19 декабря. Новосибирск [Offline] GameDev Meetup. Shredder Pizza. Бесплатно.
👾🎤🆓 21 декабря. Спб [Offline] Новогодний митап. Библиотека №5. Бесплатно.
👾🍻🆓 26 декабря. Новосибирск [Online] Покажи и Расскажи. Бесплатно.
Знаешь какие-то ещё интересные события, особенно в регионах — оставляй информацию в комментариях 👇
—————————————
#it #development #gamedev #gamejam #meetup #conference #разработка #айти #геймдев #конференция #митап #событие #подборка
🆓 Бесплатные курсы с YouTube 🆓
Уровень материала: 🎓 #education
На YouTube-канале CodeMonkey недавно вышло два больших видео, два бесплатных курса. Это 12-часовой курс по C# и 7-часовой курс по DOTS. Я их ещё не просмотрел и не могу объективно оценить. Но если вдруг какой-то подобный контент был как раз нужен — возможно это оно. Ранее там же выходил ещё курс по C# Intermediate.
# Про C#:
Видео по C# для меня интереса не представляет. Полистал, вроде всё адекватно, примеры нормальные. Видел пример реализации [Flags] для enum через побитовый сдвиг — очень полезная штука, почему-то её при обучении любят игнорировать.
✨ Про DOTS:
А вот видео по DOTS я, пожалуй, затестирую лично, но уже в новом году — пока катастрофически загружен. Напомню, что DOTS — это не только ECS-фреймворк, но и целый стек технологий, часть которых доступно и вне ECS (например, Burst Compiler и Job System).
Из ECS-решений ранее я пробовал DOTS, Entitas, LeoECS и Morpeh — и последний мне нравится больше всех, пусть он и не самый производительный. А DOTS нравился меньше всех. Интересно будет посмотреть, что в нём изменилось и что он из себя представляет сейчас.
📖 Про подобные курсы в целом:
Помнится, год назад Сакутин тоже выпускал подобные YouTube-курсы по C# и по Unity. Я их не смотрел, ничего сказать не могу. Видел только в чатах отзывы проходивших, что классическое «обо всём и ни о чём». Что, на самом деле, ожидаемо. 7–12 часов — это капля в море, особенно для Unity. Можно только успеть «тегов» набросать и по верхам пробежаться.
Так что это всё не более чем помощь в самообучении и практике. Только самостоятельное копошение в теме сможет чему-то научить. Не нужно ждать, что такие короткоформатные курсы смогут резко прокачать. Только подскажут и направят, не более.
🔖 Рекомендация от себя:
Пользуясь случаем, порекламлю мой любимый ресурс по C# (и не только) — Metanit. Удобный, качественный, бесплатный, масштабный. Он не заменит всё на свете, но это очень хороший дополнительный ресурс, который удобно использовать параллельно с другими ресурсами и к которому удобно возвращаться потом.
Сам по нему учился, параллельно с кучей других профильных книг. В «своё время» выел там весь контент по C#. Пригодилось ли мне это?
С практической точки зрения: что повседневно не использую, то уже, конечно, не помню совершенно.
С точки зрения эрудиции: в моменте, когда учишься, когда много белых пятен, такой широкий контекст помогает выстроить майндсет и осознать, что где, как и почему используется. А в последствии помогает решать проблемы более высокого порядка, чем простое написание кода.
—————————————
#unity #gamedev #development #ecs #programming #csharp #code #разработка #геймдев #обучение #образование #курсы #программирование #рекомендация
📝 Заметка про шорткаты в Rider и Unity 📝
Уровень материала: 🐣 #junior
Кто из лагеря Visual Studio уже успел попробовать теперь уже бесплатную версию Rider? Внутри много интересного: тесная интеграция с движками, шустрый и настраиваемый анализатор кода, полезные подсказки и автодополнения, генератор кода, мощный отладчик и всякое другое.
Даже простое знакомство с настройками может затянуться не на один час (при этом они удобно скомпонованы, и поиск по ним работает отлично). Но что важно — у Rider очень гибкая система шорткатов и хоткеев.
❓ Зачем это нужно? Для удобства. Конечно, для эффективности тоже. Но главное — для удобства. Нажатие на клавиши значительно быстрее, чем аналогичное действие совершённое мышкой. И требует меньше внимания. Мышку нужно перехватить, передвинуть, навести на меню, потом на вложенное меню, кликнуть и вернуть руку обратно (если нет навыка однорукой печати).
Rider позволяет полностью отказаться от мыши и сосредоточиться на работе. Захотел что-то сделать – стукнул пальцами и моментально увидел результат. При доведении до автоматизма, это превращается в настоящую магию, как-будто IDE управляется силой мысли. И это доставляет определённый кайф от работы.
Особенно ярко это раскрывается при рефакторинге кода. Во многих IDE есть куча автоматизаций для этого процесса, которые невероятно облегчают жизнь разработчику. И шорткаты превращают это всё в увлекательный процесс грациозного и эффективного дирижирования кодом.
🎥 Приложу видео, которые могут помочь познакомиться с основными возможностями. Они не очень свежие, но всё ещё актуальные, только с тех времён всё стало ещё лучше, и возможностей прибавилось.
Горячие клавиши Rider: K-Syndicate
Эффективная разработка в Rider IDE: DevGamm 2018
Shortcuts, Editing, and Completion: Rider Essentials
An Introduction to JetBrains Rider: Dan Clarke
⚙ Рекомендую также заглянуть в настройках во вкладку Keymap, где можно через поиск найти практически любое действие в IDE, которому можно назначить свой шорткат. Что-то часто приходится делать мышкой? Или на видео показывают полезный шорткат, который у тебя не срабатывает? Зайди в Keymap, найди нужное действие и назначь желаемую комбинацию.
Если запоминать комбинации не хочется, достаточно запомнить название операции и использовать поиск по Action'ам. Также в запоминании шорткатов может помочь плагин Key Promoter X (или может раздражать, если шорткаты игнорировать).
🤹 Шорткаты есть во всех программах. И везде они помогают сделать работу более комфортной (и эффективной). Не только в Rider и не только в IDE стоит уделять этому внимание. В т.ч. горячие клавиши есть и в Unity. И я рекомендую посмотреть их официальный тутор. Уверен, что ты сможешь узнать что-то новое, потому что в Unity далеко не все полезные возможности «лежат на поверхности». Также у них есть Shortcuts Manager, куда стоит периодически заглядывать.
—————————————————
#gamedev #development #rider #unity #code #programming #hotkey #shortcut #хоткеи #шорткаты #горячиеклавиши #разработка #геймдев #код #рекомендация #видео
