Как сделать игру через unity
🏓 Создаем 2D-игру на Unity: инструкция для новичка
Двумерные игры сравнительно просты: для них не требуется сложных 3D-моделей, программный код по сравнению с 3D-проектами выглядит понятнее. Такие игры популярны как на десктопах, так и на мобильных устройствах. Unity также позволяет разрабатывать игры и для браузеров.
За последние годы вышло много популярных двумерных игр:
Программная реализация 2D-игр проще не только из-за отсутствия третьего измерения: на самой сцене меньше объектов, вместо трехмерных моделей плоские спрайты, вместо скелетной анимации – покадровая. А еще 2D-игры проще портировать на другие платформы – легче найти новую аудиторию.
Особенности создания 2D-игр на Unity
Предварительно рассмотрим основные понятия Unity, без понимания которых будет проблематично создать игру:
Пошаговый процесс создания 2D-игры на Unity
Предполагаем, что вы уже установили редактор и создали аккаунт на портале Unity.
В первую очередь создадим новый проект и откроем его настройки (Edit → Project Settings). Во вкладке Editor установим параметр Default Behaviour Mode в значение 2D
Настройка проекта
Детальная настройка проекта
Следующим шагом сохраним текущую активную сцену, назвав ее, например, Scene1. Теперь создадим основные игровые объекты: ракетку, мяч и менеджер игры, в котором будет храниться основная логика игры.
1. Создаем пустой объект, переименовываем в GameManager.
Создаем пустой объект
2. Создаем C#-скрипт с названием GameManager. Ассоциируем скрипт с объектом GameManager, перетащив мышкой скрипт на объект.
Создаем C# скрипт
3. Создаем квадратный спрайт, называем его Pad (Assets → Create → Sprites → Square). Аналогично создаем круглый спрайт Ball (Assets → Create → Sprites → Circle). Масштабируем спрайт Pad со следующими параметрами – x:0.5, y:2.5, z:1.
Создаем спрайты
4. Создаем префабы для Pad и Ball, после чего добавляем к ним компонент Box Collider 2D (включаем параметр Is Trigger) и компонент Rigidbody 2D (выставляем параметр Body Type в значение Kinematic).
5. Создаем C#-скрипты Ball и Pad. Ассоциируем их с префабами.
6. Заполняем скрипты следующим кодом.
GameManager.cs Ball.cs Pad.cs
6. Добавляем к префабу Ball и Pad теги с аналогичными именами. Выделив префабы, в инспекторе мы можем видеть выпадающий список тегов. Там же расположены и кнопки для добавления и редактирования тегов.
7. В настройках камеры выставляем параметр Projection в значение Orthographic, а параметр Clear Flag – в значение Solid Color.
Настройка камеры
8. Настраиваем кнопки, как показано на следующих скриншотах (Edit → Project Settings → Input Manager).
Настройка ввода, основное
Настройка ввода, первый игрок
Настройка ввода, второй игрок
Вот и всё, игра готова!
Пинг-понг, итоговый результат
Билд для платформы Windows
Дополнительные туториалы
1. Официальный туториал от Unity, где детально рассмотрен процесс создания roguelike RPG.
3. Youtube-канал N3K EN содержит множество уроков как по отдельным компонентам Unity, так и полноценные серии уроков по созданию игр с нуля.
В числе прочего вы разработаете 2D-платформер с физическими загадками и динамическим освещением, научитесь портировать его на мобильные устройства. Кроме того, разработаете полноценную браузерную стратегию, а также игру в жанре двухмерных гонок.
По окончании обучения вы будете иметь портфолио из 4 игр, которое можно показать на собеседовании. Если же какая-то часть материала будет непонятна, вы всегда можете обратиться к персональному преподавателю.
Разработка первой игры [на Unity3D]
Когда-то я пошел на ПОВТ (можете вставить свою специальность в IT) для того чтобы узнать как писать игры. Хотя обучение и было несколько отдалено от интересующей тематики, оно принесло фундаментальные знания, без которых было бы очень тяжело. Дальнейшая после выпуска работа в нескольких компаниях только затягивала в энтерпрайз, отдаляя от геймдева. Но, время от времени, покупая новую игру, или наблюдая за разработкой очередного тайтла, возникает очень навязчивая идея — «Хочу этим заниматься!».
Первые попытки обычно ничем хорошим не заканчиваются — множество мини прототипов так и остаются на самой ранней стадии, или укладываются «в стол». Это не плохой этап и от него никуда не деться. Со временем, желание завершить что-либо станет настолько навязчивым, что вы сможете это сделать.
За последний проект я взялся очень крепко и довел до стадии релиза.
В данной статье хотелось пройти по базовым этапам создания новой игры, с изрядной долей субъективного мнения. Я не буду углубляться в детали реализации и код — больше хотелось поделиться своим опытом и помочь тем, кто вынашивает свои идеи, но не предпринимает дальнейших шагов. Если вы готовы, то добро пожаловать!
Вступление
Поиск и взращивание идеи
Идеи приходят достаточно часто, в большинстве своем они быстро отметаются, но некоторые будут возвращаться снова и снова. Записывайте их, просто запоминайте, и если через какое-то время вы снова вернетесь к конкретной, и начнете прокручивать ее вариации — стоит к ней присмотреться. Если она все еще будет вас захватывать — беритесь за нее!
Нельзя начинать без основной идеи, определяющей всю игру с самого начала. Конечно, во время разработки вы пройдете через этапы, когда она покажется слишком банальной и никому не интересной, вас будут отвелкать новые возможности, захочется все изменить, бросить начатое, но не стоит отступать от начального плана, у вас еще будет шанс скорректировать начатое.
В моем случае, идеей стал жанр гонок на лодках.
Сюжет
Был написан небольшой сценарий — буквально несколько абзацев текста, который делил игру на все стадии, от начала и до конца, с конкретными целями и задачами, объединенными общей историей. Нет, в нем не было каких-то откровений и поворотов, он абсолютно прямой. Но без сюжета, без возможности завершить игру — вы просто тратите время игрока впустую — да, есть аудитория и у такого рода игр, но это просто неуважение к игровой культуре в целом. Если вы в очередной раз садитесь делать раннер — то дайте игрокам ощутимый прогресс, дайте возможность завершать начатое, дайте наконец пройти все, что есть, и обновляйте игру позже для следующей части приключений(или продавайте), подумайте над реиграбельностью, повторным прохождением, если уж других идей нет — но никогда не выпускайте что-то без завершающего экрана!
Отсутствие сюжета оправданно, только если ваша игра — сугубо соревновательная дисциплина. В последнем случае, если это не совсем абстрактные игры вроде Го, шашек, шахмат — стоит озаботиться четким описанием мира игры, чтобы самому не допустить ошибок этого мира, при наполнении контентом или во время создания героев. «Lore» очень важен для игроков, и если детали мира подчеркиваются невидимыми нитями сквозь все произведение, это придаст атмосферность, ради которой игрок будет возвращаться снова и снова.
Вдохновение
Многие разработчики сами играют в игры, смотрят фильмы и сериалы, читают книги и зачастую привносят в проекты свое видение или новую интерпретацию оттенков затронутых произведений. Сейчас сложно придумать что-то концептуально новое, и не бойтесь перенять что-либо у других продуктов. Иногда, хороший проект скаладывается из достаточно простых вещей на поверхности других игр, конечно, и здесь есть исключения, но черпайте вдохновение повсюду и осторожно смешивайте в своем проекте.
Мое вдохновение пришло в основном из трех игр. Главный стиль вспомнился, неожиданно, с Mario, а именно Sunshine — была такая игра на GameCube — в ней вода была повсюду, она была очень красива, в игре даже были несколько миссий-мини гонок на этой воде, но, как мне до сих пор кажется, с тех пор, во всех новых Mario такой приятной воды просто нет. Еще в то время когда я проходил игру у меня появился концепт гоночного аппарата с двигателями-водометами из игры. Я не особо задумывался о том, что когда-то реализую эту задумку, но вспомнить свои эмоции более чем десятилетней давности было очень приятно.
Основным вариантом геймплея стал, так называемый, заезд на время — тут хотелось добиться чего-то схожего с серией TrackMania. Возможно, в последней части (Turbo) разработчики перешли некую грань хардкорности граничащей с невозможностью идеальных прохождений на
но интенсивность гонок, которые хочется проходить без ошибок как можно быстрее, с мгновенным перезапуском в случае ошибки — вот тот ключевой момент, который определил весь геймплей.
Дополнительно не хотелось ограничивать игрока между уровнями, хотелось постоянного контроля за героем, поэтому решено было сделать игру в открытом мире, при этом запуск гонок вдохновлен начальным BurnoutParadise, в котором не было запуска гонок из меню, и даже рестарта — нужно было всегда подъезжать к точке на карте и начинать заново. В моем случае рестарт остался, но эта возможность поддерживается очень непродолжительное время после конца гонки.
Конечно, это все игры ААА-класса, и из каждой была взята только небольшая деталь, но, как я уже упоминал, никогда не стоит отворачиваться от того, что уже есть на рынке. Несомненно, если ваш геймплей настолько уникален, что никто вокруг не предлагает ничего подобного это замечательно, но в моем случае был интерес — создать приятный продукт без замашек на концептуальную уникальность. Вспомнилось время, когда я ставил себе каждую из shareware игр, прилагаемых к игровым журналам, и хотелось сделать игру по качеству не ниже таких проектов.
Концепт
Концепт должен отражать главную механику — в моем случае это было поведение базовой лодки, на воде, с возможностью изменения ее характеристик, а также базовое управление и камера.
Несмотря на то, что с Unity3d до этого не было особого знакомства, этот этап не стал чем то невероятно сложным.
Для достоверного поведения лодки пришлось несколько углубиться в физику процессов и написать свой честный Buoyancy-скрипт взяв за основу один из найденных в сети. После первых попыток, в которых использовалось значительное упрощение протекаемого процесса, без плеча силы, и разделения объемов, все стало ощущаться просто отлично!
Также был создан скрипт с параметрами, определяющими максимальную скорость, плавучесть, и некоторые другие через интерфейс редактора. Старайтесь не злоупотреблять публичными полями для редактора, зачастую многие из изначально выбранных в качестве открытых редактируемых редактором полей, после некоторых тестов принимают конкретные значения навсегда, и с этого момента стоит их закрыть в свойства класса.
Камера была создана как отдельный физический объект, который стремится к следованию за определенной точкой в пространстве — для этого к ней применяется сила притяжения и дополнительно ограничиваются максимально возможные углы мгновенного поворота и расстояние на мгновенное перемещение. Даже в итоговом варианте я не стал ничего предпринимать по поводу прохождения камеры сквозь объекты, лишь добавилась возможность мгновенного телепорта камеры к новой точке.
Рабочий прототип
На данном этапе сконцентрируйтесь на реализации всех моментов вашей сюжетной составляющей. Все части игры и основные механики(если их несколько) должны быть реализованы, чтобы вы смогли «пройти» пусть урезанную игру в виде последовательности всех механик от начала и до конца — пусть без конкретных решений в визуальном дизайне, именно на уровне прототипа.
Этот этап самый важный — именно здесь вы поймете, что будет представлять игра без всей мишуры оформления арта и дизайна. Только голая механика всей игры. Именно с такими прототипами — дополнительно улучшенными визуально, и собранными в некий бесшовный продукт, студии утверждают свои проекты. Вы также можете обнаружить на данном этапе, что механики не работают, что нужны радикальные изменения. Утвердите для себя игру и продолжайте дальше, с этого момента игра наполнится продолжительностью, украшениями и содержанием.
В моем случае я создал базовый вариант треков, со стартерами, непосредственно стартом и финишем и чекпоинтами. Стало возможным проехать различные треки, появился стартовый экран и механика отображения истории в слайдах — сначала это были просто квадраты цвета — и их я видел еще очень продолжительное время.
Развитие прототипа
Время улучшать наш прототип до вида продукта, который определенным образом похож на окончательный. Выпишите все идеи по поводу того чем можно украсить игру, и все, без чего вы не можете ее видеть в релизном варианте, отметьте незначительные. Постарайтесь включить как можно больше самых привлекательных для вас пунктов. Смиритесь с тем, что и они не все уйдут в конечный продукт. Теперь вы готовы к украшению и наполнению мира вашей игры! Совет во время реализации — не бойтесь что-то ломать!
Местами это похоже на работу скульптора(или художника), когда ты должен высечь форму, но идеального варианта не существует, и каждый штрих лишь придает новые очертания. По-началу с этим сложно свыкнуться, т. к. с точки зрения программиста это слишком недетерминированно. Попробую объяснить — когда в нашей сцене раскладываются какие-то объекты, то надо просто принять, что они будут лежать на своих местах всегда, и если в очередной раз мы бросим свежий взгляд и сдвинем все под наше новое видение, то этого не изменить — промежуточные варианты затираются среди всех возможных. Быстро восстановить один из конкретных вариантов просто нельзя. Конечно, в критических ситуациях я дублирую все объекты для отката, но после принятия нового варианта старый уходит безвозвратно.
Для кода же используйте любую систему контроля версий, но это скорее обязательный пункт, и я не думаю, что кто-то в наше время обходится без него.
Я (еще|не) художник!
Самым сложным стала разработка всех моделей, текструирование и отрисовка картинок сюжета, поданных в виде кадров стилизованных под комикс.
Картинок было немного — в районе 20, но создать раскадровки, и наполнить их содержанием — к сожалению, на это ушло больше времени чем хотелось.
С моделями все тоже было неоднозначно — когда-то был небольшой опыт моделинга в личных целях, и даже были добавлены пара автомобилей в GTA3, но в таких масштабах ничего не делалось. Учитывая развертки и оптимизацию моделей, это было самой сложной частью. Всего, для наполнения мира, их было создано больше сотни, и я считаю, что этого все еще недостаточно, но с таким темпом игра никогда бы не подошла к стадии релиза.
Аналогично художественной составляющей есть работа со звуком. Это очень важная часть, но, к сожалению, без возможности лицензировать треки и звуки наш выбор очень ограничен. Есть несколько ресурсов, из которых я выбрал совсем не требующие лицензирования варианты. Однако для более серьезного проекта это не подойдет. Если вы сами сможете записывать и производить нужные звуки, музыку — это просто отлично!
В будущем стоит скооперироваться с композиторами инди сцены, они также рады к сотрудничеству, и множество современных инди игр именно так и озвучены.
Завершение продукта
Просмотрите еще раз первоначальный сценарий — завершите все задачи по его исполнению. Еще раз осмотрите список идей по украшению, но остановите себя, если он содержит пункты непервостепенной важности. Покажите этот вариант знакомым, спросите, что им понравилось, а что нет. Не бойтесь принимать критику, но и не поддавайтесь пустым замечаниям — ваше видение не должно быть полностью перечеркнуто отзывами. Зачастую в этот момент вы еще сможете включить в игру пару несложных в реализации деталей. Дальше — только релиз!
Задел на будущее
Множество идей, конечно, останется нереализованными. В моем случае в списке задач осталось более 20 пунктов, из которых только 2 добавляют что-то действительно новое, остальное это дополнительная шлифовка и украшение мира. Оставьте их, умейте себя остановить, иначе проект будет бесконечным. Если пользователи примут его положительно, то, возможно, стоит продолжить его совершенствовать, однако полировать все можно очень долго, и, учитывая потраченное время — у меня ушло около 5 месяцев работы одного человека с самого раннего прототипа — стоит завершать на том, что есть.
Если бы у меня в команде был опытный моделлер, художник и композитор — то все можно было закончить и за месяц, но в одиночку, без необходимых навыков, все происходит значительно медленнее.
Также была задумка выпустить проект и на мобильных платформах — все же это мультиплатформенный движок, но действительность такова, что без дополнительной жесткой оптимизации этого не получить. В случае, если у игры наберется аудитория и будут запросы, то попытка портирования точно будет. Сейчас же необходимо наличие дискретной графики(проверялась интегрированная IntelHD4400 — ее явно недостаточно, однако при использовании дискретной видеокарты даже ноутбука, можно рассчитывать на нормальное количество кадров)
Впечатления от Unity3d
Работать было очень удобно, учитывая имеющийся опыт C# разработки, лишь в некоторых случаях сталкиваешься с ограничениями Mono и спецификой самих объектов. Достаточно много уроков — правда большинство ориентированы на новичков, поэтому сложно долго слушать про расположение скобочек, наименования переменных, стандарты их кода с разными нотациями и прочим подобным, причем этим мелочам уделяется просто несоразмерное количество времени. Но на скорости в полтора-два раза быстрее, зачастую, быстро просматриваешь или проматываешь до ключевого в ролике момента, смотришь как работать с очередным окном, раскрываешь прилагаемый листинг и продолжаешь в своем проекте.
Для Unity много различных плагинов, и даже собственноручно был разработан небольшой диалог-расширение редактора, для генерации буйков на трассе, с некоторыми коэффициентами для сглаживания поворотов. В сети можно найти огромное количество скриптов, также не стоит обходить мимо встроенного AssetStore, в котором есть как платные(большинство) так и бесплатные варианты. Дополнительно — обращайтесь на официальный форум, где вам обязательно ответят.
Также — в Unity еще встречаются проблемы в виде некорректной работы чего-либо, и в моем случае, выпускать игру пришлось на последней бета версии, т. к. все предыдущие просто не были предназначены для WindowsStore билда — ошибка в работе с тенями. В итоге, до сих пор есть одна нерешенная до конца проблема, из-за которой пришлось генерировать проект в Il2CPP режиме, хотя хотелось получить обычный C# — проблема известна и висит в предложениях на улучшения, однако надеяться на скорое разрешение не стоит.
Единственное, о чем хочется добавить — это очень долгий пересчет освещения! Его запекание может легко перейти границу в 20 часов на сцене, и это при не самом слабом CPU. Но без этого на ваши тени будет страшновато взглянуть. Видимо, все разработчики дожны иметь как минимум 8 а то и 10 и больше ядер, с неограниченным количеством оперативной памяти, т. к. одна задача на пересчет света легко уходит за потребление 4Гб, количество же таких задач на больших сценах измеряется в сотнях.
Ошибки
Их я могу увидеть только оглядываясь сейчас.
Главное — после месяца работы начните продвигать свой проект — это не обязательно должна быть реклама, но подерживайте записи в блоге, покажите над чем вы работаете, очень хорошо если к этому моменту можно будет опубликовать какие-то концепты, или ранний геймплей, но не молчите! В моем случае я понял что готов рассказать всем вокруг, только когда у меня появился финальный билд, и мне кажется, что так не стоит делать.
Разработка моделей и картинок, в моем случае, слишком затянули проект, и большинство из них можно было оставить более схематичными, сосредоточившись больше на нескольких основных.
Попробуйте где-то посередине, или даже изначально — билд на целевую платформу. В моем случае ушло еще две недели, чтобы поправить все недочеты, и дождаться последней беты исправляющей все критичные баги.
Все же самое главное это полученный опыт выпуска первого завершенного проекта. Даже если он будет неудачным, это не должно остановить от планов работать дальше и совершенствоваться.