Brackeys: Как создать 2D-игру

Brackeys — один из самых популярных и авторитетных каналов для Unity-разработчиков.

How to make a 2D Game in Unity
2D Movement in Unity (Tutorial)
2D Animation in Unity (Tutorial)
2D Camera in Unity (Cinemachine Tutorial)
2D Shooting in Unity (Tutorial)
MAKE ORGANIC LEVELS!! Unity Sprite Shape
2D Lights in Unity!
TOP DOWN SHOOTING in Unity
MELEE COMBAT in Unity
How to make a BOSS in Unity!



Смотреть на YouTube

Внутриигровые эмодзи: как мы создаем анимации для Rush Royale

Привет! Я Виталий, ведущий 2D-художник, аниматор и специалист по эффектам в мобильной tower-defence игре Rush Royale студии IT Territory. Сегодня я расскажу об одной довольно важной части нашего проекта — эмодзи. Именно благодаря им игроки могут выразить свои эмоции в жарких боях за башни.

Подробнее

Делаем систему ближнего боя на Unreal Engine 4

В этом видео я рассказываю о том, как создать простую систему рукопашного боя в Unreal Engine 4. Мы настроим ее так, чтобы персонаж мог держать меч и атаковать им, а также создадим простого врага, которого мы сможем атаковать и наносить ему повреждения.

Хочу в геймдев: 27 ответов от 8 профи

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

Сжатые атласы в Unity Runtime

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

Подробнее

Лучшие советы по ведению гейм-дизайнерской документации

СОВЕТ №1: Структурируй.
Пример структурирования разделов страницы типового описания игровой системы в ГДД:

Цель — для чего система создается, какие задачи в игре решает. Удержание, монетизация, целеполагание, снижение скуки, эмоциональный отклик и т.п.
Общее описание — краткое, ёмкое описание сути системы, чтобы с самого начала человек прочитал и понял, о чём далее пойдёт речь.
Логика работы — подробное описание логики работы системы. Можно в виде юзер-сториз, можно в виде отдельных абзацев-кейсов. Здесь нелишними могут быть схемы/циклы и прочие поясняющие диаграммы и изображения.
Интерфейс — схематический макет и описание элементов интерфейса. Схема переходов, если в этом есть необходимость.
Балансировка — комментарии ГД по концепции баланса системы. Диапазоны, пределы, варианты формул/функций, рекомендации.
Настроечные данные — список всех переменных, которые должны быть вынесены в настроечные таблицы игры.
Аналитика — список событий, которые необходимо фиксировать в системе сбора и анализа данных по игре (опционально).
Затронет системы — список всех систем (ссылки на их описание) и изменений в них в результате реализации этой системы.


СОВЕТ №2: Оставляй перекрёстные ссылки.
Не ленись оставлять перекрёстные ссылки в документе на другие страницы описания других игровых систем, если в этом есть необходимость.

СОВЕТ №3: Выделяй эффекты, звуки и анимации.
Обозначай Эффекты, Звуки и Анимации в описании фичи отдельными выделенными блоками. Это упрощает формирование задач художниками, специалистам по эффектам, саунд-дизайнерам и аниматорам.

СОВЕТ №4: Используй цветовую кодировку времени изменения.
Есть положительный опыт использования цветовой кодировки в описании фичи для обозначения:
актуальная информация (обычный черный);
текущие последние изменения (красный);
устаревшая, неактуальная информация(светло-серый и вычеркнутый).

СОВЕТ №5: Оставляй шпаргалки.
Оставляй подробные примечания к ячейкам таблицы. Каждый раз, когда тебе кажется, что тут и так все понятно, подумай о тех, кто будет читать таблицу в твоё отсутствие.

СОВЕТ №6: Заведи базу знаний.
Вести общую трелло-доску на весь отдел гейм-дизайна. Есть разные колонки, с концептами новых игр, новых фич, подборки визуальных референсов, интересные статьи и видео про игры или гейм-дизайн, которые нашли и решили что они полезные.

Отдельно вести доску с лайфхаками внутри проекта. Там содержатся всякие подсказки как выполнять какие-то редкие задачи, или как выполнять какие-то рутинные задачи быстрее. Доска ведется в виде FAQ. Заголовки — вопросы, а в описании подробный ответ.

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

СОВЕТ №7: Избегай дублирования.]
Максимально избегать дублирования информации. Любая информация должна быть только в одном месте в ГДД, все остальные места должны либо подхватывать из первоисточника, либо ссылаться на него. Если пренебрегать этим правилом, рано или поздно кто-то обновит диздок в одном месте и забудет про другое, а еще через пол года команда начнёт путаться в разных данных.

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

СОВЕТ №8: Помечай настраиваемые константы и переменные.
Всегда стоит помечать параметры и константы, которые должны быть вынесены в настроечные таблицы проекта. Если есть хотя бы малейший шанс, что цифру в диздоке понадобится в будущем поменять (то есть практически всегда) нужно отмечать цветом или символом или как угодно еще, что это параметр, который может меняться. Иначе есть риск, что цифру захардкодят. И это будет вина ГД.

