Разработка игр на unity


Разработка первой игры [на Unity3D] / Хабрахабр

Когда-то я пошел на ПОВТ (можете вставить свою специальность в IT) для того чтобы узнать как писать игры. Хотя обучение и было несколько отдалено от интересующей тематики, оно принесло фундаментальные знания, без которых было бы очень тяжело. Дальнейшая после выпуска работа в нескольких компаниях только затягивала в энтерпрайз, отдаляя от геймдева. Но, время от времени, покупая новую игру, или наблюдая за разработкой очередного тайтла, возникает очень навязчивая идея — «Хочу этим заниматься!».

Первые попытки обычно ничем хорошим не заканчиваются — множество мини прототипов так и остаются на самой ранней стадии, или укладываются «в стол». Это не плохой этап и от него никуда не деться. Со временем, желание завершить что-либо станет настолько навязчивым, что вы сможете это сделать.

За последний проект я взялся очень крепко и довел до стадии релиза.

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

Общий план основных этапов создания игры, освещенных в статье:
  • Идея
  • Сюжет
  • Вдохновение
  • Концепт
  • Рабочий прототип
  • Развитие прототипа в конечный продукт
  • Завершение
В конце статьи я затрону планы на будущее, впечатления от выбранного инструмента и некоторые ошибки. Идеи приходят достаточно часто, в большинстве своем они быстро отметаются, но некоторые будут возвращаться снова и снова. Записывайте их, просто запоминайте, и если через какое-то время вы снова вернетесь к конкретной, и начнете прокручивать ее вариации — стоит к ней присмотреться. Если она все еще будет вас захватывать — беритесь за нее!

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

В моем случае, идеей стал жанр гонок на лодках.

Был написан небольшой сценарий — буквально несколько абзацев текста, который делил игру на все стадии, от начала и до конца, с конкретными целями и задачами, объединенными общей историей. Нет, в нем не было каких-то откровений и поворотов, он абсолютно прямой. Но без сюжета, без возможности завершить игру — вы просто тратите время игрока впустую — да, есть аудитория и у такого рода игр, но это просто неуважение к игровой культуре в целом. Если вы в очередной раз садитесь делать раннер — то дайте игрокам ощутимый прогресс, дайте возможность завершать начатое, дайте наконец пройти все, что есть, и обновляйте игру позже для следующей части приключений(или продавайте), подумайте над реиграбельностью, повторным прохождением, если уж других идей нет — но никогда не выпускайте что-то без завершающего экрана!

Отсутствие сюжета оправданно, только если ваша игра — сугубо соревновательная дисциплина. В последнем случае, если это не совсем абстрактные игры вроде Го, шашек, шахмат — стоит озаботиться четким описанием мира игры, чтобы самому не допустить ошибок этого мира, при наполнении контентом или во время создания героев. «Lore» очень важен для игроков, и если детали мира подчеркиваются невидимыми нитями сквозь все произведение, это придаст атмосферность, ради которой игрок будет возвращаться снова и снова.

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

Мое вдохновение пришло в основном из трех игр.Главный стиль вспомнился, неожиданно, с Mario, а именно Sunshine — была такая игра на GameCube — в ней вода была повсюду, она была очень красива, в игре даже были несколько миссий-мини гонок на этой воде, но, как мне до сих пор кажется, с тех пор, во всех новых Mario такой приятной воды просто нет. Еще в то время когда я проходил игру у меня появился концепт гоночного аппарата с двигателями-водометами из игры. Я не особо задумывался о том, что когда-то реализую эту задумку, но вспомнить свои эмоции более чем десятилетней давности было очень приятно.

Основным вариантом геймплея стал, так называемый, заезд на время — тут хотелось добиться чего-то схожего с серией TrackMania. Возможно, в последней части (Turbo) разработчики перешли некую грань хардкорности граничащей с невозможностью идеальных прохождений на

максимальной концентрации,

у меня 316 медалей на 128 треках и временами хочется никогда не открывать игру снова

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

Дополнительно не хотелось ограничивать игрока между уровнями, хотелось постоянного контроля за героем, поэтому решено было сделать игру в открытом мире, при этом запуск гонок вдохновлен начальным BurnoutParadise, в котором не было запуска гонок из меню, и даже рестарта — нужно было всегда подъезжать к точке на карте и начинать заново. В моем случае рестарт остался, но эта возможность поддерживается очень непродолжительное время после конца гонки.

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

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

Несмотря на то, что с Unity3d до этого не было особого знакомства, этот этап не стал чем то невероятно сложным. Для достоверного поведения лодки пришлось несколько углубиться в физику процессов и написать свой честный Buoyancy-скрипт взяв за основу один из найденных в сети. После первых попыток, в которых использовалось значительное упрощение протекаемого процесса, без плеча силы, и разделения объемов, все стало ощущаться просто отлично!

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

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

