готовые коды для unity
Топ 15 бесплатных Unity ассетов для начинающего 2D разработчика
Введение
Unity3D – безумно удобная среда, которая многое делает за нас. Именно поэтому она сейчас так востребована: разработка игр при правильном подходе становится не сложнее сборки конструктора.
Сама платформа Unity предоставляет широкий набор инструментов, но иногда не хватает и их. Тогда в дело вступает Asset Store с миллионами ассетов, моделей и примеров проектов.
Если у вас еще мало опыта в разработке приложений, имейте в виду: Asset Store – это огромный склад велосипедов, которые уже изобрели до вас. При этом там можно найти очень много бесплатного контента, или же контента по цене одной чашки кофе (сэкономьте на латте!).
Почему мы посвятили статью именно 2D играм? Посмотрите на рынок: 2D игры сейчас переживают ренессанс. Чтобы в этом убедиться, достаточно взглянуть на инди-сектор в Steam, Ketchapp и Zeptolab в мобильной разработке. 2D игры давно превратились из отжившего свое сектора в отдельную процветающую нишу рынка. Поэтому если вы решили делать 2D игру на Unity, сначала убедитесь, что у вас в арсенале есть все нужные инструменты, чтобы обеспечить должное качество продукта.
Немного про Asset Store
Если вы читаете эту статью, то скорее всего что-то слышали про Asset Store. Там хранятся несколько тысяч моделей, плагинов, систем частиц, скриптов и многое другое. Часть этого добра распространяется за деньги, а часть совершенно бесплатно! И мы настоятельно рекомендуем пользоваться этим обстоятельством. Прежде чем реализовывать A* для ваших юнитов, подумайте: может быть, кто-то уже сделал это до вас и выложил в общий доступ в удобной форме.
Ассеты с точки зрения 2D разработки
Так как мы рассматриваем 2D направление, модели, скрипты для камеры, скайбоксы и подобное отсекается сразу. Естественно, найдется разработчик, который сможет применить эти вещи в 2D игре, но статья предназначена в первую очередь для начинающих, которым в таких проектах лишние сложности не нужны.
Что же нам может понадобиться? Вот список:
Непосредственно ТОП
Пак стандартных ассетов от самой Unity. Это самые необходимые и проверенные в деле ассеты. Все они относятся к следующим категориям: 2D, Cameras, Characters, CrossPlatformInput, Effects, Environment, ParticleSystems, Prototyping, Utility, Vehicles. Эти ассеты можно подключить при установке Unity.
Великолепная библиотека твинов. Содержит все необходимые виды твинов (move, scale, rotate, alpha, color). Ее отличает очень удобный вызов методов, поддержка easing type и многое другое. Комбинируя простые твины, можно создавать очень интересные эффекты.
Очень простой для начинающего разработчика паковщик спрайтов. Необходим для создания атласов, которые экономят вам место и улучшают производительность.
Очень мощный инструмент для работы с полигон-коллайдерами. Позволяет более тонко настраивать количество вершин, работать с ними в рантайме.
Более сложный пример 2D платформера от самой Unity. В отличии от 2D Platformer Controller здесь добавлена анимация, стрельба и еще множество функций и объектов.
Ассет, который содержит в себе все необходимое для создания платформера. Здесь есть скрипты, управление персонажем, работа с камерой, вся необходимая физика и механика различных платформ. Очень рекомендуем посмотреть на этот ассет, прежде чем приступать к своему проекту.
Небольшое улучшение для ваших полигон-коллайдеров. С этим ассетом они становятся более плавными и… более тяжелыми с точки зрения производительности. Но если вам нужны точные формы коллайдеров, то этот ассет для вас.
Удобный ассет-редактор для создания тайловых уровней; может разбивать атласы по сетке, рисовать уровни в редакторе Unity, добавлять коллайдеры на блоки и настраивать слои отрисовки.
Достаточно удобная и простая система локализации. Не подойдет для больших игр, но в маленьких проектах отлично справляется с заменой текста на разных языках.
AutoSave – ассет, который не ценишь, пока он не сработает. Суть в том, что при обычном положении вещей если Unity зависает или вылетает, а вы не сохранили сцену, то все внесенные изменения пропадут. То есть вы можете час делать уровнь, забыть сохраниться и потерять его из-за критической ошибке в скрипте (например, бесконечного цикла). AutoSave сохраняет сцену при каждом нажатии на кнопку Play. Это очень удобно.
Хороший бесплатный пак частиц с готовыми префабами. Содержит взрывы, вспышки, эффекты огня и так далее. Для начального проекта самое то, особенно если вы будете менять шейдеры у частиц и получать свои, новые эффекты.
Мощный шаблон «рогалика». Содержит в себе управление героем, врагов, этажи уровней, звуки и эффекты.
Расширенный и усиленный вариант Simple Sprite Packer. Огромное количество функционала для работы с атласами.
Интересный ассет для создания красивой 2D системы освещения с контрастными тенями. Хорошо подойдет если вы делаете тактическую игру, стэлс платформер или какой-нибудь хоррор. Подобный ассет добавит в вашу игру атмосферы.
Структура кода в Unity3d — личное мнение и пара трюков
Хотелось бы поделиться личными впечатлениями о разработке мобильных игр на основе Unity3d. Изначально думал уместить в одном посте все мелкие «Tip&Trick» с которыми столкнулся при работе с Unity3d за последнее время. Но их оказалось черезчур много. Так что в этом посте будут только те, которые касаются непосредственно написания кода.
Главная тема поста — разделение классов по «слоям», связывание их через события и чуть-чуть о том, как наладить взаимодействие объектов на сцене.
Кому интересно — добро пожаловать под кат!
Структура приложения
Когда эти слои как-то сформировались у меня в голове, встал вопрос — как наладить взаимодействие между ними? Т.е. я понимал, что класс, который отвечает за загрузку следующего уровня, никак не должен быть завязан на соответствующую кнопку в меню. Но как это сделать?
Проблема была решена через статические классы и события.
Общая идея — объекты каждого слоя не взаимодействуют с объектами другого слоя. Они только вызывают статические события на своем слое, а на них уже подписываются все, кому нужно.
Почему события статические?
Дело в том, что чтобы подписаться на события конкретного объекта в сцене нужно иметь ссылку на него. А это добавляет кучу лишних связей и идея разделения «слоев» теряется.
В ряде случаев решение оказалось еще проще — достаточно было добавить синглтон для общения со слоем, и взаимодействие сильно упрощалось.
Далее постараюсь на примерах описать, как это работает в каждом слое.
Интерфейс
Туториалы по Unity полны вот таких примеров:
Этот, кстати, из официальной документации.
Что здесь не так?
Во время разработки и отладки в Unity пользоваться кнопками очень удобно. Но при переходе на мобильное устройство они заменяются на элементы интерфейса. Если завязаться на кнопки — придется потом редактировать класс игрового объекта. К тому же, что делать, если на нажатие кнопки должны реагировать несколько объектов?
Оказалось удобнее создать отдельный класс, например, UserInterface, в нем объявить глобальное событие OnFireButtonClick, и подписываться на него везде, где нужно.
Основная идея по интерфейсу такая: не делать обработку Input в игровых объектах. Сделать отдельные объекты интерфейса, которые будут принимать все команды от пользователя, а в игровых объектах подписываться на события. События лучше порождать в синглтоне, т. к. конкретные объекты интерфейса, могут меняться, и это не должно влиять на игровые объекты.
Бррр… Как-то сумбурно получилось, но, надеюсь общую идею я донес.
Кстати, если подписываетесь на события, не забудьте добавить «отписку»:
А то будет забавная ситуация, когда сцену закрыли, а объект живет и обрабатывает event’ы. Да и сборщик мусора корректно не отработает. Не отписываться можно только в том случае, если объект порождающий событие находится в той же сцене, что и обработчик и будет удален вместе с ним.
Тут непонятная ситуация — я предполагал, что закрытие сцены означает уничтожение всех ее объектов и автоматическую «отписку» от всего. Оказалось, что это не так. Больше похоже на то, что приложение просто выходит из блока, отвечающего за сцену. Предполагается, что на объекты больше нет ссылок и, их удалит сборщик мусора. Не понял, баг это или фича. Если кто понимает суть этой ситуации — поделитесь, плизз, знаниями. Очень любопытно.
Игровые объекты
Это все, что бегает, прыгает, крутится, стреляем и взаимодействует между собой на нашей сцене.
Для их общения Unity предлагает несколько подходов.
1. Связать их через public свойства. Выглядит это примерно так:
Минус в том, что нам нужно связывать объекты между собой. А если мы их динамически генерируем?
Тут нам на помощь приходит второй подход:
2. Найти объект на сцене по имени или тегу. Например:
Минус этого способа виден в самом примере — нужного объекта в сцене может и не оказаться. Хорошо, если его там вообще нет, и мы можем ничего не делать, а что, если его туда добавили, но с другим именем?
Тут опять можем обойти через статическое событие. Если каждый инстанс Car будет пробрасывать свое столкновение через статическое событие класса (CarManager), нам не придется искать объект или привязываться к нему.
Получится что-то вроде:
У такого подхода есть свои минусы и подводные камни, так что пользоваться им нужно осторожно и не забывать отписываться от событий. Но иногда он сильно помогает.
Состояние игры
Состояние игры — это обобщенное название классов, отвечающих за фиксацию прохождения уровней, загрузку следующих, набранные очки и т. п.
Главное, что тут нужно учесть — не нужно делать Application.LoadLevel( ); из игровых объектов — рано или поздно, вам потребуется ввести дополнительные проверки, подсчеты, промежуточные экраны и т. п. Лучше вынести все это в отдельный класс. Туда же можно вынести команды паузы и восстановления игры и т. п.
Т.е. в сцене уже не придется заботиться о том, что нужно делать при завершении уровня и какое имя было у предыдущей сцены, если игрок вдруг захочет ее переиграть. Просто вызываем класс-менеджер и все.
Аналогично, если нам нужно в сцене реагировать на приостановку игры, например, проставить Time.timeScale = 0; достаточно подписаться на соответствующее событие.
Все эти мелочи сильно упрощают разработку.
Взаимодействие с сервисами Google
Google расщедрился на замечательные сервисы, которые можно вызывать из мобильной игрушки. Теперь не нужно писать собственные лидерборды, ачивки и многое другое. К тому же, эти сервисы развиваются и обещают стать какой-то супер-пупер-вундервафлей.
Учитывая все это, выглядит логичным не размазывать их вызов тонким слоем по всему приложению, а сконцентрировать в одном-двух класс, связав с остальными частями приложения через события. Это позволит развивать «социальную» составляющую игры не сильно влияя на геимплей.
Реклама
Каждый провайдер рекламы предоставляет свои инструменты для показа. Разбираться в игровых классах со всем этим зоопарком нет никакого желания. Я для себя сделал простенький статически класс AdsController, с одним публичным методом: ShowBanner() и вызываю его там, где хочу показать рекламу. Вся работа с AdMob спрятана внутри и, если я решу перейти на что-то другое, лазить по коду и отлавливать вызовы не придется. Мелочь, а приятно.
Завязаться так же можно через события, но в моем случае больше подошел синглтон, т. к. интерфейс вызова рекламного блока я вряд ли буду менять, а вот игровые события могут измениться.
Т.е. вводим ограничение на частоту успешных показов. Актуально для показа баннеров. Например, я показываю их при завершении уровня или гибели. Но первые уровни проходятся за десяток секунд. Чтобы не нервировать игрока, добавил такое ограничение.
Главное — учитывать именно успешные показы. А то при глюках с соединением игрок рекламу не увидит никогда и будет огорчен тем, что не отблагодарил разработчика своим вниманием.
Социальные сервисы
Этот «слой» по своей роли очень похож на рекламный, но суть его еще проще — все команды для социальных сетей собрать в кучу, наружу выставить один статический класс с методами: PostToFacebook, PostToVk и т. п. Все, что можно спрятать — спрятать внутри классов. Через параметры передавать минимум. У меня он свелся к одному параметру — количеству набранных очков. В принципе, использование этого класса сводится просто к вызову нужного метода, когда пользователь жмет кнопку «Поделиться».
В таком виде его можно таскать из проекта в проект практически без изменений.
Заключение
Надеюсь, что этот поток мыслей оказался кому-нибудь полезен. Знаю, что ничего особенного я не рассказал и что люди, работающие с Unity давно и толково знают все это и еще 100 более подходящих способов сделать тоже самое. Надеюсь, что я помог новичкам, а знатоки поделятся своим опытом в комментариях.
Если есть интерес, могу рассказать про шишки, которые я набил при импорте 3d объектов и выстраивании структуры проекта.
Игра на Unity, с открытым кодом
Суть игры
Идея пришла внезапно, и пока она не улетела решил записать а потом и воплотить ее. Представьте холодную, темную камеру в некой тюрьме. В ней сидит, неизвестно как и неизвестно кем, прикованный волшебник, которого каждую ночь мучает всякая нечисть. Из последних сил он создает небольшой файрбол и вдыхает в него подобие жизни.
Познакомьтесь, это Кальцифер, ваш аватар в этой игре.
Именно им вы будете уничтожать вся гадость, которая ползет в сторону нашего закованного бедняги.
Пояснения насчет кода
Начнем с GameManager. Он всему голова, именно в нем меняется состоянии игры — Initialization->GameLoop->Win или Lose. Одинок и един, ибо синглтон. Так как игра не сетевая, простая, и без сложных переходов, то было принято решение использовать этот паттерн. Здесь же идет обработка попаданий по игроку (см. ниже Известные проблемы), учет хитпоинтов и проверка на выигрыш\проигрыш. Был бы GodObject, да слишком мало у нас классов, поэтому знает не всё обо всех. На этапе инициализации, создается пул объектов отображающих анимацию урона по игроку и смерти врагов. Для отслеживания состояния хитпоинтов, можно подписаться на UpdateHpWizardDelegate или UpdateHpCalciferDelegate. В нашем случае это делает GUIManager для отображения текущего хп на экране.
К этому времени SpawnManager уже составил список точек спавна врагов
a WaveManager загрузил порядок волн создания врагов. Волны можно настроить двумя способами: прописать в коде игры или загрузить с Json файла. Для редактирования этого Json написан кастомный editor:GameDataEditor
Можно прописать точный номер спавна или указать что можно создаться на любом свободном.
Создание волн сделанно с помощью хитрой корутины:
Вначале проходит firstWaveDelay секунд до начала запуска 1 первой волны. После этого в цикле прогоняют все волны по очереди, вставляя нужную задержку step.delay между шагами волны. Почему в корутине а не например в Update? Да собственно можно и так и эдак, просто тут более наглядно, видно где задержка ( yield return new WaitForSeconds) и не надо городить лишние циклы и проверки.
Давай те глянем что же представляют из себя SpawnPoint. Это MonoBehavior c 2 компонентами: SpawnPoint и CircleCollider2D. В первом, с помощью второго, определяется занят ли спавн каким то врагом. OnDrawGizmos отображает в редакторе Unity расположение спавнов.
Все враги происходят от базового класса BasicEnemy в котором есть несколько виртуальных методов:
Кстати, врагов и многие другие объекты (много и часто создаваемых на сцене) мы не удаляем с помощью Destroy(this), а отправляем обратно в пул объектов — ObjectPool.Recycle(this). Таким макаром мы неплохо экономим на создании объектов, которое как известно достаточно затратное дело.
Так например анимации заканчиваются вызовом SelfDestroy(), который и возвращает объект анимации обратно в пул.
Движутся же враги с помощью силы пафоса компонента BasicEnemyMoving. В нем нас интересуют два метода: OnEnable()и Move(). OnEnable () вызывается после вытаскивания врага с пула и нужен для поворота врага (если необходимо) в сторону цели.
Move() же является виртуальным методом, который и движет врага к цели. Его можно переопределить в потомках и сделать особенное движение (с рывками, синусоидальное и т.п.)
Готовые коды для unity
Местные жители используют синие кристаллы для создания защитных полей вокруг своих домов 🎮🏠💎
А ничего что количество аргументов в делегатах разное и оверрайднуть нельзя из-за этого?
Mr_Fog, Спасибо) осенью планируем выпустить новую демку)
Игра просто супер. Спасибо большое за столь интересный и не обычный проект.
Делаем с командой игру.
В этой сцене мы впервые сталкиваемся с потусторонними силами.
Линейка новых скриншотов The Darkest Red 🎮🤺💥🧟🔥
Jusper, Привет!
Так она же давно в релизе уже больше года)
Продолжаем делать наш Unity for dummies платформер.
Полные версии кода будут находиться в конце поста.
Если вы не в курсе, как работают хуки жизненного цикла в Unity, вы можете ознакомиться с данной статьёй.
Создаём в панели ассетов C# cкрипт PlayerBehaviour, и запихиваем его в папку Scripts (её можно создать в той же панели ассетов).
Затем выбираем наш объект Player слева, в меню иерархии, и закрепляем инспектор (меню справа), нажав на замок в верхнем правом углу.
Пока закрываем все ненужные компоненты (Box Collider 2D, etc), нажимая на стрелочку у каждого из них.
Теперь перетаскиваем наш скрипт в инспектор, и он прикрепляется к объекту Player (если вы не выполнили предыдщуий пункт с закрепением меню, то вы этого сделать не сможете).
Если зайти в Edit => Project Settings => Input Manager, то мы можём увидеть настройки управления. Например, прыжок (Jump) назначен на пробел, в то время, как движение по горизонтали назначено на a, d, ←,→.
Запомним это для того, чтобы затем использовать в коде (названия инпутов Jump, Horizontal).
Пора покодить. Два раза нажимаем на наш скрипт PlayerBehaviour, и Unity отдаст его в руки Visual Studio.
Сохраняем файл, и переходим обратно в Unity. После того, как Unity проверит код (линтинг, ошибки, пустые переменные). Если что то неправильно, то вы увидите сообщение об ошибке.
Исправляем код, и страшные красные буквы исчезают. Можно запустить игру, и проверить, как все работает.
Мне не нравится, что персонажа переворачивает. Исправим.
Заходим в инспектор, открываем Rigidbody2D и ставим галочку на Freeze Rotation Z.
Есть два основных способа научить камеру двигаться за персонажем.
1. Подвинуть камеру внутри сцены, чтобы она была на персонаже, а затем в привязать камеру к объекту персонажа через меню иерархии.
2. Задать движение камеры за персонажем програмно.
Создаём скрипт CameraBehaviour, и привязываем его к объекту Main Camera (добавляем через инспектор).
Открываем наш новый скрипт, и начинаем кодить (да, мне на работе не хватает, продолжаю и после).
Фиксируем объект камеры на замок в инспекторе, и перетаскиваем наш объект Player в GameObject.
Теперь камера двигается за игроком.
Однако камера постоянно вылезает за пределы уровня, показывая синий фон.
Я не уверен, что моё решение правильное. Буду рад, если кто-нибудь поделится своими соображениями на данный счёт.
Добавляем в наш скрипт CameraBehaviour следующий код:
Двигаем камеру, и снимаем наши измерения ее положений.
На скрине ниже камера стоит в левом нижнем углу сцены.
Проставляем снятые позиции для камеры (мои и ваши позиции будут отличаться).
Теперь обновим метод UpdateCameraPosition в скрипте CameraBehaviour
Отлично, камера перестала «гулять». Работаем дальше.
Выбираем наш Foreground, и создаём новый слой ‘Ground’ в инспекторе.
Снова тыкаем на Foreground, и выбираем в поле Layer наш только что созданный слой.
Добавим в PlayerBehaviour такую строчку.
Теперь в объекте Player мы можем выбрать наш свежесозданный слой.
Обновляем наш PlayerBehaviour. Добавим коллайдер (rigidBody мы создавали ранее).
Теперь мы можем обновить обработку перемещения персонажа в методе updatePlayerPosition
Летать мы разучились, а по платформе больше не скользим. Победа!
Я не уверен, что моё решение правильное. Буду рад, если кто-нибудь поделится своими соображениями на данный счёт
Привет.
Я, конечно, дохуя вовремя, когда у тебя уже пять статей и рефакторинг, но вот щас иду за тобой пока вот на этом месте.
Короче, в ассет-сторе есть проект 2D Game Kit от разрабов движка. Там движение камеры сделано буквально следующим образом, если помню (давно открывал). Уровень завёрнут в коллайдер, ещё один коллайдер на камере. Соответственно, когда она о него стукается, то расслабляется и не двигается. И ещё там угарный камера-лаг стоит, чтоб камера не жёстко следовала за персонажем, а как бы за верёвочку.
Привет.
Да, я изначально так и пробовал.
Но персонаж, почему-то, попросту исчезает при старте игры.
Попробую ради эксперимента новый проект создать.