СОВЕТ №9: Используй изображения и анимации.
Не лениться делать гифки и тратить время на оформление ТЗ. Иногда 3 гифки в ТЗ на анимацию вместо тысячи слов, как рафаэлло!

СОВЕТ №10: Не перекладывай ответственность на исполнителя фичи.
Не указывайте в диз.доке варианты выбора на усмотрение исполнителя. В стиле «тут можно сделать любого цвета, какого захочется, неважно» или «строка может быть длиной от 30 до 400 символов».

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

То же самое касается и призывов к обсуждению в ГДД, в стиле «как думаешь, 5 строк рейтинга в окне будет нормально?» Обсудите этот вопрос заранее в чате, а в диз.док запиши уже конкретные данные. Когда кто-то откроет документ через несколько месяцев, он будет совсем не в восторге от того, что ему придется читать еще и какие-то ветки решенных комментариев, чтобы докопаться до нужных данных.

СОВЕТ №11: Обозначай исключения.
Если есть особое требование к функциональной логике системы, которое обозначает исключительные случаи, лучше эту информацию отдельно выделить для разработчика.

СОВЕТ №12: Пиши кратко и ёмко.
Текст описания логики работы системы в фиче должен быть максимально ёмким и концентрированным, при этом раскрывать все аспекты системы, чтобы программист и другие специалисты могли в полной мере реализовать функционал.

Воссоздали щит Капитана Америки на Unity

Четыре полезных подхода к созданию ваших персонажей

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

Подробнее

Механика удара через землю на Unity

00:00 Intro
00:11 Crack Model
01:55 Depth Mask & Model Setup
03:21 Crack Script
04:10 Crack Control Script
05:48 Animate Crack Opening
07:31 Fix Crack Seam & Beginning
08:07 Fix Crack Range
08:27 Crack Close
09:22 Corner Points Setup
09:59 Side Cracks
11:51 Slam Effect
12:01 Shockwave Particle
12:40 Flash Lines Particles
13:36 Small Rocks Particles
14:23 Crack Particle
14:42 Smoke Particle
15:28 Slam Setup
16:16 Scale Fix
16:34 Small Puff Setup
17:16 Rock Emerge Overview
17:53 Rock Ground
19:50 Rock Emerge Setup
21:29 Outro

Prince Of Persia (1989)

Разработчик: Jordan Mechner
Издатель: Brøderbund
Платформа: Apple II / DOS / many more
Обзор кода: fabiensanglard.net

Prince Of Persia произвёл фурор благодаря плавной анимации, голливудскому стилю подачи истории и интересному геймплею.

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

Исходник (Apple II): github.com/jmechner/Prince-of-Persia-Apple-II

Как создавали игру Prince of Persia

👊А вы уже знакомы с новым форматом битвы кодов от Geecko?

Сейчас вовсю идёт «битва программистов» — Sberfight. Участников ждёт фан, призы (💻, 📱, ⌚️) и даже приглашения на работу.

Это прикольная «разминка для мозгов»: быстро найти неочевидное решение, написать код и… наслаждаться визуализацией, как виртуозно дерётся персонаж🥷 Он даже может сделать «сберталити», ну вы понимаете😉

👉Отборочный этап — до 25 февраля.
👉В плей-офф пройдут 256 участников.
🏆 Финальные битвы — 25–27 февраля.

А ещё в Sberfight открылась арена с отдельными призами: сражайтесь в PvP или клановых боях «стенка на стенку» и общайтесь с союзниками в голосовом чате.

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

История алгоритмов рандомизации «Тетриса»
Как алгоритм рандомизации эволюционировал с 1985 года.

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

Подробнее

Как правильно выстроить сложность в
видеоигре

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

Подробнее

Художник по окружению CD Project Red рассказывает, как создавал мир в игре «Ведьмак 3: Дикая охота»

Старший художник по окружению компании CD Project Red Михаль Жанижевски написал для издания 80 Level колонку о том, как команда студии разрабатывала виртуальный мир игры «Ведьмак 3: Дикая охота» и её дополнения «Ведьмак 3: Кровь и вино». Он описал создание мира, связь игровых локаций и реального мира, планирование виртуальных городов и другие аспекты дизайна.

Подробнее

NavMesh - поиск пути и перемещение по карте [Unity 3D]

С помощью системы Nav Mesh можно сделать множество вещей связанных с перемещением объектов в игре - управление юнитами игрока, перемещение NPC по карте, поиск пути в лабиринте. В этом видео я расскажу как этим всем пользоваться в Unity 3D, покажу как использовать Nav Meshes на карте с движущимися препятствиями, или на процедурно-генерируемом уровне, создавать разные типы юнитов и зон

​​https://www.youtube.com/watch?v=LrDYS4RxCXA

Вышел Scene3D для Defold
Это коллекция ассетов для упрощения разработки 3D игр с помощью Defold.

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

Unity: 8 причин отказаться от Coroutine в пользу Async

Когда речь заходит об асинхронных операциях в Unity, на ум первым делом приходит coroutine. И это не удивительно, так как большинство примеров в сети реализованы именно через них. Но мало кто знает, что Unity поддерживает работу с async/await еще с 2017 версии.

Подробнее