готовые скрипты для юнити

Топ 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 системы освещения с контрастными тенями. Хорошо подойдет если вы делаете тактическую игру, стэлс платформер или какой-нибудь хоррор. Подобный ассет добавит в вашу игру атмосферы.

Источник

Скрипты C#/JS | Unity3d

Скрипты C#/JS | Unity3d запись закреплена

C# Clean Code Tips&Tricks #1

В данной рубрике будут простые и короткие примеры как сделать ваш код более красивым и читаемым.

В конечно результате y будет равен 100, так как x равен null.

Иногда мы обращаемся к объекту, а он может быть равен null, тогда надо перестраховаться и сделать проверку на null, которая будет выглядеть вот так:

Но можно сделать данное выражение более красивым и приятным для чтения:
_player?.Gun.SomeMethod();

Скрипты C#/JS | Unity3d запись закреплена

Liskov Substitution Principle

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

«Пусть q(x) является свойством верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T.» © Wikipedia

«Если для каждого объекта o1 типа S существует объект o2 типа T, такой, что для любой программы P, определенной в терминах T, поведение P не изменяется при замене o2 на o1, то S является подтипом T.» © Metanit

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

Итак, принцип подстановки Барбары Лисков. Он же Liskov Substitution Principle. Он же LSP. Простыми словами принцип звучит так:

Объекты класса родителя должны иметь возможность замещаться объектами класса наследника так, чтобы целостность программы не нарушалась.

Т.е. Если у вас есть класс Enemy и она весит на объекте в игре, все работает и все прекрасно, потом вы решили создать класс Zombie, который наследуется от Enemy, и у вас должна быть возможность заменить класс Enemy на объекте на Zombie и ваша игра должна продолжить функционирование.

Драма в 3-х актах:
Акт 1.

Акт 2. Первые проблемы.

Акт 3. Решение проблемы.

Надеюсь, что данный пример и разбор был вам полезен. Также, если под этим постов будет много лайков, то я начну прикреплять примеры кода в Unity, чтобы вам стало еще более понятно.

Всем спасибо за внимание.

Скрипты C#/JS | Unity3d запись закреплена

SOLID. Часть 2.
Open/Closed Principle
Принцип закрытости/открытости:
Объекты и сущности должны быть открыты для расширения, но закрыты для модификации.

А вот как было бы правильно. Прочитав эту статью, вы набрались знаний и сели заново проектировать атаку робота. Так, думаете вы, логика атаки явно будет изменяться, так что надо предусмотреть ее модификацию, но сделать так, чтобы основной класс обработки атаки не раздувался. Поэтому вы прописываете базовую логику атаки, а-ля просто ее запуск по нажатию на клавишу. Но сам запуск логики мы будем производить через интерфейс, т.е. само нанесение урона, спавна каких-то эффектов и еще особенности, которые будут присущи какому-нибудь типу атаки, будут уже в классе, которые реализует интерфейс IAttackType. В этому интерфейсе будет всего одна функция Attack(). А классы LazerAttack, BulletAttack и т.д. будут реализовывать логику атаки. Таким образом у вас будет класс PlayerAttack, а в нем будет переменная типа IAttackType, которая будет в себе содержать ссылку, на нужный нам класс, который реализует интерфейс IAttackType. Таким образом, когда вас попросят реализовать еще какой-нибудь вид атаки, то вы просто создадите класс, который реализует интерфейс IAttackType и все. А когда вашего PlayerAttack не изменится. А подмену ссылки в зависимости от выбранного вам типа атаки, можете сделать в классе AttackTypeSelect. Теперь вы можете создать новые типы атак не модифицирую PlayerAttack и соблюдая принцип открытости/закрытости.

Все спасибо за внимание!

Скрипты C#/JS | Unity3d запись закреплена

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

Сначала я думал вставлять код в данную статью, но это выглядит очень не аккуратно и громоздко, так что я отказался от этого. Я попытаюсь дать вам какой-нибудь хорошо запоминающийся пример, который вы вспомните, когда будете проходить собеседование или писать код. Но сначала немного теории.

SOLID — принципы объекто-ориентированногопрограммирования.

