TheodorTalion

TheodorTalion

на Пикабу
поставил 453 плюса и 79 минусов
отредактировал 1 пост
проголосовал за 3 редактирования
30К рейтинг 37 подписчиков 8034 комментария 12 постов 0 в горячем
-36

Почему инди игры так сильно лагают?

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

Почему инди игры так сильно лагают? Разработка, Игры, Gamedev, Оптимизация, Лаг, Баг, Компьютерные игры, Длиннопост

(Можно было бы отфотошопить картинку и дописать, когда пое  на секунду фризануло в 30 раз за минуту, но мне лень)


Все хардкорные геймеры знают с какими словами ассоциируются инди игры у комьюнити. А именно: лаги, фризы, краши.

Конечно, мы сейчас не говорим об инди студиях, которые состоят из опытных ветеранов с большим опытом и талантом. Мы говорим об инди студиях (или можно сказать "инди-людях", т.к. в таких студиях 1-2 человека).


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

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

ФПС - это, простыми словами, сколько раз в секунду картинка на экране обновится.

Но, любые игровые движки мыслят более глубокой сущностью: миллисекундами исполнения (мс).

В 1 секунде = 1000 миллисекунд. Для того, чтобы выполнить какие-то действия, приложению затратить 20 миллисекунд. Сколько это фпс? 1000\20=50 фпс.

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

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

Что даёт нам это понимание? Давайте проведём немного вычислений для наглядности.
Допустим, для игры требуется 1 млрд. действий в секунду.
Наш процессор имеет 3.2 млрд. действий
Итого вычислим ожидаемый ФПС на такой машине:
(100\320)*100=31 мс или 1000\31=32 фпс.

Сейчас мы имеет 31 фпс, но ведь 3.2 ггц - не самый слабый процессор. Что же будет на 2.2?
(100\220)*100=45 мс или 1000\45 = 22 фпс.


Итого, мы имеем, что чем меньше вычислений, тем больше производительность (спасибо, кэп). Но такая очень банальная вещь забыта многими начинающими инди разработчиками.

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

Почему инди игры так сильно лагают? Разработка, Игры, Gamedev, Оптимизация, Лаг, Баг, Компьютерные игры, Длиннопост

Круто, такая хорошая формула, как по учебнику. Жаль, что она не подходит для геймдева от слова совсем. Начнём мыслительный процесс: что такое длина от одной до другой точки? Это относительное растояние между точками. Посмотрим пример расчётов с того же сайта:

Почему инди игры так сильно лагают? Разработка, Игры, Gamedev, Оптимизация, Лаг, Баг, Компьютерные игры, Длиннопост

Итак, тут длина - 6. Но в формуле у нас есть корень - сложная математическая операция, которую не используют в типичных формулах в геймдеве. Давайте просто его уберём и получим, что длина = 36, а не 6. Разве для нас или игроков есть разница на какую цифру мы ориентируемся на 36 или 6? Никакой разницы нет, а процессорное время сэкономили. Т.е. вы просто будете сравнивать этот результат с другими числами - вот и всё.

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

И это самое базовое - математика\физика. Существуют так же другие пути оптимизации графики и прочего, но все они сводятся к простой истине: Чем меньше расчетов - тем лучше.


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

Допустим, в сцене стоит 2 моба. Человек тестирует его, вроде бы всё ок по производительности. Он всё сделал, отдал дизайнерам, которые начали в сцене использовать 40 мобов. Т.е. в будущем допустив небольшую ошибку производительность на сцене упадёт разительно, ибо потребление ресурсов будет умножено на 40. (Привет POE)


------------------------------------------------
Давайте немного примеров:

Майнкрафт - огромный мир из множества блоков.
Ведьмак 3 - огромный красивый мир с синематиками, динамичной боёвкой и крупными локациями.
Инди игра Eco - небольшие миры, где можно кооперироваться, строить дома как в майнкрафт и, в целом, игра и задумывалась как улучшенный клон майнкрафта.

Что по производительности?
Майнкрафт - запуск на любом ведре и игра без лагов.
Ведьмак 3 - запуск только на средне-хороших компах и игра без лагов.
Eco - запуск на топ компах, фризы и лаги на каждом шагу.


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

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

Что ещё? Хм, миры в Eco загружаются\создаются очень долго, миры в Minecraft - 2 секунды. Почему? Всё просто. Ребята из Eco в тупую хранят все клетки как физ. объекты, а не как Гейб в Minecraft-е - в паре тысяч цифр.

Так же весь мир загружается сразу в видеокарту и оперативу, что тоже жесть и просто не уважение к игрокам.


P.S. К слову говоря, когда-то давно, в моей фриланс активности была попытка попасть в их команду, но я не осилил технический тест, в котором требовалось написать динамически генирируемый лабиринт и поиск пути в нём не копируя чужие решения. Сам тест - чушь, потому что копируя решения задача решается за 10 минут, но вероятно поэтому у них такие проблемы с оптимизацией.

P.S.S. Не идите дети в разработчики игр, если не готовы въебывать как проклятые изучая гору инфы и разочаровыватся в собственных силах.

Показать полностью 2
4

Unreal Engine vs Unity Engine

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

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

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

Также пост имеет одну рекламную интеграцию, ради которой, в сущности, и писался этот пост, т.к. администрация пикабу верно заметила, что плюсики - это не та оплата, которая интересна, чтобы писать крупные, полезные и интересные посты, поэтому прошу отнестить к этому с пониманием, так как данная интеграция дополняет взгляд на проблему. Требования сообщества требуют того, чтобы ссылка была либо в начале, либо в конце поста, поэтому я ставлю её тут: это ссылка плагин для Unity - Fast Data View.



Пост построим по типу: название рассматриваемой части движка + пояснение.

Комфортно-минимальные системные требования


Юнити: видеокарта на 2гб+, 4-8 гб оперативы, проц 2+ ядра на 2.5 ГГЦ+

UE4: видеокарта на 2гб+, 8-16 гб оперативы, проц 4+ ядра на 3 ГГЦ+

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

Оперативная память и её текучесть

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


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

Однако я не заметил, чтобы UE хоть как-то освобождал память самостоятельно в отличии от Unity.


