Войти
Unreal EngineФорумПрограммирование

Мнение о UE4 после работы с ним (3 стр)

Страницы: 1 2 3 4 5 6 Следующая »
#30
9:45, 1 мая 2016

cin
https://docs.unrealengine.com/latest/INT/Gameplay/index.html
не благодари

cin
> Как соединить всё вместе правильным путём
Без достаточного опыта в играх и C++ в анриал можно не соваться.


#31
10:41, 1 мая 2016

cin
> Я запутался с ним.
Горит у тебя не хило, прям как у меня раньше от физики. :D
Если у тебя проблемы с английским, то печалька.
На сайте УЕ4 есть отдел Learn и Community, где все разжевано и коротко и длинно (кому как нравится) на англ.
Всё, абсолютно всё.

#32
10:43, 1 мая 2016

BingoBongo
> Без достаточного опыта в играх и C++ в анриал можно не соваться.
Смотря какой сложности игра, можно и без C++.

#33
13:18, 1 мая 2016

cin
Документация же есть. Правда незаконченная и куча справочной информации не выведена в основное дерево ссылок.

Вот тут все о блупринтах:
http://docs.unrealengine.com/latest/INT/BlueprintAPI/index.html, 5177 файлов.
Есть такой же оффлайн справочник по API, тут:
C:\Program Files (x86)\Epic Games\4.11\Engine\Documentation\CHM\API.chm
____________________
В целом движок весьма неплох. Визуальный редактор материалов, ня, я такой хотел в Unity. Но в Unity шейдеры ручками приходится писать.

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

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

_________________
Если б у меня Unreal Editor так не издевался над процессором, мне бы движок еще больше понравился. А так откладываю до лучших времен.

#34
14:07, 1 мая 2016

AntonioModer
> Смотря какой сложности игра, можно и без C++.
Можно, но это развитие разработчика в ложном направлении, потом придется переучиваться.

Barabus
> Ну а что касается C++, от там применяется как обычный скриптовый язык, как и C#
> в Unity, и каких либо глубоких познаний в оном не требуется
Эхехе, например, не нужно знать как работать со сборщиком мусора и какой жизненный цикл объектов и ресурсов :)

#35
14:39, 1 мая 2016

BingoBongo
> Эхехе, например, не нужно знать как работать со сборщиком мусора и какой
> жизненный цикл объектов и ресурсов :)
Это все описано на одной страничке документации. Да, приступая к изучению Unity не нужно знать и этого.

Если же вы о C++, то оный не имеет сборщика мусора как такового. Это особенность движка движка.

#36
15:09, 1 мая 2016

Barabus
> Это все описано на одной страничке документации.

Там тонкости не расписаны, например, частая проблема новичков: создаю класс через NewObject<MyClass>() через минуту при очередном обращении к нему игра всегда падает, в чем причина? какими способами лечится?

Barabus
> Если же вы о C++, то оный не имеет сборщика мусора как такового.

Окей, вот мой список навскидку что нужно знать по C++ для анрила:
1. наследование, полиморфизм (виртуальные функции), множественное наследование
2. шаблоны
3. указатели, ссылки
4. основные структуры данных (например, STL C++)
5. как работают #define, #ifdef и т.д.

К тому же надо знать основы 3Д-графики, т.е. OpenGL или DirectX, текстуры, меши, материалы, шейдеры, матрицы преобразования. Желательно знать принципы скелетной анимации.
А такие знания можно получить, только если уверенно и плотно приходилось на каком либо языке с этим столкнуться. Значит подразумевается, что человек как минимум один язык программирования знает.

И еще надо немного знать C#, потому что модули в анриал добавляются на C#, но эт так - из несущественного, но интересного )

upd. И ты же игру в итоге на C++ пишешь - хотите сказать, чтобы сделать игру на C++, достаточно его знать на уровне скриптового языка?

#37
15:15, 1 мая 2016

cin
> Блупринты?
Нет, там все на с++. Но пример хороший. Понятно для чего предназначены классы, и как их использовать.

#38
16:52, 1 мая 2016

BingoBongo
> Там тонкости не расписаны, например, частая проблема новичков: создаю класс
> через NewObject<MyClass>() через минуту при очередном обращении к нему игра
> всегда падает, в чем причина? какими способами лечится?
Выход за пределы видимости и/или потеря ссылки, GC грохнул объект без ссылок?

Без примера кода сложно сказать, я с таким не сталкивался.

> 1. наследование, полиморфизм (виртуальные функции), множественное наследование
> 2. шаблоны
> 3. указатели, ссылки
> 4. основные структуры данных (например, STL C++)
> 5. как работают #define, #ifdef и т.д.
Это тоже все элементарно. Это основы. Ну кроме п.1, где есть важные ньюансы.

А что касается п.1, точно без всего этого не обойтись? Я еще не изучал ту часть разработки, что относится к программированию на C++, но что-то у меня сомнения, что все это действительно нужно.

