Как я сделал FreeFlow боевку на Unreal Engine

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

И засел за написание своей собственной игры.

Предыстория

Важно понимать, что к этому моменту я уже в совершенстве освоил инструментарий для 3D разработки, прикупил несколько премиумных расширений для blender’а, а так-же, даже, выпустил один из ассетов на Unreal Engine Marketplace пройдя жесточайшую модерацию, вот он — ссылка.

Про модерацию там можно отдельно написать еще одну статью посвящунную моему сильнейшему возмущению. Сложно передать, как же я ненавижу всех этих проверяющих с их невменяемыми требованиями. И всюду так. Что в яндексе, что в эпик геймс, даже в банальном DTF сидят свои модераторы и модерируют. Диктуют свободным людям, что можно писать, а что нельзя. Эх, мать Анархия приди, порядок наведи…

Однако, пройдя сам этап модерации я как-то успокоился. И пост писать не стал. Ну а мой ассет продавался там почти год. Как думаете сколько я за это время выручил? Смешные 300 долларов. Это ни в какое сравнение с айти не идет даже близко. А гемора было раз в 10 больше, чем с самыми ебанутыми заказчиками в айти секторе.

Помимо этого, не так давно, ради эксперимента, я сделал трех персонажей на CGTrader. Как думаете сколько продаж было там? Ноль. Ноль, именно так. Ну и просмотров соответственно тоже мало.

Не знаю, как там система устроена. Да и пофиг как-то стало. Однако сами модельки пригодились. И, вероятно, еще пригодятся для других задач. В каком-то смысле я ими даже горжусь.

Ход разработки игры

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

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

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

И связано все было с системой перемещения персонажей, которую я выбрал в готовом виде (не делать же самому, так я думал тогда). Система называлась — advanced locomotion и те из вас, кто знаком с Unreal Engine знают, что выглядит эта система очень хороше. Выглядит то да, а вот работает плохо. Даже на симуляцию сцены с 10 персонажами, что смешно, уходит куча ресурсов системы, а фпс падает до недопустимых значений в 40-30 кадров на моей, пусть и слабой машине. Что уж говорить о большем их количестве.

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

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

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

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

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

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

Начало разработки

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

На удивление закончил разработку системы я достаточно быстро, записав в процессе несколько видосов на свой ютуб-канал. Разработку я вел в blender’е с применением купленного еще в сытном (для меня) 2018 году плагина AutoRig Pro.

Так были сделаны анимации ходьбы: вперед, назад, вперед вправо, вперед влево, назад вправо, назад влево.

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

Аналогичную работу я провел с анимациями бега, так-же я добавил промежуточное между бегом и ходьбой состояние. которое называется Jog, гугл переводит его как «бег трусцой». И, конечно-же, перемещение в Crouch, то есть пригнувшись. Осмелев от своих успехов я даже сделал Crouch Jog, то есть бег в состоянии пригнувшись, для разнообразия. Никогда не понимал, почему разработчики скайрима, например, не добавили такую возможность в свою игру. Раз уж есть стелс, должна быть и возможность спринтовать в стелсе. Игроки сильно не любят ограничения.

Теперь о сути самих анимаций.

Все они собраны по одному паттерну из 30 фреймов. Да, 30 фреймов имеет даже бег, который обычно, судя по ассетам которые я смотрел, делают в 40-50 фреймов. По классике 1 и 30 фреймы это одно и то-же, а фрейм 15 это отзеркаливание с фрейма 1. Ну а промежуточные фреймы занимают перестановки положения ног. Разные анимации настроены на разные дистанции движения: ходьба на 1.8 метра, jog на 3 метра и бег на 4 метра.

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

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

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

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

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

Да, проект было решено писать вообще без применения с++. Где-то в интернете, то ли на DTF то ли у IXBT я читал мнение недалекого человека о том, что блюпринты проще. Дескать они легче, чем написание самого кода. Так вот: это крайне поверхностный, основанный исключительно на маркетинге, взгляд на вопрос. Каждый, кто хотя-бы пытался написать примитивную пузырьковую сортировку на блюпринтах знает это. Хотя-бы потому, что весь код приходится делать самому. С++ же запросто гуглится на Stackoverflow даже без включения мозгов. А уж учитывая то, какие возможности он открывает в подключении библиотек и использовании файловой системы для хранения данных…

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

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

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

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