На данном этапе сконцентрируйтесь на реализации всех моментов вашей сюжетной составляющей. Все части игры и основные механики(если их несколько) должны быть реализованы, чтобы вы смогли "пройти" пусть урезанную игру в виде последовательности всех механик от начала и до конца — пусть без конкретных решений в визуальном дизайне, именно на уровне прототипа.

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

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

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

Местами это похоже на работу скульптора(или художника), когда ты должен высечь форму, но идеального варианта не существует, и каждый штрих лишь придает новые очертания. По-началу с этим сложно свыкнуться, т. к. с точки зрения программиста это слишком недетерминированно. Попробую объяснить — когда в нашей сцене раскладываются какие-то объекты, то надо просто принять, что они будут лежать на своих местах всегда, и если в очередной раз мы бросим свежий взгляд и сдвинем все под наше новое видение, то этого не изменить — промежуточные варианты затираются среди всех возможных. Быстро восстановить один из конкретных вариантов просто нельзя. Конечно, в критических ситуациях я дублирую все объекты для отката, но после принятия нового варианта старый уходит безвозвратно.

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

Самым сложным стала разработка всех моделей, текструирование и отрисовка картинок сюжета, поданных в виде кадров стилизованных под комикс.

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

С моделями все тоже было неоднозначно — когда-то был небольшой опыт моделинга в личных целях, и даже были добавлены пара автомобилей в GTA3, но в таких масштабах ничего не делалось. Учитывая развертки и оптимизацию моделей, это было самой сложной частью. Всего, для наполнения мира, их было создано больше сотни, и я считаю, что этого все еще недостаточно, но с таким темпом игра никогда бы не подошла к стадии релиза.

Аналогично художественной составляющей есть работа со звуком. Это очень важная часть, но, к сожалению, без возможности лицензировать треки и звуки наш выбор очень ограничен. Есть несколько ресурсов, из которых я выбрал совсем не требующие лицензирования варианты. Однако для более серьезного проекта это не подойдет. Если вы сами сможете записывать и производить нужные звуки, музыку — это просто отлично!

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

Просмотрите еще раз первоначальный сценарий — завершите все задачи по его исполнению. Еще раз осмотрите список идей по украшению, но остановите себя, если он содержит пункты непервостепенной важности. Покажите этот вариант знакомым, спросите, что им понравилось, а что нет. Не бойтесь принимать критику, но и не поддавайтесь пустым замечаниям — ваше видение не должно быть полностью перечеркнуто отзывами. Зачастую в этот момент вы еще сможете включить в игру пару несложных в реализации деталей. Дальше — только релиз! Множество идей, конечно, останется нереализованными. В моем случае в списке задач осталось более 20 пунктов, из которых только 2 добавляют что-то действительно новое, остальное это дополнительная шлифовка и украшение мира. Оставьте их, умейте себя остановить, иначе проект будет бесконечным. Если пользователи примут его положительно, то, возможно, стоит продолжить его совершенствовать, однако полировать все можно очень долго, и, учитывая потраченное время — у меня ушло около 5 месяцев работы одного человека с самого раннего прототипа — стоит завершать на том, что есть.

Если бы у меня в команде был опытный моделлер, художник и композитор — то все можно было закончить и за месяц, но в одиночку, без необходимых навыков, все происходит значительно медленнее.

Также была задумка выпустить проект и на мобильных платформах — все же это мультиплатформенный движок, но действительность такова, что без дополнительной жесткой оптимизации этого не получить. В случае, если у игры наберется аудитория и будут запросы, то попытка портирования точно будет. Сейчас же необходимо наличие дискретной графики(проверялась интегрированная IntelHD4400 — ее явно недостаточно, однако при использовании дискретной видеокарты даже ноутбука, можно рассчитывать на нормальное количество кадров)

Работать было очень удобно, учитывая имеющийся опыт C# разработки, лишь в некоторых случаях сталкиваешься с ограничениями Mono и спецификой самих объектов. Достаточно много уроков — правда большинство ориентированы на новичков, поэтому сложно долго слушать про расположение скобочек, наименования переменных, стандарты их кода с разными нотациями и прочим подобным, причем этим мелочам уделяется просто несоразмерное количество времени. Но на скорости в полтора-два раза быстрее, зачастую, быстро просматриваешь или проматываешь до ключевого в ролике момента, смотришь как работать с очередным окном, раскрываешь прилагаемый листинг и продолжаешь в своем проекте.

