Что можно приготовить из кальмаров: быстро и вкусно

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

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

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

Вступление

• Сюжет
• Вдохновение
• Концепт
• Рабочий прототип
• Развитие прототипа в конечный продукт
• Завершение

Поиск и взращивание идеи

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

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

Сюжет

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

Вдохновение

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

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

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

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

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

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

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

Концепт

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

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

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

Рабочий прототип

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

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

Развитие прототипа

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

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

Я (еще|не) художник!

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

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

Звук

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

Завершение продукта

Задел на будущее

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

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

Впечатления от Unity3d

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

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

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

Ошибки

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

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

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

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

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

Игры для мобильных устройств – один из наиболее бурно развивающихся сегментов IT-рынка. А наиболее распространенный движок, на котором они создаются – это Unity, который обладает самыми широкими возможностями и исключительно прост в освоении. В IT-Академии Алексея Сухорукова совсем скоро стартует , выпускники которого создадут свою собственную игру, а также получат возможность стажировки в игровой компании Новосибирска. О том, что такое Unity, почему он столь популярен, и как стать специалистом по созданию игр на этом движке, мы поговорим с преподавателем курса Андреем Гончаровым.

Андрей, расскажи, пожалуйста, что такое Unity?

Популярен ли сейчас этот движок, как средство разработки?

Безумно!

А в чем причина такой его популярности?

В первую очередь – очень низкий порог вхождения. Человек, который более-менее понимает принципы объектно-ориентированного программирования, может начать эффективно работать с Unity буквально через месяц после начала обучения.

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

Есть разные формы его использования. Он может быть полностью бесплатным, вплоть до того, что такую бесплатную игру, сделанную с его помощью, можно выложить в общий доступ. А может быть и с подпиской. Причем подпиской по разной цене – обычной, премиальной и т.д. Разумеется, в зависимости от ее вида вы получаете разные наборы пакетов инструментария. Но стоимость даже самой дорогой подписки весьма демократична и не превышает 125 долларов.

Какие игры делают на Unity? Для мобильных платформ или для персональных компьютеров?

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

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

Игры. Именно их я создаю на протяжении всей своей профессиональной деятельности, то есть, начиная аж с 90-х годов.

Ты владелец бренда "Puzzles & Solutions LLC". Что это за компания?

Это, собственно, моя компания по разработке игр. Изначально мы были известны как «Gamover Games», потом, как ООО «Хорошие игры», а очередной ребрендинг привел к появлению вот этого названия. Раньше мы делали игры преимущественно для персональных компьютеров, а сейчас в основном сосредоточились на геймдеве для мобильных платформ. Всего мы выпустили в релиз уже более 50 самых разных игр.

Как давно ты используешь Unity в своей работе?

Ранее довольно длительное время для создания игр мы применяли движок своей собственной разработки. И пользовались им вплоть до 2014 года, когда приняли решение о смене его на Unity в силу всех тех преимуществ, о которых было сказано выше. Основным языком программирования у нас был С++, а Unity использует С#. Но, честно говоря, переход с одного языка на другой произошел у нас очень легко и быстро – эти языки родственные, и программист, владеющий каким-либо из них, способен моментально сменить инструмент работы.

Андрей, а велик ли спрос на рынке на таких специалистов?

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

А почему так? Геймдев-компании ощущают нехватку кадров? Или организации, работающие в других сферах, тоже заинтересованы в таких специалистах?

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

И какова зарплата у Unity-разработчика в среднем?

Во многом это зависит от региона. В столице зарплата всегда будет выше. Но если говорить в среднем, то junior-разработчик обычно получает порядка 30 000 рублей в месяц. Поднявшись на уровень middle, вполне можно рассчитывать на заработную плату в 50-60-70 тысяч. А уже топовый специалист по Unity, профессионал уровня senior, получает в месяц 90-100 тысяч.

А куда расти Юнити-разработчику? Где потолок в профессии?

После прохождения классической IT-лестницы: junior, middle, senior такой специалист вполне готов занять место руководителя команды – team-lead’а. Ну, а потом, если он обладает определенными амбициями, ему вполне открыты пути в высший менеджмент компании. Он может возглавить ее IT-отдел, например. Технических, практических, «программистских» знаний, которые дает работа с Unity, для этого ему наверняка хватит.

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

Боюсь, что нет. Мы начинаем не с самых азов, базовая подготовка или некоторый опыт в объектно-ориентированном программировании обязательно понадобятся.

Мы начнем с базового блока, который займет 20 часов. Туда войдут те понятия и инструменты, знание которых необходимо практически любому программисту. Плюс мы заложим основу для будущего развития навыков уже в сторону овладения Unity. Второй блок – подготовка до уровня junior-специалиста. Эта часть обучения имеет вдвое большую продолжительность – 40 учебных часов. И тут я буду говорить непосредственно о принципах создания 3D и 2D игр, мы рассмотрим некоторые основные особенности и этапы этого процесса, обсудим вопросы оптимизации игр на разных платформах, изучим скриптование и, разумеется, каждый из студентов попробует создать свой собственный проект.

С какими проблемами сталкивается чаще всего Юнити-разработчик?

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

Андрей, дай главный совет новичку в программировании на Юнити.

Самое важное – упорство. Постоянная практика, настойчивость в работе. Будете планомерно осваивать Unity от простого к сложному – рано или поздно обязательно станете профессионалом. Не сдавайтесь!

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

Разработчик детского мобильного паззла Fold the Adventure Алексей Галкин написал для ЦП колонку о том, на что следует обратить внимание при разработке мобильной игры на платформе Unity: как выбрать правильные ассеты из Asset Store, в каком сервисе хранить данные о прогрессе пользователей и где взять звуки для игры.

В закладки

Начало

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

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

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

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

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

• Необходимо с самого начала потратить время на изучение базовой архитектуры 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-файла, содержащего колонку для каждого языка. Наличие такого файла очень удобно для отправки строк на перевод (для этого существует большое количество специализированных сервисов) и последующей вставки переведённой версии.