Но у UE есть еще один грех: бывает, что вы откроете какую-то большую сцену и она откроется нормально, потом закроете UE, попытаетесь открыть ииии... он не открывается! Выпадает с ошибкой, потому что оперативной памяти ему не хватило (такое бывает, если ссылочная масса плохая). Приходится очищать Intermediate папку, чтобы не открывало эту сцену сразу. Можно, конечно, установить себе просто 64-128 гб и не ловить таких проблем.

Физические размеры проекта

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


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


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


Примерные размеры движка UE - 70 гб.

Примерные размеры движка Unity - 2 гб.


Но так же папка GIT\SVN и Intermediate в UE весят просто безумно много потому что все предыдущие версии ассетов там хранятся, что позволяет вам смотреть версии блупринтов через Version Check (который, к слову, очень долго грузится. По 2 минуты на каждое открытие, потому что сделано настолько топорно, что тупо грузит все данные что есть, а потом отображает, вместо того, чтобы грузить указанное количество версий ДО). А сами блупринты весят очень много относительно скриптов в юнити, поэтому и размеры проекта отличаются разительно.

Также папка Intermediate есть и в директории проекта и в директории движка и они обе копят мусор бесконечно. Т.е. для нормальной работы в UE вам нужно где-то 300-500 гб. свободных.

GIT\SVN\Система контроля версий

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

Дело в том, что все ассеты Unreal (кроме кода), включая блупринты НЕ МЁРЖАТСЯ. Т.е. если вы изменили что-то в блупринте какого-либо объекта, и кто-то уже изменил его и залил в GIT, то у вас есть возможность либо взять его изменения и по памяти (либо достав автосейв из папки проекта) копировать абсолютно всё, что вы писали и надеятся, что никто в этот момент ещё раз не залил этот ассет, иначе вам придётся всё повторять и снова надеятся, что никто его не изменит.

Т.е. ситуация такая:

ᅠ1. Вы добавляете в блупринт какой-то код минут 10

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

ᅠ3. Делаете pull и обнаруживаете конфликт вашего блупринта - похоже кто-то его изменил! У вас есть вариант: взять вариант из гита (потеряв свои изменений), просто перетереть чужую работу своей версией (этот человек будет не рад до уровня жалобы начальнику, что вы немного оборзели).

ᅠ4. Допустим, вы берете из гита версию. Дальше вы открываете редактор, минут 5 добавляете свои прошлые изменения, еще минуты 2 проверяете, что все работает.

ᅠ5 .Закрываете редактор.

ᅠ6. Снова пытаетесь сделать pull и снова кто-то перезалил файл!

ᅠ7. И вы вот так вот маструбируете ассетом туда сюда, тратя кучу времени и нервов, чтобы залить свою работу.


По моему опыту в работе небольшой командой (6-7 человек) бывало, что приходилось сделать 4 итерации такие, чтобы залить свою работу. А если в команде человек 50? А ведь некоторые сущности Unreal существуют в одном экземпляре, типа GameInstance, GameMode, PlayerController, PlayerState, GameState.


С помощью SVN вы можете заливать свои ассеты без pull-а (т.е. не закрывая редактор), но вы просто перетираете ту версию, которая там лежит (но в SVN сложно с фичами и ветками работать) Т.е. это вариант для дизайнеров, которые сами со своими файлами работают и туда никто не лезет.


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

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

Data view/удобное отображение данных ассетов для геймдизайнеров и программистов

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


Общее:

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


UE:

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


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


Удобно ли это? Нет. Это полная дичь, но вариантов нет. Зачастую, ваша структура будет иметь 20-40 полей (что очень дофига) и каждое поле вы должны будете ручками назначить для переменных. Дичь полнейшая, но других вариантов нет.


Unity:

Изначально в юнити не предусмотрено тулзов для удобного просмотра ассетов, однако это можно написать самому (в отличии от UE писать расширения для Unity не так сложно), либо купить тулзы, которые позволят удобно видеть список всех ассетов определённого типа в проекте, без необходимости писать какой-либо дополнительный код для этого, которые позволяет легко сравнивать ассеты на одном экране.


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


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

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

Unreal:
Так как списком в Unreal можно смотреть только структуры, то данные оружия и патронов должны быть в структурах, а потом нужно создать класс, который содержит поле этой структуры и в констракшн скрипте берёт из таблицы эту структуру и назначает её переменной. Т.к. ссылку на структуру дать нельзя и удобно просматривать переменные классов тоже нельзя. Так как в классах от UObject нет Construction Script, то наши Ammo должны лежать в Actor классе.


Т.е. мы создали уже 6 сущностей (структуру аммо, дататейбл, класс, структуру оружия, дататейбл, класс).


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

Скрины:

Unreal Engine vs Unity Engine Unity, Unity3d, Разработка, Игры, Компьютерные игры, Unreal Engine 4, Игровой движок, Gamedev, Длиннопост
Unreal Engine vs Unity Engine Unity, Unity3d, Разработка, Игры, Компьютерные игры, Unreal Engine 4, Игровой движок, Gamedev, Длиннопост

Unity:
ᅠ1. Создаём класс weapon
ᅠ2. Создаём класс ammo
ᅠ3. Создаём инстансы классов
ᅠ4. Открываем плагин Fast Data View и видим их все в удобном списке с возможностью показать их все сразу рядом и изменить размеры, отображения, видимые\скрытые переменные, сделать выборку переменных из списков и прочее, прочее.

Скрины:

Unreal Engine vs Unity Engine Unity, Unity3d, Разработка, Игры, Компьютерные игры, Unreal Engine 4, Игровой движок, Gamedev, Длиннопост
Unreal Engine vs Unity Engine Unity, Unity3d, Разработка, Игры, Компьютерные игры, Unreal Engine 4, Игровой движок, Gamedev, Длиннопост

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


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


К тому же, так как в c++ нет свойств (get; set), то мы не можем видеть там функции, которые показывали бы суммы каких-то данных, а в Unity мы видим в полях Damage и DamagePerSecond динамически изменяемые свойства (по сути функции, но на скринах не показал их, т.к. в анриле такого нет даже рядом).

Разницы в удобстве и подходе, как по мне, очевидная.

Архитектура

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

Unreal сажает вас на свою собственную архитектуру и подход от которого отойти практически нереально.