Для Unity много различных плагинов, и даже собственноручно был разработан небольшой диалог-расширение редактора, для генерации буйков на трассе, с некоторыми коэффициентами для сглаживания поворотов. В сети можно найти огромное количество скриптов, также не стоит обходить мимо встроенного AssetStore, в котором есть как платные(большинство) так и бесплатные варианты. Дополнительно — обращайтесь на официальный форум, где вам обязательно ответят.

Также — в Unity еще встречаются проблемы в виде некорректной работы чего-либо, и в моем случае, выпускать игру пришлось на последней бета версии, т. к. все предыдущие просто не были предназначены для WindowsStore билда — ошибка в работе с тенями. В итоге, до сих пор есть одна нерешенная до конца проблема, из-за которой пришлось генерировать проект в Il2CPP режиме, хотя хотелось получить обычный C# — проблема известна и висит в предложениях на улучшения, однако надеяться на скорое разрешение не стоит.

Единственное, о чем хочется добавить — это очень долгий пересчет освещения! Его запекание может легко перейти границу в 20 часов на сцене, и это при не самом слабом CPU. Но без этого на ваши тени будет страшновато взглянуть. Видимо, все разработчики дожны иметь как минимум 8 а то и 10 и больше ядер, с неограниченным количеством оперативной памяти, т. к. одна задача на пересчет света легко уходит за потребление 4Гб, количество же таких задач на больших сценах измеряется в сотнях.

Их я могу увидеть только оглядываясь сейчас.

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

Разработка моделей и картинок, в моем случае, слишком затянули проект, и большинство из них можно было оставить более схематичными, сосредоточившись больше на нескольких основных.

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

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

P.S. Изначально, статья была чуть ли не в два раза больше, и пришлось делать более краткую выжимку. Также были вырезаны такие моменты как: UI, земля, вода и волны, непосредственно релиз с выкладкой в стор. Если у вас есть любые вопросы по теме — задавайте, и я постараюсь ответить.

habrahabr.ru

Мобильная игра на Unity. Первый блин… / Хабрахабр

После завершения создания игры-головоломки на Unity и выпуска ее на Google Play и AppStore, появилось желание поделиться опытом и впечатлениями. И получить конструктивные замечания и предложения, если таковые возникнут

Командная работа
Итак, проект делался на Unity 4.5 Free усилиями 5 человек в свободное от работы и домашних забот время. Для организации командной работы мы использовали сервис Bitbucket — там как раз до 5 человек можно добавлять в проект бесплатно. Система контроля версий — Git. Насколько я понял, Unity PRO имеет свою систему контроля версий, но мы решили не покупать PRO и не хакать — юзали Free

Первой проблемой, с которой столкнулись, было довольно сложное сливание изменений, внесенных разными разработчиками. Файлы Unity проекта — формы, префабы и проч. — имеют свои своеобразные форматы, и как текстовые файлы не сливаются. В итоге мы просто разделили ответственность: более одного человека не правили одновременно одну форму или один префаб. Этого несложно добиться, если правильно распределять задачи. С файлами скриптов на C#, конечно, никаких проблем не возникло, их правили одновременно

Производительность
Проект решили делать в 2D. Итоговая картинка формируется из 3 слоев: подложка, тень от элемента и элемент

Тестируя потом игру на устройствах, мы обнаружили, что у нас очень низкие FPS — около 20, и безумное потребление батарейки. Выяснилось, что проблема в отображении полупрозрачного слоя теней. Их вроде не так много на уровне, но в Unity это совершенно убивает производительность

Мы занялись оптимизацией — уменьшили размеры текстур элементов, собрали текстуры в атласы. FPS стали повыше, но батарейка по-прежнему высаживалась очень быстро. Тогда мы сделали механизм понижения FPS в те моменты, когда пользователь не перемещает элементы, и нет никакой анимации

Выглядит он приблизительно так: есть словарик, где ключами служат различные анимации и действия пользователя. Каждому ключу ставится в соответствие целое число — счетчик. Анимация или действие инкрементирует счетчик, когда завершается — декрементирует. Когда по всем ключам счетчики==0, мы понижаем FPS:

Application.targetFrameRate = Constants.CountFPS_Min; // == 10, в нашем случае

Как только что-то происходит — мы аналогичным образом снимаем ограничение. После этого нехитрого фокуса мы забыли о проблемах с батарейкой

Отдельной темой может служить, как мы бодались со шрифтами и вообще GUI в Unity. Это была не очень простая работа. Но, к счастью, в Unity 4.6 все значительно переделано и улучшено, так что останавливаться на этом не буду

Выпуск
В момент выхода на Google Play, мы написали на несколько сайтов и форумов о нашей игре. Это дало первый пик закачек:

Потом мы попали в «Топ набирающих популярность» в разделе Головоломки. После этого все устаканилось на уровне 150 закачек в день. Следующий пик был через 3 недели — мы попали в раздел «Похожие» к нашим основным конкурентам — «Lazors» и «Dr. Laser». На текущий момент у нас 200 закачек в день

