Главная » Хабрахабр » [Из песочницы] Ещё одна погоня за мечтой. RTS + eyetracker руками студента

[Из песочницы] Ещё одна погоня за мечтой. RTS + eyetracker руками студента

Привет.

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

Под катом вы увидите: подробную историю создания RTS своими руками (концепция, код, интерфейс, баланс, карта, модели) и эксперимент по привязыванию к ней айтрекера как средства ввода.

Ну что ж, начнем.

На дворе 2014 год.
Я студент кафедры Информационного дизайна в Политехе (ныне «Инженерная графика и дизайн»).

Своим бакалаврским дипломом я разрабатывал игру под кинект про дуэль двух пуджей, где нужно было уклоняться от атак противника и швырять в него свой крюк (GET OVER HERE!!!).

На тот момент в лаборатории при кафедре появилась техническая новинка — айтрекер. В магистерской работе я решил шануть дальше. То, что работа будет игрой, сомнений не было никаких, оставалось выбрать лишь тематику. Выбор сразу пал на него. После недолгих размышлений понял, что хочу отдать почести стратегии, на которой я вырос и которая открыла мне чудесный мир программирования – Warcraft3.

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

Большинство игр стараются очистить экран от элементов управления, отдавая основное пространство контенту. Здесь вступил в дело многолетний игровой опыт. Чтобы понять, что представляет из себя определенный юнит, его нужно найти на экране, выделить, перевести взгляд на “панель состояния” и там уже найти нужный параметр. В стратегиях же интерфейс занимает огромное пространство. Когда же возникает подобная потребность во время сражения больших армий, такая последовательность действий зачастую создает трудности.

Почему бы не получить её, просто взглянув на него? Возник вопрос: раз мы и так находим юнита на поле, то зачем нам потом его выделять, чтобы считать информацию? После демонстрации вопрос был трансформирован в премудрое название “Функциональные возможности операционной зоны зрения человека в человеко-компьютерном взаимодействии”, что, по сути, означало сравнение эффективности мыши и глаз при решении задачи поиска объекта из множества и считывания с него информации.

Summa Technologiae

Тема есть. Концепция есть. Дело было за выбором технологии. После обзора рынка выбор встал между Unity, UnrealSDK, libGDX, среди которых выбрана Unity + C#. Освоив интерфейс, жизненный цикл объектов на сцене и возможности взаимодействия с ними, я приступил к разработке.

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

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

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

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

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

Когда все было готово, пришла пора ставить эксперимент.

На ней после запуска спаунятся юниты (танки, лол) и начинают хаотично передвигаться. Есть сцена, ограниченная пределами одного экрана.

Все юниты имеют максимальное здоровье, кроме одного, имеющего половинный уровень хп. Каждый юнит обладает определенным количеством здоровья. У кого здоровье полное – индикатор зеленый и заполнен полностью. При выделении юнита мы видим вокруг него рамку с индикатором здоровья. Цель – найти среди остальных раненый танк и удержать выделенным в течении секунды. У раненого же юнита он рыжий и заполнен наполовину. Эксперимент состоял из 5 уровней, отличающихся количеством юнитов на сцене – 5, 10, 15, 20, 25. Основным замеряемым параметром является время, неоходимое на выполение этого задания. Гипотеза была в том, что решение этой задачи при помощи айтрекера потребует меньше времени.

Настало время обработки статистики. Эксперимент был проведен, данные собраны. В качестве зависимой переменной, понятное дело, использовалась скорость выполнения задания. Я воспользовался привычными для себя средствами – PHP и JavaScript, рассчитал критерий Фишера и обнаружил, что разница между использованием курсора и использованием айтрекера статистически значима. Дальше я при помощи D3.js визуализировал результат.

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

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

Исследование мы с научным руководителем оформили в статью и оно было опубликовано в журнале Perception.

Успех, слава и тд. Воу!