У Unity есть ряд сущностей: gameObject, prefab, scriptable object, monoBehaviour components
У Unreal: GameInstance, GameMode, PlayerController, PlayerState, GameState, Pawn, Actor, Character, Child Actor, Actor Component, Scene component, Character Movement Component и еще ряд компонентов со своими особенностями.

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

К тому же, для понимания положения, чтобы перенести какие-либо данные, либо объекты между уровнями нужно сделать следующее:
Unity: добавить на любой gameobject скрипт DontDestroyOnLoad
Unreal: добавить данные в класс GameInstance.

Т.е. у анрила есть только один объект, который может переносить информацию между уровнями и в крупных командах будет постоянно столкновение лбами на этом объекте, потому что он нужен всем и умеет переносить только типы значений. Все ссылки будут удалены. Т.е. все данные, что вы хотите переносить должны храниться в структурах и ни в коем случае не в классах. И любые объекты на сцене перенести НЕВОЗМОЖНО. Т.е. вы даже чисто теоретически не можете многие вещи сделать независимыми модулями, т.к. в ряде общих объектов вы будете вынуждены вносить какие-то данные.

Графика\качество картинки итогового продукта

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

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

Внешний вид редактора

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

Unreal Engine vs Unity Engine Unity, Unity3d, Разработка, Игры, Компьютерные игры, Unreal Engine 4, Игровой движок, Gamedev, Длиннопост
Unreal Engine vs Unity Engine Unity, Unity3d, Разработка, Игры, Компьютерные игры, Unreal Engine 4, Игровой движок, Gamedev, Длиннопост

Отладка

Отладка идентичная. Всё примерно 1 в 1. Т.к. оптимизация - это то, что мне больше всего нравится в разработке, то я изучил все тулзы и они плюс-минус идентичные.

Код

Бытует мнение, что код на ++ более "правильный" для разработки, более православный (не зря же в названии целых ДВА креста), а #, мол, для работяг, потому что на ++ написано большинство движков и игр, но вот моё мнение и аргументы на тему сравнения ++ и #, соглашаться или нет - дело ваше:

ᅠ1. Когда разработка игр набирала обороты и индустрия только появлялась, то # еще только-только появился, поэтому специалистов на нём было мало. Был С и был С++ и люди выбрали С++ из-за ООП и более строгой типизации и меньше шансов себе в колено выстрелить, но у C# в этом всём еще больше строгости и меньше вариантов ошибки. Я считаю, что если бы индустрия появлялась сейчас, то все бы выбрали C#.

ᅠ2. С# на всех проектах одинаковый, С++ на каждом проекте абсолютно разный. Подход к коду в С++ на каждом проекте абсолютно другой.

Если вы работали на UE c C++, то придя в какой-то другой проект на C++, то вы поймёте, что подход, функции и код абсолютно другой. Т.е., например, в коде UE очень не рекомендуют использовать стандартные библиотеки С++, т.е. то, что вы учили в универе вам не слишком поможет.

На С# я писал .net приложения, Unity приложения, немного сайты - все практически идентичное, кроме некоторых моментов.

Таким образом, работая с С# на Unity у вас больше возможных путей развития, чем c C++ Unreal.

ᅠ3. Омега душная история с хидерами и PCH в С++. Бывает, что копируешь все хидеры из одного класса в другой, пытаешься использовать функции из них и функции не находит! И ты бесконечно долго сидишь и ломаешь голову почему и как это решить. В C# такой ерунды нет даже рядом, поэтому обучение C# и написание кода идёт намного быстрее. Да и если ты даже немного накосячишь с хидерами в C++, то редактор может начать в разы дольше запускаться, что тоже не круто.

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

Блупринты

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

Зачем он придуман?

ᅠПотому что осилить анриловский код на С++ не только лишь все могут, а так как Unreal - это движок написанный дизайнерами для дизайнеров, то придумали блупринты.


Разработчики утверждают, что вы можете использовать блупринты или код - как захотите. Мол, если вы решили использовать блупринты, то код вам совсем не нужно писать. ЭТО ВСЁ ЛОЖЬ!


Вы обязаны использовать и код, и блупринты. Без вариантов.


Блупринтами вы не сделаете и 10% того, что можете сделать кодом, а от попытки использовать некоторые вещи в коде - вы посидеете.


Минусы работы с кодом:

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

ᅠ2. Некоторые фичи использовать в коде больно физически. Например, система переводов - она нацелена на использование исключительно из блупринтов.

ᅠ3. Можно косякнуть легко.

ᅠ4. Добавив новый класс нужно ручками нажимать на "Generate Visual Studio project files".


Минусы работы с блупринтами:

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

ᅠ2. Каждая прямая ссылка на каждый объект наращивает ссылочную массу, что повышает время запуска редактора. Если объект ссылается на объект, который ссылается в свою очередь на ссылаемый объект, то время загрузки редактора растёт. Даже если объект будет ссылаться на объект и где-то там в ссылках у этого объекта есть объект, которые ссылается на первый объект, то это повысит время загрузки редактора.

ᅠ3. Блупринты не мёржатся.

ᅠ4. В целом на блупринтах писать дольше, чем обычным кодом.

ᅠ5. Все математические вычисления в блупринтах потребляют больше ресурсов.

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


Почему блупринты в целом порочная концепция?

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


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

Звук

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

Расширений редактора

В целом, все движки поддерживают плагины, но написать плагин\расширение на Unreal сложнее по той причине, что писать его придётся полностью на C++, в омега захардкоженной экосистеме анрила. Например, вы хотите изменить вид отображения переменных в блупринтах - и это оказываться весьма тяжкая задача, в отличии от аналогичной задачи в Unity,

Подход к мультиплееру

Изначально, в UE мультиплеер как бы подразумевается как данность, т.е. все объекты имеют плашку сериализации, а все функции можно сразу помечать как мультикасты\серверные\клиентские функции и пр.

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

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

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

Стандартные редакторы материалов\геймобджектов и пр
UE тут побеждает Unity с головой. Во много в UE все эти редакторы более удобные и приятные глазу, чем аналоги в Unity, но функционально всё примерно идентично.

Т.е. в Unreal редактор материалов имеет свой особый интерфейс, а в Unity шейдеры пишутся кодом (хотя вроде бы какой-то похожий редактор для Unity я уже видел), но по итогу это одни и те же шейдеры.