Игра имеет внутренние покупки — можно открывать главы без прохождения уровней и покупать подсказки. Наибольшим спросом пользуются именно подсказки, особенно самый маленький пакет — 20 подсказок за 1$. Чистая прибыль в день составляет сейчас около 200 руб.

Интересное наблюдение: улучшение игры, добавление музыки, более сложных уровней, изменение дизайна и проч. — не приводит к повышению рейтинга игры (места в поиске) и увеличению закачек, но увеличивает число покупок. Вот так

В отсутствие профессионального дизайнера, корячились с иконкой самостоятельно:

Еще одно интересное наблюдение: я потратил пару дней, чтобы сделать рекламный ролик, а потом обнаружил, что его просматривает очень малое число людей, из приходящих на страницу приложения. Стоило ли?

Через месяц после выхода на Google Play, мы решили выйти в AppStore. Тоже с минимальной рекламой на нескольких форумах. Выглядел наш выход вот так:

Называется: поднялся и упал… Первые пять дней принесли нам 1,5 тыс закачек и 45$, а потом все плавно опустилось до 30 закачек в день и 2$ дневного дохода

Было принято следующее решение: мы удалили игру с AppStore, доработали ее и выложили под новым именем. Сейчас у нас Дубль#2, чуть позже смогу рассказать, что нам принесло это решение

Аналитика и покупки
В какой-то момент мы решили добавить в нашу игру сбор аналитики. Добавили Google Analystics (дальше — GA), используя плагин для Unity GoogleAnalyticsV3. Сама интеграция аналитики совсем не сложная. Если интересно, могу в отдельной статье описать, как это лучше всего сделать

Хочу отметить, что само представление данных в web-интерфейсе GA не самое удобное. Я экспортирую данные в XLS и работаю с ними уже в Excel. Да и запись аналитики в GA возможна только в рамках заданных шаблонов. Если проводить какой-то серьезный анализ поведения пользователей, то наверно стоит использовать свой сервер статистики и собирать информацию в желаемом формате. Ну, еще есть другие сервисы статистики — тот же Flurry. Но я про них ничего сказать не могу, ибо не юзал

Ну и на последок расскажу про одну проблему, с которой мы столкнулись. Надеюсь, мое предупреждение кому-то поможет

Для организации внутренних покупок мы используем плагин Soomla версии 1.5.3. Неделю назад мы добавили в игру новую покупку — открытие 6 главы. Установили себе на телефоны, проверили, что все работает. Залили на Google Play. И получили кучу гневных отзывов! Почему? — потому что, как оказалось, при первой установке нашей игры, все покупки работают как надо. Но при обновлении игры, Soomla не подхватывала новую покупку, и пользователи наблюдали интересный баг с 6 главой. Возможно, дело в том, что Soomla кэширует на телефоне список покупок и при обновлении не находит новую…

Мы просто обошли эту проблему в следующем обновлении. Но глобальный вывод напрашивается сам собой: при обновлении игры, обязательно нужно тестировать и то, как игра ведет себя при «чистой установке», и то, насколько корректно проходит обновление

Эпилог
Этот проект для нас дебютный. Мы научились работать вместе, набили пару шишек с Unity и Маркетами. Впереди другой, большой и серьезный проект. И, надеюсь, успех!

Буду рад обсуждению и обмену опытом!

habrahabr.ru

Создание игры на Unity небольшой командой: особенности технологии

Начало

Чтобы сделать хорошую игру, нужна хорошая идея. Но даже имея идею, создать на её основе достойную игру совсем непросто. Помимо банальной удачи, существует огромное множество вещей, с которыми приходится иметь дело. Бесконечное число решений необходимо принять в весьма скромное время. Ведь время — это деньги, а бюджет проекта имеет тенденцию исчезать до того, как сделано хоть что-то достойное демонстрации (не говоря уже о выпуске).

Эта история о том, как наша небольшая инди-команда создавала игру Fold the Adventure («Сложи приключение») на основе оригинальной идеи. Поскольку игра выпущена, мы можем перевести дух и окинуть взглядом три месяца, потраченные на разработку. Несмотря на наличие многолетнего опыта в игровой индустрии, создание Fold the Adventure заставило нас изрядно попотеть ввиду непредсказуемых поворотов событий и весьма ограниченных ресурсов. Добро пожаловать в наше приключение!

Выбор движка: Unity

Сказать по правде, движок нам выбирать не пришлось. Мы сразу взяли Unity и не пожалели об этом. Нашей первостепенной задачей было создание сравнительно небольшой игры и запуск её на максимальном количестве платформ. При этом хотелось избежать возни с программированием на Objective C и Java. С Unity нам это удалось. И хотя всё было не так просто и гладко, как предполагалось, движком мы остались довольны.

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