Постепенно система приобрела целостный вид. Сами анимации я встроил в animation blueprint, вложив их в соответствующие state machines. Выглядит это так:

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

Итоговая производительность всей системы меня приятно удивила. Даже сейчас, с подключенным AI и с встроеннй боевкой и таргетигом(используется tick), производительность остается на крайне высоком уровне.

Специально, чтобы продемонстрировать это я добавил на сцену сто (100) персонажей. Конечно, это простые маникены, но… с таким количеством персонажей лагать начинает даже сам движок в режиме разработки.

30 кадров выдает движок. Что же будет при запуске?

19-20 кадров при запуске в редакторе, но это не самый производительный режим.

28-30 кадров в режиме standalone

Ну и если нажать на Launch и все скомпилиовать, то будет так:

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

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

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

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

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

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

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

Добавление боевки

Думаю многие из тех кто играл в игры серии Batman Arkham, Mad Max и Sleeping Dogs задавались вопросом — как именно там устроена боевая система, как работают все эти парирования и взаимодействия персонажей.

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

План был таков — начать с самого сложного и продвинуться уже в глубь расширяя возможности системы. В качестве самого сложного были выбраны анимации т.н. takedown — атаки персонажа из состояния «невидимости». Благо Crouch я уже сделал, оставалось лишь сделать хотя-бы пару анимаций парного взаимодействия персонажей. Я сделал даже три такие анимации, правда из за неопытности одну из них запрол к чертям.

Сами анимации были разбиты на «Attacker» и «Opponent» части, которые проигрывались соответственно на атакующем и получающем урон от атаки персонажах. Подобные анимации я делал впервые и… в «слепую». Ибо, очевидно, гайдов по ним в интернете просто нет. Я импровизировал на основе имеющихся знаний. Но импровизировал на столько хорошо и успешно, что даже смог собрать свой собственный сетап для анимаций, а так-же развить его. О чем тоже могу написать, но в отдельной статье, все таки тут и так уже много текста.

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

На картинке вы видите, что контролируемый игроком персонаж находится за спиной своего противника, в положении приседа. При этом угол между оппонентами составляет что-то в районе 80 градусов.

От нас требуется развернуть персонажа на эти 80 градусов, поместить его на расстоянии 1 метра от цели, после чего проиграть анимацию на обоих персонажах. Это позволит добиться совпадения и синхронизации обоих анимаций.

Обратите внимание на положение ноги, которая не проваливается, а находится именно там, где и должна.

Разработка этого вот идеального сопоставления заняла у меня порядочно времени. Пришлось ввести новые понятия типа — Direction Enum, пришлось помучаться с тригонометрией, чтобы корректно эти дирекшны распознавать. Ууу. Это невозможно просто так взять и описать.

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

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

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

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

Поэтому сначала я засел за просмотр ютуба на предмет боев. Разумеется, очевидным решением было бы взять анимации боевки из игр которыми я вдохновляюсь, в частности Batman или Mad Max, однако, посмотрев видосы с их боевками я понял, что к моей системе это не подойдет. Потому что анимации в Batman’е слишком качественные и многосложные, врятли я смогу такие сделать. Плюс сам персонаж там облачен в костюм, что … скрывает его не совсем реалистичные повороты. А у меня маникен. Если на нем я поверну какую-то кость как-то не так, все это сразу заметят.

Аналогично отпала и идея воссоздать анимаций из Mad Max. Они там слишком бешенные, слишком много бросков. Макс, буквально, дерется как рестлер. Это можно было, конечно, сделать, но учитывая проблемы с коллизиями, которые у меня были в ходе разработки анимаций takedown, я решил не рисковать. Все таки броски это через чур. И анимировать их сложно, ибо когда тело персонажа поднимается над землей, его надо как-то дергать, как-то перемещать, анимировать так, чтобы оно не казалось деревянным. А это очень сложно. Я же не специалист с 20 летним стажем рисования комиксов. Я обычный сельский парень. Ну ладно, не совсем обычный, но анимировать то я научился вот… в сентябре-октябре. Это не дело всей моей жизни.

Поэтому, потратив кучу времени в пустую, на просмотр видосов и кино с Ван Даммом, я начал делать анимации «как получается».

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

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

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

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

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