Благодаря ему я и написал оба своих диплома, да и в целом двинулся в сторону программирования и человеко-компьютерного взаимодействия. Здесь хочется отдельно упомянуть моего научного руководителя. Павел Орлов (1 и 2), сейчас он преподает в Imperial College London, а в целом изучает людей при помощи айтрекера и создает всякие классные шутки.

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

Учимся ходить

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

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

К этому моменту у меня сущестовал класс WorldObject от которого наследовались Unit и Building, каждый из которых обладал соответствующим функционалом. Эта мысль стала краеугльным камнем, определившим дальнейшее развитие и полный рефактор моего проекта. Здания же могли стоять и производить юнитов, а двигаться и атаковать – не могли. Юниты могли передвигаться, атаковать, добывать ресурсы, строить здания. Турель должна являться по своей сути зданием, но обладать способностью атаки, свойственной юнитам. Появилось желание сделать охранное здание — башню или турель. Нужно было как то выносить функционал атаки из класса Unit… Это поломало все мои планы.

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

И знаете что? Для разбора полетов я решил изучить: а какие ещё несоответствия подобного рода присутствуют в игре взятой за реферес – Warcraft3. Есть здания, которые могут атаковать, например Guard Tower или Orc Burrow. Оказалось их там целая плеяда. Eсть и юниты, которые не могут атаковать, например Wisp или всякие нейтральные овечки да свинюшки снующие по карте (critters). Есть такие, которые могут ещё и двигаться, например Ancient of War. Это лишь смыслы, навязанные программе игроками для собственного удобства. В моей голове пошли размышления о природе отличия зданий от юнитов и я осознал, что таких отличий нет. Есть только юниты и их способности – передвигаться, атаковать, производить юнитов, строить здания, добывать ресурсы и так далее.

Были созданы: MoveAbility, RotateAbility, AttackAbility, DefenceAbility, HpRegenAbility, DefenceAbility, ProduceAbility, BuildAbility, RepairAbility, SellSelfAbility. Очевидным решением ситуации стало создание интерфейсов, которые юниты могут реализовывать. Все остальные способности привязываются к нему поверх. Юнит по сути остался лишь контейнером с названием, изображением и моделью.

Brave new world

Теперь дело за концепцией.

Тогда был в жанре стратегий некий застой, и это повлияло на выбор жанра самой игры. Напомню, что дело происходило в 2014 году. Я был большим фанатом миров, одетых в медь и латунь, окутанных паром, несущихся в свое механическое будущее. Также в те годы переживал явный подъем популярности сеттинг стимпанка. Хотелось добавить в игру противостояние. Но делать игру только с ударом в стимпанк мне казалось скучным и я искал развитие идеи. Конечно же магия и единение с природой! И что может быть максимально противопоставленным техногенной индустриальной цивилизации? Дальше вы увидите, что проект развился не в клон, сляпанный студентом на коленке, а в нечто совершенно иное. Да, конечно, вы скажете Arcanum, но черт побери, со временем красота такого сеттинга не теряется. Пожалуй, в полную идеологическую противоположность Арканума.

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

А что может быть более абстрактным, чем шар? Мне хотелось максимально отстранится от этого всего, абстрагироваться. Добавил в неё порцию “зерговой” биоморфности (да-да, согрешил против себя). Я пошел от этой идеальной геометрической формы. Подумал: почему бы астрактным существам не иметь фозможность формировать свое тело и все покровные ткани?

Так родились орбы.

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

Один – традициональный, консервативный, где считают, что они дети природы и должны максимально вливаться в неё и способствовать её развитию.

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

Разве не так в один не очень-то прекрасный день индейцы увидели на горизонте мачты конкистадорских кораблей? За этой завязкой скрывалась аллюзия на вполне исторические события. В мире орбов история повторилась, только местным индейцам мы дали настоящее колдовство, а завоеватели приплыли не из Испании 15 века, а, скажем, из бисмарковской Германии.

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

Между бубном и шестеренкой

А в чем же развитие?

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

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

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