Вот некоторые из рекомендаций, которые мы выработали после довольно продолжительного использования Unity (не ограниченного созданием Fold the Adventure):

  • Необходимо с самого начала потратить время на изучение базовой архитектуры Unity, включая игровые объекты, скриптуемые объекты, сцены, префабы, ассеты, методы-события и порядок их вызова, сопрограммы, измерение времени, обработку ввода, сериализацию. Unity может показаться лёгким в использовании движком, но без понимания его основ можно провести бесконечные часы за отладкой и рефакторингом.
  • С самого начала сформулируйте правила структуризации, а также именования ассетов и игровых объектов. Даже небольшая игра имеет тенденцию превращаться в хаос без должной организации. Существует много статей, посвящённых данному вопросу. Можно также ориентироваться на проекты, публикуемые разработчиками в Unity Assets Store.
  • Программируйте как можно меньше. Вместо этого активно используйте WYSIWYG (What You See Is What You Get — свойство прикладных программ, в которых содержание отображается в процессе редактирования и выглядит максимально близко похожим на конечную продукцию — ред.) возможности редактора Unity. Благодаря лёгкой расширяемости, редактор Unity позволяет превратить разрабатываемую игру в удобный конструктор, которым смогут пользоваться даже те, кто не умеет программировать. А это существенно упрощает и ускоряет создание игрового контента.
  • Избегайте использования привычных практик, которые плохо сочетаются с идеологией Unity. Какой бы заманчивой не была возможность размещения всех объектов игры в рамках одной сцены или сохранение параметров игровой механики в XML-файлах, подобный подход существенно осложнит жизнь на более поздних этапах разработки.
  • Будьте аккуратны и внимательны при использовании систем управления версиями. Unity имеет тенденцию непредсказуемо менять файлы. Например, внесение изменений в префаб влечёт за собой модификацию всех файлов сцен, в которых он используется, но только после их последующего сохранения. Всегда используйте force text в качестве режима сериализации ассетов и внимательно следите за файлами, которые заливаете на сервер, чтобы не уничтожить результат работы коллег.
  • Тестируйте игру на максимально возможном количестве платформ. При этом не забывайте, что настройки можно определить для каждой из платформ в отдельности. Без подобного тестирования, вы, как и мы, можете столкнуться с тем, что ваша игра ведёт себя по-разному в web player-е под Windows и OS X.

Ассеты: создавать или покупать

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

Если ассеты для игры могут быть сделаны силами команды — одной проблемой меньше (cкорее всего). Но есть ещё фаза прототипирования, а для неё также нужны ассеты, которые с большой долей вероятности будут выброшены. Поэтому практически каждой команде требуются ассеты, которые она не может или не хочет делать. Вопрос в том, где их взять.

Первым и самым очевидным ответом для нас, как для Unity разработчиков, был Unity Assets Store. Какой бы заманчивой ни казалась эта возможность, она влечёт за собой и ряд сложностей:

  • Ассеты в Unity Assets Store доступны всем без исключения. Однако никто не хочет, чтобы их игра была похожа на другие. По крайней мере, мы этого очень не хотели.
  • Практически невозможно купить один пак ассетов, который бы удовлетворил все нужды проекта, и возникает проблема стилистической совместимости. Для Fold the Adventure мы купили несколько паков, из которых использовали меньше половины.
  • Несмотря на то, что общее количество ассетов в Unity Assets Store довольно велико, найти среди них что-то подходящее для конкретных нужд бывает весьма непросто. При этом качество зачастую оставляет желать лучшего. Мы потратили часы на поиски, при этом не всегда имея возможность оценить качество пака без его покупки.

Вторым вариантом был аутсорсинг ассетов. Безусловно, этот путь отнимает больше времени и денег, чем просто покупка чего-то из Unity Assets Store. Однако, при удачном раскладе, получаемые ассеты уникальны и более качественны.

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

Когда мы принимали решение о том, какие ассеты делать самостоятельно, а какие нет, мы начали с их категоризации. Как оказалось, ассетов, которые были уникальны для нашей игры и выделяли её среди прочих, было сравнительно немного. Их мы решили сделать своими силами, прибегая к помощи аутсорса там, где это было возможно. Остальное было куплено в Unity Assets Store.

Вот несколько простых правил, к которым мы пришли в ходе поиска и покупки ассетов в Unity Assets Store

  • Чтобы избежать стилистических расхождений, желательно покупать ассеты одного типа у одного автора. Это не мешает купить модели у одной студии, а партиклы у другой, но при этом нужно следить за совместимостью стилей.
  • Избегайте использования ассетов в том виде, в котором они были куплены. Достаточно внести небольшие изменения (например, немного перерисовать текстуры, реструкурировать партиклы) или использовать ассеты нестандартным образом.
  • Если вы планируете выпуск игры на мобильных платформах, убедитесь, что покупаемые ассеты оптимизированы под них.

