Русский
Русский
English
Статистика
Реклама

Unity 3d

Meta Gameplay Framework, или бэкенд без серверных разработчиков

12.11.2020 12:19:49 | Автор: admin


Привет! Меня зовут Кирилл, я руководитель отдела серверной разработки в Pixonic. Здесь я работаю уже более 5 лет. Долгое время Pixonic была компанией одной игры War Robots. Но однажды к нам пришло осознание, что так больше продолжаться не может, и мы начали работу над созданием новых проектов.

Поначалу мы взялись за это дело по старинке, используя традиционные для нас подходы: писали клиент на Unity 3D, бэкенд разрабатывали на Java. Это было привычно, понятно, но имело ряд серьезных недостатков. Проекты разрабатывались медленнее, чем нам бы хотелось. Для выполнения любой задачи необходимо было задействовать как минимум двух разработчиков. Однако, когда в разработке участвуют два и более человека, неизбежно возникают ошибки в духе: то один не так понял другого, то второй работает быстрее, чем первый. Такие ситуации приводят к тому, что кому-то из разработчиков в дальнейшем приходится возвращаться к задаче, которую он, казалось, уже давно закончил, а ведь у него и других дел полно. Так мы начали думать над тем, как разрешить эту проблему.

Еще нас огорчало, что каждый раз так или иначе приходилось сталкиваться с инфраструктурными вопросами: разработка и поддержание API и схем баз данных, написание DTOшек, их преобразование из и в модели на клиенте и сервере. Эта рутина многим привычна, они ее даже не замечают, однако она отнимает время, которое можно было бы использовать с большей пользой. Эту проблему, казалось бы, можно решить клонированием предыдущего проекта но все оказывается сложнее, когда дело доходит до взаимодействия с геймдизайнерами. Они постоянно придумывают что-то новое, и даже если поначалу кажется, что у проектов много общего возьми да скопируй, то по факту оказывается, что это совсем не так. В итоге от клонированного проекта остается только набор библиотек и каркас la bootstrap.

После долгих размышлений наши желания оформились в следующие требования:

  • Один разработчик должен уметь выполнить задачу как на клиенте, так и на сервере: не должно быть разделения ролей по профилю.
  • Разработчики в своей работе не должны задумываться об инфраструктуре: о базах данных, протоколах взаимодействия между сервисами, логировании совершенных операций. Все внимание должно быть сосредоточено на разработке бизнес-логики.
  • Модели, используемые на сервере, должны как можно чаще использоваться на клиенте.
  • Фреймворк должен предоставлять простые и понятные механизмы для выполнения рутинных операций: списания/начисления игровой валюты, выдачи игровых предметов, открытия лутбоксов, работы с платежами из сторов, с аналитикой и т.д.
  • Все операции, совершаемые игроком, должны быть доступны из панели администрирования это позволило бы команде техподдержки, тестировщикам и разработчикам лучше понимать, что происходило с игроком в случае поступления жалоб или обнаружения ошибок.

На момент начала разработки фреймворка на рынке уже было несколько предложений, частично удовлетворяющих нашим требованиям, PlayFab и GameSparks. Это отличные решения, построенные по модели LiveOps, но имеющие ряд критических для нас недостатков:

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

