Релиз демо-версии F. D. HROFT. Скачать бесплатно.

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

Forging Destiny HROFT - это средневековый экшен-платформер с элементами ролевой игры.

За время разработки игра претерпела значительные изменения в лучшую сторону - из 2D перешла в 2,5D.

Для прототипа использовали образ Рагнара

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

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

4.7K пост 19.4K подписчиков

ОБЩИЕ ПРАВИЛА:

- Уважайте чужой труд и используйте конструктивную критику

- Не занимайтесь саморекламой, пишите качественные и интересные посты

- Не употребляйте мат без необходимости

СТОИТ ПУБЛИКОВАТЬ:

- Посты о Вашей игре с историей её разработки и описанием полученного опыта

- Обучающие материалы, туториалы

- Интервью с опытными разработчиками

- Анонсы бесплатных мероприятий для разработчиков и истории их посещения;- Ваши работы, если Вы художник/композитор и хотите поделиться ими на безвозмездной основе

НЕ СТОИТ ПУБЛИКОВАТЬ:

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

- Посты, содержащие только идею игры

- Посты, единственная цель которых - набор команды для разработки игры, для этих целей больше подойдёт Discord-сервер сообщества

- Посты, не относящиеся к тематике сообщества

Подобные посты по решению администрации могут быть перемещены из сообщества в общую ленту.

ЗАПРЕЩЕНО:

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

- Выдавать чужой труд за свой

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

О РАЗМЕЩЕНИИ ССЫЛОК:

Ссылка на сторонний ресурс, связанный с игрой, допускается только при следующих условиях:

- Пост должен быть содержательным и интересным для пользователей, нести пользу для сообщества

- Ссылка должна размещаться непосредственно в начале или конце поста и только один раз

- Cсылка размещается в формате: "Страница игры в Steam: URL"

-- убирайте невозможность удара при малом количестве энергии, замените на замедление удара от количества энергии от 100% - 30% норм скорость от 30% - 10% пониженная ниже 10% вообще еле шевелится но блин не стоит ка дебил.(реализм не пострадает а во динамика останется нельзя сильно тормозить игровой процесс )

- не надо делать комбо ради комбо (это было в МК на сеге), реализуйте разнообразие ударов простыми способами.

например во так:

> = кнопка перемещения по направлению движения

< = кнопка перемещения против направления движения

дальность удара от 1 до 10 например (ДУ)

сила удара от 1 до 10 (СУ)

расход энергии от 1 до 10 (РЭ)

У = простой удар ДУ-2, СУ-2, РЭ-2

У+> = удар с выпадом ДУ-3, СУ-2. РЭ-3

У+< = удар с разворотом ДУ-2 в обе стороны, СУ-2, ДУ-2, РЭ-4

у+^ = удар снизу вверх ДУ-2, СУ-3, РЭ-4

у+v = удар сверху виз ДУ-2, СУ-3, РЭ-4

>>+У = удар с разбега ДУ-4, СУ-3, РЭ-4

еще с прыжком комбинации доделайте

ну и тд., интуитивно понятны должны быт эти вещи

если есть желание создавать длинные связки придется вначале завязать все на условия в каком находиится атакуемый предмет(враг)

>>+У (добавляем эффект отталкивания) противник в анимации отталкивания

если атакуемый в анимации отталкивания то ^+У удар снизу вверх подкинет противника и СУ будет равна СУ+2ед и так далее.

конечно тут много нюансов но этот путь интереснее.

Что касаемо картинки немного маловато видно местности и не стоит делать таким крупным масштабирование персонажа, будет меньше мороки с детальность прорисовки анимации и текстур с 3D.

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

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

Хм, по мне, и 2D было неплохо. Душевнее, что ли)

Теперь по демке:

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

- зачем мне сражаться, если я могу кувыркаться? :)

Пересмотрите подход к цветовой палитре. Реалистичная серость - это плохой выбор. За скриншоты глаз просто не цепляется. Т.е. перейдя от 2D к "3D ради 3D" вы лишь ухудшили визуальное восприятие игры. Я бы посоветовал сделать цвета насыщеннее (реальный мир он все же не серый), не впадая в противоположную крайность до мультяшного яркой картинки. Если же хочется оставить серую картинку (хотя повторюсь, реальный мир не был серым), то необходимо сильно прибавить детализации миру - мелких деталей побольше.

по первому скрину подумал, что это Blade of Darkness. Может кто сделает продолжение этой замечательной игры?

иконка со скелетом напомнила Blade of Darkness (пустил слезу от умиления)

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