Музыка и звуки заслуживают отдельного внимания. Они редко создаются инди-командой самостоятельно (если у вас есть композитор, то вам либо очень повезло, либо вы уже не инди). К счастью, существует большое количество сервисов, поставляющих royalty-free музыку и звуки, включая Unity Assets Store. И это совсем недорого.

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

Где хранить данные: Parse

Даже если вы, как и мы, создаёте однопользовательскую игру, вам всё равно потребуется место для хранения данных о текущем прогрессе игрока, статистике его действий, сделанных покупках и прочей информации. Самым простым решением будет использовать для этого класс Unity PlayerPrefs. Однако он сохраняет данные локально и, совершенно очевидно, не подходит для таких деликатных вещей, как внутриигровые покупки.

В поисках лучшего решения мы обнаружили Parse. Parse — это кросс-платформенный сервис BaaS (Backend as a Service — платформа типа «бэкенд как сервис», предоставляет облачную серверную инфраструктуру для всех типов приложений — ред.), который позволяет приложению сохранять данные в облаке, поддерживает авторизацию пользователей, серверные функции, push-оповещения и аналитику. Это не исчерпывающий список функциональности, но он даёт общее представление о том, что есть Parse.

Одной из причин, по которым мы выбрали Parsе, была его интеграция с Facebook (первая версия Fold the Adventure создавалась именно для Facebook). И, несмотря на то, что позднее фокус разработки был смещён на мобильные платформы, мы продолжили использовать Parse.

Ещё одной приятной особенностью Parse является его ценовая политика. Поначалу она кажется немного странной, но, после размышлений и расчётов, оказывается более чем удачной. По существу, вы ограничены количеством запросов в секунду. Хорошая новость в том, что 30 запросов в секунду даются бесплатно. Может показаться, что это совсем немного, но на деле этого достаточно для поддержки тысяч пользователей. При условии, что вы используете эти запросы разумно.

В Parse вы делаете всё через запросы. Для получения и изменения полей данных, создания отношения между таблицами, формирования выборки - для всего нужен запрос. На первый взгляд, количество запросов должно быть довольно большим, но, на деле, большую часть элементарных операций можно объединить в один запрос с помощью метода ParseObject.SaveAllAsync. Кроме того, Parse выбросит исключение, если предел запросов в секунду превышен. Но ничего не мешает вам подождать некоторое время и выполнить запрос повторно. И хотя игра в таком случае может показаться пользователю «подвисшей», эта проблема легко обходится с помощью внесения небольших изменений в пользовательский интерфейс и логику сохранения и чтения данных.

Единственное, для чего Parse не следует использовать, так это для создания игрового сервера. Даже если вы разрабатываете пошаговую игру, предназначение Parse в корне отлично. Существуют другие решения, которые существенно лучше подходят для этих целей.

Использование Parse в рамках Unity не сопряжено с особыми трудностями и хорошо документировано. По сути, вам необходимо скачать Parse SDK, настроить вашу игру на сервере Parse и в проекте Unity, а также немного попрограммировать. Один очевидный нюанс: вы не сможете использовать Parse, если устройство, на которое установлена ваша игра, не имеет доступа к интернету.

Если есть необходимость поддерживать офлайн-режим и обновлять данные в Parse при наличии сетевого соединения, то вам придётся написать для этого небольшую отдельную систему. Мы использовали для этого класс PlayerPrefs. Система сохраняет данные локально и заливает их в Parse, как только обнаруживает наличие подключения к интернету.

Стационарные платформы против мобильных: компромиссы

Несмотря на постепенное сближение в течение последних лет, стационарные и мобильные платформы по-прежнему сильно отличаются друг от друга. Это становится очевидным при попытке заставить «красивые» шейдеры работать приемлемо (не говоря уже о том, чтобы заставить их работать быстро) на всех устройствах, на которых предполагается запуск игры. Unity существенно облегчает этот процесс, но, к сожалению, не решает всех проблем.

Существует огромное количество статей, посвящённых оптимизации Unity-игр под мобильные платформы, так что здесь на эту тему будет сказано немного.