Итак, у нас получился следующий набор необходимых технологий и методов:

  • C# (.net core для сервера и клиента, .net 3.5, 4.X для клиента). Мы хотим, чтобы разработчик мог разрабатывать как клиентскую, так и серверную часть задачи. Уйти от Unity 3D мы не можем, а вот написать сервер на C# вполне.
  • Orleans фреймворк для построения распределенных, отказоустойчивых и масштабируемых систем в модели акторов от Microsoft (использовался в Halo). Использование этого фреймворка обусловлено тем, что с нашими задачами рано или поздно придется масштабироваться к тому же, хочется, чтобы решение было отказоустойчивым.
  • GRPC для общения сервисов между собой, так как в системе, кроме сервиса игроков, построенного на Orleans, существуют и другие: авторизация, загрузка каталогов и прочее в том числе и сервисы, которые ранее были написаны на Java и оказались по-настоящему автономны и независимы от того проекта, в котором используются.
  • Postgres для хранения данных игроков. Для масштабирования базы данных мы используем шардирование.
  • Docker с ним удобно разворачивать окружение локально и в тестовой среде. Таким образом, геймдизайнеры и разработчики могут работать с метой так, чтобы никому не мешать. Можно у себя ее локально поднять, проверить, что все работает, как нужно, и запушить уже измененный код в репозиторий.
  • Prometheus для мониторинга.
  • Event Sourcing парадигма, которую мы используем для хранения данных игроков. Она часто используется в банках. Подход здесь такой: когда мы работаем через Event Sourcing, все, что мы делаем, представлено в виде потока событий. Как упоминалось ранее, хотелось бы постоянно иметь историю, которая сохраняется в базе данных. Этот поток событий и есть наша история, по которой мы можем отслеживать, что происходило. Если что-то пошло не так, мы можем посмотреть интересующее нас событие в прошлом и полностью восстановить состояние игрока.

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

Обычно настройками параметров игры занимаются геймдизайнеры. Они уже давно работают в таблицах Excel или Google Sheets, поскольку в них удобно производить расчеты, задавать формулы, строить графики. Поэтому мы решили, что хорошей идеей будет эти же таблицы использовать не только для расчетов, но и для хранения параметров игры. Единственное, чего нам не хватало формализации правил хранения данных, чтобы парсер знал, откуда эти данные брать. В итоге мы сделали несколько вариантов шаблонов вкладок под наши нужды:

  • вкладки конфигурирования игровых предметов;
  • вкладки настройки экспериментов (A/B тестов);
  • вкладки настройки лутбоксов;
  • вкладки настройки игровых валют;
  • вкладки для хранения простых настроек, заданных в виде ключ-значение.



Пример конфигурирования предмета

На примере выше показана вкладка, содержащая конфигурации предметов. Они имеют несколько стандартных колонок: ID, теги и цена. Эти значения обрабатываются особым образом. По ID и тегам, например, производится индексирование, так что по ним легко осуществлять поиск. Остальные колонки задаются свободно, и их может быть сколько угодно. Из кода такие данные получить очень просто:

// Находим в каталоге предмет с идентификатором 'Reaver_1':ItemBlueprint itemBlueprint = catalog.GetItemBlueprint(ItemBlueprint.ValueOf("Reaver_1")); // Получаем проверенное значение из колонки с названием 'grade'. // Если поле отсутствует или имеет неверный тип, далее этот результат будет передан // в админку, где будет выведена информация о месте нахождения ошибки:Validated<int> grade = itemBlueprint.ShouldHasIntAttr("grade");

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

  • Профиль игрока. Он содержит имя и дату регистрации пользователя, а также позволяет хранить проектно специфичные данные.
  • Кошелек. Благодаря нему начисляются и списываются валюты, выводится их баланс. Помимо прочего, реализация нашего кошелька позволяет отслеживать источники, из которых были получены валюты, и, как следствие, определять, на что игроки тратят реальные деньги, а на что полученные в процессе игры. Это важно для понимания того, что представляет большую ценность для игрока.
  • Инвентарь. Он позволяет управлять внутриигровыми предметами: добавлять их, удалять, осуществлять поиск.
  • Предметы. Они делятся на два вида:

  1. Обладающие индивидуальностью и состоянием. Таким предметам можно задавать проектно специфичные параметры. Так, например, у брони может отслеживаться состояние ее износа.
  2. Не обладающие индивидуальностью. Обычно это потребляемые предметы. В таком случае хранится только счетчик их количества. Пример таких предметов бутылки с целебным зельем.

  • Лутбоксы. Сейчас без них немыслима ни одна free-to-play игра. Наше решение позволяет задавать различные варианты генерации контента для выдачи: от 100% гарантированного в этом случае лутбоксы можно использовать как обычные контейнеры, до полностью случайного.

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

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