Unreal Engine vs Unity Engine Unity, Unity3d, Разработка, Игры, Компьютерные игры, Unreal Engine 4, Игровой движок, Gamedev, Длиннопост
Unreal Engine vs Unity Engine Unity, Unity3d, Разработка, Игры, Компьютерные игры, Unreal Engine 4, Игровой движок, Gamedev, Длиннопост

Проблемы в редакторе уровней

В UE есть масса проблем с редактором уровней. Например, используя синглтон какой-либо как эктора, он почему то иногда дублируется на сцену. Т.е. в рантайме появляется объект и когда сцену выключили (по esс), то он почему-то остался. Почему? Неизвестно.

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


В Unity я таких проблем пока не заметил, но не отрицаю, что они могут быть.

Система переводов

В UE есть только одна система переводов, она жестко захардкожена в движок и её никак не вынять и не заменить нормально. Она уже более 3 лет лежит под плашкой "Эксперементальная" и, скорее всего, никогда оттуда не уйдёт из-за того, что в ней много багов, однако, если работать по четко намеченным лекалам, то она вполне жизнеспособна и как-то работает, особенно, если не требовать от неё невероятных вещей, типа "нажал на кнопку и все фразы перевело на все указанные языки через гугл переводчик" и использовать её только через блупринты (не через код, потому что в коде её использовать - это ад).

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


Понятно, что гугл переводчик - это такое, но как placeholder нормальная тема.

Претенциозность платформ

Дело в том, что компания Unreal очень сильно пытается мелькать в информационном поле и во всех около игровых сферах пытается впихнуть своё Я. Например, создали свой магазин и не добавив даже поиска по играм сразу заявили, что они "убивцы стима". Это типичная маркетинговая стратегия анрила - создать какой-то некачественный и недоделанные продукт и сразу начать его рекламить и объявлять всем "войны".


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

Т.е. у Unity позиция:
ᅠEсть мы и вот наш продукт.


Позиция у Unreal:
ᅠМы двигаем индустрию вперёд, ну и что, что у нас тонны багов, зато мы постоянно добавляем новые технологии в движок, ну и что, что они работают кое-как - зато они передовые! А еще у нас магазин убийца стима, которые ориентирован как бы на разработчиков, но по функционалу отстаёт от стима лет на 10, а ещё мы создадим издателя своего и будем платить разрабам за разработку.


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

Вакансии
Вакансий на Unreal всегда намного меньше, чем на Unity. Взяв тот же hh и спросив по вакансиям получаем:
741 вакансий по Unity
186 вакансий по Unreal


Это по всему СНГ, по другим сайтам примерно всё в таком же соотношение.

Unreal Engine vs Unity Engine Unity, Unity3d, Разработка, Игры, Компьютерные игры, Unreal Engine 4, Игровой движок, Gamedev, Длиннопост

Магазин ассетов

Магазин ассетов в Unreal в большинстве своём содержит только модели\текстуры и обёртки под блупринты, в отличии от магазина Unity, который содержит абсолютно всё, что можно. Но в этом всё играет роль подход Unity и UE к своим движкам.

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

Стоит отметить, что ряда вещей, которых в Unity изначально нет (но есть в магазине), изначально есть в Unreal бесплатно. Типа изменения цвета папок и пр. Как по мне, то для норм работы с Unity так или иначе 100-200$ выложить на плагины придётся, в отличии от Unreal (возможно, потому что у Unreal особо нечего покупать для удобной работы с редактором).

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

Итог
Unreal-------------------------------------------------------------------------------------------------------------------------------------------------------------

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

Все положительные отзывы об UE4 - это отзывы дизайнеров, моделлеров, создателей шейдеров и так далее, т.е. тех, кто работает только с графикой либо имеет мало опыта в создание игр. Графика - это единственное чем можно похвалиться UE4, но сами же эпики не создают "фотореалистичных" игр.
70% содержаний апдейтов движка - это исправление предыдущих багов, которые зачастую порождают еще баги. К тому же, некоторые баги не могут исправить уже многие годы, по типу добавления поля в BP структуру от которой ломается весь проект, ибо все места, где структура используется вдруг не могут найти эту структуру и приходится изощерятся и молится, чтобы этот баг не словить в очередной раз.

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

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

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

Unity-------------------------------------------------------------------------------------------------------------------------------------------------------------

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

Unity предпочитают не заливать от своего имени тестовые фичи, предлагая пользователям огромный ассортимент торговой площадки, однако, некоторые вещи из торговой площадки, такие как Text Mesh Pro они включили в стандартные ассеты.


Интерфейс юнити никак не поменялся за последние лет 5. Юнити не хватает тулзов для дизайнеров, которые есть у Unreal, что делает работу визуальных дизайнеров не самой удобной.

Показать полностью 9
43

VR development или почему VR разработка\ гейминг в жопе

По просьбе @BHGames, о том, почему VR разработка не стоит того, чтобы даже думать о ней.

Рассматриваем только VR гейминг для ПК, не беря в учёт мобильных телефонов.

Давайте построим данный пост на тезис-пояснение структуре - сделаем его как список тезисов с пояснениям к ним.

1. Сообщество VR гейминга составляет менее, чем 1% от сообщества компьютерных геймеров

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


2. Сообщество VR гейминга разрозненное. Т.е. у каждого разные девайсы, которые делаются компаниями от балды, без каких либо договорённостей.

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


3. Каждый тип девайсов придётся имплементировать по разному, т.е. тратить время\деньги.

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


4. Чтобы всё сообщество могло играть в вашу игру придётся купить все девайсы на которые вы собрались осуществлять продажу

Нельзя использовать контроллеры без шлема, например, да и вы сами понимаете, что что-либо выкладывать на продажу не проверяя это предварительно - бред и неуважение к игрокам. Поэтому придётся выложить примерно 3000$ только чтобы купить основные шлемы:

HTC Vive - 700-1000$

Oculus Rift - 400-700$

HMD Odyssey - 300-600$

Valve Index - 1000$


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

VR development или почему VR разработка\ гейминг в жопе Vr game, Виртуальная реальность, Очки виртуальной реальности, Разработка, Gamedev, Игры, Vr игры, Длиннопост
VR development или почему VR разработка\ гейминг в жопе Vr game, Виртуальная реальность, Очки виртуальной реальности, Разработка, Gamedev, Игры, Vr игры, Длиннопост