SOLID это аббре­ви­а­тура пяти основ­ных прин­ци­пов про­ек­ти­ро­ва­ния в объ­ектно-ори­ен­ти­ро­ван­ном про­грам­ми­ро­ва­нии — Single responsibility, Open-closed, Liskov substitution, Interface segregation и Dependency inversion (прин­ципы един­ствен­ной ответ­ствен­но­сти, откры­то­сти / закры­то­сти, под­ста­новки Бар­бары Лис­ков, раз­де­ле­ния интер­фейса и инвер­сии зависимостей)

Аббре­ви­а­тура SOLID была пред­ло­жена Робер­том Мар­ти­ном, авто­ром несколь­ких книг, широко извест­ных в сооб­ще­стве разработчиков. Эти прин­ципы поз­во­ляют стро­ить на базе ООП мас­шта­би­ру­е­мые и сопро­вож­да­е­мые про­грамм­ные про­дукты с понят­ной биз­нес-логи­кой.

Single responsibility (прин­цип един­ствен­ной ответ­ствен­но­сти)
Open-closed (прин­цип откры­то­сти / закры­то­сти)
Liskov substitution (прин­цип под­ста­новки Бар­бары Лис­ков)
Interface segregation (прин­цип раз­де­ле­ния интер­фейса)
Dependency inversion (прин­цип инвер­сии зави­си­мо­стей)

Single responsibility principle
Итак, начнем с одного из самых простых принципов, коим является принцип единственной ответственности. Он гласит, что у вашего класса должна быть только одна причина для изменения. А под обязанностью здесь понимается набор функций, которые выполняют единую задачу. Суть этого принципа заключается в том, что класс должен выполнять одну единственную задачу. Но, думаю, тут лучше всего перейти сразу к примеру, так будет понятнее. Полагаю, что подавляющее большинство читающих именно создатели игр, поэтому и пример будет основан на моменте из разработки игры.

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

И пускай ваш код, будет таким же, как и это телефон!

Надеюсь, что пример был не плохим и понятным, и вы запомните его! Теперь, когда будете создавать свой новый шедевр, вспоминайте иногда этого робота или телефон, но не злоупотребляйте этим принципом, так как он может уже сыграть не во благо, а во зло.

Всем спасибо за прочтение!

Скрипты C#/JS | Unity3d запись закреплена

Принцип программирования KISS — keep it simple stupid (делайте вещи проще).
KISS — это принцип проектирования и программирования, при котором простота системы задается как основная цель. Есть два варианта расшифровки аббревиатуры: «keep it simple, stupid» и более корректный «keep it short and simple».

В про­ек­ти­ро­ва­нии сле­до­ва­ние прин­ципу KISS выра­жа­ется в том, что:

не имеет смысла реа­ли­зо­вы­вать допол­ни­тель­ные функ­ции, кото­рые не будут исполь­зо­ваться вовсе или их исполь­зо­ва­ние крайне мало­ве­ро­ят­но, как пра­ви­ло, боль­шин­ству поль­зо­ва­те­лей доста­точно базо­вого функ­ци­о­на­ла, а услож­не­ние только вре­дит удоб­ству при­ло­же­ния;
не стоит пере­гру­жать интер­фейс теми опци­я­ми, кото­рые не будут нужны боль­шин­ству поль­зо­ва­те­лей, гораздо проще преду­смот­реть для них отдель­ный «рас­ши­рен­ный» интер­фейс (или вовсе отка­заться от дан­ного функ­ци­о­нала);
В про­грам­ми­ро­ва­нии сле­до­ва­ние прин­ципу KISS можно опи­сать так:

не имеет смысла бес­пре­дельно уве­ли­чи­вать уро­вень абстрак­ции, надо уметь вовремя оста­но­вить­ся;
бес­смыс­ленно закла­ды­вать в про­ект избы­точ­ные функ­ции «про запас», кото­рые может быть когда-нибудькому-либо пона­до­бятся;
не стоит под­клю­чать огром­ную биб­лио­те­ку, если вам от неё нужна лишь пара функ­ций;
деком­по­зи­ция чего-то слож­ного на про­стые состав­ля­ю­щие — это архи­тек­турно вер­ный под­ход ;
Принцип программирования DRY — don’t repeat yourself (не повторяйте себя).
Если код не дуб­ли­ру­ет­ся, то для изме­не­ния логики доста­точно вне­се­ния исправ­ле­ний всего в одном месте и проще тести­ро­вать одну (пусть и более слож­ную) функ­цию, а не набор из десят­ков однотипных. Сле­до­ва­ние прин­ципу DRY все­гда при­во­дит к деком­по­зи­ции слож­ных алго­рит­мов на про­стые функ­ции. А декомпозиция слож­ных опе­ра­ций на более про­стые (и повторно исполь­зу­е­мые) зна­чи­тельно упро­щает пони­ма­ние про­грамм­ного кода. Повтор­ное исполь­зо­ва­ние функ­ций, выне­сен­ных из слож­ных алго­рит­мов, поз­во­ляет сокра­тить время раз­ра­ботки и тести­ро­ва­ния новой функциональности.