А в слаке hgam постили? там есть секция на ревью

Копия "Лезьвия тьмы" ?

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

Первый скрин-90% Skyrim 5. Прям музыку в голове услышал

По первому скрину сначала подумал, что это DS II.

Новая серия игр для ZX Spectrum

Господа, приветствую Вас!Как всегда, отдельный салют моим подписчикам.Что-то я давно не писал на Пикабу, а меж тем, написать есть о чем.Во-первых, закончился международный конкурс игр для ZX Spectrum.Собственно вот результаты:

Кроме того, "Mechwars: Arena" и "Mechwars: Centipede" удостоились упоминания в легендарном британском журнале CRASH.

Кстати, вот трейлер к этой игре (это видео уже публиковал на Пикабу, но тут добавлю ещё раз для контекста):

Если, кто не видел, то вот трейлер к третьей:

Очень рад, что успел получить физические версии журналов. Думаю, что теперь это маловероятно.Кроме того, исходники игр серии "Red Raid" открыты и доступны здесь.Надеюсь, они смогут кого-то вдохновить на создание собственных игр.Кстати, о них. Все игры находятся в открытом доступе. Также, я начал сотрудничать с ZX Online. Часть игр уже опубликована также в открытом доступе (надеюсь, что в скором времени там появятся все). Желающие могут отблагодарить при скачивании игры. :)Незадолго до конца февраля я начал работать над третьей игрой в серии "Mechwars" (сюжетно она вторая).

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

Впрочем, как известно, кризис это всегда новые возможности!

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

Да пребудет с Вами сила!

Эксперимент по разработке проекта от нуля до прибыли. 2.2.Распространенные ошибки рендеринга и где они обитают

Немного теории.

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

Продолжаем серию статей о разработке нашего экспериментального проекта.

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

Алиасинг, или "Лесенки" появляются при растеризации 3D изображения в 2D картинку для вывода на экран. Каждый пиксель в картинке может быть только одного цвета, поэтому видеокарта (GPU) выбирает цвет пикселя, проецируя 3d фигуру на сетку. И, если фигура не проходит через центр пикселя на сетке - то он не окрашивается. Отсюда и появляются “лесенки” - это хорошо видно на примере растеризации треугольника.

Бороться с этим призвано сглаживание, в нашем случае - MSAA (Multisample anti-aliasing). С включенным MSAA, видеокарта (GPU) при растеризации определяет цвет пикселя, уже по нескольким точкам, а не только в центре, собирая средней цвет в конечно отображаемом пикселе, пропорциональный количеству покрытых точек.

Таким образом, для 2x MSAA проверяются две точки, чтобы увидеть, находится ли в них треугольник, а для 4x MSAA - 4 точки соответственно.

Поскольку в “мобильном” VR, на который мы ориентируемся используется тайловый GPU, при растеризации изображение разделяется на множество прямоугольных блоков - тайлов (16х16 пикселей), и процесс растеризации выполняется уже для каждого из этих маленьких тайлов параллельно, MSAA сглаживания незначительно влияет на производительность и должно быть включено ВСЕГДА. Однако это, увы, не решение всех проблем.

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

В интерьере нашего интерактивного музея будет писательский стол с лампами:

Подставка этих ламп - отполированный металл, то есть на нем образуются блики. Проблема в том, что при игре в VR - изображение НИКОГДА не бывает статическим - подергивания от сокращений мышц шеи, дрожание головы и прочие биологический факторы создают микродвижения камеры, а значит, у блестящего предмета в месте его блика, из-за таких микродвижения и особенностей тайлового рендера, снова появится пресловутая “лесенка”. В дополнение к этому мобильный MSAA не сглаживает отражения вообще, что усугубляет ситуацию еще больше.

Бликующая тонкая подставка - при таком ракурсе на расстоянии уже 2-3 метров возникает алиасинг.

Решаем этот вопрос следующими способами:

- Стараемся вообще не использовать контрастных небольших предметов по отношению к фону.

- В LODах лодируем не только сам меш, но и материал, убирая блики пока игрок не приблизится к предмету на достаточно близкое расстояние.

- Убирать блики прямо в материале предмета

- Использовать черную магию Unreal Engine - в настройках текстуры карты шероховатости (roughness) к ней можно добавить карту нормали и указать значение Composite Power. Тогда на всех кривых поверхностях, где будет супер гладкая поверхность и блики могут давать алиасинг на карте шероховатости будет добавлен белый цвет сглаживающий этот эффект.

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