// Описываем команду, представляющую из себя обычную DTO,// которая может быть сериализована в Json:public class DemoCommand : ICommand{    public string BlueprintId;    public int Value;} // Описываем обработчик команды:public class DemoHandler : HandlerBase, ICommandHandler<DemoCommand>{    public void Handle(ICommandContext context, DemoCommand command)    {        // Inventory  объявлен в HandlerBase.        // Создаем новый предмет по образцу из каталога:        var demoItem = Inventory.GrantItem(ItemBlueprintId.ValueOf(command.BlueprintId));         // Задаем предмету значение атрибута 'demo_value':        demoItem.Attributes["demo_value"] = command.Value;     }}

Заводим команду и ее обработчик. В реализации обработчика видно, что мы обращаемся к инвентарю и выдаем предмет игроку. После этого мы присваиваем предмету атрибут demo_value со значением, переданным в команде.

Ниже приведен пример того, как происходит выполнение команды и обработка ее результата на клиенте:

// Выполняем команду на сервере:var command = new DemoCommand { BlueprintId = "Reaver_1", Value = 777 };var commandResult = connection.Execute(command); // Из ответа получаем обновленный инвентарь игрока:var inventory = commandResult.Player.Inventory; // Получаем последний созданный предмет:var demoItem = inventory.FindItemsByBlueprint(ItemBlueprintId.ValueOf("Reaver_1")).Last(); // Выводим установленное значение:Console.WriteLine(demoItem.Attributes["demo_value"]);

Так при чем здесь Event Sourcing?

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

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

Ниже приведена упрощенная диаграмма того, что происходит при взаимодействии клиента и сервера:



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

Ниже приведен пример отображения транзакций игрока из реального проекта. Здесь мы видим две прошедших транзакции. Одна из них создание нового игрока, вторая принятие пользовательского соглашения с определенной версией.


Пример лога транзакций из реального проекта

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

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

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

Учебные материалы для школы программирования. Часть 1

02.01.2021 18:15:24 | Автор: admin

Наш век запомнится мне, как время стартапов. От школьника-активиста, до жителя Кремниевой долины - все делают своих единорогов. Как поняли - так и делают. Я тоже не прошла мимо тренда на безграничные возможности самореализации, и запустила школу программирования для детей Step to Science. Время жизни этого проекта было наполнено открытиями, борьбы со страхами, маленькими и большими победами, ошибками и много чем еще. Весной 2020 года команда столкнулась с сами знаете с чем, и, немного порефлексировав, я приняла решение закрыть проект.

За годы работы школы, был найден оптимальный алгоритм обучения ребят занимательной науке разработки игр на Unity 3D. Мы перебрали много тем, которые смогли захватить интерес школьников от 10 до 16 лет, опробовали десятки способов передачи информации, тренировки навыков и оценки заложенных знаний. Эта кропотливая работа принесла нам отличные результаты, в виде комплексной программы по созданию компьютерных игр на Unity 3D, и учебных успехов, которые достигали наши ребята!

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

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

Spoiler

Справка для моих коллег - педагогов:

Unity3D это популярный движок разработки 3D-игр и интерактивных приложений для различных платформ и устройств.ПО обладает понятным и удобным интерфейсом;большим количеством мощных вспомогательных средств, связанных с проектированием и дизайном;современным уровнем трехмерной графики и спецэффектов.

Образовательные цели:

Знакомство с работой движка и языком программирования C#;

Освоение на практике основных принципов и технологий создания современных трехмерных компьютерных игр;

Формирование навыков моделирования объектов, создания персонажей и анимации, навыков работы с текстурами и освещением, проектированием ландшафта, работы со звуком, спецэффектами;

Образовательные задачи:

Создать портфолио проектов ученика;

Получить практические навыки профессионального разработчика игровых приложений;

Прохождение полного цикла знакомства с профессией game development.

