Кодовый парусный корабль #3
Первым делом хочу выразить благодарность всем пользователям, которые давали мне годные советы, что помогло улучшить. эмм. архитектуру этого модуля, его внутренние связи и тд.
Начну с краткого пояснения: 1) Я решил отойти от модели проектирования, когда сначала писался класс на чистом языке и тд. (совет @DDeni). Изначально мне казалось что более удобно хранить информацию в виде чистых классов, потому что так просто организовать магазин, но потом подумал еще раз и понял, что мне так или иначе нужно будет хранить спрайты, иконки и прочее для организации магазина.
2) Я убрал лишние методы Instantiate() в пользу использования пула объектов (совет @HartMagic), однако, сам пул объектов не добавляю в список файлов, ибо он достаточно топорный (один класс, 2 метода, 2 переменные на все возможные объекты) и не имеет прямого отношения к теме постов (конечно, без него не получиться запустить проект просто скопировав его, но, думаю, этим никто не занимается, но при желание можно заменить метод Pop на Instantiate(), а Push на Destroy()). Сначала я думал над тем, чтобы купить уже готовый пул, но посмотрев количество файлов и скриптов в продающихся пакетах передумал.
3) Переделана модель стрельбы и пушек (совет @fon.prima). Данный раздел также затрагивает и пункт 1.
Ладно, предисловие закончилось. Начнем с рассмотрения основного класса корабля:
Изменений визуально немного. Добавлены два скрипта - shipControll, содержащий методы управления кораблем и ShipInfo, содержащий просто данные о корабле, которые ранее были вынесены в класс App.Items.Ship.Ship, ныне канувший в лета. Также лист для пуль теперь один, причины изменения в подходе к стрельбе - о ней позже.
Сразу обращу ваше внимание: все объекты, которые могут умереть (в принципе), включают в себя атрибут, который добавляет класс Shape (элемент для объектного пула). Он нужен для возврата объекта в пул и выглядит так:
Итак, рассмотрим класс управления кораблем:
Метод Move: управляет кораблем. По кнопкам W и S паруса поднимаются и опускаются (если подняты, то набор скорости идет, если нет - то убывание скорости). Также я добавил проверку на то, что если скорость больше 10 (цифра от балды), то только тогда корабль может делать повороты, ибо по логике корабль не умеет поворачивать с минимальной скоростью. Таким образом, я убрал зависимость порядка исполнения Move и Rotation, которая была в предыдущем посте.
В самом низу метода тройной тернарный оператор ограничивает максимальную и минимальную скорость корабля.
Метод Fire: тут мы по кнопке для каждой пушке в одном из листов запускаем метод Fire. Более подробно будет рассмотрено в классе Cannon.
Метод Rotation: без изменений (убрал только изменения булевой переменной moving, но об этом сказано выше).
Вот так теперь выглядит наш корабль с пушками (белые зефирки - это пушки).
А вот так выглядит движение:
Итак, перейдем к классу пушки, который, вероятно, самый занятный из всего поста:
Это первая часть класса, весь не влез.
Переменная power отвечает за силу пушки и начальный импульс снаряда.
Метод Loaded: ранее этот метод был в похожем классе, но другом. Изменения: метод стал возвращать bool ииии. все! В остальном все так же. 26 строка - берем снаряд из пула, так что не смущайтесь её внешнего вида.
Метод Fire: если пушка не заряжена, то ничего не делает. Иначе, запускает метод FireProcess и корутину перезарядки. Вот насчет правильности выбора корутины я не уверен, ибо, возможно, есть менее затратные по ресурсам методы, но в голову ничего не пришло подходящего. Если есть идея - сообщайте в комментарии, буду благодарен.
Метод FireProcess: задает полученному снаряду начальную точку, наполняет полями и дает импульс для полета. Также тут мы записываем в переменную lastFire время выстрела (нужно для перезарядки с помощью следующего метода). По поводу пули и её импульса поговорим чуть позже.
Метод Recharging: словами делает следующее: если текущее время больше времени последнего выстрела и скорость огня, то перезарядить. К слову, по профайлеру, вызов этой корутины занимает относительно много ресурсов всего 1 раз - в момент вызова.
Рассмотрим результат стрельбы из разнообразных пушек:
Вот так мы стреляем из одинаковых пушек (снаряды летят вместе, может стоит сделать небольшой заброс, чтобы снаряды вылетали с задержкой для красоты, но это скорее всего будет решено небольшим рандомным изменением силы пушек при их установке на корабль)
А вот так мы стреляем из пушек с разной силой (тут находятся позиции пуль за равное поле после выстрела). Цифрами показана сила пушки (чем меньше сила, тем более медленно летит снаряд и в целом преодолевает меньшую дистанцию)
А вот так стрельба выглядит в динамике.
Итак, перейдем к классу снаряда:
Класс снаряда: Мы сюда внесли понятие импульса, времени "пробуждения", что по сути время появления и времени жизни.
На каждый кадр пуля пересчитывает свою позицию. Отмечу, что был изменен способ изменения позиции с transform.Translate(), потому что этот метод тут не походит, так как он может изменять позицию объекта по Y, что для нашего 2д пространства недопустимо.
Также тут мы добавляем к текущей скорости импульс, умноженный на дельту времени, что является способом ускорения снаряда.
Остаток класса проверяет не закончилось ли время жизни пули и если закончилось, то возвращает её в пул.
Теперь проект имеет следующую структуру (но в гит не положил файлы, которые не имеют отношения к кораблю).
На этом все. В следующем посту мы добавим такие механики:1) получение урона кораблем;2) нанесение урона снарядами;3) возможность уничтожения корабля;
4) зависимость скорости поворота корабля от текущей скорости движенияю(в целом, я не могу полноценно сейчас придумать что еще добавить в след. пост, ибо этих позиций может быть мало.)
Всем спасибо за внимание!
Лига Разработчиков Видеоигр4.8K постов 19.7K подписчиков
Правила сообществаОБЩИЕ ПРАВИЛА:
- Уважайте чужой труд и используйте конструктивную критику
- Не занимайтесь саморекламой, пишите качественные и интересные посты
- Не употребляйте мат без необходимости
СТОИТ ПУБЛИКОВАТЬ:
- Посты о Вашей игре с историей её разработки и описанием полученного опыта
- Обучающие материалы, туториалы
- Интервью с опытными разработчиками
- Анонсы бесплатных мероприятий для разработчиков и истории их посещения;- Ваши работы, если Вы художник/композитор и хотите поделиться ими на безвозмездной основе
НЕ СТОИТ ПУБЛИКОВАТЬ:
- Только гифки/арты/скриншоты из игры. Такие материалы могут сопровождать рассказ об игре или обучающий туториал, но не должны являться основой поста
- Посты, содержащие только идею игры
- Посты, единственная цель которых - набор команды для разработки игры, для этих целей больше подойдёт Discord-сервер сообщества
- Посты, не относящиеся к тематике сообщества
Подобные посты по решению администрации могут быть перемещены из сообщества в общую ленту.
ЗАПРЕЩЕНО:
- Публиковать бессодержательные посты с рекламой Вашего проекта (см. следующий пункт), а также все прочие посты, содержащие рекламу/рекламные интеграции
- Выдавать чужой труд за свой
Подобные посты будут перемещены из сообщества в общую ленту, а их авторы по решению администрации могут быть внесены в игнор-лист сообщества.
О РАЗМЕЩЕНИИ ССЫЛОК:
Ссылка на сторонний ресурс, связанный с игрой, допускается только при следующих условиях:
- Пост должен быть содержательным и интересным для пользователей, нести пользу для сообщества
- Ссылка должна размещаться непосредственно в начале или конце поста и только один раз
- Cсылка размещается в формате: "Страница игры в Steam: URL"
Desert Strike за 4 месяца. Часть 4
Поздравляю всех с прошедшими праздниками!
Постов не было целую неделю, но это не значит что работа встала.
За неделю было сделано достаточно много. Например появился Ai у техники, появились NPC с зачатками интеллекта, система для квестов и начал появляться UI.
Со звуками пока еще полная шляпа и такая шляпа продлится еще долго(
Для системы квестов была сделана система нод.
Все спауны и команды на перемещение для NPC исходят из квеста.
NPC в свою очередь имеют немного мозгов и при встречи с врагами начинают их атаковать.
Этот небольшой квестик (на видео) сейчас выглядит вот так (ну вдруг кому интересно)
Еще чисто случайно заметив что в паке который я использую для игры все оружие модульное то было решено добавить конструктор оружия) И выглядит это все пока вот так
Посты скорее всего буду выкладывать раз в неделю чтобы было что показать. Изначальный план выдавать короткие посты раз в 2 дня провалился.
- добавить различный транспорт(20%)
- добавить ai ботам(80%)
- добавить систему квестов(20%)
- разработать и собрать ui(5%)
- сделать возможность смены транспорта(100%)
- добавить различного вооружения
- добавить возможность бегать без транспорта (80%)
- найти нормальных звуков
- добавить кастомизацию оружия(80%)
Недельный геймдев: #69 — 8 мая, 2022
Из новостей: Blender 3.2 Beta, Unity выложила руководство по 2D-арту, анимации и освещению, Движок BRender и исходники 3D Movie Maker выложили в опенсорс, подробности о технологии лицевых ригов MetaHuman Creator.
Из интересностей: советы для начинающих аниматоров от бывшего художника Blizzard, подробно про фотограмметрию от разработчиков из Rebellion, про случайные блуждания и цепи Маркова в геймдизайне.
Обновления/релизы/новости
Blender 3.2 Beta
В новой версии улучшены конвейеры анимации и оснастки, улучшены рабочие процессы моделирования и Grease Pencil, улучшена производительность узлов геометрии и многое другое. Импорт obj ускорен на порядок.
С дорожной картой 3.2 можно ознакомиться на сайте.
Движок BRender и исходники 3D Movie Maker выложили в опенсорс
Изначально на Гитхаб выложили исходники BRender, на котором были сделаны первые игры серии Carmageddon и 3D Movie Maker от Microsoft.
А чуть позже и Microsoft опубликовала в открытом доступе исходный код 3D Movie Maker после просьб в Твиттере.
Unity выложила руководство по 2D-арту, анимации и освещению
120-страничный гайд можно скачать бесплатно.Ключевые темы:
- Настройка вашего 2D-проекта
- Переключение между Unity и DCC-софтом
- Работа со спрайтами, картами нормалей и картами масок, а также сортировка слоёв
- Создание анимации и риггинг
- Настройка источников света и специальных шейдеров
Скачать можно бесплатно с сайта Unity.
Технология лицевых ригов MetaHuman Creator
В 18-страничном документе от Epic Games изложены принципы проектирования и базовая архитектура Rig Logic, лёгкого портативного солвера лицевых ригов, первоначально разработанного 3Lateral, которую Epic приобрела в 2019 году.
На консоли Playdate реализовали демосцену с рейтрейсингом — один кадр рендерится 30 минут
В симуляторе рендеринг происходит практически в реальном времени, а на самой консоли на обработку одного кадра уходит 30 минут.
TressFX 5.0 вышел как патч для Unreal Engine
TressFX 5.0, последняя версия патча TressFX UE, обеспечивает высококачественную симуляцию и визуализацию реалистичных волос и меха с использованием графического процессора.
Халява/раздачи/бандлы/курсы
Коллекция Inferno от ActionVFX и FILMPAC
9 бесплатных клипов огня, дыма, искр и горящих обломков доступны в виде 2K .mov файлов и лицензированы для использования в коммерческих проектах.
Бесплатные ассеты в Unreal Engine Marketplace за май
«Ты сам должен много играть в игры и чувствовать, что по твоему мнению клёво»: главное со стрима с Николаем Кузнецовым — создателем Despot’s Game
О создании автошахмат, которые тщательно скрывают, что они автошахматы. От проверки гипотезы на Ludum Dare, до добавления мультиплеера после заключения договора с издателем.
Если хочется обсудить, то можно это сделать в комментах на DTF.
Rebellion: подробно про фотограмметрию
Людовико Антоничелли из Rebellion, работавший над Sniper Elite, поделился эксклюзивной информацией о 3D-сканировании и создании игровых ассетов.
Советы для начинающих аниматоров от бывшего художника Blizzard
Майкл Куэвас, работавший в Blizzard, Sony Santa Monica, Obsidian, Midway Games, поделился своей мудростью и показал, как натренировать чувствительность глаз к таймингу и интервалам.
Случайные блуждания и цепи Маркова в геймдизайне
Геймдизайнер из Whalekit в статье разберет две математические концепции: цепи Маркова и случайные блуждания. Статья скорее «поп», чем «науч», поэтому часть доказательств выведенных формул опущена. После теории автор переходит к реальным кейсам, где эти инструменты могут пригодиться.
Вычислительные шейдеры в графике: размытие по Гауссу
В статье представлен первый опыт авторы по написанию вычислительного шейдера для реализации размытия по Гауссу.
Показано, как написание пиксельных шейдеров может значительно превзойти неоптимизированные вычислительные шейдеры.
Roguera: как препод рогалик на Java делал. Часть 2
Преподаватель Java в одном из московских вузов в этой части продолжил рассматривать процесс разработки рогалика. Речь в статье пойдёт в том числе о процедурной генерации комнат.
Chaos Scene Queries и Rigid Body Engine в UE5
В Unreal Engine 5.0 физический движок Chaos используется по умолчанию, заменив PhysX. Проще развивать и оптимизировать. В посте разработчики поделились бенчмарками этих движков. В разных тестах результаты сильно отличаются. Однозначного лидера нету.
Но команда в процессе улучшения движка. Посмотрим, что будет в 5.1.
Зацикленная анимация бега в Blender
3d-художник поделился советами в Твиттере.
Cascadeur 2022: улучшение анимации персонажей на основе физики
Александр Гришанин, продюсер и технический директор Cascadeur обсудил новые функции последней версии, рассказал об улучшении работы пользователей Blender и поделился планами развития компании.
Динамическое, бесшумное, рассеянное экранное глобальное освещение
В статье представлено решение для Global Illumination. Показаны четыре шага процесса и то, как объединяются отдельные результаты.
Советы для начинающих (и не очень) разработчиков на Unreal Engine
В основном статья будет полезна начинающим разработчикам, у которых уже есть небольшой опыт работы с движком (может пару месяцев или пол года).
Создание контроллера в MoI 3D, ZBrush и UE4
Робин Марианчик рассказал нам о работе над проектом TRNTL Controller, поделился инструментами, которые он использовал для ретопологии, и рассказал о том, какие настройки будут более эффективными для освещения.
Как стримеры и разработчики игр могут работать в идеальной гармонии?
Или, по крайней мере, способы не разозлить друг друга. Клара Сиа из Devolver Digital делится советами.
Производные в вычислительном шейдере
В статье показан способ вычисления производных для фильтрации текстур в вычислительных шейдерах (для затенения буфера видимости).
Стилизованная водичка, река и галька в UE5
Зимние фоточки из UE5 с Nanite и Lumen
С ArtStation Остапа Гордона.
Desert Strike за 4 месяца. Часть 3
С момента последнего поста добавил колесную технику. Реализована на колесной физике а это значит что подвеска будет отрабатывать неровности ландшафта и имитировать более реалистичное передвижение.
Игрок теперь может не только летать на своем вертолете но и забираться в свободную технику.
Ведутся работы по созданию искусственного интеллекта для вражеской техники. На текущий момент вражина научился только стрелять в приближающиеся цели.
В соответствии с требованиями отдела вертолетостроения пикабу в лице товарища @jaonai, несущий винт поменял направление вращения.
Спасибо @Setsu, партиклы в таком режиме отрисовки действительно отрисовываются корректнее.
В ближайшее время враги начнут перемещаться по карте учитывая препятствия.
- добавить различный транспорт(20%)
- добавить ai ботам(10%)
- добавить систему квестов
- разработать и собрать ui
- сделать возможность смены транспорта(100%)
- добавить различного вооружения
- добавить возможность бегать без транспорта (80%)
- найти нормальных звуков
Я не добавлял специально букву V на технику.
Desert Strike за 4 месяца. Часть 2
Прошлый пост вышел в горячие и у меня появилось целых 27 подписчиков и товарищ майор.
Этот факт не может не радовать.
Добавил в игру возможность высаживаться из вертолета это потребуется нам для смены техники и прохождения некоторых миссий. Куча анимации, блендов и инверсная кинематика и на выходе получил неплохое управление персонажем.
В ближайшее время наш персонаж научится использовать другую технику и стрелять.
- добавить различный транспорт
- добавить ai ботам
- добавить систему квестов
- разработать и собрать ui
- сделать возможность смены транспорта
- добавить различного вооружения
- добавить возможность бегать без транспорта (80%)
- найти нормальных звуков
Игровой код, который сам себя программирует
На сегодняшний день у меня выпущены четыре игры в Steam, и все они написаны на языке Haxe. Мне нравится по-максимуму автоматизировать свою работу, и сегодня я поделюсь некоторыми приёмами, которые я использую при программировании своих игр.
Для непосвящённых: Haxe — это язык программирования и кросс-компилятор. Это значит, что можно написать игру на Haxe, и она автоматически "переводится" на другой язык программирования, в зависимости от выбранной платформы (C++ для Windows, JavaScript для Web, и т.д.), и компилируется в нативную программу для той платформы.
У языка есть несколько полезных функций метапрограммирования, которые используются для написания кода, который, грубо говоря, сам себя меняет. Эта статья — не туториал и не руководство, а просто несколько примеров того, как такие приёмы могут быть использованы в разработке компьютерных игр.
Кстати, некоторые из этих функций есть и в других языках, но могут называться по-другому. Так что эти идеи могут пригодиться не только тем, кто пишет на Haxe.
Это, вероятно, самый простой способ, как можно повлиять на процесс сборки. Есть возможность выборочно компилировать куски кода, используя флаги компилятора.
Например, при разработке игр я всегда пользуюсь собственным редактором уровней, который встроен в саму игру. За исключением игры Speebot, этот редактор доступен только мне, и не включён в конечную сборку, которую запускает игрок. Это достигается "заворачиванием" всего кода, что связан с редактором, в условие, которое проверяет наличие флага "dev" при компиляции. Если флага нет — редактор "стирается" из исходного кода перед нативной компиляцией игры.
Встроенный редактор уровней в игре Пайли, который доступен только в режиме разработки.
Эта функция также позволяет мне отделять ресурсы для "demo" и "prod" версий. Демо версии моих игр включают в себя несколько уровней игры, и я использую флаги компилятора, чтобы определить, какие уровни, файлы музыки и т.д. нужно включить в сборку. Так неиспользуемые ресурсы просто не попадают в демо версии.
Кроме того, я использую флаги компиляции для включения или выключения некоторой оптимизации в моём игровом движке. Например, объединение 3D объектов в общую модель не используется в режиме разработки, потому что оно только мешает во время редактирования уровней. Другими словами, движок оптимизируется для редактирования уровней в режиме разработки. В финальных билдах — движок оптимизирован для самого игрового процесса.
В Haxe есть функции metadata, которые могут быть использованы для аннотации, чтения и манипуляции частей исходного кода, который обычно не доступен.
В моём случае, есть класс Settings, в котором есть набор переменных для опций, доступных игроку в меню Опции. Настройки пользователя хранятся в отдельном файле. Этот файл генерируется автоматически на основе класса Settings. Движок бежит по всем переменным класса, и сохраняет или загружает значения из файла. Для этого используется reflection API.
Не все переменные в Settings нужно сохранять в файле, так как там есть и константы, которые менять не нужно. Такие поля помечаются мета тэгом "@ignore(true)". Движок, видя эту аннотацию, не включает такое поле в файл.
Это самая сложная и самая интересная функция метапрограммирования в Haxe. Macro позволяют запускать реальный Haxe код во время компиляции, который может напрямую модифицировать исходный код игры.
Самое простое применения этому: добавления времени компиляции и номера сборки. Эта информация у меня используется вместо номеров версий. Она всегда обновляется автоматически, поэтому мне не нужно вручную увеличивать какие-то версии.
Но самый большой плюс для меня — это возможность переместить код из run-time в compile-time.
В игре Speebot есть меню выбора уровней, которое показывает, сколько в каждом уровне кристаллов, которые игрок может собрать. Чтобы посчитать количество кристаллов в уровне, игра должна загрузить файл уровня, обработать его, посчитать кристаллы, и выдать число.
Эта логика работает нормально до тех пор, пока не становится необходимо показать эту информацию для 200 уровней одновременно. Игре необходимо загрузить и обработать 200 файлов уровней, что использует много памяти и реально тормозит игру на несколько секунд.
Всего 4 мира, в каждом по 50 уровней. Процент прохождения высчитывается на основе количества пройденных уровней и собранных кристаллов в каждом уровне данного мира.
Конечно, я мог бы вручную посчитать все кристаллы и прописать количества в исходном коде игры, но мне лень. Кроме того, могут появиться ошибки, если я отредактирую уровень и забуду поменять число.
Решение: написать макро, которое загружает все 200 уровней (у макро есть доступ к файловой системе), обрабатывает все необходимые данные, и сохраняет нужные числа в массивы. Игре больше не нужно ничего вычислять в run-time, потому что вся информация на этот момент уже жёстко прописана в исходном коде игры с помощью макро.
Такой же подход используется в игре Путь Фантома. Игрок может найти артефакт, который показывает количество пропущенных секретов, сокровищ, записок и т.д. в каждой области игры на карте. Вместо того, чтобы загружать и обрабатывать информацию всех областей игры в run-time, это происходит в момент компиляции с помощью макро.
Так, полностью пропадает зависание игры при просмотре карты. Кроме того, игра использует меньше памяти, так как не нужно подгружать все уровни сразу.
Недельный геймдев: #68 — 1 мая, 2022
Из новостей: Modo 16.0, Substance 3D Stager 1.2, Substance 3D Designer 12.1 с поддержкой USD, Redshift теперь поддерживает AMD Radeon PRO в Windows.
Из интересностей: о том как устроена экономика видеоигр, про создание персонажей для Dying Light 2 Stay Human, как в DOOM Eternal изменили Push Forward боёвку, эволюция машин в Horizon Forbidden West.
Windows Graphics News: первый квартал 2022
Дайджест материалов/новостей за этот период: приложение Windows HDR calibration, публичный релиз DirectStorage, OpenGL приложения теперь работают на ARM и многое другое.
В новой версии переосмыслили дерево шейдеров, добавили Wrap Effector, предлагающий единый простой метод интеллектуального и эффективного управления сложными мешами. И более 20 новых функций.
Substance 3D Designer 12.1 с поддержкой USD
Обновление также добавляет Substance material graph, в том числе новый набор инструментов для создания 3D-текстур и новые 2D- и 3D-шумы.
В Roblox появился инструмент для создания одежды для любого типа телосложения
Система делает одежду и аксессуары подходящими для любого аватара.
Вышел Substance 3D Stager 1.2
Обновление добавляет новую панель материалов для управления материалами сцены и улучшает качество режима рендеринга в реальном времени, который теперь поддерживает тени от освещения окружения.
Redshift теперь поддерживает AMD Radeon PRO в Windows
Поддержка в настоящее время пока только в закрытой предварительной версии, и разработка активно продолжается.
Epic Games запустила новую программу по изучению виртуального производства
Unreal Connectors, новая программа обучения навыкам виртуального производства, предоставит сокращённую версию Unreal Fellowship, которая впервые была запущена в июле 2020 года и призвана помочь специалистам в области кино, анимации и визуальных эффектов изучить Unreal Engine.
Халява/раздачи/бандлы/курсы
Kitbash от Алексея Ванжулы для Houdini
Алексей выпустил Kitbash для Houdini, бесплатную библиотеку компонентов, таких как гайки, винты и трубы, предназначенные для упрощения процесса проектирования сложных механических моделей в Houdini.
Библиотека ранее была частью Modeler for Houdini, но теперь выделена отдельно.
Интересные статьи/видео
Как устроена экономика видеоигр
В видео рассмотрено, как устроена типичная игровая экономика, и как ресурсы перемещаются по системе. По ходу дела автор показывает, как эти экономические объекты можно использовать для создания интересного игрового процесса для игрока. Приведены возможные способы решения проблем.
Создание персонажей для Dying Light 2 Stay Human
Разработчики Dying Light 2 рассказали о дизайне главных персонажей и второстепенных NPC, а также поделились мыслями про анимации.
Как искать работу Junior Unity Developer на удалёнку
Автор статьи рассказал какие были ТЗ, что спрашивали на собеседовании, какой был фидбек и почему его до сих пор не взяли. Помимо самой статьи ещё интересно будет почитать комментарии.
Отличный тред про меши и топологию
От разработчика, который работал над Dragonage, Civ IV, God of War, Stellaris и другими играми.
Как в DOOM Eternal изменили Push Forward боёвку
После своего славного возрождения в 2016 году DOOM Eternal выводит франшизу на новую территорию. В видео рассмотрено, какие же большие изменения как в хорошую, так и в плохую сторону произошли.
Эволюция машин в Horizon Forbidden West
Разработчики из Guerrilla Games обсудили ключевые обновления, которые команда сделала для роботов Horizon Forbidden West, подробно описав, какие приёмы они использовали, чтобы убедиться, что машины работают, и определить, какие ключевые механики нужно обновить.
Документалка в честь 10-летия The Walking Dead
Skybound Games выпустили новый мини-документальный фильм, в котором представлены различные закулисные события, в том числе ранние кадры прототипа и даже раскрыли то, что определяющее жанр приключение Telltales в какой-то момент планировалось стать спин-оффом Left 4 Dead.
Настройка показателей производительности в Unity Profiler
Оптимизация игр требует возможности точного измерения того, как ваш проект потребляет аппаратные ресурсы. Дополнение Unity Profiler собственными показателями производительности позволит вам лучше понять уникальную историю производительности вашего приложения. В посте команда Unity рассказывает о новых функциях расширения Profiler в Unity 2021 LTS.
Как в рисунке сделать эффектный переход между светом и тенью
Замечали приём, когда художники добавляют на границе света и тени яркий цветовой переход? Иллюстратор из Disney Марко Буччи показывает, как добавить своим картинам живости подобным образом.
Какой взять тексель и сколько текстурных групп?
Плотность текселя показывает сколько пикселей будет содержать размерная единица модели px/см. Чем больше значение, тем больше пикселей будет выделено на отрисовку деталей, соответственно тем выше качество картинки. Обратной стороной высокого качества является высокий вес текстур, и как следствие движок будет дольше просчитывать отрисовку. Чтобы вес текстур не был лишним, значение TD надо подбирать.
Как Cookie Run приносит колоссальный доход создателям
С момента запуска в начале 2021 года Cookie Run: Kingdom заработала четверть миллиарда долларов при всего 22 миллионах загрузок. Cookie Run отличается от многих азиатских игр. Только 50% всей выручки приходится на Южную Корею, и игра завоевала значительную популярность на ключевых западных рынках.
Аавторы Deconstructor of Fun решили подробно разобрать эту игру.
Адаптация анимации Lyra к вашей игре UE5
Системы анимации в новом бесплатном примере проекта Lyra Starter Game демонстрируют текущее состояние того, как Epic Games создаёт игры на Unreal Engine 5. Статья в блоге познакомит с инструментами и подходом, которые использовались для превращения анимации движения из Fortnite и Paragon, в анимацию как в The Matrix Awakens: An Unreal Engine 5 Experience.
Интервью с геймдизайнером Loop Hero: о финансах, работе с Devolver Digital, отзывах игроков
Много полезной информации для новичков: про взаимодействие с издателем, о маркетинговых уловках.
Искусственный интеллект в DOOM (1993)
DOOM — одна из самых важных игр всех времён. А ИИ, стоящий за ней, сейчас так же впечатляет, как и почти 30 лет назад. В видео автор канала рассказывает, как всё это работает.
Прекрасный фанарт JINX
Разработчик RujiK показал систему, которая позволяет разводить монстров и создавать множество новых вариаций.
Desert Strike за 4 месяца
Так как под моим комментарием на пикабу появились заинтересованные люди (@Mortes84, @buzzeiro, ). То как и обещал попробую сделать Desert Strike на Unity за 4 месяца.
Первая поблема с которой пришлось сталкнуться это политика из-за которой нет возможности оплатить выбранные паки. Покапавшись в аккаунте и фришных асетах удалось найти замену почти для всего кроме одного пака.
Покалдовав над ними пару дней и накидав базовую архетектуру проекта получилось что-то такое.
- добавить различный транспорт
- добавить ai ботам
- добавить систему квестов
- разработать и собрать ui
- сделать возможность смены транспорта
- добавить различного вооружения
- добавить возможность бегать без транспорта
- найти нормальных звуков
В целом за 4 месяца вполне реально)
Проектирование юнитов в Citizens: Far Lands
Привет всем. Прежде всего, я приношу извинения за проблемы с этим текстом. Я пользуюсь Яндекс-переводчиком :)
Я подумал, что было бы неплохо написать небольшой пост о механике нашей боевой системы в Citizens: Far Lands. Его разработка заняла некоторое время, и он прошел капитальный ремонт, поэтому я думаю, что уроками, которые я извлек из него, можно было бы поделиться с более широким сообществом для общего блага :)
Для тех из вас, кто не увлекается программированием, я постарался сделать это легко. Возможно, вам все еще будет интересно посмотреть, как все это работает "изнутри".
Изначально боевая система в Citizens начиналась как пошаговая система. С самого начала он был написан так, чтобы его можно было использовать как можно чаще. Хотя я не очень хороший программист, я стараюсь делать свои системы похожими на плагины: что-то, что я могу просто легко добавлять и удалять из программы, над которой я работаю.
Первоначально основными требованиями были:
- Несколько солдат (назовем их подразделениями) должны двигаться вместе, как единое целое. Мы будем называть эти "Флаги".
- Каждый флаг имеет статистику, которая всегда одинакова, а некоторые из них увеличиваются или уменьшаются с каждым подразделением в блоке. Например, урон должен быть увеличен, когда есть больше субъединиц, и должен уменьшаться по мере их смерти.
- У каждого подразделения есть свой собственный аниматор, они должны иметь возможность двигаться, атаковать, умирать и бездействовать
Я начал с разработки базового компонента, называемого "Единичный объект". Это был объект с возможностью написания сценариев, который определял, что такое единица измерения, как она называется, какую статистику она имеет и так далее. Со временем он будет расти, чтобы получить дополнительные параметры, но я начал с некоторых простых, таких как здоровье и урон.
Здесь вы можете увидеть результат и. Вот как мы определяем "Лучника". Есть некоторые дополнительные необязательные параметры, которые оставлены пустыми (например, юниты могут иметь уникальные носители баннеров). Если юнит бросает ракеты, мы тоже можем указать их (стрелы, топоры, гигантские цыплята . ). Важный список, на который следует обратить внимание, - это "Ключевые слова". Позаимствовав идею из настольных стратегических игр (kings of war, warhammer), мы определяем, что такое юнит, задавая ему набор строк. "Ракета", "Пехота", "Кавалерия" и так далее. Таким образом, мы также можем добавить модификаторы "защита" и "атака", которые основаны на указанных ключевых словах. Мы обсудим это позже.
Скриптовые объекты хороши тем, что они предоставляют дизайнеру визуальный интерфейс, позволяющий быстро и легко изменять статистику юнитов. Если бы мы пытались сделать игру модифицируемой (так что, в принципе, если бы мы писали ее снова :) ), я бы, вероятно, сделал что-то вроде этого, но конечный результат был бы преобразован в XML-файл, считываемый из потоковых ресурсов.
Следующая часть - это подразделение. Подразделение - это сборный модуль, который определяет отдельного солдата. У него есть своя сетка, аниматор и компоненты, необходимые для его работы.
Компонент SubUnit содержит в основном данные и несколько вспомогательных методов. Большая его часть заполняется во время выполнения менеджером сражений (родительский флаг, отряд, якорь и так далее). В нем есть несколько основных элементов управления для анимации, таких как "перемещение", "бездействие", "смерть" и "атака". Компонент анимации солдата - это, по сути, оболочка для аниматора. Он обеспечивает немного более дружественный интерфейс.
Чем полезна солдатская анимация:
Последним и наиболее важным компонентом является компонент "Флаг". Компонент Flag содержит все методы и параметры, с которыми постоянно взаимодействует менеджер сражений. Поскольку мы ленивы, мы используем встроенный агент Navmesh от Unity для перемещения войск. Флаг обнаруживает свое собственное движение и сообщает всем своим подразделениям: "Эй, я сейчас двигаюсь, воспроизведите анимацию перемещения". Флаги могут увеличивать и уменьшать количество активных субъединиц, поэтому нам тоже нужны методы для них. Каждая добавляемая нами субъединица увеличивает здоровье и урон, но оставляет некоторые другие статистические данные, такие как скорость передвижения или скорость атаки, неизменными. Всякий раз, когда субъединица умирает, они уменьшаются.
Поскольку мы отошли от пошаговой системы, атака ведется в режиме реального времени. Есть простой таймер, который отсчитывает время, чтобы проверить, достаточно ли времени прошло между атаками, чтобы можно было провести еще одну. Когда таймер истечет, юнит попытается атаковать выбранную цель. В выборе целей есть определенная логика, но для этого потребуется собственный длинный пост.
Итак, атаки! Помните ключевые слова, которые я упоминал? Нанесение урона само по себе довольно просто. По сути, мы просто убираем количество урона от здоровья флага, но есть уменьшение и усиление урона. Отряд копейщиков может получить 50% бонус к атаке против ключевого слова "Кавалерия". Юниты, стоящие в лесу, могут получить 50% бонус к защите от ключевого слова "Ракета". Модификаторы местности также могут внести большой вклад! Мы можем влиять на дальность, скорость юнита, усиление урона, уменьшение урона, скорость атаки. всякие вещи.
В целом, система работает довольно хорошо. Если у вас есть правильные анимации и сетки, дизайнер может настроить новый, полностью функционирующий модуль за несколько минут. Я надеюсь, вам понравился этот маленький дневник разработчика, и, возможно, он натолкнул вас на некоторые идеи, если вы работаете над своим собственным материалом.
Наш следующий дневник разработчиков будет посвящен искусственному интеллекту и самим полям сражений!
Капитал - стратегии революции
Когда я начинал разработку проекта Капитал: Искры Революции, я совершенно не представлял, во что все это выльется и какой получится игра. В конце концов, классовая борьба - штука абстрактная, и каждый представляет ее по своему. И вот, спустя три с половиной года разработки, ответ найден!
В вашем городе живет три класса: дворяне, буржуи и работяги. Каждый из них играет важную роль в экономике: дворяне - работают в администрации, буржуи - занимаются торговлей, рабочие - вкалывают на заводах. Все эти роли важны для развития города. Но имеющихся ресурсов слишком мало, и на всех не хватает. Тем более, что классы недолюбливают друг друга. Поможешь одному - обидишь других. А кризис все усиливается: аварии, эпидемии, конфликты… Только продуманная стратегия может спасти город от погружения в анархию.
Чтобы преодолеть разруху, придется не только затянуть пояса, но и засучить рукава. Ускоренная модернизация - вот что спасет отечество! Все на ударные стройки новой жизни! Чем быстрее будет развиваться экономика, тем скорее общество достигнет эры благополучия и процветания. Однако дожить до этого смогут не все. Ведь при ускоренном росте не остается денег на поддержание социальной среды. Очереди из голодающих, высокая преступность, трупы на улицах - цена опережающего развития высока. Хорошо, что поток мигрантов не иссякает и город не останется без рабочих рук.
Впрочем, есть и другой путь. Жизнь каждого человека - бесценна! Поэтому ресурсы следует направить на развитие социальной сферы - обеспечить людей продовольствием и жильем. Вкладывать средства в борьбу с преступностью и развитие медицины. Но ждать экономического чуда с такой политикой не приходится. Развитие будет мучительно долгим, а цена ошибки - высокой. Придется устанавливать ограничение на приток новых жителей - в уютном и безопасном городке нет места для всех. К тому же ошибка или случайность может разрушить хрупкое равновесие и ввергнуть город в пучину кризиса.
Какая из этих стратегий правильная - решать вам. На карту поставлено выживание вашего народа. Впрочем, не исключено, что вы найдете свой собственный путь и ваше будущее будет по-настоящему светлым.
Релиз игры в Steam, GOG и Epic Store состоится 28 апреля. Присоединяйтесь к революции!
Этот момент, когда…
Программирование и стаж
Так и живем
Как я создаю игры на своём 3D движке в одиночку
Много лет назад я занимался созданием маленьких Flash игр и публиковал их на сайте Newgrounds. Сейчас я делаю полноценные игры для ПК.
На сегодняшний день у меня 4 законченных коммерческих игр в Steam, и самая последняя из них — выпущенная в 2021 году Pilie Pals, о процессе создания которой я расскажу в этой статье. Я работал над игрой всего примерно 6 месяцев, по вечерам после работы и на выходных.
Оригинал статьи на моём сайте, с ссылками на другие связанные статьи: https://kircode.com/ru/post/how-i-make-games-in-my-own-3d-ga.
Pilie Pals — это игра-головоломка, в которой игрок возглавляет группу милых существ, способных складывать в стопки и носить разные предметы, и даже друг друга.
Я занимаюсь дизайном, программированием, графикой, звуками и музыкой в одиночку. Мне это нравится, и таким образом я могу часто переключаться с одного вида деятельности на другой, благодаря чему не теряю интерес к разработке игры.
Я написал собственный 3D игровой движок YUME, используя Haxe, C++ и OpenGL, и на данный момент он используется тремя моими играми. Подробности и причины создания собственного движка приведены в отдельной статье (подробности на сайте). Такой подход меня вполне удовлетворяет, и я не планирую его менять.
Разработка Pilie Pals
В начале разработки Pilie Pals я скопировал папку проекта своей предыдущей игры Phantom Path и удалил все ресурсы и файлы кода, связанные с игрой. Остался "чистый" движок, с которым можно экспериментировать, чтобы создать прототип следующей игры.
Перед тем, как описывать создание Pilie Pals, я объясню несколько главных принципов работы моего движка.
Хранение игровых данных в текстовых файлах
Мой движок почти полностью основывается на внешних данных (data-driven). Это значит, что я создаю набор файлов с данными, а движок их читает и обрабатывает.
Я стараюсь избегать жёсткого прописывания чего-либо в исходном коде игры. По возможности, вся информация хранится в отдельных файлах: игровые объекты, уровни, переводы текстов, визуальные и звуковые эффекты, и даже некоторая игровая логика, написанная на собственном языке сценариев YumeScript (подробности на сайте). Большая часть данных хранится в формате JSON.
Самое большое преимущество такого подхода заключается в том, что я могу создавать и править игру, не выходя из неё. При изменении какого-либо файла с данными движок автоматически перегружает ту часть данных, которая изменилась, без необходимости перезапускать или пересобирать что-то вручную. То же самое происходит с другими ресурсами, например, с текстурами, 3D моделями и звуками.
Ещё один плюс — это потенциальная поддержка пользовательских модификаций игры. Для Pilie Pals это не так актуально, но это область, которую я хотел бы изучить в будущем.
Два главных компонента сцены игры в моём движке — это сущности и карты.
Сущность — игровой объект, который я описываю в JSON файле, чтобы впредь создавать экземпляры объектов такого вида. Например, персонаж игрока — это сущность.
Файл описания сущности содержит информацию:
- Какие 3D модели содержит данная сущность, и как их отображать
- Какие анимации могут совершать модели этой сущности, и как осуществляются переходы из одного состояния в другое
- Какие эффекты может запускать данная сущность
- Какие звуки может воспроизводить данная сущность
- Какие области соприкосновения есть у данной сущности
- Какие у сущности могут быть состояния, и каково поведение сущности в разных состояниях
- Другие данные для использования в игровой логике: специальные тэги, группы, и т.д.
Каждый персонаж, дерево, ящик, элемент игры и декораций — это отдельная сущность.
Стоит отметить, что у каждого экземпляра сущности есть собственная машина состояний, и у каждого состояния есть последовательность действий, которую сущность может проигрывать.
Например, можно задать состояние "walk" (ходьба) для сущности персонажа игры, и последовательность действий этого состояния может содержать команды, которые запускают нужную анимацию 3D модели, проигрывают звуки шагов и показывают эффект поднимающийся с земли пыли. Всё это описывается в текстовом файле, который можно редактировать и сразу тестировать, и это сильно ускоряет процесс разработки.
Карта — это файл данных, который содержит описание расположения сущностей. В этом файле также есть многоуровневая сетка "плиток", из которой можно построить ландшафт. Я не меняю файлы карт вручную — карты создаются с помощью встроенного редактора.
Так как движок знает всю информацию о сущностях, которые располагаются на карте, он в состоянии автоматически оптимизировать некоторые вещи. Например, если сущность является статичной и никогда не двигается (например, дерево или ландшафт), то движок автоматически объединяет её вместе с другими статичными сущностями, которые используют одинаковую текстуру, и создаёт одну общую 3D модель. Это значительно сокращает количество отображаемых видеокартой объектов, что сильно улучшает производительность игры.
Игровая логика
Некоторая часть игровой логики может быть описана в текстовых файлах, но она используется только для создания игровых сценариев, а не основной функциональности игры. Такая логика, как система соприкосновений, поведения искусственного интеллекта, правила игрового процесса и т.д. — программируется в исходном коде Haxe, который превращается в C++ при компиляции.
Есть 2 категории файлов кода, связанных с логикой:
- Процессоры логики сущностей — могут быть присоединены к отдельным сущностям, используются для обработки индивидуальной логики объектов (например, искусственного интеллекта). Не каждой сущности нужен процессор логики
- Ядро — одиночный класс, который описывает общую логику правил игрового процесса.
Первый месяц: Прототип
У меня была идея о пошаговой игре-головоломке, в которой игрок может управлять сразу несколькими персонажами, способными поднимать и переносить всякие предметы. Логика игры должна была быть пошаговой, потому что я хотел записывать каждый игровой шаг, чтобы дать игроку возможность отменить свои шаги, т.е. вернуться в прошлое.
Сначала я написал ядро логики и реализовал пошаговую систему. Для каждой сущности, которая является частью головоломки, ядро выставляет состояние.
Игрок может выделить персонажа и выполнить действие (например, переместиться, или поднять предмет), которое меняет состояние игрового мира. Игра потом вычисляет, является ли возможным новое состояние мира (например, не столкнулся ли игрок с препятствием), и проверяет, нужна ли какая-либо реакция на это изменение, со стороны других элементов головоломки (например, если игрок положил какой-то предмет на кнопку, то у кнопки должно измениться состояние на "нажатая"). Если все проверки пройдены, то изменения применяются и добавляются в историю шагов.
Игрок может отменить последний шаг, просто вернувшись в предыдущее состояние мира.
В этом заключается основная функциональность игрового ядра. На самом деле, всё немного сложнее, потому что мне нужно обеспечить плавные, анимированные переходы между состояниями, позволить элементам быть переносимыми другими элементами, и делать другие интересные вещи — но всё это добавляется к базовому "фундаменту" логики игры.
Реализация такой системы и всех крайностей заняла у меня примерно неделю. Оставшееся время заняли размышления о том, какую игру я хочу сделать. В это время у меня появилась идея о том, что персонажи могли бы переносить других персонажей, и даже создавать стопки из друг друга.
Я создал 4 уровня игры, используя мой существующий редактор карт, чтобы убедиться, что игровой процесс действительно интересный. Результат мне понравился, и я продолжил разработку.
Второй месяц: Графика
Теперь у меня был рабочий прототип игры, и можно было начинать экспериментировать с художественными стилями. Я остановился на мультяшном визуальном стиле, и весь месяц занимался созданием 3D моделей, анимаций, эффектов, интерфейса, переходами, и т.д. Игра разбита на 5 тематических миров.
Я использую Blender для создания 3D моделей и анимаций, и GIMP для создания текстур.
Пластиковый вид игры достигнут с помощью написанного мною шейдера, который применяет заранее приготовленные данные об освещении к моделям. Работает это так: берётся заготовленная картинка освещённой сферы, применяется к некоторым частям модели, смешивая цветовые данные текстуры на основе нормалей модели в пространстве экрана.
Идея такого эффекта появилась у меня после работы с программами 3D моделирования и скульптуры. Подобный эффект в таких программах иногда называется MatCap. Мой подход заключается в том, что я смешиваю такой приём с традиционными алгоритмами освещения в реальном времени. Получается интересный эффект, который обрабатывается видеокартой очень быстро.
До и после применения предварительно "запечённых" данных освещения к моделям.
Третий месяц: Полировка
Весь месяц я улучшал User Experience игры: добивался плавности анимаций, хорошей чувствительности управления, чистоты графических элементов, удобности интерфейса.
Было реализовано меню паузы, меню выбора уровня, система последовательности уровней и системы сохранения — практически весь этот функционал у меня уже был создан для предыдущих игр, поэтому можно было повторно использовать часть этого кода, откорректировав некоторые визуальные вещи.
Работать над интерфейсами довольно утомительно, но плохой UX раздражает игроков, поэтому важно сделать всё правильно с самого начала.
Я решил сделать отполированный, полноценный "вертикальный срез" как можно быстрее. Таким образом я смог бы проверить, как бы выглядел готовый проект. Так как в игре на тот момент было мало контента, можно было свободно вносить глобальные изменения без особых проблем.
Четвёртый месяц: Музыка, звуки и демо версия
Я пишу музыку и создаю звуки в виртуальном модульном синтезаторе SunVox. Я — самоучка, и создание музыки у меня занимает довольно много времени.
В моём движке есть система динамического звукового окружения, которая может генерировать окружающий шум в реальном времени, используя подготовленные звуки (например, шум волн или крики птиц), меняя их частоту и воспроизводя в разных направлениях и в разных комбинациях. Эта информация описана в отдельном JSON файле.
На тот момент у меня была полностью "отполированная" игра, в которой было всего 4 уровня. Я создал ещё 6, и выпустил демо версию игры.
Так я стал собирать отзывы от игроков на ранней стадии разработки, и смог на их основе улучшить User Experience игры.
Примерно в это время я добавил систему подсказок в игру. О ней я подробно написал в отдельной статье (подробности на сайте).
Пятый и шестой месяцы: Контент игры
Следующие два месяца я делал новые уровни, добавлял новые игровые элементы, используя ту систему сущностей, которую я описал выше. В исходном коде игры уже практически не было никаких изменений, потому что ядро игры уже было полностью готово.
Эти два месяца я в основном работал в редакторе карт.
В целом я удовлетворён результатом.
В начале разработки игры у меня уже было довольно чёткое представление о том, какую игру я хочу сделать. Поэтому процесс разработки прошёл намного плавнее и быстрее, чем обычно. Так я осознал важность наличия чёткой цели с самого начала.
Также оказалось хорошей идеей сделать отполированный вертикальный срез как можно скорее. Таким образом, я мог начать делать скриншоты, видео и даже выложить демо версию хорошего качества всего после 4 месяцев работы. Я получил несколько полезных отзывов от игроков ещё до того, как большая часть контента была готова, поэтому было проще вносить изменения, ничего при этом не ломая.
В этот раз я практически ничего не менял в ядре своего движка, и большая часть времени ушла непосредственно на создание игрового контента. Я буду продолжать использовать свой движок в будущих проектах.
«Так, падажжи, ёклмн»
У тебя тут ошибка
Новая серия игр для ZX Spectrum
Господа, приветствую Вас!Как всегда, отдельный салют моим подписчикам.Что-то я давно не писал на Пикабу, а меж тем, написать есть о чем.Во-первых, закончился международный конкурс игр для ZX Spectrum.Собственно вот результаты:
Кроме того, "Mechwars: Arena" и "Mechwars: Centipede" удостоились упоминания в легендарном британском журнале CRASH.
Кстати, вот трейлер к этой игре (это видео уже публиковал на Пикабу, но тут добавлю ещё раз для контекста):
Если, кто не видел, то вот трейлер к третьей:
Очень рад, что успел получить физические версии журналов. Думаю, что теперь это маловероятно.Кроме того, исходники игр серии "Red Raid" открыты и доступны здесь.Надеюсь, они смогут кого-то вдохновить на создание собственных игр.Кстати, о них. Все игры находятся в открытом доступе. Также, я начал сотрудничать с ZX Online. Часть игр уже опубликована также в открытом доступе (надеюсь, что в скором времени там появятся все). Желающие могут отблагодарить при скачивании игры. :)Незадолго до конца февраля я начал работать над третьей игрой в серии "Mechwars" (сюжетно она вторая).
Однако, пока я вынужден притормозить разработку.Один из моих контрактов заморожен, поскольку компания не уверена в том, что может себе позволить развивать проект в нынешних условиях. Второй, пока ещё, жив. :)
Впрочем, как известно, кризис это всегда новые возможности!
В данный момент, я почти закончил разработку софта для автоматического распознавания документов на основе входящих электронных писем, или файлов сетевой папки, с последующей сортировкой по категориям, перенаправлению сотрудникам, поиску по содержимому, и многое другое. Поддерживается множество форматов, включая архивы. Надеюсь выпустить первую версию к концу апреля, но об этом как-нибудь в другой раз.
Да пребудет с Вами сила!
Ползу в направлении мечты. Пост № 9
Всем привет, дорогие Пикабушники. Прошел еще месяц и как обещала, выкладываю видео игры, которая получилась по итогу. Это не полноценная игра, это проект, который я делала, обучаясь на Udemy. Вот само видео, после него будет небольшой обзор самого курса и того, чему научилась, ну и планы на будущее.
И так, курс скажу я не плохой, но и не отличный. Он очень поверхностный с одной стороны, но с другой, если это самое начало, и ты ничего не умеешь, то этот курс “для скелета” очень даже подойдет. Но, конечно, необходимо будет изучать Unity дальше, более углубленно, чтобы использовать в будущем правильные вещи в игре. Мне повезло еще в том, что у меня имеется очень хороший наставник, который мне объяснял какие вещи, например лучше не использовать, хотя они указаны в курсе, т.к. они, например жрут много ресурсов, памяти или медленные и т.д. Ну и давал дополнительные какие то задания, вот тут и начинается настоящее обучение, когда делаешь сам, а не просто повторяешь всё по курсу. Еще в этом курсе много багов, которые автор даже убирает в каких-то уроках, но на самом деле они остаются. Как например двойной прыжок. То решение, которое он показывает, на самом деле не решает эту проблему. Но как я и говорила, курс очень поверхностный, и автор сам этого не скрывает. Из плюсов, дополнительно, автор показывает еще и мобильное управление, это не плохо.
И так, в этом курсе я поняла, как работать с камерой, создавать персонажа, как работать с ассетами, даже как делать анимацию (не глобально, конечно) но что-то про анимировать по мелочи могу. Управление персонажем: бег, ходьба, прыжки, боевка, работа с врагами, их движения, атака, преследование персонажа, работа с префабами, как добавлять музыку и определенные звуки, работа со сценами, менюшками, какие-то взаимодействия в игре. В общем, считаю, что у меня появилась не плохая база. Которую я могу уже перенести на свой проект, и уже на своем проекте изучать Юнити более углубленно. Думаю, в этом плане уже хорошо будут помогать книги по Unity.
Теперь, после окончания этого курса, считаю, что можно больше времени уделять и С#. До этого основной упор был на Юньку. НО! Для тех, кто только начинает или собирается начинать, мой совет, в начале изучаете С#, просто основы, а потом уже переходите в Unity. Иначе у вас будет каша и вы вообще не будете понимать, чтобы пишите.
И так, мои планы. Наверное, в начале апреля хорошо займусь С#, а после начну свой проект и параллельно уже буду более углубленно изучать и шарп, и юньку. Свой проект тоже хочется создать уже по нормальному, поэтому еще немного времени уделю на геймдизайну и левелдизайну. Что бы понимать, что это вообще за верь и было более полное понимание своего проекта. Всё-таки это потом будет мой карточкой. В которую я скорее всего загляну в будущем и буду удивляться, какую же чушь я раньше писала в коде)))
Если у кого то в процессе обучения появились какие то вопросы, то можете писать мне в телеграмм, группа @annaleeplay Она у меня больше по играм, но возможно совмещу ее с обучением с геймдевом.