Сле­до­ва­ние прин­ципу DRY при­во­дит к модуль­ной архи­тек­туре при­ло­же­ния и к чёт­кому раз­де­ле­нию ответ­ствен­но­сти за биз­нес-логику между про­грамм­ными клас­са­ми. А это — залог сопро­вож­да­е­мой архи­тек­ту­ры. Хотя чаще не DRY при­во­дит к модуль­но­сти, а уже модуль­но­сть, в свою оче­редь, обес­пе­чи­вает прин­ци­пи­аль­ную воз­мож­ность соблю­де­ния этого прин­ципа в боль­ших про­ек­тах.

В рам­ках одного про­грамм­ного класса (или модуля) сле­до­вать DRY и не повто­ряться обычно доста­точно про­сто. Также не тре­бует тита­ни­че­ских уси­лий делать это в рам­ках неболь­ших про­ек­тов, где все раз­ра­бот­чики «вла­деют» всем кодом систе­мы. А вот в боль­ших про­ек­тах ситу­а­ция с DRY несколько слож­нее — повторы чаще всего появ­ля­ются из-за отсут­ствия у раз­ра­бот­чи­ков целост­ной кар­тины или несо­гла­со­ван­но­сти дей­ствий в рам­ках команды. Следовать прин­ципу «don’t repeat yourself» в рам­ках боль­ших про­ек­тов не так про­сто, как это может пока­заться на пер­вый взгляд. От раз­ра­бот­чи­ков тре­буется тща­тель­ное пла­ни­ро­ва­ние архи­тек­ту­ры, а от архи­тек­тора или тим­лида тре­буется нали­чие виде­ния системы в целом и чёт­кая поста­новка задач раз­ра­бот­чи­кам.

В пректировании DRY тоже имеет место — доступ к кон­крет­ному функ­ци­о­налу дол­жен быть досту­пен в одном месте, уни­фи­ци­ро­ван и сгруп­пи­ро­ван по какому-либо прин­ципу, а не «раз­бро­сан» по системе в про­из­воль­ных вариациях.

Принцип программирования YAGNI — you ain’t gonna need it (Вам это не понадобится).
Основ­ная про­бле­ма, кото­рую решает принцип YAGNI — это устра­не­ние тяги про­грам­ми­стов к излиш­ней абстрак­ции, к экс­пе­ри­мен­там «из инте­реса» и к реа­ли­за­ции функ­ци­о­на­ла, кото­рый сей­час не нужен, но, по мне­нию раз­ра­бот­чи­ка, может либо вскоре пона­до­бить­ся, либо про­сто будет поле­зен, хотя в реаль­но­сти такого очень часто не про­ис­хо­дит.

«Бес­плат­ных» функ­ций в про­грамм­ных про­дук­тах про­сто не быва­ет. Если рас­смат­ри­вать мате­ри­аль­ную сто­ро­ну, то любые ненуж­ные, но фак­ти­че­ски реа­ли­зо­ван­ные «фичи» опла­чи­ва­ются либо Заказ­чи­ком (в бюд­жет закла­ды­ва­ются рас­ходы на те функ­ции, кото­рые не нужны), либо Испол­ни­те­лем из при­были по про­ек­ту. И тот, и дру­гой вари­анты с точки зре­ния биз­неса невер­ны. Если же гово­рить о нема­те­ри­аль­ных затра­тах, то любые «бонус­ные» воз­мож­но­сти услож­няют сопро­вож­де­ние, уве­ли­чи­вают веро­ят­ность оши­бок и услож­няют вза­и­мо­дей­ствие с про­дук­том, — между объ­ё­мом кодо­вой базы и опи­сан­ными харак­те­ри­сти­ками есть пря­мая зави­си­мо­сть. Больше напи­сан­ного кода — труд­нее сопро­вож­дать и выше веро­ят­ность появ­ле­ния «багов», тут очень уместна пого­вор­ка: «луч­ший код — это нена­пи­сан­ный код».