5. У каждого девайса есть свои тонкости, учитывая которые вы тратите время\деньги
Например, шлем Oculus в отладке выдаёт какой-то процесс, которые пожирает много ресурсов, а шлем Vive - нет. Что это за процесс и как его фиксить - загадка. Иди догадывайся, чтобы твои игроки могли нормально играть.
Или HMD Odyssey трекает руки камерами из шлема, поэтому нужно еще и учитывать это разрабатывая геймплей и тд.


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


7. Требуется очень глубокая оптимизация проекта, чтобы в него было приятно играть
В отличии от ПК гейминга, где для нормальной одиночной игры достаточно стабильных 60 фпс, в VR гейминге можете считать, что вы рендерите сразу на два монитора (два глаза), поэтому GPU жрёт в два раза сильнее, чем на ПК, поэтому вы обязаны супер оптимизированные текстуры\модели\шейдеры использовать и сильно оптимизировать сцены\код, но это еще не всё.
У VR гейминга для приятной картинки должно быть 90 фпс и выше. Если планка падает хотя бы на 89 фпс, то ваш шлем будет работать в режиме 45 фпс, а если фпс постоянно будет скакать с 90 до 89, то будут жуткие фризы в шлеме. Это какие-то особенности работы этих VR шлемов, поэтому с этим ничего не сделать и придётся смириться и разрабатывать так, чтобы выдавало 100 фпс стабильно как минимум, но в действительности вы сами понимаете, что из-за таких требований VR игры не могут выдавать очень качественную картинку, как PC игры.


8. Некоторые площадки требуют, чтобы 90 фпс было стабильно на оборудование, котором они указали.
Т.е. понимаете насколько это идиотски? Вы не можете просто указать требования для системы выше, потому что у вас игра требует больше ресурсов для обработки (что обыденно для ПК гейминга). Это всё потому что Oculus продаёт свои очки заранее указав на каких характеристиках системы будут работать игры и эти очки, поэтому вы, как разработчик, обязаны обеспечить 90 фпс именно на этих характеристиках и их (команду Oculus) ничего не беспокоит.


9. Разрабатывать фичи под VR неудобно.
Например, я составляю формулы аналитическим путём, вместо математического. Т.е. выполняя какое-то действие я собираю результаты и по ним анализирую, чего не хватает и откуда взять недостающие значения и тд. Работая с VR шлемом это неудобно. В нём не видно, что выводится в дебаг лог или на экран, поэтому нужно мучительно выбирать позиции, чтобы шлем\контроллеры находились в нужном положении чтобы понять какие цифры там сейчас идут.
А еще шлем\контроллеры часто любят отлетать, из-за чего нужно его перезагружать и так далее.


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


11. Доход от VR проектов минимальный
Из-за того, что VR сообщество маленькое, то отношение доход\трудозатратность на разработку игр под VR на днище. Да, игра может окупиться, но реалии таковы, что даже супер крутые VR игры не заработали столько, сколько средненькие, малоизвестные игры с рисованной графикой.
Например, не будем считать чужие деньги, а посмотрим просто на количество отзывов по играм в стиме (думаю, примерно одинаковый % людей пишут отзывы на VR и на ПК игры).

Сразу отмечу, что я не уничижаю PC проекты, с которыми сравниваю VR проекты, но я взял их как пример игры от каких-то не самых известный студий с не самой продвинутой графикой\рекламой\технологиями.

VR development или почему VR разработка\ гейминг в жопе Vr game, Виртуальная реальность, Очки виртуальной реальности, Разработка, Gamedev, Игры, Vr игры, Длиннопост
VR development или почему VR разработка\ гейминг в жопе Vr game, Виртуальная реальность, Очки виртуальной реальности, Разработка, Gamedev, Игры, Vr игры, Длиннопост
VR development или почему VR разработка\ гейминг в жопе Vr game, Виртуальная реальность, Очки виртуальной реальности, Разработка, Gamedev, Игры, Vr игры, Длиннопост
VR development или почему VR разработка\ гейминг в жопе Vr game, Виртуальная реальность, Очки виртуальной реальности, Разработка, Gamedev, Игры, Vr игры, Длиннопост

Итого:
Half life:Alyx - 23.626
Beat saber - 31.101
Slay the Spire - 58.759
Raft - 41.004

Т.е. HL:A от Valve, о которой трубили по всем новостям и на весь Steam, продалась хуже, чем Raft (хз что за игра, взял первую неизвестную мне) и обе топ VR игры (HL:A и Beat saber) продались хуже, чем Slay the Spire с простенькой рисованной графикой и не выдающимися технологиями.


Резюмируем:
Даже самая простая игра на PC, которая не требует омега вложения денег, может запросто обогнать самые топовые VR игры и принести больше денег при намного меньшей затрате времени\сил\денег.

Какое решение для VR гейминга?
Только если производители девайсов будут 100% покрывать расходы на создание игр, договорятся об инпутах, кол-ве и типу кнопок на контроллерах, придумают девайсы для удобной разработки под VR.
Иначе разрабатывать VR проекты нет никакого, даже теоритического смысла.

Показать полностью 5
-7

Забросил игру, которую пилил последние 1-5 лет или как не словить депру

Довольно часто в сообществе инди девелоперов можно наблюдать похожие сообщения, причины, зачастую, однотипные:
1. Угас запал

2. Идея больше не кажется такой уж интересной, как казалось ранее
3. Нет комьюнити\ до каких либо играбельных версий еще далеко, поэтому никакого интереса от комьюнити нет
4. Денег нет

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

Предпосылки почти у всех забросивших свои проекты одинаковые:

------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Самые начальные

1. Слабое осознание количества труда, которое необходимо вложить для создания игры
Когда вы играете в любую игру, то всё технически кажется "чё там делать, раз-раз и готово", а когда начинаешь делать, то оказывается, что для того, чтобы сделать более-менее адекватную стрельбу или ходьбу нужно вложить десятки и сотни часов в каждую из этих функциональностей.


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


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

------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Предпосылки середины пути (одинокий вариант)

Данные моменты - это то, что уже подталкивает к тому, чтобы угас запал

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


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

------------------------------------------------------------------------------------------------------------------------------------------------------------------------

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


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