Еще один пример - стол с красивой столешницей из отдельных досок:

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

Masked materials

На материалах с маской нужно примерять Alpha to coverage (включается в настройках материала). В таком случае по контуру добавляется несколько градиентных слоев (четыре при MSAAx4).

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

Итак, алиасинг на окружающей игрока геометрии устранен переходим к алиасингу текстур и материалов.

Текстурный алиасинг, как и геометрический, происходит при растрировании в 2D-сетку пикселей. Если пиксели на текстуре не совпадают с 2D-сеткой, на которую мы растеризуем, выходное изображение после растеризации будет интерполировано примерно так:

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

Multum in Parvo

Бороться с этим беспорядком нам помогает Mip Mapping.

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

Именно это делает Mip Mapping - уменьшает разрешение текстуры при удалении её от игрока.

Цветная кодировка на гифке показывает, как изменяется разрешение текстуры при удалении. Каждый уровень mip уменьшает разрешение текстуры в 2 раза. То есть если белая текстура 256х256 пикселей, то красная 128х128, желтая 64х64 и т.д.

Результат уже гораздо лучше! Но всё же идеального совпадения размера текстуры с размером сетки растеризации не достигнуть – всегда будет небольшое различие. И при растеризации определить какой будет цвет конечного пикселя при смешивании нескольких пикселей текстуры помогает фильтрация.

Применяющиеся методы фильтрации следующие:

Расстояние, на котором срабатывает переключение на следующий mip уровень, то есть разрешение текстуры уменьшается в 2 раза, можно менять. Это может понадобится, если текстура слишком “мыльная” на близком расстоянии. Или слишком “четкая” на дальнем, что приводит к алиасингу.

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

Смена расстояния срабатывания mip levels называется Mip Bias и по умолчанию он равен 0.

Параметр меньше нуля заставит GPU выбрать текстуру с более высоким разрешением на большем расстоянии, а больше нуля приведет к обратному результату. По моему опыту, смещение в -0,7, хорошо помогает детализированным текстурам сохранять четкость на больших расстояниях, без появления алиасинга, но это только примерная цифра – параметр нужно подбирать индивидуально для каждого случая.

В Unreal engine выглядит это так:

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

Основная проблема в том, что при создании 3d виджетов меню, интерактивных подсказок и всякого такого, в мобильном рендере, что к ним не применяется mipmaping, не применяется сглаживания и даже пост процесс не применяется. Поскольку текстура формируется в реальном времени и перезаписывается каждый кадр - создавать ей mip уровни довольно затратное мероприятие. Выглядит всё это примерно вот так:

Происходит здесь ровно то же самое, что и при растеризации текстур.

Методы борьбы же следующие:

1. Подобрать расстояние, с которого игрок будет смотреть на виджет:

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

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

2. Stereo Layers

Стереослои позволяют отправлять текстуру в VR композитор шлема, а не рендерить её в движке. Что даёт не только преимущество в производительности, но и композитор рендерит текстуру 1:1 - по сравнению с экраном на мобильном устройстве. То есть как раз все пиксели текстуры совпадают с сеткой растеризации! Идеально! Обязательно используйте стереослои.

Минусов же следующие - скудная документация.

При использовании ES3.1 рендера нельзя рассчитать глубину слоя - он будет всегда виден поверх всего остального, что есть на сцене. В Vulcan рендере глубину задать можно, но убирается вся прозрачность. Вообще вся.

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

С моей точки зрения стереослои - самый хороший способ.

3. Multisampling

Можно написать кастомный шейдер использующий деривативы (ddx, ddy), общая идея в том, что нужно создать блок 2x2 субпикселя, повторив в нем каждый пиксель оригинальной текстуры 4 раза создав таким образом кастомный мультисампллинг и упростив выборку для растеризации.

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

Give me the TL;DR

Если нет желания читать все буквы сверху, то вот выжимка:

- Включить 4x MSAA, это обязательно!

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

- Отключаем блики и отражения на расстоянии от игрока.

Для всех текстур:

- Включаем mipmapsВключаем trilinear filtering

- Для текстур пола и стен включаем anisotropic filtering

- На текстурах предметов повышенной четкости выставляем mipmap bias в значение -0.7

- Используем стереослои для меню и прочих 3d виджетов.

- Регулярно всё смотрим и тестируем непосредственно в VR на устройстве. Preview рендер в движке не даёт полного понимания.

Статья от Oculus (без VPN не откроется)

Блог Бена Голуса (Ben Golus)

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

Часть 0 - Поставили задачу разработать приложение с нуля до вывода прибыли.