Вот несколько рекомендаций:

  • Если вы планируете запуск на мобильных платформах и используете тени, то ограничьтесь режимом forward lighting. Несмотря на запекание освещения и сокращения числа объектов, отбрасывающих тени, мы не смогли добиться приемлемой производительности в режиме deferred lighting. Возможно, мы недостаточно старались, но форумы Unity, по большей части, солидарны с нами в этом вопросе.
  • Минимизируйте количество draw call-ов. Большое количество полигонов в моделях не скажется так сильно на производительности, как дополнительные draw call-ы. Мы планировали большую оптимизацию, направленную на сокращение количества draw call-ов, чтобы лучше поддерживать старые модели мобильных устройств, но, к сожалению, не смогли сделать её в отведённые жёсткие сроки.
  • Не злоупотребляйте текстурными выборками в шейдерах. Это может привести к существенному падению производительности. В нашей игре мы были вынуждены использовать несколько специальных шейдеров вместо одного универсального — именно по этой причине.

Помимо различий в производительности и аппаратных ограничений, существует ещё одно важное отличие между стационарными и мобильными платформами. И это отличие — режим ввода. Игра, созданная для управления с помощью клавиатуры и мыши, плохо переносится на мультитач и акселерометр. Мы убедились в этом на своём горьком опыте. Прежде всего, в Unity разделена обработка мыши и мультитача. А потому было необходимо создать систему, унифицирующую этот аспект. Для этих целей мы использовали систему ввода из состава NGUI, которая, после небольших доработок, показала себя весьма хорошо. Она также позволила нам решить проблему распределения ввода между пользовательским интерфейсом и игровым управлением, которая доставляла нам некоторые неприятности на тот момент.

Пользовательский интерфейс в целом потребовал ряда модификаций для корректной поддержки мобильных устройств. Например, вместо прокручивания колёсика мыши и удерживания кнопок пришлось ввести мультитач-жесты. Некоторые из модификаций можно было потенциально упросить с помощью готовых решений из Unity Assets Store. Но в нашем случае это был простой pinch, а потому мы решили написать его за час с нуля, вместо того, чтобы тратить дни на подключение и отладку системы, которая «делает всё и даже больше».

Наибольшее количество проблем вызвало внутриигровое управление. Мы начали с традиционного набора ASWD + мышь для управления персонажем и камерой, планируя использовать экранный джойстик на мобильных устройствах. Но всё получилось не совсем так, как мы ожидали: игра стала практически неуправляемой. Нам пришлось срочно менять внутриигровое управление, при этом внося изменения даже в игровую механику. Методом проб и ошибок мы остановились на point-n-click управлении, которое на мобильных устройствах воспринимается интуитивно.

Локализация: чем проще, тем лучше

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

Локализовывать необходимо всё, что имеет отношение к человеческому языку. То есть тексты, речь, надписи на текстурах — всё это должно быть локализовано. Такой процесс очень быстро может стать весьма трудоёмким и дорогим. Поэтому крайне важно свести количество локализуемого контента к минимуму.

Надписей на текстурах лучше избегать, и использовать, например, текстовые поля NGUI. Если в игре необходима речь, то, скорее всего, потребуются и субтитры, поскольку локализация речи не только дорогое удовольствие, но ещё и требовательное с точки зрения места, занимаемого игрой.

Но минимизация локализуемого контента - это только начало. Следующий этап - подготовка самой игры к локализации. Плохая новость состоит в том, что Unity (на момент написания данной статьи) не имеет встроенных механизмов для этих целей. И хотя существует целый ряд специализированных решений в Unity Assets Store (например, l2 Localization), мы решили использовать систему локализации, идущую в составе NGUI.

Система локализации NGUI проста и понятна в использовании. Она построена на основе одного CSV-файла, содержащего колонку для каждого языка. Наличие такого файла очень удобно для отправки строк на перевод (для этого существует большое количество специализированных сервисов) и последующей вставки переведённой версии.

Мы использовали Google Docs Sheets для хранения файла локализации. В таком варианте он легко доступен всем членам команды, может быть быстро обновлён и скачен в CSV формате. Кроме того, мы открыли доступ к этому файлу ряду друзей, говорящих на других языках. Таким образом мы получили часть переводов бесплатно.

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

Заключение

После того, как все сделано, игру необходимо тщательно протестировать (стоит это делать и неоднократно в процессе разработки). Этим должно заниматься максимальное количество людей на максимальном количестве устройств. Ничто не портит хорошую игру так, как пропущенный баг. При этом нужно обязательно слушать жалобы игроков. Поскольку эти жалобы превратятся в неудовлетворённых клиентов сразу после выхода игры на рынок. А этого точно никто не хочет.

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

Эта история, вместе с выпущенной игрой, завершает три месяца тяжёлой и кропотливой работ. И, несмотря на то, что мы столкнулись с множеством сложностей, процесс разработки Fold the Adventure был весьма захватывающим. Надеемся, что игра, которую мы создали, а также полученный нами опыт сделают мир немного лучше. Удачи в создании ваших игр!

(Можем дать ключи на игру в App Store — запросы пишите в комментариях)