2. Не видно конца и края.
Последствия пункта 1 зачастую появляются в результате данного пункта. Когда вы заранее знаете, что вы будете 3-5 месяцев сидеть без дохода, то это еще норм, но когда начинает всё уходить дальше и дальше на "нужно немного допилить, пофиксить баги", то запас уходит, каждый член команды делает всё спустя рукава.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Примерно так и заканчиваются 95% историй инди-девелопинга.

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

Итак, начнем советы:
1. Не начинайте разрабатывать игру.

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

Забросил игру, которую пилил последние 1-5 лет или как не словить депру Разработка, Gamedev, Игры, Длиннопост

Таким образом, даже если вам надоест разрабатывать именно эту игру, то у вас останутся независимые модули, которые вы можете впихнуть в любой другой походящий следующий проект и съэкономить время для нового проекта. Помимо этого, независимые модули легко заменяемы и зачастую НАМНОГО более стабильнее (но зависит от ваших навыков всё), хотя и требуют чуть больше времени на то, чтобы они начали хоть как-то работать, но меньше времени на расширение.

2. Покупайте плагины\модельки, которые сэкономят вам время
Лично я не фанат плагинов, потому что зачастую они настолько убогие, что внедрив чей-то плагин в проект - вы его потом не выкинете без жопной боли. Почти все плагины убогие в этом плане, но если вы начинаете использовать чужой плагин, то будьте готовы, что вам его нужно будет дорабатывать.
Однако модельки\картинки имеет смысл покупать, хотя бы чтобы вставить их как заглушку. Просто прикиньте сколько времени вам нужно потратить на создание такого кол-ва объектов как в продаваемом пакете и насколько вы будете в минусе, если будете делать это сами.
А еще можете купить плагины в магазине и если они говно, то вернуть деньги. Либо скачать их на CgPersia  и только потом покупать, когда убедитесь, что они норм.
3. Продавайте свои плагины\модельки
Например, у вас есть дизайнер, который делает модельки, изучите требования к моделям в магазинах ассетов\моделек и делайте по их требованиям всё, формируйте в паки и продавайте за какие-то копеечки. Поверьте, получить хотя бы 100-200$ для начинающих дизайнеров за свой труд - это офигеть какая мотивация и отсрочка ухода в офис.
4. Выбирайте маленькие и короткие игры для начала
Зачастую все начальные инди-проекты поистине огромные. Открытый мир, мультиплеер на 2000 человек\сервер, супер омега ПВП сражений и так далее. Ничего из этого не дойдёт до релиза.
Берите кусочек механики от вашего запланированного проекта и делайте игру только на основе него.
5. Будьте готовы к провалу
Реалии таковы, что нет денег - нет рекламы, а без рекламы про вашу игру мало кто узнает, поэтому будьте готовы к тому, что ваша игра не принесёт денег и сгинет в пучине многих похожих.
6. Ходите на выставки\всякие активности для разработчиков
Рекламы вы там особо никакой не получите, но может быть найдете инвесторов. Да, с инвесторами вы не положите в карман тех заработков, которые могли бы быть (в самой радужной перспективе), если бы вы всё делали сами, но зато высока вероятность, что вы закончите проект в результате того, что начнут платить зарплату, однако, ваш проект скорее всего будет принадлежать инвесторам, а не вам, поэтому по факту вы будете работать только на зарплату. Это не лучший вариант, но иногда единственный, чтобы довести проект до конца.
7. Создавайте игры в малоконкурентной сфере
Например, можете создавать порно игры, ибо секс продаст всё, но не забудьте заранее отложить денег на адвоката и сухари, потому что это незаконно и вас могут взять за жопу по уголовность статье, как одного старого охотника.
Но если серьёзно, то проанализируйте, какие сферы действительно релевантны для инди проектов (вероятно, на эту тему будет следующий пост-исследование) и от этого отталкивайтесь.
8. Будьте богатыми
Чем больше у вас денег, тем проще вам жить. Поверьте, это так, поэтому нет смысла быть бедными.

Показать полностью 1
-12

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

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

Т.е. подготавливаемая мной статья будет 20-30 тысяч символов + картинки, однако, я так же хочу опубликовать и другую статью. Сейчас мне пришлось всё, что я в редакторе поста написал копировать в блокнот, чтобы потом вставить и чтобы я мог написать, например, этот пост.

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

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

Моё предложение: дать возможность сохранять до 5 черновиков, либо сделать функционал загрузить\выгрузить черновик в файл.

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

29

Валянный Пикачу

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

Валянный Пикачу Рукоделие без процесса, Сухое валяние, Пикачу, Покемоны, Длиннопост
Валянный Пикачу Рукоделие без процесса, Сухое валяние, Пикачу, Покемоны, Длиннопост
Валянный Пикачу Рукоделие без процесса, Сухое валяние, Пикачу, Покемоны, Длиннопост
Валянный Пикачу Рукоделие без процесса, Сухое валяние, Пикачу, Покемоны, Длиннопост

Если смотреть на него сверху, то он явно недоволен :D

Валянный Пикачу Рукоделие без процесса, Сухое валяние, Пикачу, Покемоны, Длиннопост
Валянный Пикачу Рукоделие без процесса, Сухое валяние, Пикачу, Покемоны, Длиннопост
Валянный Пикачу Рукоделие без процесса, Сухое валяние, Пикачу, Покемоны, Длиннопост

И несколько забавных фото до набивания глаз и удаление лишних волосков:

Валянный Пикачу Рукоделие без процесса, Сухое валяние, Пикачу, Покемоны, Длиннопост
Валянный Пикачу Рукоделие без процесса, Сухое валяние, Пикачу, Покемоны, Длиннопост
Показать полностью 8
-47

Заложники одной темы : предложение по улучшению сайта

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

Пример:
Человек создал серию постов, которые освещают какое-то общественное событие, к нему набились десятки тысяч подписчиков, но тема себя исчерпала в связи с завершенностью. После этого, через какое-то время, человек постит какие-то другие посты, связанные с своим хобби (а может у человека несколько хобби) и 99% подписчиков удивлены - откуда у меня в ленте не интересующий меня контент? Подписчикам нужно отписаться, постер видит что люди отписываются, ставят ему минусы, потому что контент не интересен и тд.

