В Universal Render Pipeline, создавая свои RendererFeature, можно легко расширить возможности отрисовки. Добавление новых проходов в конвеер рендеринга позволяет создавать различные эффекты. В этой статье, используя ScriptableRendererFeature и ScriptableRenderPass, создадим эффект обводки объекта (Outline) и рассмотрим некоторые особенности его реализации.
В Universal Render Pipeline, создавая свои RendererFeature, можно легко расширить возможности отрисовки. Добавление новых проходов в конвеер рендеринга позволяет создавать различные эффекты. В этой статье, используя ScriptableRendererFeature и ScriptableRenderPass, создадим эффект обводки объекта (Outline) и рассмотрим некоторые особенности его реализации.
Spelunky 2, к сожалению, так и не вышла в 2019 году, да и дату релиза в 2020 еще не объявили. Если вы не играли в первую часть, предлагаю вам пока ознакомиться с этим примером хорошего гейм-дизайна и разобраться, чем же он хорош.
В этой статье:
"Играй как гейм-дизайнер" — одна из самых популярных рекомендаций для тех, кто делает свои первые шаги в профессии. Что же на самом деле скрывается за этими словами? Авторы книг и статей рекомендуют играть как можно больше, играть в игры разных жанров, играть не только в хорошие игры, но и в плохие, всячески повышая свою наигранность.
В повышении наигранности ничего плохого нет, но почему-то не для всех очевидно, что одной наигранности недостаточно. Неплохо бы не просто потреблять игры, но и критически к ним относиться.
Результатом критического анализа может быть статья / видеоролик о том, как в рассматриваемой игре были решены те или иные задачи разработчиков.
Кому и зачем это нужно? В первую очередь такая работа будет полезна вам, как разработчику, а также вашим коллегам. В отличие от игровой журналистики, предназначенной для игроков, игровая критика полезна специалистам. Польза может заключаться как в описании сильных решений, интересных находок, так и в указании на ошибки.
Предлагаю вам ознакомиться с вариантом проведения такого критического разбора.
Начнём с того, что я обожаю сериализацию в Unity. Она надёжна и очень проста в использовании. Я просто расширяю MonoBehaviour, ScriptableObject и подобные классы и настраиваю сериализуемые поля экземпляров в инспекторе.
Но у неё есть и слабости. Одна из них ― человеческий фактор. Представьте себе огромный проект, который живёт несколько лет и над которым работает около сотни человек. И любой из них может совершить ошибку: оставить пустую ссылку на объект, указать число вне диапазона, ввести строку в неверном формате, заполнить массив слишком маленьким или, наоборот, слишком большим количеством объектов. Уверен, у каждого из вас найдутся такие примеры из своего опыта. Причин и оправданий тоже множество: невнимательность, неожиданные последствия слияния веток, сбои редактора… И никто от этого не застрахован.
Такие ошибки до поры до времени остаются незаметными: компилятору до них нет дела, в отличие от опечаток в коде. Особенно неприятны они тем, что проявляются часто уже во время выполнения кода. Только тогда вы начинаете читать журнал сообщений и идёте проверять данные: тыкать их в редакторе или листать YAML. Но объектов может быть достаточно много, есть риск что-то пропустить или попросту залениться.
Конечно, можно добавить проверок в коде, но от этого он загрязнится. Иногда эти проверки негативно влияют на производительность. А ещё не всегда однозначно понятно, как именно обработать каждую конкретную ошибку.
Универсального или даже штатного метода бороться с подобным в Unity нет. Поэтому мы в Pixonic реализовали свою систему валидации ассетов. И это очень помогает нам жить.
Сейчас я опишу, как там всё устроено.
Читать полностью »
Простой вопрос: в какой момент разработки нужно задуматься о туториале?
Почти все мои прошлые туториалы — провал. Они часто откладывались на самый конец разработки. Когда до запуска оставалось считанные дни, всегда находился человек, который спрашивал: «А не должны ли мы сделать туториал?». Мы были слишком заняты реальной разработкой, чтобы думать об этом. «Я знаю игру, как свои пять пальцев. Ее не так сложно понять, ей не нужно обучение», — часто я себе говорил.
Читать полностью »
Если вы следили за моей серией постов «Растеризация за одни выходные», но не компилировали и не запускали демо, то для вас станет большим сюрпризом, если я скажу, насколько медленными они оказались. В конце серии постов я упомянул существующие техники, позволяющие ускорить мучительно тормозной растеризатор. Теперь настало время двигаться дальше и посмотреть, как они применяются на практике.
Как часть этого проекта я реализовал Tyler — тайловый растеризатор, который мы проанализируем в данной статье. Моей целью при разработке этого проекта были масштабируемость. настраиваемость и понятность растеризатора для людей, которые хотят немного больше понять в этой теме и поэкспериментировать с ней. Эта статья достаточно сильно связана с тем, что объяснено в серии «Растеризация за одни выходные», поэтому лучше будет прочитать и её. Я не буду предполагать, что вы её изучили, но в статье будет больше высокоуровневых объяснений — я не хочу повторять уже сказанное и то, что можно найти в других источниках.
Тайловый рендеринг (tile-based rendering или tiled rendering) — это улучшенный по сравнению с традиционным immediate-mode-рендерингом; в нём render target (RT) разделяется на тайлы (т.е. субрегионы кадрового буфера), каждый из которых содержит примитивы, которые можно рендерить в тайлы по отдельности.
Обратите внимание на выражение «по отдельности», потому что оно подчёркивает одно из самых больших преимуществ этой техники по сравнению с immediate-mode: ограничение всех операций доступа внутри тайла буферами цветов/глубин, которые остаются в «медленной» DRAM благодаря использованию отдельного тайлового кэша на чипе.Читать полностью »
Разработчикам при создании игры приходится искать баланс не только в механиках, но и в физике. Реализм или аркада? В общем-то, кому что нравится. Главное — фан и удовольствие. Нужно создать фундаментальные законы своего мира, и объяснить, что возможность ходить по потолку — механика, а не баг.
Насколько сложной должна быть игровая физика, какие виды бывают и на какие хитрости идут разработчики при ее реализации — в переводе под катом.
Читать полностью »
Привет! Представляю вашему вниманию перевод статьи "ECS back and forth — Part 1 — Introduction" автора Michele skypjack Caini.
Часть 1 — Введение.
Когда я в первые узнал про архитектурный шаблон entity component system, я пошёл искать больше информации о нём в интернете. Но, к сожалению, тогда на эту тему не было пролито достаточно света, а ресурсов, где описывались бы разные подходы с их плюсами и минусами, не существовало. Почти каждые статья, пост, комментарии (существенная их доля) были об одной специфичной реализации и только слегка ссылались на другие примеры.
В этом посте я попытаюсь вас ввести в курс дела и открыть для вас несколько вводных моделей, давая некоторые советы для того, чтобы вы могли сделать свою собственную ECS.
Старайтесь не быть одураченным тем, что говорят вокруг. Если вы работаете над AAA проектами на серьёзном уровне, главной причиной почему вы должны использовать такой серьёзный инструмент — это организация кода, а не (только) производительность. Конечно, производительность имеет не последнее значение, но хорошо организованная кодовая база бесценна, и с большинством игр у вас не будет проблем с производительностью, будь они написаны с использованием ОПП парадигмы либо с другой опциональной реализацией компонентного шаблона.
В сущности, компонентно-ориентированное программирование — это крайне мощный инструмент, который позволяет сделать код легко расширяемым и ускорить цикл разработки. Бесспорно, всё это должно быть вашей первостепенной целью.
Конечно, не забываем о производительности. Хотя пока мы находимся в другой лиге, но в следующих статьях и в следующих вводных статьях я дам вам достаточно примеров моделей, по крайней мере некоторые модели будут точно ориентированы на производительность.
Работа игровой студии невероятно объемная и сложная. Процедура разработки и выпуска готового продукта проходит множество этапов. И получить прибыль с проекта не так и просто, и точно это не одномоментный процесс. Даже с помощью издателей.
У тех, кто пробует себя в игрострое, возникает ряд вопросов. Как разработчикам показать себя с лучшей стороны и представить свой проект? Как выгодно представить игру издателю и убедить его в будущем успехе? Как затем продать игру?
Мы в Слёрме любим пробовать и узнавать новое. И нам близка тема образовательных проектов.
Тем интереснее было заглянуть на территорию геймдева благодаря управляющему директору направления премиум игр в компании 101XP Ольге Макушенко. Перед вами лекция Ольги, которая которую она прочитала в Высшей школе бизнес-информатики НИУ ВШЭ в рамках образовательной программы Менеджмент игровых проектов, и родилась эта статья.