vc.ru

Разработка игр на Unity 5

Важная информация!

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

В свою очередь платная подписка стоит всего 3$ за 3 месяца, и дает такие преимущества.

  • Самое главное это большой плюс к карме за поддержу нашего сайта.
  • Заказ курсов и быстрая реагирования администрации сайта. (отдельный чат telegram)
  • Новые фишки функционала в личном кабинете
  • И конечно же сайт без рекламы, майнеров и т.д.

Подписаться на платную подписку вы можете в своем личном кабинете

Надеемся на ваше понимание и поддержку и верем что вместе ми сделаем этот ресурс еще лучше.

Администрация сайта

Unity 5: 3D Essential Training

Открыть все курсы от lyndacom

Unity 5: 3D Essential Training - Полный список уроков

  • Урок 1. Welcome
  • Урок 2. What you should know
  • Урок 3. Exercise files
  • Урок 4. Setting up the project overview
  • Урок 5. Importing standard packages
  • Урок 6. Creating a player controller
  • Урок 7. Setting the resolution and quality
  • Урок 8. Importing meshes
  • Урок 9. Importing textures
  • Урок 10. Importing animation
  • Урок 11. Importing audio
  • Урок 12. Exporting models from 3ds Max
  • Урок 13. Exporting models from Maya
  • Урок 14. Generating colliders on geometry
  • Урок 15. Applying and optimizing colliders
  • Урок 16. Creating a prefab
  • Урок 17. Creating and applying a custom mesh collider
  • Урок 18. Updating geometry in a prefab
  • Урок 19. Adding physics to game objects
  • Урок 20. Adding audio clips to a prefab
  • Урок 21. Creating and organizing new materials
  • Урок 22. Using composite maps for smoothness and height
  • Урок 23. Adjusting metallic and smoothness properties
  • Урок 24. Creating normal maps from grayscale
  • Урок 25. Segmenting imported animation into clips
  • Урок 26. Accessing animation using Mecanim
  • Урок 27. Creating event-driven transitions in Mecanim
  • Урок 28. Using scripts in Mecanim
  • Урок 29. Animating an object in Unity
  • Урок 30. Adjusting animation in the Curve Editor
  • Урок 31. Using the Dope Sheet to scale animation timing
  • Урок 32. Instancing prefabs to build a level
  • Урок 33. Placing level prefabs for variety
  • Урок 34. Bounding the player through design
  • Урок 35. Creating and sculpting terrain
  • Урок 36. Painting terrain materials and textures
  • Урок 37. Adding trees and grasses to terrain
  • Урок 38. Fine-tuning the default daylight
  • Урок 39. Creating and adjusting point lights
  • Урок 40. Adding mood with spot lights
  • Урок 41. Setting area lights for baking
  • Урок 42. Excluding lights from geometry
  • Урок 43. Setting up the level for baking lighting
  • Урок 44. Adjusting baking parameters for a designed look
  • Урок 45. Setting object and light parameters for baking
  • Урок 46. Using light probes to light dynamic objects
  • Урок 47. Adding reflection probes for simulated dynamic reflections
  • Урок 48. Creating a particle system
  • Урок 49. Adjusting the behavior of particles
  • Урок 50. Modifying the appearance of particles
  • Урок 51. Adding depth of field to focus the view
  • Урок 52. Letting lights and highlights glow
  • Урок 53. Grounding the scene with ambient occlusion
  • Урок 54. Using color correction to create a mood
  • Урок 55. Bringing the environment to life with ambient sound
  • Урок 56. Triggering sound to play with an animation
  • Урок 57. Creating reverb zones
  • Урок 58. Mixing and balancing sound
  • Урок 59. Setting up occlusion culling
  • Урок 60. Enabling batching to reduce draw calls
  • Урок 61. Creating a splash screen and icon
  • Урок 62. Compiling a desktop build
  • Урок 63. Building for Android
  • Урок 64. Making Revisions
  • Урок 65. Next steps
Развернуть

Unity является одним из самых популярных игровых движков для мобильных и настольных игр и в режиме рил тайм моделирования. В этом курсе, автор Адам Креспи рассматривает методы, используемые в разработке игр Unity и вводит в основы дизайна уровней, анимации и много других прелестей движка. Сперва, узнай, как импортировать модели и текстуры из таких программ, как 3ds Max и Maya, настрой игровые объекты, а также добавь анимацию, чтобы довести игру до жизни. Тогда исследуй, как реализовать реалистичное освещения, а также добавь штрихи, такие как частицы, эффекты и аудио. Конечный результат представляет собой образец игры с пышной средой, полностью анимированных объектов.

Следи за последними обновлениями и новостями в наших пабликах facebook, или вступай в наш канал telegram.

coursehunters.net


Смотрите также