Количество детей в группе: 7-10 человек.

Возраст детей: 10-16 лет.

Форма и режим занятий: занятия проходят в практической форме, 2 раза в неделю по 2 академических часа с 10 минутным перерывом.

Минимальные технические требования к ПК: OS Windows 7 SP1+, 8, 10, только 64-разрядные версии; ЦП поддержка набора инструкций SSE2; видеокарта с поддержкой DX10 (версия шейдеров 4.0).

Общая продолжительность программы: 2 модуля по 48 часов каждый.

Знакомство с Unity 3D мы начнем с легкой в разработке и веселой игры "Spaceship". Этот проект мы всегда делали на первом пробном занятии, т.к. благодаря простоте, ученик быстро получает желаемый результат, укрепляется в вере в свои силы, получает массу положительных эмоций и в глазах зажигается тот самый, желаемый родителями, интерес к новым знаниям!

Итак, поехали!

Spaceship

В данном занятии рассмотрено создание простого космического симулятора.


Занятие является пробным и рассчитано 1.5 - 2 часа времени.


Версия Unity 3D от 5.5 и выше. На компьютеры учеников должен быть скопирован файл Spaceship_template (если ссылка сломалась - пишите в Telegram @Evgeniya_Koroleva).

В ходе выполнения будут затронуты основы работы с редактором, моделями, скриптами, физикой и звуком.

Порядок выполнения.

Откроем юнити и создадим новый 3D проект, нажав на кнопку New. Дадим проекту имя и нажмём Create project.

Откроется окно редактора. На данном этапе стоит рассказать ученикам о назначении основных вкладок и окон. В рамках данного занятия, рассматриваем только самые основные, представленные на скриншоте.

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

Чтобы выйти из режима игры, ещё раз нажмём на Play.

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

Заменим стандартный скайбокс на скайбокс Млечный путь. Для этого необходимо вызвать окно освещения.

В данном окне надо найти поле Skybox Material и нажать на кнопку выбора материала.

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

Окно Lighting можно закрыть.


Чтобы небо отображалось в окне Scene редактора, должна быть нажата кнопка показа неба и атмосферных эффектов (выделено красным) , а в выпадающем списке должна стоять галочка напротив пункта Skybox (выделено синим).

Космическому симулятору необходимы точки, смотря на которые мы бы понимали, что объект двигается. Для этого проекта такой точкой является космический корабль SF_Corvette-F3.
Найдём его в ресурсах и выложим на сцену.

Скорее всего, камера окажется внутри корабля и в окне Game корабль будет виден наизнанку. Выберем инструмент Move tool (выделен красным) и выдвинем камеру наверх.

На данном этапе стоит рассказать о том, как перемещаться по карте в режиме редактирования, а именно в окне сцены зажимаем правую кнопку мыши и летаем, нажимая WASD. Для большей скорости перемещения удерживаем Shift.


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

Следующим этапом будет расположение игрока перед камерой. Выложим модель игрока на сцену и с помощью инструмента Move tool установим его перед камерой, чтобы игрок был в поле её зрения.

Чтобы камера лучше видела игрока, можно развернуть её с помощью инструмента Rotate tool.

Настало время добавить кораблю способность двигаться. На данном этапе стоит рассказать ученикам о том, что всё поведение объектов полностью зависит от компонентов, которые находятся на этом объекте. Допустим, объект SpaceFighter содержит компонент Transform, который задаёт объекту его положение в пространстве. Чтобы корабль мог летать, необходимо добавить ему компонент физики. Выделим SpaceFighter и нажмём в панели настроек кнопку Add Component, в появившемся выпадающем списке выберем Physics->Rigidbody.

Если сейчас мы нажмём на Play, то мы увидим, что корабль падает.

Чтобы этого не происходило, нам необходимо отключить гравитацию. Для этого достаточно у компонента Rigidbody убрать галочку Use Gravity.