Решение:
Ввести спец. топики (либо не индексируемые теги) для каждого пользователя.
Например, постишь с тегом "воры в музее" (предварительно выбрав это как личный тег) и люди подписываются на твои посты с этим тегом. (*1 сноска с пояснением)
Потом постишь с тегом "как я ворую в музее" и люди, подписавшиеся на первый тег не видят эти посты у себя в ленте, т.к. она для них не актуальна.

Пояснение:
*1: Подписываемся имеется ввиду не на тег, а на пользователя, перейдя к нему в профиль и после нажатия кнопки "подписаться" выбрать нужный личный тег пользователя под которым он уже запостил какие-то посты (либо дать возможность создавать теги заранее, даже пока постов не было).

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

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

Как разрулить ситуацию с текущими постами без таких тегов и подписками:
Пусть изначально у каждого человека будет топик "Общий" (название такого можно не показывать) и пусть считается, что все люди, подписавшиеся на человека подписались на этот топик (дать ему просто id = 0) и сам постер может изменить название топика под id = 0, т.к. в настоящее время многие все же стараются постить одинаковые темы, а для новых тем создают новые аккаунты.


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

-57

Отчет о разработке #1

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

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

В целом, за всю неделю я сделал следующее:

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

- ловкость - шанс критического урона, восстановление выносливости, незначительно влияет на защиту;

- виталити - кол-во хп;

- выносливость - кол-во выносливость, которая тратиться на использование физ. умений;

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

- маг. сила - урон от заклинаний, дальность маг. толчков\притяжений, незначительно влияет на маг. защиту;

- маг. выносливость - кол-во мп;

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

- красноречие - для не боевых событий и влияет на стоимость предметов при торговле;

- физ-армор (временный), физ-армор (постоянный) ну и такие же маг арморы. Временный - значит что армор заменяет хп, а постоянный, что от каждой атаки отнимает значение.

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

------------------------------------------------------2. Способности-----------------------------------------------------

Добавил несколько способностей разных типов, чтобы представлять какие у меня будут типы ударов, движений и тд. Я лучше просто опишу способности, которые я реализовал сейчас. Думаю, на опыте поймете что к чему.
-----------Общие:
- Движение вперед-назад;

-----------Физические:

- Атака - простой удар перед собой;

- Разбег (Charge) - быстрое передвижение на n кол-во клеток и, если на пути есть враг, то атака его;

- Физ. толчок - если перед вами стоит враг, то оттолкнуть его на n клеток назад;

- Стан - не дает произвести следующее действие противнику (только одно);

-----------Магические:
- Огненный шар - простое направленное заклинание;

- Маг. толчок - толчок врага на отдалении;

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


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


К слову, с магией у меня возникали концептуальные вопросы. Изначально я думал колдовать магию по 3-м линиям и двигать её не мгновенно (как сейчас), а чтобы она летела с определенной скоростью (n кол-во клеток каждое действие), но про линии передумал, ибо это лишнее усложнение, скорее всего, а про определенную скорость не уверен. Как вы считаете, стоит двигать заклинания мгновенно, как сейчас или лучше с определенной скоростью на ход, как описано выше? (также, скорее всего, будет добавлена дальность на которой заклы летят)

-----------------------------------------------------------3. Битва---------------------------------------------------------

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

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

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

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

Следующий пост будет через 4-7 дней и будут сделаны следующие действия:
1-2. Рефакторинг способностей и битвы до финального (пока что) состояния;

3. Создание меню наград (и мб еще что-то по мелочи);
4-5. Добавление модуля предметов персонажей, создание первых экземпляров предметов;

6-7. Модуль магазина и торговли.

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

Всем спасибо за внимание!

Показать полностью 1
-45

Кодовый парусный корабль #4

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

Предыдущий пост: http://pikabu.ru/story/kodovyiy_parusnyiy_korabl_3_5094712
Гит для тех, кому лень читать: https://gitlab.com/open_sourse/pirate

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

Кодовый парусный корабль #4 Код, Программирование, Unity, Gamedev, Разработка игр, Гифка, Длиннопост

Рассмотрим дополненный спрайт пули. Теперь он умеет взаимодействовать с объектам. Особенность в том, что данный способ взаимодействия отличается от тех способов, которые обычно приводятся в уроках. Зачастую в уроках делают проверку на тэг объекта, либо имя и тд.(но это жесть, ибо если будут добавлять новые объекты, то нужно будет прописывать взаимодействие), а тут мы проверяем есть ли у объекта компонент UniApp.General.Effects - это общий компонент для всех объектов, которые в принципе могут взаимодействовать с другими объектами. Т.е. у корабля есть такой компонент, у препятствия...ну, короче, у всех типов объектов на карте с которым можно будет взаимодействовать.

Кодовый парусный корабль #4 Код, Программирование, Unity, Gamedev, Разработка игр, Гифка, Длиннопост

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

Кодовый парусный корабль #4 Код, Программирование, Unity, Gamedev, Разработка игр, Гифка, Длиннопост

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

Для дальнейшего рассмотрения обсудим абстрактные размышления о том как умирает корабль, ему наноситься урон и тд.
У каждого объекта класса есть HP, Wearout, armorValue и ArmorCount (вот снизу переработанный класс item, чтобы было более понятно).

Кодовый парусный корабль #4 Код, Программирование, Unity, Gamedev, Разработка игр, Гифка, Длиннопост

Когда кораблю наносят урон, то отдельные части корабля получают урон HP и Wearout (это износ). Зачастую Wearout у корабля гораздо больше, чем HP, потому что HP можно восстановить до посещение порта, а Wearout - нет. И когда у корабля заканчивается хп в бою, то по Wearout отдельной части корабля наноситься двойной урон.

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


Таким образом весь класс ShipEffect занимается принятием в себя урона, первую часть можно увидеть до обсуждения, а вторая вот:

Кодовый парусный корабль #4 Код, Программирование, Unity, Gamedev, Разработка игр, Гифка, Длиннопост

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

Кодовый парусный корабль #4 Код, Программирование, Unity, Gamedev, Разработка игр, Гифка, Длиннопост

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


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


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

Кодовый парусный корабль #4 Код, Программирование, Unity, Gamedev, Разработка игр, Гифка, Длиннопост

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

Скорее всего, я буду сообщать о успехах разработки примерно раз в 4-7 дней, но уже без кода, ибо код, думаю, не особо интересен людям (потому что ничего гениального не делает).