Что же касается STL, плохая идея использовать это с UE4. Это очень медленные инструменты. То же можно сказать о большей части .Net, которую лучше обходить стороной и не использовать без крайней необходимости при разработке под Unity. Скрипты есть скрипты и относиться к ним нужно как к скриптам, а не как к полноценной части программы. Чем проще, тем лучше.

> upd. И ты же игру в итоге на C++ пишешь - хотите сказать, чтобы сделать игру на
> C++, достаточно его знать на уровне скриптового языка?
Да. Понятно, что не на уровне примитива вроде lua, но на уровне Unreal Script вполне достаточно.

> И ты же игру в итоге на C++ пишешь - хотите сказать, чтобы сделать игру на C++,
> достаточно его знать на уровне скриптового языка?
Вместо C++ там мог бы быть Unreal Script и принципиально ничего бы не изменилось. Все же большая часть кода находится в ядре движка, а то, что мы создаем, — это очень высокоуровневый прикладной код. C++ тут лишь дает возможность повысить производительность за счет компиляции в машинный код.

#39
17:53, 1 мая 2016

cin
> Например, я не понимаю что такое gamemode
На странице документации по GameMode есть ответы на твои вопросы. В том числе: когда создается, для чего нужен и т.д. Думаю, такая же ситуация и с другими классами.
https://docs.unrealengine.com/latest/INT/Gameplay/Framework/GameMode/
Когда разберешься с ними, а также GameInstance, можно смотреть реальные примеры в Learn. Да, там полноценные игры с кучей лишнего кода, но никто не жалуется, если действительно нужно разобраться с движком.

Barabus
> Вместо C++ там мог бы быть Unreal Script и принципиально ничего бы не изменилось.
В сложных проектах приходится работать с потоками и синхронизацией. Скрипты с такими вещами не очень дружат.

#40
18:15, 1 мая 2016

wmask
> В сложных проектах приходится работать с потоками и синхронизацией. Скрипты с
> такими вещами не очень дружат.
Если говорить о Unity, то именно так и есть и для многопоточности там есть существенные ограничения. Хотя бы потому, что фактически все объекты реализованы в плеере движка на C++, а C# отдана лишь возможность управления ими. Не, вы можете создавать отдельные потоки с собственным кодом на C#, но классы Unity в этом коде вы использовать не сможете.

Именно поэтому надо относится к коду для Unity как к скриптам.

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

#41
18:49, 1 мая 2016

Barabus
> GC грохнул объект без ссылок?
в точку )

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

> Это тоже все элементарно.
поверьте, нет. вы не видели как люди на коммерческих(!) проектах тупят с указателями )

> Что же касается STL, плохая идея использовать это с UE4
знать STL надо, чтобы беспроблемно использовать альтернативу STL в анриале (у них там все свое).

> Вместо C++ там мог бы быть Unreal Script и принципиально ничего бы не
> изменилось. Все же большая часть кода находится в ядре движка, а то, что мы
> создаем, — это очень высокоуровневый прикладной код.
Тут я не согласен, потому что у нормальных игр объем кода для логики сопоставим с объемом кода фреймворка, на базе которого строится игра
(я имею ввиду не низкоуровневый код, типа, исходников OpenGL, а, например, код, который из OpenGL делает графический движок).
Ядро анриала конечно тяжело переплюнуть, но кода будет много. Если тоже самое делать на скриптоподобном языке, то начнется Ад.

#42
18:54, 1 мая 2016

Barabus
> без вмешательства в код движка для многопоточности вероятно будут ограничения.
Я пока не заметил ограничений в этом плане. Можно комбинировать что угодно с чем угодно. В одном проекте клиент UE4 даже на Android создает FRunnableThread и общается через обычные sockets с сервером. На десктопе работает std::thread. Можно в любом месте программы создать переменную std::thread и запустить поток. Синхронизация так же работает: и встроенная, и std::mutex, и CRITICAL_SECTION.

#43
22:26, 1 мая 2016

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

Ну и отдельно порадовало наличие готового персонажа, как встроенного класса, весьма функционального. В Unity тоже есть персонаж, однако он не встроен, а включен в стандартные ассеты.

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

Ну и да, блупринты — классная вещь. Странно, что они появились в игровой индустрии только сейчас. Не считая того, что в редакторах шейдеров и материалов  эта система используется давно. Вполне логично применить ее и для игровой логики. Все это проще реализуется и более наглядно, чем голый C++, C# или любой другой код.

Конечно есть вещи, которые проще написать, чем составить: циклы for/foreach, селектор switch-case и прочее. К слову, в CoDeSys они в визуальном виде не поддерживаются. В остальном же визуальное программирование удобнее.

#44
23:20, 1 мая 2016

Barabus
> Странно, что они появились в игровой индустрии только сейчас.
Ты упрлс. Kismet на UE3 существует с начала времён. Playmaker на Юнити - с 2011-го года. Так что всё это старо как мир.

Страницы: 1 2 3 4 5 6 Следующая »
Unreal EngineФорумПрограммирование

Тема в архиве.