Пришлось создавать два вида комбинаций. Четыре обычных удара, и три пинка. Хотелось бы больше, но я просто не представляю как еще можно … разнообразить такую простую задачу как удар в морду. Без шуток. Ударить в морду можно снизу и сбоку. Больше бить не откуда. Если ваш оппонент стоит в боевой стойке, бить по его туловищу не эффективно ибо рука у вас туда просто не достает. К тому-же перед нами не человек, а маникен. Удары по туловищу маникена выглядят убого, я проверял, оно того не стоит. Вот и вышло у меня четыре анимации атаки в морду: на низ и бок слева, на низ и бок справа. С пинками чуть сложнее, тут я решил заморочиться, ибо пнуть мы можем как в низ торса, так и вверх, и с разворота. Так и получилось три пинка. Пинок с разворота я сделал ради эксперимента, опять-же, посмотреть, как система способна переваривать подобные сложные удары.

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

Но не атаками едиными. Вот тут то и начинается самое нудное. Ибо в итоге я сделал почти 200 анимаций(186) и основные анимации тут это импакты. Ударить левой рукой можно спереди, слева, сзади и справа. Аналогично для правой. А так-как атаки слева и справа у нас две, то и импакта надо два на каждую сторону. Думаете это все? Есть же Блок! Да, куда же нам без блока.

При блокировании персонаж поднимает руки и встает в соответствующую позицию. Урон от атак, в это время, по нему не проходит.

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

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

И уже закончив все приготовления, приступил к написанию кода.

Я добавил т.н. hit trace, то есть регистрацию попадания, добавил активный блок. добавил дополнительные состояния в animation blueprint, настроил корректное проигрывание animation montages.

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

Думали все? А вот и нет, ибо не атаками и импактами едиными жива боевка. Есть же еще анимации падения и «смерти» пораженных противников. Причем падать нам надо, опять-же, не только вперед и назад, но еще и вправо — влево.

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

А как определить, что персонаж упал набок? Как это корректно сопоставить? Ух какая задачка была. В итоге определяю положение персонажа я по вращению кости spine_1 по оси Y(вверх она на кости смотит). Работает корректно. Рагдолл периодически проваливался через пол, пришлось долго гуглить решение, потом добавлять его, проверять…

Специально для тестирования рагдолла была создана «эстакада», по котрой персонаж скатывается вниз и принимает произвольные позиции.

Так-же я сделал анимации для перекатов, просто потому что могу и потому что это очередной челлендж. Нечто вроде «а чо бы и нет». Хотя сами перекаты плохо сочетаются с написанной мной боевкой. Зато теперь они у меня есть.

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

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

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

Изначально хотел не выпендриваться и сделать обычные полоски «как у всех», но потом запилил цифровые индикаторы, которые выглядят более интересными.

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

Алый… ну я на этом цвете в данный момент остановился. Вроде видно.

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

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

Теперь уклоняться от атак может только противник. И то исключительно от каждой 4 атаки. Для разнообразия.

Вторым вариантом выхода из «окружения» было добавить откидывание персонажа вперед при ударе сбоку или сзади. И я сделал такие откидывания, взяв за основу уклонения и добавив к ним импакт и отшатывание.

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

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

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

Ух… длинная же вышла статья. Ну а что вы хотели то, собственно.

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

Заключение

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

На самом деле мне стремно, знаете… продавать эту работу. Хочется закрысить ее себе. Все таки это уникальная система и я не хочу, чтобы она попала в чужие руки.

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

Такая вот простая логика. Хотя не такая уж она и простая. Мне ведь действительно нужны деньги на разработку игры. На жизнь. И если хотя-бы 2-3 человека оплатит и купит этот проект я уже буду счастлив. Поэтому, дорогие друзья, же не манж па сис жур, подайте бедному разработчику на кусок хлеба да банку тушенки в эти тяжелые и сложные времена.

Даже если не учитывать сам код я буквально продаю 186 анимаций за 45 долларов… это 24 цента за анимацию.

Да ценник все-еще не маленький — 3 тысячи рублей, но вдумайтесь — где те люди, которые покупают Call Of Duty за 4 тысячи рублей каждый год? Я не осуждаю, я предлагаю. Нет ли у них желания прикупить реально полезную интеллектуальную собственность от своего же собрата-разработчика, отечественного, из России, а не от корпорации зла Бобби Котика.

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

Ссылка на маркетплейс для покупки.

Вы помогаете мне, я помогаю вам.

Запись Как я сделал FreeFlow боевку на Unreal Engine впервые появилась Личный блог Гарри.

Источник