Hello i Know that u probably never gonna see this comment but I have a question. What is the diferent between using PlayAnimMontage and using this: UAnimInstance* MyInstance = GetMesh()->GetAnimInstance(); MyInstance->Montage_Play(m_pDashMontage); ??? Thank u if can answer me :P
I did both. I think it's much easier to get started with Unreal and you feel a greater sense of satisfaction more quickly, but I honestly found it was a case of giving with one hand and taking with the other. There would be something Unreal did great, something Unity was terrible at. There would be something Unity did great, barely existed in Unreal. Unreal did X straight out of the box. Unity needed a load of extra plugins or crappy community-built asset packs to do the same. Unity does Y. Unreal does Y slightly differently and they call it Z. The Unreal editor had something hidden behind a load of different panes and menus. Unity had it right there in front of you. In Unity it's dead easy to set up A. In Unreal it's a nightmare to get A working, but it's better than Unity when you do. Unreal has B, but again, it's a nightmare. Unity now has support for B, but it's a nightmare because it's a preview version and sucks. Unreal's Blueprint system is really not that beginner friendly and dragging spaghetti around just gets old. Unity lets you just write the code in C# and you can maybe write your own Visual Studio macro to autogenerate boilerplate. Meanwhile the C++ code used by Unreal is non-standard and very cumbersome, it's also not that easy to access it within the editor. And so it went on. I was conscious of the fact that there seemed no publicly available engine with the best of both.
Unity's Asset store is a hell. I have to constantly rewrite purchased code to work with each other. I tend to use them more like a guide or a course / tutorial. Our 3D artist does the same with purchased models, and we are talking about best sellers here. I don't have much experience with Unreal, and for our current project it's a no go. But after a few years of Unity, it felt natural and user friendly to me. On the other hand, back when I was choosing a game engine to learn, UE4 scared me away. On the tutorial side: Unity's docs tend to be outdated ("this is called that from now on", "that is deprecated" "use the new stuff", new stuff? it's in beta). Can't talk for Unreal, more then likely there are outdated docs, etc. too. Blueprints is somewhat slower then C++, on the other hand, if you want to use Unity, and rely heavily on Asset Store packages it can be even worse. I'm not dragging Unity down, the engine itself is good, C# is good, even their Visual Script solution is, well, fine, but if the game you are building is a bit heavier on performance, then be prepared to get into C# or Visual Script (or modelling if you are an artist) to re-invent the purchased packages. So, best tip I could give is: when using Asset Store stuff, it's better to stay away from packages that do everything. Rather get multiple smaller ones. Need a character controller? Get one that does exactly that. Need an IK system? Get something that fits that need. Etc.
Absolutely. I tried to follow an official Unity tutorial, but it was literally impossible to complete it. Why? Because they wanted you to click on things that didn't exist anymore because the editor had been updated. Unreal's docs let you pick your version from a dropdown. The docs are also rubbish. You go onto Unity's development docs to look up what Quaternion.DoFancyDance and it'll say something like "Calls the FancyDance function on a Quaternion object". Wow, so helpful. What does that even mean and what does it do? Why is that code sample beneeath so totally irrelevant? Also, most of the Unity tutorials on RU-vid seem to be using ancient versions of the editor from like 1979, everything has moved and you can't follow along, they're using features that no longer exist. They're not good teachers, everyone has their own way of doing the same thing, everything moves at warp speed and they just click click click without explaining what they are actually doing. There's no uniformity and no way for a beginner to know what's right. And even the more modern ones are telling you to do things _wrong_ like the old input system, manually manipulating the position instead of using Translate, or manually updating the camera instead of using CineMachine.
Great video! I'm not as new to coding, but I am new to game development and this video has been so helpful in just reasoning out to myself why I would want to consider one over the other.
If you think unity documentation is better heres a challenge: Try to make custom hdrp graphics settings in unity (not just presets, i want you to change the actual "scriptable" pipeline setting, you'll find out its not very scriptable) Don't cheat and use my scripts or tutorials, ignore the forum post where i posted the scripts. Let me know when you've given up or died trying.
@ 8:00 Well, Unity has a component based hierarchy only while Unreal has both. A class based hierarchy where one class is derived from another + the component hierarchy where components can also be derived from other components but you can just make a component for task X and apply it to anything you want that. You do not have do inhert from x other classes, it really depends on what you want to do. In Unity you do not have a choice and it's less of a choice whether you like it or not, it is more a technical design choice where you do whatever does the job best. In Unity you do not have this choice at all, you are always forced to do everything and anything by using components which is not good from a software engineering point in my opinion.
From what I can tell, unreal doesn’t have a transformation hierarchy, which bothered me at first, cuz I was used to Unity’s transformation hierarchy. But honestly, it’s interesting when you get use to unreal’s methods of doing this
As a cs student and programmer I can honestly say C++ is a headache. I also love C++ but that is mainly due to it being the main language I used at my school. Never used C# before so Unreal appealed to me over Unity but yeah C++ is one of the harder languages you can learn.
I find myself really torn between which one to go with. I'm a complete begginer at this too, and I started in Unreal for a few days, then saw a video about Unity and have been giving that a shot for the last week. I found a course I really like and the same guy has 15 hour courses for Unity and Unreal making essentially the same game, so I'll be taking the Unreal one once I'm done with Unity so I can more fully decide. Based on my little bit of experience I tend to agree with most of your points so far, so I'm leaning towards Unreal, but I still want to give Unity a fair shot.
I know this comment was made a while ago, but I would be interested in the video series you mention, where the guy teaches the same game in both engines. Could you please tell me where I can find it? Thank you!
Thanks for the video friend tell me please if I want to develop VR projects or create Metaworlds, what game engine will suit me best as a beginner? Друг спасибо за видео подскажи пожалуйста если я хочу заниматься разработкой VR проектов или созданием Метавселенных, то какой игровой движок мне подойдёт лучше как для новичка?
Hey Brother. I love this video and your truly honest nature of this subject. If you would like to really break out. You should learn Lua programming. It's very simple by far in comparison to c# and c++ . You can use it to make Unreal games via the Core Engine. Which is built on top of the Unreal engine. I hope this helps you my brother. My name is Patrick Ginn my friend.
i started on unity, for months i could not do much if i did not spend money on third party assets, and than the personalization was a probleme unreal engine is way more easy to use, the blueprint system is so much better, creating complexe gameplay mechanics is way more easy than on unity very sad i spent time on unity to be honest :(
How can you make it so that you don't have to hold down the sprint button, and just press it when you start sprinting, and then press it again to stop sprinting?
For anyone who might have the same question, just create one sprint function with a Boolean called something like “bIsSprinting”. On the function call start with bIsSprinting=!bIsSprinting to toggle the variable between true and false. Then just have 2 of checks to set movement speed based on if the bool is true or false
Great video! Just wanted to say that Unity has had starter assets for 1 or 2 years now so you can drag and drop a 3rd/1st person character even there :)
When I was younger I self-studied C++, the most difficult part is memory management and understanding others C++ codes. C++ syntactic sugar makes it more difficult to read other codes. Whereas C# is much simpler and straightforward, with built-in garbage collection, I don't have to worry about memory leaks. But I still like C++ because it is faster and it is a lower-level programming language.
If you're working on a serious 3D project mid to big size with Unity you're gonna encounter many problems as the engine lacks many tools and reliable systems.
@@WelshGuitarDude honestly if I were to start we'd end up with another wall of text and the best way to rly know is diving deep into a complex mid to big size project or you can read through long paragraphs of rants on reddit/Unity forums.
@@eaglenebula2172 even one example would be nice because I've not come across any when looking at demos of big projects nor on my own project which has been in the works for 2 years now. A lot of people say it doesn't do well in large projects but no one ever really defines in what way. Like its a thing that is spoken but never really explained.
@@WelshGuitarDude idk what you mean by "looking at demos of big projects" like you had access to their source code and files which I doubt and in such case that's a no argument cuz studios with resources can overcome the engine's limitations and fill in the blanks. The problem with Unity is that it lacks straight solid game development tools the as it feels like the engine just offers more 3D rendering & animation tools than actual game dev ones. Then you have tools that are incomplete or barebones like the Polybrush tool has some good features but not complete with a limited UI and for example you can't even use it on terrain even 3 years later for w/e dumb excuse they can give knowing other 3rd party tools even small free ones can do it just fine. *Important note:* some of the things that I mention may have been addressed in the last few years but if you started your proj before they were prod ready you can easily miss them, unable to use them if instable or not have the time to test each and every package worrying it ends up not answering your needs and thus go for a more reliable 3rd party equivalent considering UT tools' general reputation. -CharacterController is very barebones if you have a serious locomotion system, doesn't even have gravity unless your character "never needs to use the y axis" like wtf is this rule ?? so if you need your char to jump etc you have to not just apply gravity yourself but it doesn't have any of the physics methods that rigidbody has so you have to make everything yourself and doesn't even have the full collision events, only the OnHit which keeps getting called continuously unlike OnEnter. -No AI tools. -Probably no _in-depth_ cinematics systems (looked slightly at Cinemachine but didn't seem to match some 3rd party tools in that regard). -You don't have an AutoLOD tool (I tested a Unity unofficial preview package in ~2020 but it conflicted with an auto-save system). -You don't seem to have a _simple ready to use_ foot IK system (when a cheap 3rd party offers a simple plug & play solution). -No dynamic footstep sound system. -You don't have a _simple ready to use_ weapon/body trail systems. -Pathfinding has limited usage due to non-exposed constraints like gravity and being navmesh-bound (i.e literally glued) and not being open source to adapt. -No world streaming tools (yet but I suspect they may hopefully add one to HDRP in the future which brings the SRP problem that I'll discuss later). -Until last year they didn't even have a proper PBR terrain details solution making your vegetation look like complete garbage without 3rd party systems. -No Light probes placement tools nor automation of the process. -GI from light probes visibly differs from that from lightmaps (probably differs between versions too cuz it's an old bug that was supposedly fixed but was not when I used it in 2020.3.15 LTS, will try again in 2022 version later). -We didn't even have splines til this year. -We still don't even have auto-save ffs. -We don't even have an in-game settings menu UI which used to exist but they scrapped it years ago ! -Iteration time takes a hit the bigger your proj grows and you have to make constraining efforts to keep it reasonable. -Project browser and hierarchy are very barebones which makes project organisation & usage quite annoying. -SVT only currently works in HDRP. -DX12 only came out of experimental about a month ago in the 2022.2 latest alpha and still needs work. Nowadays they mostly only care and add features to the SRPs but the problem with those is the uncertainty factor like years after they were claimed "Production ready" one or both didn't even have point light shadows !! which was added relatively recently. HDRP didn't have a native proper PBR terrain vegetation until a while ago. Many fundamental tools exist only in HDRP which isn't a viable choice for ppl without enough resources/knowledge to make use of it which probably means most users espec when you know it basically gatekeeps players without upper mid to high end hardware to run it with good fps due to its overhead. The other issue with SRPs is you don't have a proper tool to convert custom shaders which are quite common in some good quality assets from their store some of which were updated while others did not + the SRP versions tend to break stuff over & over again putting strain on the asset authors too. In my opinion, my situation and many other ppl from what I read, Built-in pipeline is the most stable & reliable of the bunch for non-hobby projects but I know some ppl and studios use SRPs. There're free 3rd party open source solutions to some of the points mentioned but some can come with restrictive licenses or obsolete... I don't think Unity is a bad engine but can't say it's great either for the mentioned cases, my main issue is really that it lacks proper game development tools as opposed to fundamentals like rendering or animation and doesn't facilitate that process the moment you go beyond basic projects. You can have some solutions in packages but they aren't necessarily as straight to use as other 3rd party which can save you some hassle and possibly reading through dozens of doc pages or if lucky find a video tutorial. I still intend on using it nonetheless for a while but not for the long run with its current state. I also started learning UE's workflow & toolset my free time to have a more objective opinion on each's pros & cons which even at a glance you can see the drastic difference between the two but again it rly depends on the type & scope of the project. Edit: some of the things mentioned may seem specific but really they're not cuz they're common to many main 3D game genres.
@@eaglenebula2172 Unity has a big project that is available to dig into. As for tools - more often than not the tools both Ue and Unity give lack features or need tweaking and relying on them to update it or add what you want is waste of time. You might aswell modify it to your needs or use an asset where you can join a discord and get the help to tweak that instead. Even in UE i found the tools lacked what i needed so i would have to customise it... i saw no difference between the engines for that issue. But these days i don't make any particular game that requires some major engineering tools or overhauling anyway. Almost anything i plan to make i can pretty much do myself now i have learnt to do it. As for using character controllers etc. Yeah i would never use built in ones because i want my games to have their own feel - so i always make my own CC anyway.
For me I find that unreal has at best horrible documentation, community support and UI. unity for me has the vastly superior support, so it is easier to get into and find help. in my opinion you can have a superior game engine, but give no indication of how to use it and/or horrible UI, it will always be worse as it will be very difficult to draw out all of its potential, compared to a slightly inferior game engine but have tons of easy to follow and p to date tutorials, documentation and good UI, even if it is limited it is easier to draw out all of its potential.
Maybe it is just me but I don't understand how C++ is harder to "learn" than C#. I do, however, think C++ is much more difficult to "use" in practice because you have a much greater chance of screwing up; so you need to be more careful in writing your code. the reason is that you have to manage all of your memory, you deal with pointers quite a bit, and it is not as type-safe as C#. On the other hand, C# does allow you to manage your memory and allows you to use pointer by unsafe means if you really want to.