А значит, пришло время определиться с тем, кто же будет в нашей игре! И вот у нас есть концепция. После долгих дискуссий, решили остановиться на базовом для стратегий наборе – рабочий (строит здания, добывает ресурсы), легкий юнит (быстрый, слабый), тяжелый юнит (медленный сильный), катапульта (очень медленный, очень тонкий, дальний бой). Какие юниты и здания, как они будут изменяться. Из зданий – база (производит рабочих), гнездо (дает прирост к пище), казарма (производит легкого и тяжелого юнита), мастерская (производит катапульты), святилища/фабрики (позволяет совершить прокачку).

Мы решили остановиться на классической паре – кристаллы + лимит пищи, а также дополнительный ресурс для продвижения по древу развития. Да, я совсем забыл рассказать про игровые ресурсы. Дополнительный ресурс зарабатывается при помощи постройки на ядовитых гейзерах зданий одного из двух типов – святилищ или фабрик. Кристаллы добываются из разбросанных по карте залежей (привет starcraft), лимит пищи повышается постройкой специальных зданий – гнезд. Если игрок зарабатывает новый уровень и имеет святилище или фабрику, то он может прокачать один перк на древе развития. Кроме того, в игре присутствует опыт, который дается за уничтожение армий противника и нейтральных существ.

Но вернемся к юнитам и прокачке.

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

В созданном нами мире технология и магия не взаимоисключают друг друга. Помните, выше я говорил, что игра получилась идеологической противоположностью Арканума? Фантазия то и дело подсовывала нам видения колдунов, шагающих на механических ногах, и танков, приводимых в движение магическим кристаллом вместо паровой или дизельной силовой установки.

Найти точку равновесия

Все это звучит довольно просто, но, когда мы этот нарратив попытались перенести в пространство чисел, точных значений и их приростов, то все оказалось ОЧЕНЬ ЗАПУТАННЫМ. Легко накидать какие то дельты значений для способностей, например, этот юнит получает +20 к урону, а этот +15 к скорости движения. Но потом очень сложно свести этот огромный массив параметров к балансу.

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

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

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

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

Отвечу быстро – первое время методом скрупулезного перебивания. Тут наверное к вам в головы закрался вопрос: а как же все это безумие преносилось в игру? Как это — мне, не-твари-дрожащей, приходится делать такую вот унылую бестолковую рутину?! Но к моменту, когда каждая ветка получила по 2 этапа развития в каждую сторону и общее число юнитов дошло до 9, то мой внутренний лентяй-программист взбунтовался.

Тогда я создал веб-приложение для генерации дерева прокачки.

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

На выход эта система отдавала JSON, который теперь принимала Юнити и конфигурировала игровые объекты (над этой системой импорта тоже пришлось побиться определенное количество времени, ведь с непривычки строить и обходить деревья было не так то и просто).

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

Музыка Айнур

Здесь хотелось бы вставить ремарку. На протяжении всего рассказа я использую разные местоимения – то Я, то МЫ. Дело в том, что начал проект я в одиночку, провел исследование, создал “движок” игры и тд. Но затем своей активностью я заинтересовал своих товарищей и к процессу присоединились на первых порах двое человек – Владимир Ермаков (Avega) в роле опытного программиста и Павел Шилин в роле художестенно-описательного консультанта. Потом добавились ещё Анна Трофимова и Николай Морозов помогающие с ландшафтом и программированием, соответственно. К созданию баланса приложил руку и пару ночей своего времени мой хороший товарищ Дмитрий Машошин.

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

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

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

Ну, я и попробовал создать что-то похожее, но свое (хех, этими словами можно писать всю разработку в целом).

Сначала карта была отрисована и спроектирована на бумаге.

Изначально строгая, затем она приобрела плавность сглаженность и шум. Затем обрисована в Photoshop’e в фомрате черно-белой карты высот. Важным моментом здесь было сохранить различие между непроходимыми гранями поверхностей и спусками и подъемами.

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

Он был полностью белый и громко кричал – ДОБАВЬТЕ МНЕ ТЕКСТУР. Но что то с ним было не так.

Чем я и занялся.

Свои текстуры рисовать времени у меня не было (каюсь, но время сдачи диплома подходило, и нужно было вертеться), поэтому были использованы текстуры WorldOfWarcraft, скачанные из открытых источников.

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

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

Быстро был найден плагин (модуль?) для Unity решающий проблему — A*. Здесь в дело вступил многоопытный Владимир, который разведал тему и понял, что реализовывать самим какой либо из существующих способов решения задачи слишком трудозатратно. После этого юниты начали отлично находить путь даже на другой конец карты, когда пред ними были и скалы, и низины, и прочие радости ландшафта. Владимир разобрался в интерфейсе и адаптировал его под наши нужды.

После создания мира стал актуальным самый трепетный вопрос – почему все наши юниты это чертовы КУБЫ?

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

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

Придать форму бесформенному

Встречайте орбов!

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

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

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

На легкого юнита и тотемы не хватило времени, увы. Всего для игры было смоделировано 6 объектов (3 юнита и 3 здания) + 4 модификации (2 магические, 2 технические).

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

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

При появлении юнита на сцене создается его базовая часть, а затем в стуктуру WorldObject’a из ассетов добавляются все необходимые обвесы. В Unity это было добавлено следующим образом – юниты обладают базовыми элементами, например телом, плюс каждый тир прокачки (учитывая базовый) имеет ссылку на соответствующие ему элементы графики.

Окно в мир

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

Дело в том, что не разработан адекватный интерфейс, HUD, как принято называть его в играх. Почему же тогда игрок страдает?

Для решения задачи построения интерфейса первоначально я собрал аналоги, старые и новые – Command&Conquer, Казаки, Warcraft 3, Starcraft 2, Warhammer, Dota, LoL – и начал анализировать составные элементы.

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

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

В те древние времена нативные инструрменты Unity для создания HUD’a представляли из себя небольшой набор элементов, которые необходимо создавать и располагать на экране напрямую через код.

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

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

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

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

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

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

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

В целях экономии места на экране было принято решение делать полосы здоровья всех юнитов определенной длины (чтобы при прокачках и баффах полоса здоровья в 10000 хп не была от края экрана до края).

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

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

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

Ну и, конечно же, опыт и дерево прокачки.

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

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

Да, довольно топорно выглядит, но это же было всего лишь начало!

Ура, большой путь позади, впереди бесконечное пространство вариантов развития. И вот для первого запуска все готово!

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

ЭВЕНЕДИУМ.

Поехали!

И немного скриншотов для тех, кому не хочется смотреть ролик выше.

Finita?

Базовая версия игры была готова.

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

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

Целый год я корпел над созданием этого детища, обрастал соратниками, и вот мы – команда, перед нами продукт и светлое будущее. Клавиатуры кипели, ещё месяц мы что-то активно писали и вдруг, внезапно, я обнаружил, что прошел уже год разработки! Мы решили отпраздновать.

Последний коммит начал встречать всех вот таким постом.

Последний. И да. Он требовал времени и усилий, к которым они не были готовы. Как бы это ни было странно, но именно в этот момент ребята, которые к концу серьезно помогали с созданием, решили покинуть проект. Они не видели в нем ни перспектив, ни смысла.

Обидной, ударившей довольно сильно. Для меня это было неожиданностью.

Все описано выше. Длинного вывода не будет, к чему он?

В целом я горд, что я погнался за своей мечтой создать мир и довел её до такого состояния.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Перевод] Браузеры отключают звук в вашем WebRTC-приложении. Стоп, что?

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

Создатель игры while True: learn() о программировании в геймдеве, проблемах с VR и симуляции ML

Постоянно выступал, проводил Gamesjam, был частым гостем подкаста Как делают игры. Несколько лет назад мне казалось, что Олег Чумаков (тогда еще из Nival) был самым известным программистом геймдева. Но вы все знаете, с виртуальной реальностью что-то пошло не так, как ...