В самой нижней строке мы видим сообщение об ошибке. Это сообщение говорит нам о том, что требуется сделать пересчёт физической модели столкновения для объекта. Для этого откроем объект SpaceFighter, нажав на стрелочку рядом с ним и найдём объект Default. По умолчанию на данном объекте находится компонент Mesh Collider. Выставим на компоненте галочку Convex и увидим реальную физическую модель столкновений для данного объекта.

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

Теперь заставим наш объект двигаться. Для этого в объект SpaceFighter, рядом с Rigidbody, добавим ещё один компонент Constant Force (выделено красным).

Данный компонент добавляет силу, которая будет двигать наш корабль. Чтобы объект полетел вперёд, выставим ему в отмеченном синим цветом поле значение в районе 100.

Нажав на Play, мы можем видеть, как корабль улетает вдаль.

Теперь, прикрепим камеру к игроку. Для этого достаточно объект Main Camera перетянуть мышью на объект SpaceFighter.

Должно быть так

Теперь камера находится внутри нашего космического корабля и поэтому двигается вместе с ним.

Далее, необходимо добавить управление нашему игроку. Для этого в папке CustomResources/Scripts найдём скрипт Player_Battleship и перекинем его на игрока.

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

Если мы попытаемся зайти в режим игры, то можем заметить, что корабль управляется слишком резко и слишком быстро набирает скорость. Это вызвано тем, что компонент Rigidbody, обеспечивающий физику, настроен по стандарту на массу в один килограмм. Добавим массу нашему космическому кораблю, а заодно немного поменяем значения замедления, чтобы корабль был более управляемым.

Теперь наш корабль, напротив, стал довольно медленно поворачиваться. Настроим управление корабля:

Теперь можно заметить ещё одну странность корабль игрока проходит сквозь корабль SF_Corvette-F3. Чтобы этого избежать, необходимо на корабль SF_Corvette-F3 добавить компонент Mesh Collider.


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

Осталось немного добавить фоновую музыку и звуки полёта.


Возьмём звук \Absolute Space & Sci-Fi Vol.1 - Sample Pack - Voltz Supreme\Preperation - 70 bpm\Variations\Preperation - No Snare or Vox.mp3 из папки проекта и просто перекинем на любой объект, допустим, на космический корабль SF_Corvette-F3.

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

Чтобы добавить звук полёта, возьмем звук Standard Assets\Vehicles\Aircraft\Audio\FlightWind.wav
и перетянем его на игрока. В настройках поставим галочку Loop (выделено синим) это закольцует звук и он будет проигрываться постоянно. Скрипт Player_Battleship автоматически найдёт этот звук и будет управлять его громкостью в зависимости от скорости игрока.

Если учащиеся справилась с заданием раньше срока, можно добавить немного динамики нашему проекту. Для этого закинем на объект Main Camera скрипт Player_Camera и настроим в соответствии со скриншотом.

Также можно добавить следы на краях крыла: внутри объекта SpaceFighter есть две точки trail и trail_1.
Добавим на них компонент Trail Renderer и протестируем - должны получиться яркие розовые линии.

Чтобы это исправить, в компоненте Trail Renderer найдём массив Materials, раскроем его, найдём поле Element0 и нажмём на кнопку выбора- кружок с правой стороны поля.

Выберем белый материал, допустим, этот:

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

В конце можно добавить простой прицел, создав объект типа Image и настроив его:

В поле Sprite компонента Image нажмём на кружок выбора и выберем текстуру прицела.

Выберем прицел.

В компоненте Image нажмём на появившуюся там кнопку Set Native Size (выделено красным). Дополнительно, можно выбрать цвет прицела, нажав на поле Color (выделено синим).

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

После данного действия будут созданы файл *.exe, папка *_GameData и UnityPlayer.dll, где * - выбранное имя. Файл UnityPlayer.dll в зависимости от версии может и не создаваться. Для работы готовой игры на другом компьютере все сгенерированные в ходе данного действия файлы и папки должны находиться в одной директории.

На этом мы завершаем первое занятие-знакомство с Unity 3D.