Часть 1 - Концепт и Диздок. Создаем приложение для знакомства с творчеством Брайона Гайсина (Brion Gysin) и его Dreamachine в VR!

Часть 2.2 - Алиасинг и рендеринг

Как издать настольную игру? Кровь пот и миплы. Часть 1

Осенью 2021 года я сделал серию постов о том, как я решил запустить издательство настольных игр, как мы делали свою первую игру «Фототур», как выходили на краудфандинг. Спустя 5 месяцев после того, как мы собрали деньги на тираж, игра поступила на склад, продаётся на сайте издательства и маркетплейсах.

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

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

За механиками лучше всего обращаться к гейм-дизайнерам, которые специализируются на настольных играх. В случае с «Фототуром» я прописал подробнейший концепт, который описывал компоненты, правила, игровой процесс, после чего отдал его Юрию Ямщикову, съевшему собаку на настольных играх. На базе этого документа был сделал онлайн-прототип в Tabletopia, в котором уже содержались новые механики и усовершенствования, которые предложили гейм-дизайнеры. После тестовой партии я дал свой фидбек. И за 2-3 итерации мы вышли на итоговые механики и геймплей. Оставалось провести несколько серий тестирования, отшлифовать баланс и правила. На все про все ушло около 4-5 месяцев.

С сеттингом было всё гораздо проще. Последние 14 лет я профессионально занимался природной фотографией. Путешествовал по миру, продавал фотографии через агентства, возил людей в фототуры, преподавал. «Фототур» — это идея, которая напрашивалась. Так как игра планировалась на российский рынок, то, без сомнений, игрокам нужно было предлагать путешествовать по своей стране.

Визуальное оформление — это то, за что я сражался с полной самоотдачей. Я люблю красивые настольные игры. И для моего издательства принципиально выпускать проекты с исключительным визуалом. В работе над «Фототуром» сильно помог мой опыт фотографа. Для каждой иллюстрации в игре создавалось техническое задание художнику с 3-4 фотографиями с разных ракурсов, с разным освещением. Я подробнейшим образом расписывал как должна выглядеть иллюстрация. После первых эскизов мы добавляли цвет и детали, на каждом промежуточном этапе вносились правки. И так 50 раз (это количество карточек с достопримечательностями в игре) + 1 иллюстрация для обложки (её одну рисовали 2 недели). После того, как иллюстрации были готовы к проекту подключились графические дизайнеры. Итоговый внешний вид всех компонентов игры — их заслуга. Чтобы вы понимали объем работы, наша переписка только с дизайнерами насчитывает более 300 писем!

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

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

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

P.S. А ещё об играх я пишу в Телеграме и ВК. Подписывайтесь!

Арканоид-like с процедурной генерацией

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

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

Поэтому, когда начал осваивать Unity и одним из первых учебных проектов был как раз "Block Breaker" из учебного курса Udemy то решил потом довести проект до ума и добавить процедурную генерацию уровней. Это было в 2020, но проект я не забросил и периодически добавляю к нему новые режимы. В 2021 добавил казуальный режим, а сегодня и для этого режима добавил процедурную генерацию.

Вот небольшой трейлер сегодняшнего обновления 1.4:

А вот как выглядит процедурная генерация для обычного режима, добавленная в версии 1.1:

Процесс создания локации на UE5

Автор: Евгений Вегера

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

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

Ползу в направлении мечты. Пост № 9

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

И так, курс скажу я не плохой, но и не отличный. Он очень поверхностный с одной стороны, но с другой, если это самое начало, и ты ничего не умеешь, то этот курс “для скелета” очень даже подойдет. Но, конечно, необходимо будет изучать Unity дальше, более углубленно, чтобы использовать в будущем правильные вещи в игре. Мне повезло еще в том, что у меня имеется очень хороший наставник, который мне объяснял какие вещи, например лучше не использовать, хотя они указаны в курсе, т.к. они, например жрут много ресурсов, памяти или медленные и т.д. Ну и давал дополнительные какие то задания, вот тут и начинается настоящее обучение, когда делаешь сам, а не просто повторяешь всё по курсу. Еще в этом курсе много багов, которые автор даже убирает в каких-то уроках, но на самом деле они остаются. Как например двойной прыжок. То решение, которое он показывает, на самом деле не решает эту проблему. Но как я и говорила, курс очень поверхностный, и автор сам этого не скрывает. Из плюсов, дополнительно, автор показывает еще и мобильное управление, это не плохо.

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

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

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

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