С развитием HTML5 и мобильных платформ 2D игры возвращаются в моду и привлекают внимание даже крупных издателей. Благодаря таким инструментам, как Unity, и онлайн-ресурсам с игровыми ассетами, разрабатывать эти игры стало намного легче. Ниже представлен список из 10 лучших сайтов с 2D ресурсами для игр – как платными, так и бесплатными.
*Сайты перечислены в случайном порядке*
Крупнейший сайт с платными игровыми ассетами. Использовать движок Unity для работы необязательно – чтобы получить доступ к ресурсам на Asset Store, нужно лишь загрузить его бесплатную версию. Скачанные файлы будут сохранены в папку проекта Unity, откуда их можно импортировать в любой игровой 2D движок.
Стоит отметить, что Unity в руках умелого разработчика обладает огромным потенциалом, о чем свидетельствует большое количество успешных 2D игр (чего только стоит популярная Bad Piggies от Rovio). А Unity Asset Store предлагает широчайший выбор 2D ассетов.
GameDev Market – относительно новый сайт, удобно организованный по категориям контента (как и Super Game Asset, о котором пойдет речь ниже). Здесь вы найдете как 2D, так и 3D ресурсы, включая UI, спрайты персонажей, иконки и окружения. Художники выставляют ассеты на продажу, и ассортимент растет с каждым днем.
Graphicriver – один из самых популярных ресурсов шаблонных изображений. В связи с развитием казуальных мобильных игр, там появилась отдельная категория с 2D ассетами. До размещения на сайте весь контент проходит внутреннюю проверку, а после публикации любой пользователь может оставить свою оценку и отзыв. Итого: это надежный, активно развивающийся сайт под пристальным модерированием Envato.
Scirra – компания-разработчик Construct 2, популярного 2D редактора на HTML5, у которой недавно появился собственный магазин ассетов. Здесь можно найти аудио-, графические ресурсы и даже готовые игровые шаблоны для Construct 2. Впрочем, для работы можно использовать и любой другой 2D редактор.
На сайте Game Art Partners можно купить разнообразные мультяшные ассеты для 2D платформеров, включая анимированных персонажей, монстров, оружие, визуальные эффекты и наборы элементов интерфейса.
Если вы создаете RPG или игру с изометрической графикой – этот сайт для вас. Здесь вы найдете самые высококачественные ассеты: красочные иконки для RPG (пожалуй, лучшие из доступных онлайн), 2D спрайты, анимированные спрайты персонажей и огромные изометрические карты. Что немаловажно, большинство представленных ресурсов выполнены в одном стиле.
Исчерпывающий ресурс для разработчиков игр с открытым исходным кодом, Open Game Art можно назвать крупнейшим собранием игровых ассетов со свободной лицензией. Все материалы – от спрайтов до иконок – можно загрузить по лицензиям GNU или Creative Commons. Это отличный сайт для новичков, но многие ассеты отличаются по визуальному стилю, поэтому их придется тщательно отбирать.
Еще один отличный сайт с более чем 20 тыс. ассетами, включая элементы UI и различные спрайты для 2D платформеров. Большинство ресурсов представлены в векторной графике и подойдут для любого устройства, независимо от разрешения экрана. Ассеты можно скачать по отдельности (бесплатно) или одним набором (за скромную плату в $9).
Game-icons.net – лучший сайт с бесплатными иконками, которых здесь ни много ни мало 2000. Несмотря на то что все иконки черно-белого цвета, они достаточно универсальные и могут быть использованы для обозначения действий, заклинаний, навыков, предметов и т. п. Приятный бонус – векторный формат.
Лучший сайт c бесплатными тайлами. Здесь можно найти спрайты животных, растений, построек, оружия, визуальных эффектов и практически любых объектов для RPG с изометрической графикой. Стиль ассетов напоминает Diablo II. Это отличный ресурс для начинающих разработчиков, желающих протестировать игровой движок или приступить к созданию своей игры.
2D магия в деталях. Часть вторая. Структура
Помните небезызвестный мем про «корованы»? Наверное, каждый, кто разрабатывает игры (или хотел бы этим заняться) раздумывает о неком «проекте мечты», где можно будет «грабить корованы» и «набигать». А ещё, чтобы погода менялась динамически, и на грязи следы от сапог оставались, и деревья росли в реальном времени. И ещё, чтобы .
Понятно, что в реальном игровом проекте такая погоня за хотелками — смерти подобна. А вот в техно-демке — самое то.
Предыдущие статьи
Оглавление
Вступление
Напомню, что в прошлой части был опрос: на какую тему написать следующую статью. И динамическая вода показалась сообществу наиболее интересной. Но это долгая история и начать придется со структуры проекта и алгоритмах, которые используются под капотом, а затем рассказать о доработках освещения и постэффектах. Текст получится большой, так что вода переезжает дальше, в одну из ближайших статей. Кстати, эта статья содержит поменьше красивых рендеров, но куда больше технических хинтов. Не скучайте.
С момента написания предыдущей статьи было сделано очень многое. Переписан начисто весь код проекта, оптимизированы алгоритмы, добавлены новые источники света, реализовано фоновое освещение, реализована вода с бликами, волнами, кипением и замерзанием. Как вы могли заметить — ни слова о персонажах или геймплейной составляющей, это ещё впереди. Не буду забегать вперед и расскажу всё по порядку.
Спрайты
Наш проект про магов, а значит, без старых каменных за́мков не обойтись. Вот только рисовать каждый с нуля — себе дороже. Попробуем собирать их из небольших кусочков, например, вот таких:
Аккуратные кусочки, из которых можно сделать ВСЁ.
Чтобы у этих кусочков был общий контур, напишем какой-нибудь шейдер, а статический батчинг в Unity3d оптимизирует количество вызовов отрисовки. Вот только чтобы получить общий контур, придется использовать двухпроходный шейдер со stencil буфером: первая часть нарисует контуры, а вторая — заливку. А любые элементы, которые используют материалы с многопроходными шейдерами в батчинге не участвуют. Лучше отрисовывать каждый спрайт дважды, но с разными материалами. Количество вершин увеличится, зато вызовов отрисовки останется всего два.
Читайте также: Рисунок 1 предложение земли
Таким нехитрым способом можем создать вот такой за́мок:
Стены в редакторе. Текстуру и цвет контура можно настраивать отдельно.
- Убираем копипасту. Конечно, не стоит руками копировать спрайты. У меня есть класс Contour, который содержит все нужные настройки для спрайта и 2 материала. При появлении на сцене этот класс создает по два наследника с SpriteRenderer (для контура и фона).
Автоматизируем перенос. Изначально у меня уже были префабы-спрайты, которые использовались на сцене (несколько сотен элементов). Когда я решил обернуть их в Contour, изменения префабов почему-то не применялись к созданным объектам. К счастью, можно легко написать скрипт, который для каждого существующего элемента найдет соответствующий префаб (по имени), и создаст в нужной позиции элемент из этого префаба. Ключевые методы — UnityEditor.AssetDatabase.LoadAssetAtPath и UnityEditor.PrefabUtility.ConnectGameObjectToPrefab
Правильный drag’n’drop. Минус разделения на спрайты — теперь по умолчанию на сцене выбирается и используется в drag’n’drop’е один из спрайтов-наследников. Решается проблема добавлением атрибута [SelectionBase] перед классом Contour.
Отображение префабов. В меню проекта префабы с контурами теперь не отображаются как спрайты, и, если честно, я не нашел способа самому генерировать иконку. Поэтому в префабы я добавил ещё и SpriteRenderer, спрайт которому задаёт мой Contour. При добавлении на сцену я удаляю из объекта не нужный в геймплее SpriteRenderer.
Удаление из OnValidate. При добавлении объекта на сцену вызывается OnValidate и именно там я удаляю SpriteRenderer. Вот только ни Destroy, ни DestroyImmediate в этом методе не работают (без колдовства с собственным редактором класса), поэтому использую такой костыль:
Полигоны
Правда, иногда придется делать мешанину из спрайтов: если мы хотим получить большой и сложный объект, как поверхность земли с ямами и пещерами. Вместо этого будем генерировать такие элементы на лету, в редакторе (как в PolygonCollider2D). Рендерим полигоны через стандартный MeshRenderer с двумя материалами (для разделения контура и заливки используются submeshes).
Не стану утверждать, что написать аккуратный редактор для полигонов просто. Но вся информация доступна в интернете, а в AssetStore есть готовые решения.
Редактор, неотличимый от редактора в PolygonCollider2D.
Для максимальной гибкости классы для полигонов выстроены так:
- Core.Shapes.Shape — основной класс, содержащий точки полигона и нужную математику. Не MonoBehaviour;
- Core.Shapes.EditableShape — наследник MonoBehaviour для хранения и редактирования Shape;
- Core.Shapes.ShapeRenderer — отображает полигон из EditableShape с помощью MeshRenderer;
- Core.Shapes.ShapeCollider2D — создает физический полигон из EditableShape с помощью PolygonCollider2D.
Почему-то я очень долго упускал из виду атрибут RequireComponent. Это очень удобный механизм для автоматического добавления нужных компонентов. Например, ShapeRenderer требует EditableShape и MeshRenderer, при добавлении его в GameObject автоматически создаются все зависимости.
Pixel perfect и целочисленная геометрия
Используя крупные пиксели мы убиваем целую стаю зайцев:
- Можем рендерить небольшое изображение (пиксель в пиксель) и растягивать его под экран;
- Можем использовать сложные постэффекты (небольшие текстуры увеличат производительность);
- Можем работать с целочисленной арифметикой (быстрее и приятнее);
- Можем маскировать недоработки или баги 🙂
Правда за этих зайцев придется заплатить, реализовав поддержку «целочисленной геометрии», а именно:
- Базовые вещи, такие как:
- IntVector2 — по сути, копия UnityEngine.Vector2, но с целочисленными координатами. Иногда нужно конвертировать данные из обычного UnityEngine.Vector2, с учётом масштаба или без (в одном юните 32 пикселя, только не нужно использовать магические числа!), поэтому добавляем следующие функции:
- IntRect. Ничем не отличается по функциональности от UnityEngine.Rect. Доступен метод LineCollision для поиска пересечений с отрезками прямых (алгоритм Лианга-Барски);
- IntLine. Отрезок прямой с целочисленным началом и концом. Используется в некоторых алгоритмах;
- IntMatrix. Матрица для двумерных преобразований, где повороты кратны 90°, а смещение и масштаб — целочисленны;
- IntAngle. Небольшой класс для округления градусов до 90°, выбора направления. Представляете, какая там красивая таблица косинусов?
- Poser. Элемент, позиционирующий GameObject кратно игровому «пикселю», запрещающий повороты, не кратные прямому углу и масштабирование на дробное значение (с учетом того, что в элементе может быть SpriteRender и тогда придется учитывать pivot спрайта). Этот класс работает в редакторе благодаря атрибуту [ExecuteInEditMode]. Важный момент: при изменении состояния (позиции, поворота, масштаба, спрайта и т.д.) Poser уведомляет об этом класс PoserListener, который умеет отслеживать изменения в редакторе всех элементов Poser с определенным тегом. Это понадобится в дальнейшем;
- CameraManager. Контроллер камер, который умеет выравнивать текущую камеру и позиционировать камеры для постэффектов.
- Добавляйте для геометрии отрисовку гизмо. Например, в IntVector2, IntRect и IntLine добавлен метод OnDrawGizmos. Это очень полезно при отладке.
- Выравнивать камеры — ужасно. Я позиционировал их по нижнему левому углу, в то время как координаты камеры — это координаты её центра. А при изменении renderTarget камеры углы, очевидно, уезжают, так как меняется размеры экрана в пикселях. Так что важно не только как выравнивать камеры, но и когда.
Старая структура проекта
Помните, в прошлой статье был раздел про построение теней? И больша́я часть была посвящена объединению спрайтов в некие группы для оптимизации финального меша? Так вот, забудьте, это все неправда. 🙂
Изначально все модули писались независимо, в режиме прототипирования. И для каждого придумывались свои алгоритмы, структуры и типы данных. В результате возникло две крупных проблемы (помимо legacy-кода говнокода, будем честны):
- Дублирование кода. Одних только классов для целочисленных координат было штуки 3-4 и все — вложенные в другие классы (обычная точка, точка с нормалью, точка с какой-то метаинформацией).
- Не оптимальные решения. Каждому модулю были нужны одни и те же данные о спрайтах, но чуть чуть-чуть по-разному обработанные. И эти данные копировались туда-сюда со всякими преобразованиями, что не добавляло ни скорости, ни изящества кода.
Читайте также: Порядок приобретения муниципальных земель
Вот такие модули требуют какой-то информации о «твердых» спрайтах за́мков:
- Тени;
- Ветер;
- Рассеянное освещение;
- Трава;
- Частицы;
- Физика;
- Вода;
- Прочее (нити паутины и цепи светильников).
- UnityEngine.Sprite. Графические спрайты. База для всего остального;
- Contour. Контур объекта (или группы объектов). Представляет собой массив вертикальных и горизонтальных линий с нормалями;
- UnityEngine.Sprite[] → Contour: преобразуем каждый спрайт в контуры, для получения списка внешних сторон.
- UnityEngine.Sprite[] → Rects: заполняем спрайт прямоугольниками, чтобы потом использовать их для объединения всех объектов в один.
- Для построения мешей;
- Для проверки точки на твердость;
- Для рейкаста.
Все это безумие используется вот так:
- Тени.Batch → общий Contour: для построения теневого меша;
- Ветер.WindGrid → Batch → Shapes: для расчета ветра (поиск коллизий);
- Рассеянное освещение.
- Batch → Shapes:
- Для raycast’а (поиск прямой освещённости);
- Для testPoint’а (поиск твердых объектов).
- QuadTree → Batch → Shapes:
- Для поиска пустых объемов.
- Batch → Shapes: метод CircleQuery для поиска ближайших поверхностей;
- Batch → общий Contour: для посадки травы;
Region tree
После некоторого анализа и длительного гугления находим решение — Region tree, иногда называемый Volume tree.
Разбиваем двумерное пространство на 4 части до тех пор, пока каждый лист не окажется либо полностью пустым, либо полностью заполненным. Выставляем листу бит заполненности (или любым другим способом отличаем пустые узлы от заполненных).
Возможности, которые дает это дерево, покрывают все наши потребности:
- Построение дерева. Можно заполнять дерево, указывая твердые точки, прямоугольники или даже другие деревья с неким смещением. Поэтому для спрайтов предрасчитываются собственные Region tree, а затем, при добавлении на сцену, строится общее дерево.
- Проверка твердости точки. Рекурсивно спускаемся по дереву, пока у узла есть потомки (в моей версии дерева узел пустой, если Node = null, полный — если Node.children == null, в противном случае в Node.children — массив потомков);
- Raycast. Рекурсивно проверяем пересечения луча с квадратами узлов.
- Поиск кратчайшего пути до пустого пространства. Находим лист в заданной точке, поднимаемся по дереву вверх, проверяя узлы соседей (если узел пустой, сразу считаем расстояние до него, если есть потомки — спускаемся рекурсивно вниз и снова ищем ближайший пустой).
- Поиск отрезков, лежащих на границе. Тут сложнее, если кратко — получаем все заполненные квадраты из дерева, убираем стороны, принадлежащие нескольких квадратам, оптимизируем результат.
Визуально это выглядит так (ура, картинки!):
Визуальная часть. Стены из спрайтов, земля — полигоны.
Предрасчитанный region tree.
Менеджеры
Как оказалось, эта дерево квадрантов реализует почти все возможности, которые нужны модулям. Теперь нужно связать эти модули друг с другом.
В «прототипной» версии все контроллеры/менеджеры сами реализовывали соответствующий функционал (расчет освещения, обработку физики частиц и т.д) и наследовались от MonoBehaviour. Возникало несколько проблем: сложный и разросшийся код, сильная зависимость менеджеров друг от друга, отсутствие какого-то общего потока данных между контроллерами.
Например, когда в редакторе я передвигал какой-то элемент, менеджеры не подцепляли эти изменения автоматически. Приходилось сначала тыкнуть галку в менеджере дерева, затем в менеджере света, затем в менеджере воды и т.д. И всё ради того, чтобы посмотреть, хорошо ли выглядит новый за́мок. Так себе, правда?
Во-первых, по максимуму избавимся от MonoBehaviour. Все объекты по возможности представляются обычными с# классами.
Во-вторых, разнесем код по разным пространствам имён, одно имя — один функционал.
И, в-третьих, для каждого функционала реализуем один MonoBehaviour-менеджер, который будет хранить нужные настройки, управлять генерацией контента и т.д.Менеджеры. Причёсанные и в галстуках.
Итак, на сцене лежат контроллеры, у каждого одна сфера влияния, код аккуратно упакован в пространство имён NewEngine.Core (Core.Geom, Core.Illumination, Core.Rendering и т.д.). Двигаем спрайт в редакторе и… никакой реакции. Помните, выше был описан класс PoserListener? Он умеет слушать изменения позиции, спрайта, размера у объектов типа Poser. Все менеджеры, которые зависят соответствующих GameObject‘ов наследуем от этого класса.
Теперь, когда мы двигаем кусок стены (c тегом «foreground«) уведомляется Core.Quad.QuadManager, а когда меняем опорные точки для воды (тег «waterLayer«) Core.Water.WaterManager сразу же узнает об изменениях.
Осталось связать контроллеры между собой, ведь вышеописанному WaterManager требуется знать, когда будет перестроено дерево квадрантов в QuadManager, а ShadowMeshManager‘у важно подхватить изменения в SurfaceManager’е. Для этого воспользуемся очень удобным UnityEvent. Его единственный недостаток — по умолчанию, если мы создаём событие-generic с каким-нибудь своим аргументом, Unity3D не отображает его в редакторе. Это исправляется элементарно:
И теперь мы можем связывать менеджеры прямо в редакторе, не загрязняя код странными зависимостями:
Читайте также: Экономическая зависимость крестьян за пользование землей до ее выкупа
При необходимости зависимости выполняются и в редакторе.
Постэффекты.
Итак, все модули на старте генерируют необходимый контент, обновляют его, но рендерить не умеют. Время это исправить!
На самом деле, рендеринг в этом проекте сильно отличается от того, что показывают на youtube в роликах с говорящими названиями «Запилим свою мега-крутую игру на Unity3D из трёх боксов, одного спрайта и компонента RigidBody2D». На самом деле, просто отрисовать нужно только сами спрайты стен и фона. А вот свет, воду и прочее придется делать через постэффекты.
Что это означает? Что рендеринг элементов мы будем делать не на экран, а в буферы, затем с помощью различных шейдеров сводить эти всё одну картинку. И всего-то.
Эффектов получается немало. На данный момент это:
- Рендеринг сцены. Не совсем постэффект, просто отрисовка основной геометрии сцены.
- Глобальное освещение. Расчитывается один раз, на старте уровня;
- Обычное освещение. Включает в себя источники света, тени, каустику в воде;
- Световые декали. Небольшие спрайты, которые создают эффект люминесценции.
- Постэффект сведения. Объединяет результаты всех предыдущих постэффектов в одну картинку (например, применяет эффекты освещения к отрендеренной сцене).
- И, наконец, рендеринг на экран. Который просто выводит получившуюся текстуру с учётом pixel perfect и разницы в размерах у экрана и текстуры.
В общем случае постэффект — это некий скрипт, который умеет генерировать некую текстуру/текстуры и, возможно, дополнительные данные (например, параметры шейдеров). Иногда постэффект работает только с модулями, иногда ему приходится вызывать рендеринг сцены с определенными настройками камеры.
Важный момент: постэффекты могут зависеть друг от друга. Поэтому, во-первых, важно вызывать эффекты в правильном порядке, во-вторых, нужно уметь хранить и передавать эффектам разношерстные данные о друг друге.
Делаем базовый класс для эффекта. Примерно такой:
И ещё делаем класс контекста, для связывания данных из постэффектов.
По сути, теперь в менеджере рендеринга нам нужно пройтись в правильном порядке по всем активным эффектам, вызывая у них Apply и собирая данные в PipelineContext. В результате у нас отрисуется красивый кадр. Эффекты попадают в менеджер через аналог Poser, который сообщает слушателю о добавлении/удалении эффектов со сцены. Осталось только правильно их сортировать.
И было бы круто сделать красивые атрибуты, которые добавлялись бы в постэффекты и автоматически определяли зависимости и порядок, как-то так:
Но, по правде говоря, мне было лень это делать и я написал очередной PropertyDrawer:
Просто перетаскиваем все постэффекты в общем списке. Список создается автоматически из эффектов на сцене в редакторе.
- Камеры. Ещё одна стадия, которую проходят эффекты — выравнивание камер. Перед рендерингом все созданные камеры проходят этот этап;
- Вызов постэффектов. Постэффекты должны откуда-то вызываться. В Unity3D есть специальное место — метод OnPostRender;
- GetTemporary. Как выяснилось, создавать RenderTexture и хранить его в течении жизни постэффекта — плохая идея. Медленно, память не переиспользуется. Но если создавать текстуры через RenderTexture.GetTemporary, а после использования убирать через RenderTexture.ReleaseTemporary, fps сильно увеличивается (особенно на мобильных девайсах). Unity3D не сразу удалят такие текстуры и переиспользует их по возможности. В ситуации, когда множество посэффектов отрисовываются на одинаковых по параметрам текстурах — идеальный вариант.
- Утечка текстур. Eсли постоянно создавать такие текстуры и забывать их удалять — есть шанс, что Unity3D начнёт падать (точнее, это увеличит шансы: Unity3D и так любит падать). В предыдущем видео был виден счетчик используемых текстур и волшебная кнопка «Show texture leaks», которая показывает количество созданных и не удаленных текстур с конкретными местами в коде, где произошло выделение памяти (с помощью System.Diagnostics.StackTrace()). Не забывайте оборачивать такие штуки в #ifdef и использовать только в редакторе.
- Поддержка форматов текстур. Обычно девайсы поддерживают не весь список TextureFormat и уж тем более, RenderTextureFormat. Методы SystemInfo.SupportsTextureFormat и SystemInfo.supportsRenderTextures позволят прозрачно (при наличии своей обертки с кешем) подбирать максимально подходящий доступный формат.
- Blit. Иногда нужно применить некий шейдер к набору текстур и вывести в другую текстуру. Для этого даже не нужна Camera (мы не рендерим сцену). В Unity3D есть отличный метод Graphics.Blit.
- Ещё один Blit. Правда _Graphics.Blit_не помогает, если нужно отрисовать результат шейдера на одной текстуре, а depth buffer и stencil buffer использовать из другой. Это можно обойти с помощью следующего ниже кода.
Мысли о будущем
Аккуратные алгоритмы обрабатывают данные и создают траву, воду и свет, контроллеры следят за их обновлением, постэффекты — за рендерингом. Аккуратно, быстро и достаточно чисто. И самое главное, готова основа для написания действительно интересных штук! Например, замерзающей воды или светящейся плесени в подземельях. И ведь это вполне геймплейные фишки:
… лучники начали стрелять с противоположного берега. Маг взорвал файрбол над рекой, вызвав настоящее цунами. Но волна не добралась до берега — волшебник заморозил воду и спрятался от стрел за стеной льда.
… десятый поток пламени так накалил каменный пол, что тот начал светится, как будущий меч в руках кузнеца. «Ни одна живая душа не сможет пройти за мной» — решил маг.
В следующей статье попробую рассказать о новых постэффектах и освещении, а пока, на закуску, немного видео и картинок. Спасибо за ваше внимание.
Вот про такую воду я обещал вам рассказать 🙂
Зависимости эффектов до рефакторинга.
Ну почему все работают с радианами, а Unity3D с градусами? 0о
Небольшой, но красивый косяк в поиске поверхностей.
Это не ядерный реактор, просто некие рейкасты прорвались наружу.
- Свежие записи
- Особенности стропильной системы крыши
- Гидроизоляция фундамента частного дома — нужна ли она вообще?
- Паркет – лучший вариант напольного покрытия для жилого помещения
- Как сэкономить на строительстве загородного дома
- Утепление дома пенополиуретаном и эковатой менее практично, чем полистиролом и минватой
- Правообладателям
- Политика конфиденциальности
Наша планета © 2023
Информация, опубликованная на сайте, носит исключительно ознакомительный характер