Следующие проекты - в следующих постах на habr. До скорых встреч!


P.S.: за помощь в подготовке проектов, невероятный преподавательский талант и незабываемый черный юмор, спасибо Александру Борисову!

Подробнее..

Flappy Bird на Unity 3D

10.01.2021 16:05:45 | Автор: admin

Учебные материалы для школы программирования. Часть 3

Spoiler

Часть 1 вы можете найти здесь

Часть 2 вы можете найти здесь

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

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

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

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

Решением стало снизить количество рассматриваемых тем из школьной программы, и добавить в проекты элемент узнаваемости, соревновательности и веселья! Так появилось занятие по сборке аналога игры Flappy Bird.

Цель занятия: научиться работать с 2д-физикой и Canvas при использовании последнего на разных разрешениях целевой платформы.

Рассматриваем с учащимися темы:

- включение AudioSource посредством Event-системы UI;
- детектирование тапа по экрану посредством Event-системы UI - Спрайты;
- система анимаций в разрезе 2D-игр;
- коллайдеры в 2D и их редактирование;
- сборка проекта под Android.

Поехали!

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

Для начала научимся пользоваться спрайтами. В ресурсах игры лежит файл sprites.png, который импортирован как спрайт с пометкой Multiple, это позволяет посредством кнопки SpriteEditor разрезать его на несколько одиночных спрайтов.

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

Стоит рассказать ребятам об особенностях работы коллайдеров, накладываемых на спрайт. Например, на птице установлен Polygon Collider 2D, позволяющий точно подобрать форму коллайдера под спрайт без необходимости делать его выпуклым для симуляции физики, как в 3D.

Анимация спрайтов.

Следующим шагом будет создание движущихся труб. Трубы устроены следующим образом: пара труб с установленным между ними триггером со скриптом, убивающим игрока, расположены в одном объекте. Передвигать нужно именно этот объект. Записываем на него анимацию, выходим из режима записи и проверяем.

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

Для компиляции под Android важно не забыть про удобное управление. Для мобильных игр, в большинстве своём, оно должно осуществляться одним пальцем. Делается это довольно просто (решение не является оптимальным, но оно самое простое).

В Canvas создаём панель и делаем её абсолютно прозрачной.

Все элементы управления закидываем внутрь этой панели. Это обязательно. Если этого не сделать, панель и кнопки могут некорректно отвечать на нажатия.
На панель необходимо закинуть компонент EventTrigger, и создать новое поле OnPointerEnter. В это поле закидываем птицу и выбираем внутри метод Jump.

После этого птица корректно начнет реагировать на нажатия по экрану.

Компиляция проекта под андроид.
Зайдём в File->Preferences->External Tools. Внизу страницы находятся три поля - SDK, JDK и NDK. Рядом кнопки Browse и Download. Первая - для выставления нужной папки, в которую установлены sdk, jdk, ndk, вторая - перекидывает на страницу загрузки того или иного инструмента.

Сперва необходимо установить Android studio и необходимые пакеты инструментов и SDK. На момент написания этих строк, устанавливалось API уровня 16 и 25. Также для компиляции необходим JDK.
NDK для данного проекта устанавливать нет необходимости.

Далее необходимо зайти в File-> Build Settings , выбрать платформу Android и нажать Switch Platform.

Затем переходим в Edit -> Project Settings -> Player

В свитке Resolution and presentation выбираем расположение Landscape left, это заставляет экран всегда быть в одном положении и не поворачиваться, если включён автоповорот.

В свитке other settings необходимо выставить имя приложения в том же формате, что и стандартное. Тем не менее, изменить это поле обязательно, в противном случае компиляция не пройдёт успешно. Также необходимо выбрать минимальные и целевое API.

По желанию можно выставить иконку и компилировать. На выходе мы получим APK файл игры.
Если подключить телефон на андроиде в режиме отладки и нажать Build and Run, то игра автоматически установится на телефон и запустится.

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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru