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

Почему больше не в Telegram

После выпуска первой статьи, энтузиазма писать игру хватило еще на неделю. Прилетели проблемы по работе, поиски новой, да и вообще лето. Проект был отброшен на задний план. В процессе поиска будущего работодателя возникла мысль попробовать себя в разработчиках. Спустя несколько часов диалогов с разными ребятами из IT, выбор пал на iOS-разработку. Благо, на Udemy курсы уже куплены, поэтому из летнего режима переходим в режим разработчика на 1.5[OT1] недели.

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

Проводим несколько Cust Dev исследований, и упираемся в понятие красный океан, где сложно найти инвестиции. Если кому интересно, вот пара отрисованных скриншотов проекта, умершего в зародыше.

Чем же теперь заниматься? Ведь амбиции трушного разраба никуда не делись. Точно! Есть же детская мечта - написать "свою MMORPG". Да и какой-никакой код на питоне остался.

Стоп? А зачем писать в игру в телеграме? Я зря что ли курсы проходил по iOS? И тут аргументы начали приходить один за другим

• Ограничение функционалом чатов

• Прототип у меня неплохо получилось нарисовать (по своему собственному мнению). Значит, и игру смогу

• MMORPG - это про айдентику игрока среди других. А это труднодостежимо с телегой

• Визуал воспринимается проще, чем эконки emoji и одноцветный текст

Решено. Делаем iOS

Дизайн

Заходим в Figma. Новый файл. Стоп. Нужна также и айдентика игры.

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

Что следующим этапом? Верно, стартовый экран. На нем должен быть лого и должна быть картинка. Название игры пока не придумано. Берем за пример TBMMORPG (Text based MMORPG). Как сделать красиво? Создаем 2 одинаковых текста, темный подкладываем под светлым, у темного увеличиваем letter spacing.

Теперь нужна картинка. Открываем Aseprite (редактор пиксельных изображений). Час тыкаем кисточкой в пиксели. Закрываем Aseprite. Идем на сайт по продаже спрайтов. Сутки поиска подходящих сетов и 50$, и более 1800 айтемов и персонажей у нас в папке проекта. Выбираем яркого персонажа и загадочного персонажа, ставим в конфронтацию, кладем в лапу оружие, охапка дров и плов готов!

Готово окно входа. Теперь нужен и сам экран с логами.

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

Основные механики игры

Notion: выписываем все, что хотим реализовывать в первых версиях игры:

• Классы: на начальном этапе будут Воин, Лучник, Убийца, Маг

• Характеристики персонажей: скорость атаки, уклонение, крит

• Автофарм - даже вне сети.

• Player vs Mob - автоматический фарм. Выбираются типы мобов доступные в локации, сколько максимум мобов в локации, их HP и атака. Раз в пять секунд персонаж и моб обмениваются ударами. Atack speed накапливается и при скорости атаки 50%, каждый второй обмен ударами, игрок наносит два удара. Мобы бывают с одной звездой, с двумя и с тремя. Самый сложный - с тремя, но с него гораздо вкуснее лут. Но и его появления меньше. В локациях для более высоких уровней могут быть агрессивные мобы. То есть, независимо от того, каких мобов для сражения вы выбрали, агрессивный моб может напасть на вас, даже в момент, когда вы бьете другого моба. Тогда урон будет проходить по игроку от двух мобов.

• Player vs Player - игрок может выбрать другого игрока в локации и нанести ему урон. Игрок, нанесший урон, приобретает статус PVP и для всех в локации отображается другим цветом. Если на такого игрока нападут, то выигравший получит плюс к счетчику убийств PVP. Если игрок наносит урон игроку, который не находится в статусе PVP и убивает его, игрок переходит в статус PK (Player killer). Если такого игрока убить, с высоким шансом из его инвентаря выпадет при смерти лут, который не привязан к игроку, и его смогут подобрать другие игроки.

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

• Крафт - доступен крафт, из собираемых ресурсов, из лута падающего с мобов, из лута падающего с боссов в данжах, из лута падающего при разборе предметов.

• Группа - на фарме, в PvP, в GvG, в данжи и на боссах можно сражаться в группе. Эффект группы дает бонусы к характеристикам персонажей.

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

• Заточка: максимальная заточка оружия +12, максимальная заточка вещей и бижутерии +10. Безопасная точка +3. Неудачная точка свыше +3 - сбрасывает заточку до +0. Есть усовершенствованные свитки, которые сбрасывают точку при неудачной только на -1.

• Мировой босс: появляется в определенной локации раз в сутки. Могут упасть разные ништяки. Выпадает тому, кто нанес больше всего урона (персонаж или группа).

• Арена - каждый день проводится арена в формате группового этапа. Победителям распределяются очки. Каждую неделю, персонажи набравшие большее количество очков участвуют в финалe, который проводится в режиме сетки. В воскресенье определяются победители, которые получают ништяки и возможность участвовать в Арене Героев, которая проводится раз в месяц в формате турнирной сетки. Ее победители получают уникальные шмотки/оружие, которые имеют преимущество в PvP по сравнению с другими носимыми предметами в игре, а также статус Героя, который выделяет персонажа в списке всех персонажей

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

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

• Чаты с игроками, чаты с гильдией, аукцион, и другие моменты, которые еще не до конца продуманы.

• 
  

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

Начинаем прогать все заново

Дизайн - есть, механики - есть. Нужен код.

Открываем Питонячий файл, написанный для телеги. Находим в нем WebHooks. Это нам вряд ли подходит - выбрасываем питонячий файл. Открываем PyCharm. Стоп! А как сервер писать для MMORPG?

Пару дней гуглим, находим не так много информации. Походу, MMORPG не написать копипастом из StackOverflow.

Обычные запросы нам не то, чтобы подходят. На сей раз нам помогает Reddit, где сообщают, что WebSockets отличное решение для мультиплеерных игр. Несмотря на то, что боёвка планируется по шагам (обмен ударами раз в N секунд), то PVP, GVG и другие механики требуют постоянного соединения. Поэтому выбираем Websockets и одноименный пакет для Python.

Теперь нужно получить connection к веб-сокету с клиента. Накидываем пару текстовых полей в интерфейсе. Добавляем либу. Конектим. Фейл. Еще раз - фейл. Вообще не стучится. Пробуем через браузер - стучится. Хрень какая-то. Поменяли настройки. Конектим - не стучится. Окей. Теперь время посмотреть в доку. This library for sockets connection. If you need websocket protocol you should use this library: Starscream.

Выучили урок. Теперь будем читать доку либы чуть дальше строки с ее названием.

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

Ну и настало время придумать название для игры. Что ассоциируется у меня с классическими MMORPG? Perfect World, Lineage, World of warcraf. В двух из трех есть слово World. Окей, заимствуем. В чем концепт игры? В логах! Logger World

Начинаем прогать все заново

Что-то ноут тормозит и работать становится тяжеловато. Копируем папку Developer в Yandex Disk, ребутаем устройство. Reinstall OS.

Открываем Xcode, открываем Pycharm. Открываем прое.. А вы знали, что неделя работы и 95% написанного кода Pycharm сохраняет не в Developer, а в свою директорию. Ну вот! А я не знал. И не посмотрел.

Окей. Повторенье - мать ученья. Только в этот раз - не на питоне. Что у нас есть из интересного? Swift на back! Но я не IBM - мне страшно. Java, NodeJS, C#

А что там с Kotlin? Вроде как он мультиплатформенный. Запускается там, где есть JVM. На нем можно будет написать и Android клиент. А еще можно использовать Kotlin Multiplatform Mobile, чтобы объединить кодовую базу iOS и Android приложения. И там только интерфейсные истории останется написать. Звучит easy. Как раз мой внутренний недождун устал от рутинных проектов по 50 штук в день, и подавай ему что-то эдакое.

Заходим в телегу, спрашиваем: "Есть ORM и Websockets либы для Kotlin, хватит ли этого на проект?". После краткого интродакшена игры нам подтверждают, что все гуд и Kotlin потянет (а вот ты нет!). Не зря Google пляшет вокруг Kotlin. И пару часов спустя нам пишет и предлагает поучаствовать в проекте AahzBrut. Он уже писал игры на котлин, да и явно кто-то с опытом back-end разработки, лучше, чем кто-то без опыта back-end разработки. Просим AahzBrut настроить проект, чтобы мы вдвоем могли писать код на разные части проекта. И получаем через пару часов файлик с описанием: Services, DTO, Entity, POJO, Reposintories. Уходим гуглить. Окей, AahzBrut, очень интересно, но якори нам на back-end точно не нужны. С этого момента AahzBrut у нас за серверную часть, а я за клиентскую.

Хороший старт

Ну по крайней мере на back-end у нас хороший старт

На текущий момент, у нас реализовано:

• Примерный визуал игры (как должна выглядеть)

• Экраны регистрации, логина, выбора персонажа, создания персонажа, прототип самого экрана с логами, ну и конечно иконка приложения

• Back-end: aутентификация, регистрация, Websockets STOMP, созданы локации, персонажи, персонажи бегают по локациям, оповещения об изменении количества игроков в локациях, и еще много разных и интересных штук, которые я бы понял, но не понял :(

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

Чао!

Сказ о том, как делать не стоит. Или, как я дважды сгорал на работе

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

Но, именно данный заказ натолкнул меня на мысль, что подобным опытом стоит поделиться. Дабы, не знакомые со сферой, знали, как работает внутренняя кухня, а коллеги, как делать не стоит и почему. К тому же, перспектива Top-Down специфическая и материалов по ней практически не существует. Когда я начинал работу, никакого опыта с top-down перспективой, кроме игровой, у меня не было, что подогревало интерес.

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

Проект выполнен в жанре: Top Down Stealth - Action (уникальная смесь из серий Splinter Cell и Hotline Miami).

Движок: Love2D
Арт/Дизайн/Анимации выполнены в: Adobe Photoshop ( :) )
Художественное направление: Pixel art

Проект находится в Steam, и ознакомится с ним можно по данной ссылке: Intravenous

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

Я изготовил для проекта UI (редизайн/арт), эффекты, персонажей, анимации, тайлсеты, объекты, портреты, promo-art.
В общем, практически всё, что вы увидите в игре. Но в данной статье, речь пойдёт именно про анимации, т.к. они стали "камнем преткновения" всей разработки.

Немного о перспективе

Существует распространённое заблуждение, что "top-down" - это любой угол поворота камеры, в том числе несколько видов изометрии и, так называемая, перспектива 3/4.

Связано это с тем, что у ряда перспектив, не существует какого-то объединяющего понятия/термина отличного от "вида сверху" т.е. "Top-Down".
Отсюда и возникающие недопонимания при обсуждении того или иного проекта.

"Top-Down" (топ-даун) - это перспектива, камера в которой привязана исключительно над головой персонажа.
Примеры: GTA 1/2, Darkwood, Hotline Miami

Анимации

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

Список анимаций для всех персонажей включал в себя:

• 5 видов основного оружия (Дробовик, Обрез, MP5, UZI, AK103, M4);

• 5 видов второстепенного (Glock19, HS2000, P89, SW457, VP9);

• 5 видов уникальных приспособлений (Тазер, Переносной ЭМИ глушитель, Светошумовая граната, Осколочная граната, Пустые магазины);

• Ближний бой на всех видах оружия, в том числе и рукопашный;

• Выбивание двери;

• Idle анимации;

• Анимации смерти;

• Подбор и взаимодействие с предметами;

Уникальные для персонажа игрока:

• Перенос тел;

• Оглушение или добивание персонажей;

• Использование отмычки;

• Лаз через 2 вида препятствий;

• Движение ползком;

• Бег;

Помимо этого, существует 3 степени умения обращения с оружием (что увеличило список анимаций втрое!), которые мы условно назвали:

- Умелый; (персонаж игрока, профессиональные военные)
- Не умелый; (киллеры, наёмники)
- Абсолютно не умелый; (гангстеры, шпана)

Все 3 степени отличаются геймплейно:

- точностью при стрельбе;
- скоростью перезарядки;
- скоростью реакции на события;

Что отражается визуально, через:
- наличие лишних телодвижений при перезарядке;
- положение персонажа (стойку);

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

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

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

Шаблон

Шаблон персонажа включал в себя:

- Голову;
- Тело;
- Руки;
- Оружие;
- Дополнительные слои (ладони/детали);
- Ноги/нижняя половина тела (отдельно);

Из которых покадрово собирался цикл анимации.

Экспорт

Существует 2 пути экспорта шаблонных анимаций.

Способ 1:

• Все части шаблона - отделены (слоями);

• Оружие легко заменяется (если позволяет анимация);

• Одежда кладётся поверх слоёв в игре;

+ Упор делается на сборку составляющих внутри движка игры;
+ Гибкость, возможность осуществлять исправления, буквально, на лету;
- Требователен к инструментарию движка;

Не совсем корректный, но отличный пример: Garage: Bad Trip.
(На самом деле, она известна своей скелетной анимацией скрещенной с Pixel-art графикой, и даже существует статья на эту тему, но я её не нашёл) ("Пес-песа" - тебя помнят!)

Способ 2:

• Все части шаблона склеены (монолитный слой);

• Оружие заменяется исключительно в исходнике (PSD/GIF файле);

• Одежда склеивается вместе с частями шаблона;

+ Упор делается на финализацию работ перед отправкой;
+ Лёгкий импорт в движок игры;
- Многократно возрастающий объём работы;
- РУТИНА;
- Не подходит проектам, в которых используется большой размер спрайтов;

Отличный пример: Hotline Miami

Как вы уже понимаете, нами был выбран 2 вариант. Почему?
На это повлиял целый ряд причин:

• Отсутствие инструментария для анимации (игра разрабатывалась на Love2D);

• Необходимость разгрузки программиста от лишней работы (переизбыток задач);

• Тримминг текстур (упаковка кадров анимации в spritesheets);

• Малый размер спрайтов;

А теперь поподробнее.

• Заказчику было необходимо добиться максимальной производительности, чтобы проект смог быть запущен на устройстве любой мощности;

• Разработка инструментария для анимаций не рассматривалась вовсе, т.к. эти силы разумно было бросить на встроенный level-editor (редактор уровней) и проработку ИИ (искусственного интеллекта) врагов;
  
  

Продолжение в части 2.