Всем спасибо за внимание!

Показать полностью 4
-41

Кодовый парусный корабль #3

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

Предыдущий пост: http://pikabu.ru/story/kodovyiy_parusnyiy_korabl_2_5089935
Если нет желания читать, самые актуальные файлы тут: https://gitlab.com/open_sourse/pirate

Начну с краткого пояснения:
1) Я решил отойти от модели проектирования, когда сначала писался класс на чистом языке и тд. (совет @DDeni). Изначально мне казалось что более удобно хранить информацию в виде чистых классов, потому что так просто организовать магазин, но потом подумал еще раз и понял, что мне так или иначе нужно будет хранить спрайты, иконки и прочее для организации магазина.

2) Я убрал лишние методы Instantiate() в пользу использования пула объектов (совет @HartMagic), однако, сам пул объектов не добавляю в список файлов, ибо он достаточно топорный (один класс, 2 метода, 2 переменные на все возможные объекты) и не имеет прямого отношения к теме постов (конечно, без него не получиться запустить проект просто скопировав его, но, думаю, этим никто не занимается, но при желание можно заменить метод Pop на Instantiate(), а Push на Destroy()). Сначала я думал над тем, чтобы купить уже готовый пул, но посмотрев количество файлов и скриптов в продающихся пакетах передумал.

3) Переделана модель стрельбы и пушек (совет @fon.prima). Данный раздел также затрагивает и пункт 1.


Ладно, предисловие закончилось. Начнем с рассмотрения основного класса корабля:

Кодовый парусный корабль #3 Код, Программирование, Unity, Gamedev, Разработка игр, Гифка, Длиннопост

Изменений визуально немного. Добавлены два скрипта - shipControll, содержащий методы управления кораблем и ShipInfo, содержащий просто данные о корабле, которые ранее были вынесены в класс App.Items.Ship.Ship, ныне канувший в лета. Также лист для пуль теперь один, причины изменения в подходе к стрельбе - о ней позже.

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

Кодовый парусный корабль #3 Код, Программирование, Unity, Gamedev, Разработка игр, Гифка, Длиннопост

Итак, рассмотрим класс управления кораблем:

Кодовый парусный корабль #3 Код, Программирование, Unity, Gamedev, Разработка игр, Гифка, Длиннопост

Метод Move: управляет кораблем. По кнопкам W и S паруса поднимаются и опускаются (если подняты, то набор скорости идет, если нет - то убывание скорости). Также я добавил проверку на то, что если скорость больше 10 (цифра от балды), то только тогда корабль может делать повороты, ибо по логике корабль не умеет поворачивать с минимальной скоростью. Таким образом, я убрал зависимость порядка исполнения Move и Rotation, которая была в предыдущем посте.

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

Метод Fire: тут мы по кнопке для каждой пушке в одном из листов запускаем метод Fire. Более подробно будет рассмотрено в классе Cannon.

Метод Rotation: без изменений (убрал только изменения булевой переменной moving, но об этом сказано выше).

Вот так теперь выглядит наш корабль с пушками (белые зефирки - это пушки).

Кодовый парусный корабль #3 Код, Программирование, Unity, Gamedev, Разработка игр, Гифка, Длиннопост

А вот так выглядит движение:

Кодовый парусный корабль #3 Код, Программирование, Unity, Gamedev, Разработка игр, Гифка, Длиннопост

Итак, перейдем к классу пушки, который, вероятно, самый занятный из всего поста:

Кодовый парусный корабль #3 Код, Программирование, Unity, Gamedev, Разработка игр, Гифка, Длиннопост

Это первая часть класса, весь не влез.

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

Метод Loaded: ранее этот метод был в похожем классе, но другом. Изменения: метод стал возвращать bool ииии...все! В остальном все так же. 26 строка - берем снаряд из пула, так что не смущайтесь её внешнего вида.

Метод Fire: если пушка не заряжена, то ничего не делает. Иначе, запускает метод FireProcess и корутину перезарядки. Вот насчет правильности выбора корутины я не уверен, ибо, возможно, есть менее затратные по ресурсам методы, но в голову ничего не пришло подходящего. Если есть идея - сообщайте в комментарии, буду благодарен.

Метод FireProcess: задает полученному снаряду начальную точку, наполняет полями и дает импульс для полета. Также тут мы записываем в переменную lastFire время выстрела (нужно для перезарядки с помощью следующего метода). По поводу пули и её импульса поговорим чуть позже.

Кодовый парусный корабль #3 Код, Программирование, Unity, Gamedev, Разработка игр, Гифка, Длиннопост

Метод Recharging: словами делает следующее: если текущее время больше времени последнего выстрела и скорость огня, то перезарядить. К слову, по профайлеру, вызов этой корутины занимает относительно много ресурсов всего 1 раз - в момент вызова.

Рассмотрим результат стрельбы из разнообразных пушек:

Кодовый парусный корабль #3 Код, Программирование, Unity, Gamedev, Разработка игр, Гифка, Длиннопост

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

Кодовый парусный корабль #3 Код, Программирование, Unity, Gamedev, Разработка игр, Гифка, Длиннопост

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

Кодовый парусный корабль #3 Код, Программирование, Unity, Gamedev, Разработка игр, Гифка, Длиннопост

А вот так стрельба выглядит в динамике.

Итак, перейдем к классу снаряда:

Кодовый парусный корабль #3 Код, Программирование, Unity, Gamedev, Разработка игр, Гифка, Длиннопост

Класс снаряда: Мы сюда внесли понятие импульса, времени "пробуждения", что по сути время появления и времени жизни.

На каждый кадр пуля пересчитывает свою позицию. Отмечу, что был изменен способ изменения позиции с transform.Translate(), потому что этот метод тут не походит, так как он может изменять позицию объекта по Y, что для нашего 2д пространства недопустимо.

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

Остаток класса проверяет не закончилось ли время жизни пули и если закончилось, то возвращает её в пул.


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

Кодовый парусный корабль #3 Код, Программирование, Unity, Gamedev, Разработка игр, Гифка, Длиннопост

На этом все. В следующем посту мы добавим такие механики:
1) получение урона кораблем;
2) нанесение урона снарядами;
3) возможность уничтожения корабля;

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

Всем спасибо за внимание!

Показать полностью 11
Отличная работа, все прочитано!