Принципы YAGNI и KISS очень похо­жи, если KISS наце­лен на упро­ще­ние и поле­зен в плане работы с теми тре­бо­ва­ни­я­ми, кото­рые имеют место быть, то YAGNI более кате­го­ри­чен и при­ме­ня­ется для ограж­де­ния про­ек­тов по раз­ра­ботке ПО от «раз­мы­ва­ния» их рамок.

Источник

Готовые скрипты для юнити

FXAA Fast Approximate Anti-Aliasing
Сглаживание FXAA для ваших проектов в Unity3D.

FXAA Fast Approximate Anti-Aliasing являетс.

эффект DOF с написанной мною, реалистичной фокусировкой

Можно настроить Layer Mask и выключить фокусировку
— Теперь фокусировк.

Тени, очень важная часть в 3D пространстве. Тем не менее, тени это сложный процесс для GPU.
Fast Shadow Re.

Unity 4.3.3 или выше.

Fragmented Objects представляет собой набор объектов, которые деформируются и контролируются с помощью скрипта.

Unity 4.6.5 или выше.

Time of Day это пакет для рендеринга реалистичного и динамического небесного купола со сменой дня и ночи, реали.

Источник

Скрипты для редактора в Unity3D

Сегодня поговорим о том, как писать скрипты для Unity Editor. Статья рассчитана на тех, кто уже знаком с Unity3D, что-то успел сделать, но еще не решился попробовать писать скрипты для эдитора.

Если коротко — то в режиме эдитора скриптами можно сделать абсолютно всё тоже самое, что и в режиме игры.

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

Теперь попробуем выполнить этот код в режиме эдитора, для этого нужно к коду добавить всего лишь один волшебный атрибут [ContextMenu()] к функции Create10Cubes():

так чтобы код выглядел вот так:

Теперь, если мы нажмем правой кнопкой по заголовку скрипта, там появится пункт CreateCubes, при нажатии на который функция точно также будет выполнена.

Важное замечание: функция, помеченная атрибутом ContextMenu, не должна иметь параметров, вернее, если у нее будут параметры, вы не сможете вызвать таким способом.

Лично я применяю такой способ, когда нужно что-то сделать с группой объектов, например, выключить отбрасывание теней у всех детей объекта, у которых в названии встречается «withoutshadow»:

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

Теперь давайте решим следующую задачу: мы хотим запечь occlusion culling. Для этого нам необходимо пометить галочкой Occluder Static все объекты, которые бубдут загораживать другие объекты, и галочкой Occludee Static все, которые будут скрываться за Occluder`ами. То есть нам нужно вычленить все статичные объекты, непрозрачным объкетам поставить обе галки (на самом деле все), прозрачным — только Occludee, а Occluder выключить.

Казалось бы, ну что такого, пробежался по сцене ручками — расставил кому нужно галочки — и все. Но проблема в том, что объектов в сцене может быть много и в процессе развития проекта сцена скорее всего будет меняться. Следить самому за всеми этими галочками — с ума можно сойти. Поэтому мы напишем маленький скриптик, который делает это за нас.

Для начала напишем полезный код, который выполняет нашу работу, а далее оформим это в отдельный виззард:

1) Найти интересующие нас объекты в сцене;
2) Расставить нужные галочки.

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

Здесь мы предполагаем, что статичные объекты уже до этого каким то образом нашли (скорее всего ручками) и отметили их галочкой Static, а значит, в том числе и BatchingStatic.

Теперь давайте оформим отдельный виззард, чтобы можно было удобно вызывать эту команду:

Тут нам пригодится класс EditorWindow.

На этом пока закончим наш обзор, он получился далеко не полным.

В следующих статьях я планирую описать, как можно создавать кастомные инспекторы для ваших классов, как вмешиваться в процесс импорта ассетов, как можно поставить запекать тени на 20-ти уровнях по очереди и получить скриншоты с результатом себе на почту.

Источник