EDIT 1/9/22: Wow, didn't expect this video to hit 100k views. I have seen a lot of comments clarifying mistakes I made involving the descriptions of c# and derived classes - thank you for that! This project/video was from the standpoint of a complete beginner to coding so there are a lot of rules to learn and systems to understand in a short time period. To me, at the time, they seemed to function different so it was something I thought I should mention. It seems that at the foundational level though they aren't too different in that regard. Either way, I hope the insight from a beginners point of view was useful to some people out there. Happy new year and good luck coding! Hey everyone, thanks so much for watching this video. A few people have expressed interest in following my content in the future. I am actually a UA-camr on a different account (AsuraPsych) as my primary job and this was a fun side project I did to explore the world of coding. I am a graduate psychology student with Ph.D. applications in the works and after a few months of coding I found that it was really fun but I don't think it is something I have enough time to dedicate to to make any long term projects. I may come back to coding in the future but my passion for psychology has been taking a lot of my time. That said, I hope this vlog was helpful to you as I put in as much possible effort as I could to share my genuine and authentic thoughts as someone who was new to coding. Coding is a fantastic path for those who choose to pursue it. With dedication, heart, and passion, you can learn game design and coding. For me, it has been a great side hobby but the odds of it becoming anything more than that are very slim. I simply wanted to inspire others and show that even someone without a background in coding or game design could get started if they put in the effort. So if game design is something you want to make a career out of, I hope you pursue it with all of your heart. Thanks again and good luck on your game design/developer journey.
What you're describing for Unreal with the child-parent hierarchy is inheritance, which is not specific to Unreal, not even to C++, but is one of the pillars of objects orientated programming (OOP), used in most programming languages in some form. C# as a language is no different from C++ when it comes to these features (I mean there are differences, but they are not fundamental). Now when it comes to Unity, the component model is central to the engine (and by the way other engines use components in a similar way), and you're right that it is a different way to work if you compare it to the inheritance model. Using components is encouraged by Unity as the default way to do everything. From what you're describing it is not the case with Unreal (I haven't used Unreal). But you can do exactly the same as Unreal with Unity, use classes (that are components or not), that derive from other classes. You can do it because it's part of the language C#. And the opposite is true, even if Unreal doesn't use components the way Unity does, nothing prevents a coder from creating a component system in C++ and use that. So none of these differences are language specific, but it has to do with the way the engine wants you to work (which you can always not follow, but it may not be the best to fight the engine if you chose it in the first place).
Thank you, you said basically everything I had to say. I want to add... I'm pretty sure Unity also has starter project templates. They are in The launcher.
Totally what I was looking to comment too! And it's worth mentioning that there's a principle stating that "composition over inheritance" should be the way to add on more functionality to an actor. There's a metric ton of reasoning and experience behind that simple statement, and I just think Unity is staying a little bit more true to that. However, there's a time and place for both, and while Unity doesn't go for this approach in their tutorials, it is expected that inheritance will be used a lot in Unity too. I honestly use it within 5 minutes of starting a new project every time. I think Unity in part just try to avoid teaching beginner devs about OOP in a 10-minute standalone tutorial, and try to cater more to one of the two for simplicity. In any larger Unity project, inheritance should be used as well imo.
@@kennethkrist Every Unity developer uses inheritance whether they realize it or not. Every component class inherits from MonoBehaviour, and gets certain functionality automatically if you decide to implement them.
@@Gillissie Well, yes of course. But I think that, being a default template for scripts, isn't exactly the same as a developer counsciously choosing inheritance as a tool to solve problems, which is the point I'm trying to get across.
@@kennethkrist That's the point though... if the developer is learning about how each engine wants you to work, then realizing that Unity's component model is using inheritance by default would create an "ah ha" moment for new coders like the guy in the video, who somehow thought that Unreal was using some kind of unique technique.
This was very interesting to watch. I am a professional game developer (for over a decade) working on a proprietary game engine. I know both C++ and C# very well, but never built a game in either of these engines. However, I have modded a number of games built with these engines and have therefore spent countless hours working with them. I think what you said about each engine lending itself towards different needs is spot on, and that neither engine is better than the other overall. I would like to add a few things that I think were not clear from this video. 1. Inheritance vs composition. The video seems to imply that inheritance is related to C++ and composition is related to C#. Both languages have both of these features. The difference is in the designs of the engines and how they intend people to structure their content. Neither engine fully locks you into one choice or the other. However they do steer you in a direction, and fighting against expectations of the engine would make your life a lot harder. 2. Development time. If you look at successful games built using these two engines, you will find a fairly consistent pattern. Unity games are usually built in less time by smaller teams. There are exceptions of course, but this pattern holds true most of the time. Actually completing a game is a big undertaking. Doing so in Unreal is a whole extra level of difficult. You are signing up for a lot of extra work if you choose Unreal. This is primarily due to UE's poor documentation and limited community support, but also things often just require more steps to build. 3. Performance. Unreal performs better than Unity. Also C++ performs better than C#. If you write the same exact code in both languages, the C++ code will run faster. (This is well tested and documented by many people.) What this means is an Unreal game can effectively do more at a given FPS than Unity. This could be more complex logic, higher quality graphics, whatever. You made a comment that blueprints do not perform as well as C++ in Unreal. While this is true, they generally still perform as well as or better than doing the same thing in Unity in C#. P.S. If you want to make a multiplayer game, Unreal has multiplayer capabilities built into the core of how it works while Unity basically makes you write your own thing (or buy something someone else wrote) and tack it on. I find that to be one of the biggest missing features in Unity.
Just wanna add that your point on performance while true on the surface, doesn't apply to how Unity uses C#. It really depends on how it's compiled. And for this reason, Unity comes with two compilation modes, Mono, and IL2CPP. Note that IL2CPP does mean that Unity compiles to C++ equivalent code. By default, Mono is enabled for faster compilation times, but the standard has been to switch to IL2CPP for release builds all the way since that compilation mode was added 7 years ago. Mono is more useful for quicker development with faster compilation, which is why it's the default one. And if that wasn't enough, the performance gap has been closing rapidly with both C# and Mono upgrades. There's been numerous benchmarks showing that using Mono in Unity is catching up to IL2CPP at a pace that hardly makes it necessary to do IL2CPP anymore. And frankly, that's not even mentioning Jobs, Burst compiler or ECS. While ECS isn't in a production-ready state yet, both the other are. And burst has very much showed it's proficiency. Unity's burst compiler can take calculation-heavy C# code and convert it to native instructions that in most cases are far superior to the standard C++ equivalents, given some very overcomeable adjustments to how the code is written, burst is very much a bleeding edge tool.
He forgot to emphasize performance, like every other Unity vs Unreal Engine comparison; the most important part that distinguishes the two! Plus, while both engines are free, you still end up paying more for Unity than URE! URE is a much better engine out of the box, than spending months buying/learning and struggling with Unity, which is why we still get horribly performing large open world games with unity rather than with URE... Sure, there are certainly competent developers that have brought us incredibly polished and optimized games from Unity, _(Genshin Impact/Edge of Eternity/Sable)_ but they are only 30% of the games coming out in Unity. Even though I'm not a developer, it does not mean that I'm not heavily invested in the Unity engine as I prefer indie games more than AAA ironically enough as more indie developers use unity than URE which kinda sucks as too many indie devs try to fit the engine to their ambitions rather than the other way around as unity does not perform as well with large scale open 3D worlds! I wish Unity devs would take the rose-colored glasses off and get to know Unity's limitations so that they can be overcome and help better the engine!
@@kennethkrist I don't know if Unity has fixed this, as when I last seriously used unity was late in the Unity 5 cycle, early yearly versions. But it's performance is not down to C# vs C++, but how badly optimized much of the Unity engine is. (Tbh I think that the Unity Engine itself is probably mostly c++, but that's just a guess). At least when I last worked with it, every single light source required a separate rendering pass. It's almost trivial to send multiple at once, but no... And let's not speak of Garbage Collection. The problem is not the Average time spent on GC, it was that Unity will make it happen seemingly randomly, and cause MASSIVE spikes in frametime, 10'-100's of MS!). Or loading, when loading a level, it would "lazy load" most of the stuff, so the first time you see something, you guessed it, lagspike... As for hot-reload, yeah, forget it, it requires so much care when writing your code, and adding extra code, and can often trick you into falsely trusting code/wasting time trying to get stuff to work... And UE4 has a similar system, if you set up everything properly for it...
@@kezothehappylurker787 I think there is something important to consider which likely is a big reason many indie games tend to choose Unity. Once you learn how to use it and accumulate a good set of plugins/assets from the store, it is faster at that point to build games than it would be with Unreal. Unity has that larger initial time investment to get started, but you only have to do it once. Assuming you have a firm grasp of C#, C++, Unreal Blueprints, etc. (all of the related development languages and technologies), C# will be the the option that allows for the fastest development times. This means you can do more with a smaller team in a shorter period of time. There are indie games that choose Unreal and are quite successful, but they are less common. When compared to Unity, they generally either require a larger team, create a smaller game, or take a long time to get a game finished. However, they have a significant advantage once they have a game built in Unreal, which I think was touched upon in this video. They stand a much better chance at having an organized project that they can continue to develop and add features to rather than the typical unmaintainable mess people tend to get themselves into with a Unity project. Although you can make a mess in either engine, it is a lot easier to do so in Unity. I think this is something people don't appreciate the value of until they have experienced the pain of trying to work on fragile code where anything they change affects (breaks) everything else.
Im developing a game in UE4 as a first time dev, exclusively with Blueprints and it's been fantastic. I found everything to be simple and if there was a tool that's needed, it's included out of the box. Normal coding was a huge turn off for me and im glad Unreal Engine has a battle tested alternative.
I would recommend you to keep trying and learn c++ its such a game changer, combine a main c++ class and expand on it with blueprints that is the way to go.
@@MrNPC multiplayer is more easy in unreal even with c++, it can be frustrating for sure. But if you have some basic knowledge of how everything works with replication you will be good to go. There are enough tutorials out there, but I would just recommend people to use the docs. The docs look complicated, since they don't always have code examples. But this is the way to go. Most people end up in some rabbit hole where they need to keep watching tutorials to make things for their game, this is something you must try to avoid. And that's why you need to learn how to use the docs. Overall coding experience very overwhelming at first, but after sometime you should be good to go.
@@MrNPC I could be mistaken, but I think thats possible through blueprints. I've seen tutorials on it at least, but I'm personally not making a multiplayer game at the moment so maybe there's more to it that isn't captured through blueprints.
@@gerardoob3164 you usually always make a c++ class and than add all the blueprint to that, that way you can easily add c++ code and it doesn't take time at all to generate a class...
@ 17:16, what you are talking about is called inheritance in programming. You create a parent class that holds everything you need, then child classes that extend upon that. It's really great for keep code clean, since you can add new functions to the parent and see them reverberate in the children.
UE4 certainly has a steeper learning curve, but as a development tool, Unity doesn't even come close overall imo. I use Unity for VRChat content, and have been developing in UE4 for a couple years now so I've gotten pretty familure with both. UE4 is more performance focused out of the box, comes with way more polished subsystems (like the built in multiplayer features) and the biggest thing for me is the blueprint editor. The performance of blueprints is a non-issue. Blueprints are not for "prototyping" your c++, You're intended to use both at the same time. The engine is essentially built around the logic of blueprints, which is why the c++ side may seem a little strange and difficult at first. Build performance heavy low level systems in C++, then stich them together in the blueprint editor. That's why UE4 doesn't document too much about it. They're assuming you have a pretty good reason to be doing something in c++ and thus know how. You can even program your own nodes to be used in the blueprint editor. This is really important because the power of blueprints isn't that that they're easier than programming, is that you can create absurdly complex logical systems that can be intuitively understood just by looking at them. Because of this, I'd have to very much disagree with your assessment that Unity is better for solo devs. The scope of content I'm able to create with UE4 is legendary compared to Unity. Once I establish a decent project structure, I don't get lost anymore and can easily create larger and larger systems. In my experience, UE4 has a higher learning curve because it's a better tool. Sure, Unity has a lower bar of entry, but that's because it has a lower ceiling too. If you want to make performance focused, multiplayer, or very unique games, you'll eventually find yourself deep in the backend editing and hacking at the engine to make your own plug-ins just to get get what you want to work. Cities Skylines is a good example, built in a heavily modified version of unity because they realized partway through the project it was too limited to handle a lot of what they needed. That definitely took some complex programming. One last really important note: C# is Unitys scripting language. The engine itself is C++. When you're programming in UE4, you're programming at a low level and are exposed to the engine itself. In Unity you are just scripting, essentially pasting on little snips of functional code ontop. This is why there aren't tons of little guides for programming in UE4, if you're going to be building a game in just C++, you need to understand how you'd build and organize any other object oriented program in just C++.
i'm pretty sure unreal engine doesn't support a game at the level of citites: skylines as well and you need to make most of the in-game tools by yourself to work properly, and it's doesn't make sense to poorly document the scripting side of the engine and assume "you should know c++", but those things aside, i think it all comes down to which are you comfortable with, as an environment designer, i feel much more comfort in using unity HDRP than unreal, but there are things about unity engine that i really hate, modularity and HDRP not being unity tech's priority for example.
Leviticus, seeing that you have experience in both. I want to ask you which one you would recommend for my specific case. I have no experience with either, However I do have previous programming experience(although not in C# or C++). I want to develop games primarily for Oculus Quest 2. The first project I have in mind is a racing game for Quest 2 that would have multiplayer. I did see someone on reddit say you can get more frames on Quest 2 in Unity. Anyway Was curious what your thoughts would be for this project. Thank you.
As a development tool, Unity far exceeds Unreal. People don't think this because Unity has a lot more... "beginner" tier users which leads to a lot of content made in Unity that is low quality, which some people incorrectly then attribute to Unity. The truth is, though, that Unity has tools that cater to the power level tier user that exceed Unreal's capabilities.
How has Unreal Engine ever been more "performance focused" than Unity? Unreal Engine games/editor require a far better computer to run. Unity is used for almost every mobile game for a reason. It makes no sense to argue that UE is more performant. Unreal Engine is not magic. It has the same issue with draw calls and overdraw just like any other engine.
It's been really helpful to me bro! Thank you for this breakdown, coz I'm just starting my journey as a game dev and it's actually so hard to stop on one of the platforms without such guidance:)
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.
@@becauseiambatman2019 I chose unity because: 1) My uncle's a Game Dev in a company and he uses unity. To get potential work, I should try out Unity, plus I'd have guidance. 2) More coding, tbh I wanna learn C# well.
It is a rare thing these days to find a video on this subject that comes with a subjective (as is always the case) but honest opinion on the strengths of both engines. Congrats.
Damn dude, you killed it. Good job. I have to disagree, I floundered with unity on and off for 2 years with nothing to show for it but with ue4 I feel like I can figure out anything easily and work on my own after just a few months. To each their own though :) most people would agree with you
because Unreal barely requires knowledge to get something done. Unity is harder to setup but gives you more freedom to make awesome stuff. Unreals pipeline is also pretty limited, most productions utilize the barebone frame of unreal instead of what you use, developing it into a partly custom engine. Even Epic themselve build from that a custom unreal engine because it isn't possible to do fortnite with the out of the box engine. In unity it can be easier done.
i found that learning blueprint in unreal is really hard not good enough documentation. With unity i was able to set up simple drag race between two car in an hour . Make no mistake unreal is good at level designing as compared to unity but documentation sucks
@@ajitteshballoria4852 you are so right!! I have been mentoring someone in unreal and their blueprints we're all messed up between the bad docs and the outdated tutorials. I never would have learned it without paying for quality tutorials and always making sure that things I read are up to date. I have no idea why though, but unreal just clicked for me in a way unity didn't. I do understand that it's a much steeper learning curve, but I would still recommend people give it a shot at least.
Very much useful bro. I am really interested in getting into game development but as like you I just finished computer science engineering, and i had no idea on which one to choose from. But I am aware of both c++ and c#, so think I'll start working with unreal
My biggest tip as I too approach this from a non traditional background: there actually IS a ton of information on Unreal Engine. In fact, I'll make the perhaps unpopular statement that you should rely on what Epic Games releases to begin with. How you name things, structure your game, all of the design aspects are so crucial to the game running correctly that you may pick up bad habits (even from some of Epic's own videos). The key is to approach their videos as a thought process, what are the specific tips on how to do things, but also how does what they're explaining apply to my own ideas and design structure? It's a pro and a con: Unity probably allows you to get away with more as a beginner, but if you're perfectionistic and want to do it right, Unreal essentially FORCES you to do so. It impedes on the concept of just sitting down and making something, but knowing you did it right is worth it, at least to me. Unity also seems to import 3D objects without as much complication as Unreal, however, this is purposeful by Unreal to ensure stability throughout a much larger application. Pain in the rear if you just want to get started, entirely necessary for a professional level project. Totally agree that Unity is more approachable. I just think Unreal feels more worth it and forces you to learn industry relevant concepts on software design and game design. Totally depends on one's own goals. Unreal C++ is not regular C++. Don't spend 2 months on traditional c++ like I did. It will help, but if you only read the chapters on inheritance, references, and pointers, basic classes, unless you're doing really technical programming thats all you really need prior to diving into Unreal specific programming.
Best introduction for a beginner for both game engines. Thanks Asura. I too am trying to figure out what game engine is best for me. Videos like this and tutorials are a massive help to people getting started.
First, this is a great breakdown, and very fairly approached. Obviously, these are the opinions of someone with no bias at all; rare thing. Also, great points. I agree on nearly every point, but I would actually recommend UE to a beginner. I used to say I recommend UE to anyone who will take the time to learn, but I've realized since that anyone who isn't willing to take the time to learn can use whatever because they aren't going to do much before they quit anyway. The one key difference that I believe make my opinion different that yours is a blueprints-first mentality. I've actually done software development for years and I love CPP. I love C# more as the language alone is concerned, but if I could use only one for everything I would choose CPP. For years I scoffed at UE because the whole idea of blueprints looked like a more cumbersome way of building CPP code, and I didn't understand why someone would take the time to hunt for those nodes as apposed to typing code, just to be limited to what the lego blocks offered them. I got pretty comfortable with Unity, and I liked it and I worked around a lot of the little bugs and such and I thought I was happy. Then I decided to learn UE; I mean actually take the time to learn it. Never looking back. However, the biggest surprise is how little I use CPP and how much I like working with blueprints. These days I only use CPP for things that I can't do in blueprint, like polling the state of the caps-lock. Performance isn't as good as CPP, but, as you mentioned, it doesn't tend to be a factor in the games I'm building. Anyway, I believe that UE and Blueprints is actually easier to get good results from than Unity and C# for an absolute beginner. Which is easier to get started with depends on which type of thing someone learns easier, but C# gives beginners a lot more rope to hang themselves with, and very little help compared to blueprints, and UE is far more developed, tuned, and reliable than Unity, so they're much less likely to get hooked by something that the engine does to work against them.
Last year after I got my associates I finally descuides I wanted to go into game design. I took a course in coursera that was in unity. It all was confusing and the lessons working in unity didn’t stick too well. While the unity lessons didn’t stick well, the lessons on getting into game development and business/ jobs was very insightful. I learned I wanted to be a programmer. It’s gonna be hard I just wanted to know if it’s the right decision for sure. Epic games has lots of paid internships and they’re known for using unreal and c++ I think (don’t quote me in that). But I’m still learning the basics and have been feeling a little unsure if this is the right direction for my life. Thank you for the video. It was very insightful and made me feel more sure about learning c++ and unreal engine.
Good video. I’m a unity dev and understand where you are coming from. Unreal is more for games but Unity gives you more room for business projects, mobile, AR, VR, and all the new headsets like hololens.
6:09 so as that says and use Live Coding. Allows you to compile changes to .cpp files in a matter of seconds and do it while your testing your game as well to make changes on the fly. This doesnt work well with headers but from what I've heard UE5 is set to implement that as well so it should be a nice time saver! Unfortunately the slowness at compile time comes down to the language itself, so normal compilation will always take awhile.
Good video thanks! Just to note, you can make unity scripts as big or small as you want for a single game object, you can have 1 big script doing lots of things or 10 single scripts doing specific things, it is up to the dev. You can also do the inheritance stuff, just like C++, it is not an Unreal thing.
True! It's actually recommended to break up classes into smaller one more often than not. It's basically just good coding practice. It's also not necessary to make all classes into Unity components. It's entirely possible (and easy) to have one component that uses 10 different classes without cluttering the Unity inspector. However, the Unity inspector is a mighty debugging tool that I'd recommend using to speed up development in any case.
Good video and good results for several months. As a Ue4 user, I want to add a few pluses to the side of ue4 that were not mentioned, but which are very important for game developers. Ue4 provides good multiplayer out of the box, you can also do multiplayer on blueprints. And probably the most significant plus is the opportunity to get a grant for the development of a game, I don't know if it will be issued in the future, but now ue4 has been giving grants for several years and I think this is very good support for indie developers when you want to do game development seriously and plan release the game. If I was asked for advice on how to approach the study of ue4, then I would answer to start with blueprints, and switch to c ++ after understanding the ue4 network, because after the network you better understand the difference and the need for controllers, pawns, actors and other classes, especially them logical purpose. I don't know English, it was translated by a translator
I think you've mistaken on one certain point. Complex gameplay and system is not tied to triple A games. If anything, it's the exact opposite. The difference between triple A and non triple A games are mostly in the graphics. The most complex gameplay and system are almost always found in the most graphically crude games, like Minecraft, Terraria, Rimworld, the original Dota, and even the games of the classic roguelike genre with no graphics at all but only ASCII instead. Where I don't think visual scripting like blueprint will be able to handle that level of complex game design.
Another problem with UE4 and the community is it is mainly used by AAA developers who are not going to be so open about things like best practises to use and tips and tricks of the industry.
Unity released its Unreal leveler, the rendering pipelines. I use HDRP and URP with some awesome results. I agree Unreal has things built-in like post processing, whereas Unity you been to bolt on a lot of things using the package manager, but that approach allows you to hone the project from the start and not carry lots on unnecessary features right from the start. I create my own templates depending on what I may want to do, that saves time, but you are right, Unreal assumes you are going to do something right away. I used to like that approach in Unreal, but now I specialise more, I don't want the clutter. From the editor point of view, there are quite a few mundane tasks that are required that need automating like Redirects, having to resolve them manually in Unreal and some of the settings are quite hidden. I compare the editors, I feel Unity is more set for business whereas Unreal feels a little cartoony. The Grids in the scene and object editors annoyingly flash in Unreal, unchecking them is not sticky. In Unity, some of the floating windows are also not sticky, both annoying points. As I sell a lot of packs on both engines, Unity wins with that process hands down, Unreal is more DOS like and manual Create a zip file of the project, open the zip, delete a bunch of folders, check all meshes are prefixed with SM_, materials Mat_, textures Tex_, upload to a cloud storage and provide the link. Unity is click a button, browse to the project folder, and click another button. I think the choice of Engine is dependant on your needs, there is no right or wrong.
@ 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.
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.
As a unity dev there is some misunderstood on video but it's normal bc unity has some issues when they advertising their product. You can find free first and third person character package (everything included like animation, code model, camera etc) and made by unity but it's hard to find if you don't know it. Unity has so many tools to making video game easier but if you don't search, it's really hard to find. Unity tries to support old system, i can understand them but newer ones don't know difference between old one and new one. Most of time i even don't know which is new. In fruits example, it's basically oop and inheritance. And c# supports it. If I understand correctly, in unity, you need to make that hierarchy.
I'm trying to make relatively complex project for indie (shooter-rouguelike) with Unity for 1.5 years already. And Unity choise was a bad... No. !BAD! decision. Why: 1. Mecanim is bullshit. Anim state machine quickly become overbloated and uncontrollable. In UE4 you have more options to control and built exactly what you need out of box. 2. No animation / fx support (like UE4 AnimNotify). Want to play particle system or sound in the middle of animation and shut it down at some point in time? Implement your own system with Animation Events. 3. No physics/anim blending. In UE you can just do procedural hit reactions out of box with blending physics and animation. In Unity you have to use IK or third party solution. 4. Pure audio system compared to UE4. 5. No gameplay framework. Even no normal character (capsule) controller (like UE4 CharacterMovement). Implement your own or use third-party crap. 6. No UI framework. Unity's UI is not a framework, it's 100% pure pain. 7. No AI. No sensors, no behaviour trees. There'are third party solutions, but their quality in 95% cases vary from 'bad' to 'totally garbage'. 8. Bad pathfinding system. 9. Visual Scripting (ex-Bolt) is relatively bad cause there is no easy support for C# events to build solid flow for async logic. On the other side UE have a battle-tested solutions almost for any feature you may want in your game out of box. 90% of time I implement gameplay engine features and extensions instead of creating game. Ask yourself, is that what you want?
@@enikey87 You can literally press record on the animation and do the things you said by unchecking boxes. No need to write your own fancy solutions. Also nowadays there is things like Timeline to better control these things.
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'm finding Blueprint an easier system to learn programming with than trying to learn programming concepts and C# syntax at the same time. I'm a perpetual beginner coder so not coming at this with much experience, but I must say Unreal for me has been a much nicer experience than Unity, having primed myself on Unity for a few months first.
There is a bit of a weird thing with Unity tutorials/guides out there that probably helps make things easy to understand when beginning, but also hinders "noobs" a lot: The typical approach most tutorials have with Unity is to assume that every bit of code is going to be a *MonoBehaviour*; this is what you describe when you talk about "attaching lots of small modules to an object". A *MonoBehaviour* in as simple words as possible is code that is attached to an object in the world. And most guides I've seen assume that all or nearly all code should be attached to an object in this way. This means that in order to have a game system, you'll usually attach some bit of code to something and that will result in the system working with that bit of code. This works fine, and I'm sure entire games are created with this approach but as I learned to use C# while working on a game, I slowly figured out that it is not the easiest or most effective approach by far! Instead, the way I now look at it is the following: a *MonoBehaviour* is an *interface* (not the technical C# term) between an object in the world and the code. The code itself mostly resides in standard C# classes that aren't really "somewhere" like game objects are... it's just there in the code base, ready to be used when called upon. So I no longer have 50 scripts attached to each object so it will do what I want; instead I might have 2-3 that hold that object's specific properties (like movement speed, appearance, etc.) and whenever something needs to be done with the object, some bit of code not attached to an object will exchange with these object-interfaces to get info or affect its properties. Why is this important? Well first of all, having a thousand small things attached to each object in a game makes it extremely messy... as soon as you have more than a handful of "things" in the world, remembering where the bit that controls X is held can get confusing! On the other hand, when things are "held" on the more abstract code side of things... well they have a name, and you can find them in an instant; plus things like F12 and Shifr+F12 in Visual Studio mean you can find all the places where they are *defined* and *used* in the blink of an eye. But more importantly, when you are debugging your code, you don't have to spend hours scouring information in Unity and looking up what each value is on each object: Visual Studio has incredibly powerful debugging systems built-in that will let you see stuff happening in real-time or in slow-motion (line-by-line through the code!). And if there are any errors in the code (something that is not assigned, not "connected" properly... well it will usually come with a precise comprehensive warning instead of the dreaded "Null Reference Exception" that plagues all beginner unity debugging sessions! My point with all this is that your experience coding with Unity, and the drastic difference you saw with Unreal is in large part about how tutorials/guides approach things; and not entirely down to how the system itself is designed; and those "standard" approaches are geared towards keeping things simple to learn rapidly, *not* towards making things easy to actually *use* in the context of a real project. In a way, Unity tutorials are using something that could be compared to Unreal's Blueprint system if you stretch things a lot: it's simpler to understand, but ends up limiting what you can do and often requires a lot more work as soon as things get a tiny bit complex. PS: For anyone looking into Unity, learn about *ScriptableObjects* and *Inheritance* early, and get comfortable with them... they are amazing! You will miss-use and over-use them when you start, but that's just part of learning.
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
Good choice! Especially for someone who's not from software engineering background, unreal engine has enforced some best software engineering practices like design patterns and project structure for you out of box. Bluepring visual scripting is easy for beginners. Good graphics out of box. Remember it takes time to master coding, I'm talking about a couple of years. However, regardless of which engine you choose, even with blueprint scripting, you will still need to learn how to code. You won't go far without knowing how to code. 2 cents from someone spent years using unity but switched to unreal and never look back.
post processing is very easy to add in unity to make it look just like unreal. There's some easy tutorials on making unity look like unreal. I'm very happy using C#, and I think I can get more done with unity. And I have tried both engines.
interesting to see a novice viewpoint describing basic programming concepts (inheritance, etc) through the lens of a gaming tool rather than the underlying language.
The problem is scalability. Unreal can be tweaked by the developer itself and add functionality if you know what you're doing. Also, it's performance is better in the 3d environment. Unity is great for low-scale projects and prototyping, Unreal is more powerful but you need the knowledge.
not true at all, both can get great performance. maybe that was true of Unity like 5-6 years ago but not anywhere close to true today, it really comes down to the knowledge level of the person coding and not really either engine.
Btw unity recently added new coding guidelines to utilize automatic parallelizing of tasks. Which allows even smaller dev teams to have highly multithreaded games. UE is using the C++ approach here, so you are on your own when it comes to your own logic.
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 :(
I think Unity's script components being broken up is more of a community based thing. Unity has built it's brand as a free entry level to game development for much longer than Unreal, it's community was built from the ground up to try and accommodate beginners, so multiple interchangeable script components for users to identify and understand in bite sized chunks has been sown into the culture. There is nothing stopping you from putting it all into one script like unreal. But you'll find that component system when you are working with the asset store.
Clearly you missed the "Learn" tab in the Epic Launcher. lol. It's nowhere near as good as Unity's lessons, but it does exist. I think your point is very good - the framework you get with UE4 is just so much better to hit the ground running with. Granted, coming from UDK (UE3), I think UE4 is SUPER bare bones. It pissed me off how much is missing that they used to have in UE3. If Unity is worse than UE4, I'd never touch it.
I found the tutorials before this video. My problem is it loads you up with a lot of touring the interface before getting to the "how to create [your goal]." I'm stalling out, wishing the tuts would do interface teaching while creating something. And the guy I'm watching flashes his mouse all over without highlighting where he is.
yes there is a learn button but some of the lessons are so old that things have changed or moved. a few lessons i tried to do the free assets didn't exist any more.
c# vs c++ is wrong premise, since UE uses blueprints for these things. (you just don't get cpp part of unity with unity). UE hierarchy could be implemented in Unity and "Unity scripts" can be implemented as components. Both are just ways to organize code. Generally speaking, I agree with your video.
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.
Not sure I agree with the view on small specialized scripts in Unity vs. a big script in Unreal. Unity has GameObjects and MonoBehaviours. A MonoBehaviour is a script that you attach to a GameObject. You cannot actually inherit from or modify a GameObject, you can only expand it with attaching MonoBehaviours to it. On the other hand, Unreal has Actors (also more specialized subclasses like a Pawn) which is pretty much the equivalent of Unity's GameObject. The Unreal equivalent to MonoBehaviour would be an Actor Component. You can attach as many as you need to your actor class and can perform any kind of task that your character needs to do from there. This is probably a more reusability friendly type of approach, and while you certainly can just stash everything in a subclass of Pawn using components is probably a lot more Unity-like.
lol nice man, thats the video ill be linking to people from now on hehe I tought the same, Unity is the one i usually reccomend to people because the comunity has sooooo much to offer to a beginner, its really insane, and its definately a engine i like to mess around and hopefully develop some small project, maybe even relase a solo indie game in the future; while at the same time, Unreal is the one i wanted to pursue more seriously, because of the kind of projects i want to be able to work in the industry, and its the one i am more invested in and buying courses for, in a more professional note rather than personal on Unity's case. It was nice to see your experience and i wish you the best in your journey! o/
Unity's HD Render Pipeline is getting closer to Unreal every year, but I'll agree that Unreal is better for certain types of 3D games. Unity gives you a bit more customization, which I need currently, but I've definitely been tempted by Unreal more than once. xD
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!
for me it's simply the whole philosophy and pipeline behind each engine Architecture , I find Unity logic soo understandable Unreal is so confusing and restrictive . In unity if you don't know what you are doing you will make a mess but it's still a thing if you know what you are doing then everything is fine. In unreal if you don't know what you are doing then probably you can't build anything .
f*ck this video is GOOOOD! well, my thoughts on your video may be heavily biased because we share the same opinion 😅 but yeah, I hate that people say that unity IS the go-to engine for new indie devs, when there are an f ton of reasons of why one should choose unreal over unity... who says that completely misses the point that for a lot of people coding isn't something desireable, sometimes even actively avoidable... and blueprints are RIIIIICHHHHHH. they are basically plug n' play snippets of scripts that will work and do the magic for you. blueprinted scripts can easily and quickly compile for any platform, and depending on what type of indie game you want to make, blueprints WILL suffice you. unreal is in fact harder to master, because of the c++, and it is all that pain you mentioned in your video: poor documentation, a crappy compiling, the workflow can be annoying... but for indie developer using blueprints only, unreal works clean af. anyways, thank you for your video :D good luck on your learning process! :)
I wanna mention that in Unreal u got this option to convert your blueprints into the special c++ almost as native as c++ hand coded and the performance even with 100k+ rendered actors is so small in so many sections that its incredibly accesable even with huge projects to make games using blueprints, altho most of ppl who make games in ue are using blueprints and c++ but each for specific task etc
18:46 and you just discovered OOP, it's probably easier to notice if you're taking the developers way first instead of the Unreal path it helps understanding these concepts, but I can understand that coding isn't pleasant for everyone (even for me and that's my job....)
Whatever game you imagine is where you will go. I haven't tried Unreal much. I've been happily using Unity for years. But if it ever drove me to Unreal or Godot I would jump engine.
No! Both c# and cpp are oop langs which means that inheritance pattern you were mentioning is also applicable to c# its just ue somehow expose it as an editor feature? Its weird but in c# classes do inherit base classes and implement interfaces to manage similar tasks which brought us to polymorphism you can swap objects (instances of classes) implementing or inheriting a common interface or class
Half the fun in developing is troubleshooting. But yea, as a beginner it is rough when you are having to troubleshoot from the start and don't know what you're doing at all.
omg this was so nice. thanks for sharing. could you tell me where did you get the animation and modeling lowpoly tutorials for blender to put in unity? and unreal too? i mean what you did there is pretty good , considering you're not an aritst.
Hi i just wanna say that in a part of the video u said that u bought a move assest from the unity assest store, but there are a lot of free stuff in there, like the move character assest for free (I don't know if it's as efficient as the one that you bought) Ur video was really great, thanks!
Solo developer here. Does any game use the Unity HDR pipline for games?. Have used Both engines for the last 5 years and keep coming back to Unreal. Getting to the stage where I know enough to complete my VR Flying game ( I hope!!!) in Unreal or Unity, choosing Unreal as I find it more polished in terms of work flow and consistency. Also EU5 nanites are great (VR is not ready though). Using Houdini to import terrains and find its much easier in Unreal. Both great engines though .
Bro, I am also thinking to learn UE but have some hesitations about mobile side. Everyone around me was using unity and there are tons of tutorials related to Unity. But UE has less tutorials, less examples, less mobile... So what do u suggest to me? Which side should I jump into? I want to focus on VR especially in the future.
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 UA-cam 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.
Unity is for developers, Unreal is for designers. Unreal Engine has been making a push to cut coding out of game development for years. This is a good and a bad thing. The question of whether Unity or Unreal is right for you is more of a personality thing. One will clash with your personality and one will sync. Do you want control over how your game gets implemented? Go with Unity. Do you want to follow a structured and effortless pipeline? Go unreal engine. Unreal Engine is not true open source. You are allowed to modify it to fit your needs BUT there is virtually NO support to do so and the developer's will branch off new versions on their own. It's not a collaborative open source program. Debugging and coding in Unreal Engine is an absolute nightmare.
Your first point reminds me how that kind of thing exists in many industries. Example, the old wisdom is UCLA film school is for artists, USC film school teaches you more businesss.
@@hermes6910 Source access to a game engine is overrated. If you need to go into the source to implement a feature...the game engine sucks. I wouldn't recommend anyone go into the source on unreal engine for two reasons. One, coding in unreal engine SUCKS. You have to literally recompile the engine sometimes to see if your code works...and that's when you're NOT editing the source... It's also written in c++ which is great for collaboration but even large studios don't have many people that are that involved in coding so C++ just becomes a pain in the ass. Two, you now have to update your engine changes every time UE releases a new version. "Unity is good for mobile" is such an outdated and misguided philosophy. Quite frankly, it's just blatantly ignorant. Unity has had a (very slight) edge in graphical capability for a few years now. Unity is capable of running with the same performance as Unreal out of the box and much better performance in specific test cases with its DOTS framework (if you have large numbers of programmed objects). Like I'm sorry but if you think Unity is only good for mobile, you have no idea what you're talking about. I'll remind you subnautica was made inside Unity. A lot of people might chalk subnautica up as a small indie project but...it wasn't. It's one of the first games ever to take place almost entirely under water. No game engine is equipped out of the box to handle this (pathfinding for instance is usually done with navmeshes which assume a 2D plane). Neither Unreal nor Unity at the time was built to handle large open worlds. The devs made the decision to go with Unity because it's MUCH easier to adopt the engine to suit your specific needs. If you're making a FPS or a classical third person character game, Unreal Engine has those presets built for you out of the box. If you're doing something more unique...Unity is MUCH easier to work in. That's actually why Unity is more popular among Mobile users. Mobile games tend to be very different from one another.
@@hermes6910 It sounds like she's not using source much. Source code isn't just c++ it's modifying the engine source code directly which is generally unnecessary. In the select few cases where it is somewhat proper...I still don't recommend it because it can make updating to a new engine version a nightmare. There's just not a lot of benefit to working with the source code unless there's a engine level bug or something... I coded in UE primarily too over blueprints. It is just objectively terrible compared to Unity. I'm talking like literally 10x faster iterations in Unity compared to Unreal and next to no performance difference. If UE were made from scratch today...I imagine they'd go with C#. For the longest time there was considerable advantages to using c++ since its lower level but that's not really true anymore.
@@hermes6910 lol... Lumen is a mess right now and I wouldn't recommend anyone use it. Nanite and Lumen are both experimental within ue5 which no one serious about game dev would recommend because ue5 is in early access. Additionally...it's often overrated. Nanite is essentially a replacement for LODs which is nice but LODs also work pretty well. Nanite is only remotely useful for extremely large open world projects. Blueprints do have faster prototyping and I really didn't argue against that. Regardless most people will move a lot of code into c++ and that's where ue struggles. The phrase "Unity is good for starter/mobile" is where I just immediately know the person I'm talking to has no idea what they're talking about. That's all marketing and community driven presumptions and is just absolutely not true. There is next to no performance difference between the engines. There have been demos for Unity that are just as good or better than unreal. The highest end graphical performance demos actually tend to favor Unity (Arch Viz). It is true that Unity is more commonly used for mobile but that is not because it is not suitable for AAA games. Subnautica was a Unity title and one of the smoothest and most impressive games ever made. If you think Unity is just for small or mobile games you are completely lost. Also, I have never and would never claim Unity is "better" than unreal. They have very different advantages and disadvantages.
One big difference between them is that the UE compiler only recompiles stuff that it needs to. Unity doesn't have that. You're recompiling the entire project every time something changes. This might not make much difference in enthusiast level machines, but when every single change requires waiting a couple of seconds, it becomes old fast.
If you set up your assembly definitions, that isn't a problem. Unity also only recompiles what's necessary - unfortunately, most people bundle all of their scripts in a single mega-assembly which means that you have to recompile everything when part of that assembly is modified. I've actually found Unreal much slower, but I'm not as familiar with it, so I may have been missing similar functionality.
See where you're coming from in terms of accessibility to people new to game creation, however I feel the important thing to get people sticking around with their project is making something happen on the screen. Unreal has that out of the box, you can have a shooter working in Unreal in what, quarter of an hour? In Unity you have to implement your own input system, implement your own movement system, etc etc - it takes a long time before someone gets the "wow I made this" that is likely to keep them around and fired up to learn. Unity however monetises their product through the marketplace primarily, so it intentionally does not include basic systems required to make an actual game in the hopes you'll hop on the marketplace and buy the systems one by one so they can claim a percentage. My blood runs cold at the thought of prototyping new ideas in Unity because I know I'm going to have to start from scratch on movement, animation, health systems, physics, AI, and so on. C# is a huge advantage in that it's pretty much human readable for the most part, and pretty intuitive. But outside C#, and certain specific genres (mainly certain types of 2d games) Unity is in my view actually less accessible to a complete newcomer.
About the performances of blueprint, isn't nativization a solution for most of that issue ? I mean, i've seen comparisons between C++, blueprint and nativized blueprint and the results are impressive, it's in the ballpark of C++.
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.
unreal here too, As a person that used unity for quite some time I know how painful it is to manage stuffs and some functions or systems even have to develop from scratch which isn't good if we talk about long-term development. Meanswhile most of basic functions and systems has been laid into the base UE4. One day I'll make a game that's much complicate and hard to handle which is too big for basic unity, of course there is counter messure if I want to use unity which is to develop my own systems for those stuffs. Also it's not a pain to reference objects in UE4 compared to unity.
@@hermes6910 the issue with that is that while blueprinting is good and im really good at it, it adds a lot of overhead when running the game and makes it really bad for medium to big games. I plan to finish a few small games before moving to something much bigger and blueprints just wouldnt be optimal for it. On the other hand, I know next to nothing about c++ and I know a ton about c#.
@@saltyman5603 It's a huge risk to code in a language nobody else uses and can help you with. I really wouldn't recommend it, just because the slight syntax differences between C# and C++. If you already have experience with Unity and C# and know your way around the Unreal API through Blueprints, learning C++ really isn't that hard.
oh darn.. but i wanted to know which should be used so i could ignore the other one!!! it's so case specific one really has to take a look at both and see which one will do the thing you want...
I've always stated, Unity is like Linux. You have to set up everything to get the results you want. Unreal is like Windows/Apple, everything is ready and polished. You can get good graphics out of Unity, examples are Book of the Dead, Escape from Tarkov, Ori and the Blind Forest, Ori and the Will of the Wisps, and yes also Hollow Knight. Unreal has a lot of the features and polished look you need with just a few clicks. As a game developer, I prefer Unity over Unreal, however they both have their pros and cons. Side Note: Unity also has visual scripting. You just have to download/enable it through the package manager.
Thanks for a great vid! Im starting out in Unreal...do you think I need to learn C++ in unreal first or learn blueprints first and then learn c++ when blueprints are not enough?
I've found that blueprints are a much easier way to start learning Unreal Engine. There's a lot of good tutorials out there, and I find learning by doing works well. WIthin a day of effort, you can make a simple endless runner, or random maze game. I picked up the basics doing those two. There's also huge tutorials like CodeLikeMe open world tutorial, which stands in excess of 440 vids. When it comes time for fine tuning the performance of the game, then you'll find C++ to be your friend. It may be more complex, but it's incredibly powerful. Personal opinion, blueprints are great for designing and testing. I prefer C++ for the final work. It's almost always quicker to execute C++ code vs blueprint interpretation.
Definitely start with Blueprints! I'm a software professional, and I genuinely think Blueprints are fantastic. As you say, use them as your main scripting tool, then approach C++ later if it becomes necessary.
EDIT 1/9/22: Wow, didn't expect this video to hit 100k views. I have seen a lot of comments clarifying mistakes I made involving the descriptions of c# and derived classes - thank you for that! This project/video was from the standpoint of a complete beginner to coding so there are a lot of rules to learn and systems to understand in a short time period. To me, at the time, they seemed to function different so it was something I thought I should mention. It seems that at the foundational level though they aren't too different in that regard. Either way, I hope the insight from a beginners point of view was useful to some people out there. Happy new year and good luck coding!
Hey everyone, thanks so much for watching this video. A few people have expressed interest in following my content in the future. I am actually a UA-camr on a different account (AsuraPsych) as my primary job and this was a fun side project I did to explore the world of coding. I am a graduate psychology student with Ph.D. applications in the works and after a few months of coding I found that it was really fun but I don't think it is something I have enough time to dedicate to to make any long term projects. I may come back to coding in the future but my passion for psychology has been taking a lot of my time. That said, I hope this vlog was helpful to you as I put in as much possible effort as I could to share my genuine and authentic thoughts as someone who was new to coding.
Coding is a fantastic path for those who choose to pursue it. With dedication, heart, and passion, you can learn game design and coding. For me, it has been a great side hobby but the odds of it becoming anything more than that are very slim. I simply wanted to inspire others and show that even someone without a background in coding or game design could get started if they put in the effort. So if game design is something you want to make a career out of, I hope you pursue it with all of your heart.
Thanks again and good luck on your game design/developer journey.
💜
I'm in the opposite situation. I'm a programmer with a degree in game development and I studied psychology to create simulated emotions in unity, lol.
What you're describing for Unreal with the child-parent hierarchy is inheritance, which is not specific to Unreal, not even to C++, but is one of the pillars of objects orientated programming (OOP), used in most programming languages in some form. C# as a language is no different from C++ when it comes to these features (I mean there are differences, but they are not fundamental). Now when it comes to Unity, the component model is central to the engine (and by the way other engines use components in a similar way), and you're right that it is a different way to work if you compare it to the inheritance model. Using components is encouraged by Unity as the default way to do everything. From what you're describing it is not the case with Unreal (I haven't used Unreal). But you can do exactly the same as Unreal with Unity, use classes (that are components or not), that derive from other classes. You can do it because it's part of the language C#. And the opposite is true, even if Unreal doesn't use components the way Unity does, nothing prevents a coder from creating a component system in C++ and use that. So none of these differences are language specific, but it has to do with the way the engine wants you to work (which you can always not follow, but it may not be the best to fight the engine if you chose it in the first place).
Thank you, you said basically everything I had to say. I want to add... I'm pretty sure Unity also has starter project templates. They are in The launcher.
Totally what I was looking to comment too! And it's worth mentioning that there's a principle stating that "composition over inheritance" should be the way to add on more functionality to an actor. There's a metric ton of reasoning and experience behind that simple statement, and I just think Unity is staying a little bit more true to that. However, there's a time and place for both, and while Unity doesn't go for this approach in their tutorials, it is expected that inheritance will be used a lot in Unity too. I honestly use it within 5 minutes of starting a new project every time. I think Unity in part just try to avoid teaching beginner devs about OOP in a 10-minute standalone tutorial, and try to cater more to one of the two for simplicity. In any larger Unity project, inheritance should be used as well imo.
@@kennethkrist Every Unity developer uses inheritance whether they realize it or not. Every component class inherits from MonoBehaviour, and gets certain functionality automatically if you decide to implement them.
@@Gillissie Well, yes of course. But I think that, being a default template for scripts, isn't exactly the same as a developer counsciously choosing inheritance as a tool to solve problems, which is the point I'm trying to get across.
@@kennethkrist That's the point though... if the developer is learning about how each engine wants you to work, then realizing that Unity's component model is using inheritance by default would create an "ah ha" moment for new coders like the guy in the video, who somehow thought that Unreal was using some kind of unique technique.
This was very interesting to watch. I am a professional game developer (for over a decade) working on a proprietary game engine. I know both C++ and C# very well, but never built a game in either of these engines. However, I have modded a number of games built with these engines and have therefore spent countless hours working with them. I think what you said about each engine lending itself towards different needs is spot on, and that neither engine is better than the other overall. I would like to add a few things that I think were not clear from this video.
1. Inheritance vs composition. The video seems to imply that inheritance is related to C++ and composition is related to C#. Both languages have both of these features. The difference is in the designs of the engines and how they intend people to structure their content. Neither engine fully locks you into one choice or the other. However they do steer you in a direction, and fighting against expectations of the engine would make your life a lot harder.
2. Development time. If you look at successful games built using these two engines, you will find a fairly consistent pattern. Unity games are usually built in less time by smaller teams. There are exceptions of course, but this pattern holds true most of the time. Actually completing a game is a big undertaking. Doing so in Unreal is a whole extra level of difficult. You are signing up for a lot of extra work if you choose Unreal. This is primarily due to UE's poor documentation and limited community support, but also things often just require more steps to build.
3. Performance. Unreal performs better than Unity. Also C++ performs better than C#. If you write the same exact code in both languages, the C++ code will run faster. (This is well tested and documented by many people.) What this means is an Unreal game can effectively do more at a given FPS than Unity. This could be more complex logic, higher quality graphics, whatever. You made a comment that blueprints do not perform as well as C++ in Unreal. While this is true, they generally still perform as well as or better than doing the same thing in Unity in C#.
P.S. If you want to make a multiplayer game, Unreal has multiplayer capabilities built into the core of how it works while Unity basically makes you write your own thing (or buy something someone else wrote) and tack it on. I find that to be one of the biggest missing features in Unity.
Just wanna add that your point on performance while true on the surface, doesn't apply to how Unity uses C#. It really depends on how it's compiled. And for this reason, Unity comes with two compilation modes, Mono, and IL2CPP. Note that IL2CPP does mean that Unity compiles to C++ equivalent code. By default, Mono is enabled for faster compilation times, but the standard has been to switch to IL2CPP for release builds all the way since that compilation mode was added 7 years ago. Mono is more useful for quicker development with faster compilation, which is why it's the default one. And if that wasn't enough, the performance gap has been closing rapidly with both C# and Mono upgrades. There's been numerous benchmarks showing that using Mono in Unity is catching up to IL2CPP at a pace that hardly makes it necessary to do IL2CPP anymore. And frankly, that's not even mentioning Jobs, Burst compiler or ECS. While ECS isn't in a production-ready state yet, both the other are. And burst has very much showed it's proficiency. Unity's burst compiler can take calculation-heavy C# code and convert it to native instructions that in most cases are far superior to the standard C++ equivalents, given some very overcomeable adjustments to how the code is written, burst is very much a bleeding edge tool.
He forgot to emphasize performance, like every other Unity vs Unreal Engine comparison; the most important part that distinguishes the two!
Plus, while both engines are free, you still end up paying more for Unity than URE!
URE is a much better engine out of the box, than spending months buying/learning and struggling with Unity, which is why we still get horribly performing large open world games with unity rather than with URE... Sure, there are certainly competent developers that have brought us incredibly polished and optimized games from Unity, _(Genshin Impact/Edge of Eternity/Sable)_ but they are only 30% of the games coming out in Unity.
Even though I'm not a developer, it does not mean that I'm not heavily invested in the Unity engine as I prefer indie games more than AAA ironically enough as more indie developers use unity than URE which kinda sucks as too many indie devs try to fit the engine to their ambitions rather than the other way around as unity does not perform as well with large scale open 3D worlds!
I wish Unity devs would take the rose-colored glasses off and get to know Unity's limitations so that they can be overcome and help better the engine!
@@kennethkrist I don't know if Unity has fixed this, as when I last seriously used unity was late in the Unity 5 cycle, early yearly versions. But it's performance is not down to C# vs C++, but how badly optimized much of the Unity engine is. (Tbh I think that the Unity Engine itself is probably mostly c++, but that's just a guess).
At least when I last worked with it, every single light source required a separate rendering pass. It's almost trivial to send multiple at once, but no...
And let's not speak of Garbage Collection. The problem is not the Average time spent on GC, it was that Unity will make it happen seemingly randomly, and cause MASSIVE spikes in frametime, 10'-100's of MS!).
Or loading, when loading a level, it would "lazy load" most of the stuff, so the first time you see something, you guessed it, lagspike...
As for hot-reload, yeah, forget it, it requires so much care when writing your code, and adding extra code, and can often trick you into falsely trusting code/wasting time trying to get stuff to work...
And UE4 has a similar system, if you set up everything properly for it...
@@kezothehappylurker787 I think there is something important to consider which likely is a big reason many indie games tend to choose Unity. Once you learn how to use it and accumulate a good set of plugins/assets from the store, it is faster at that point to build games than it would be with Unreal. Unity has that larger initial time investment to get started, but you only have to do it once. Assuming you have a firm grasp of C#, C++, Unreal Blueprints, etc. (all of the related development languages and technologies), C# will be the the option that allows for the fastest development times. This means you can do more with a smaller team in a shorter period of time.
There are indie games that choose Unreal and are quite successful, but they are less common. When compared to Unity, they generally either require a larger team, create a smaller game, or take a long time to get a game finished. However, they have a significant advantage once they have a game built in Unreal, which I think was touched upon in this video. They stand a much better chance at having an organized project that they can continue to develop and add features to rather than the typical unmaintainable mess people tend to get themselves into with a Unity project. Although you can make a mess in either engine, it is a lot easier to do so in Unity. I think this is something people don't appreciate the value of until they have experienced the pain of trying to work on fragile code where anything they change affects (breaks) everything else.
@@crystalferrai Thanks for the informative feedback with your comment, I have learned a lot from your post, thanks!
Im developing a game in UE4 as a first time dev, exclusively with Blueprints and it's been fantastic. I found everything to be simple and if there was a tool that's needed, it's included out of the box. Normal coding was a huge turn off for me and im glad Unreal Engine has a battle tested alternative.
I would recommend you to keep trying and learn c++ its such a game changer, combine a main c++ class and expand on it with blueprints that is the way to go.
@@MrNPC multiplayer is more easy in unreal even with c++, it can be frustrating for sure. But if you have some basic knowledge of how everything works with replication you will be good to go.
There are enough tutorials out there, but I would just recommend people to use the docs. The docs look complicated, since they don't always have code examples. But this is the way to go.
Most people end up in some rabbit hole where they need to keep watching tutorials to make things for their game, this is something you must try to avoid. And that's why you need to learn how to use the docs.
Overall coding experience very overwhelming at first, but after sometime you should be good to go.
@@MrNPC I could be mistaken, but I think thats possible through blueprints. I've seen tutorials on it at least, but I'm personally not making a multiplayer game at the moment so maybe there's more to it that isn't captured through blueprints.
@@gerardoob3164 isn't that what I said? Make a main c++ class and expand on it with blueprints?
@@gerardoob3164 you usually always make a c++ class and than add all the blueprint to that, that way you can easily add c++ code and it doesn't take time at all to generate a class...
@ 17:16, what you are talking about is called inheritance in programming. You create a parent class that holds everything you need, then child classes that extend upon that.
It's really great for keep code clean, since you can add new functions to the parent and see them reverberate in the children.
UE4 certainly has a steeper learning curve, but as a development tool, Unity doesn't even come close overall imo.
I use Unity for VRChat content, and have been developing in UE4 for a couple years now so I've gotten pretty familure with both.
UE4 is more performance focused out of the box, comes with way more polished subsystems (like the built in multiplayer features) and the biggest thing for me is the blueprint editor.
The performance of blueprints is a non-issue. Blueprints are not for "prototyping" your c++, You're intended to use both at the same time.
The engine is essentially built around the logic of blueprints, which is why the c++ side may seem a little strange and difficult at first.
Build performance heavy low level systems in C++, then stich them together in the blueprint editor. That's why UE4 doesn't document too much about it. They're assuming you have a pretty good reason to be doing something in c++ and thus know how. You can even program your own nodes to be used in the blueprint editor.
This is really important because the power of blueprints isn't that that they're easier than programming, is that you can create absurdly complex logical systems that can be intuitively understood just by looking at them.
Because of this, I'd have to very much disagree with your assessment that Unity is better for solo devs. The scope of content I'm able to create with UE4 is legendary compared to Unity. Once I establish a decent project structure, I don't get lost anymore and can easily create larger and larger systems.
In my experience, UE4 has a higher learning curve because it's a better tool. Sure, Unity has a lower bar of entry, but that's because it has a lower ceiling too. If you want to make performance focused, multiplayer, or very unique games, you'll eventually find yourself deep in the backend editing and hacking at the engine to make your own plug-ins just to get get what you want to work.
Cities Skylines is a good example, built in a heavily modified version of unity because they realized partway through the project it was too limited to handle a lot of what they needed. That definitely took some complex programming.
One last really important note: C# is Unitys scripting language. The engine itself is C++. When you're programming in UE4, you're programming at a low level and are exposed to the engine itself.
In Unity you are just scripting, essentially pasting on little snips of functional code ontop. This is why there aren't tons of little guides for programming in UE4, if you're going to be building a game in just C++, you need to understand how you'd build and organize any other object oriented program in just C++.
i'm pretty sure unreal engine doesn't support a game at the level of citites: skylines as well and you need to make most of the in-game tools by yourself to work properly, and it's doesn't make sense to poorly document the scripting side of the engine and assume "you should know c++", but those things aside, i think it all comes down to which are you comfortable with, as an environment designer, i feel much more comfort in using unity HDRP than unreal, but there are things about unity engine that i really hate, modularity and HDRP not being unity tech's priority for example.
Leviticus, seeing that you have experience in both. I want to ask you which one you would recommend for my specific case. I have no experience with either, However I do have previous programming experience(although not in C# or C++). I want to develop games primarily for Oculus Quest 2. The first project I have in mind is a racing game for Quest 2 that would have multiplayer. I did see someone on reddit say you can get more frames on Quest 2 in Unity. Anyway Was curious what your thoughts would be for this project.
Thank you.
As a development tool, Unity far exceeds Unreal. People don't think this because Unity has a lot more... "beginner" tier users which leads to a lot of content made in Unity that is low quality, which some people incorrectly then attribute to Unity. The truth is, though, that Unity has tools that cater to the power level tier user that exceed Unreal's capabilities.
How has Unreal Engine ever been more "performance focused" than Unity? Unreal Engine games/editor require a far better computer to run.
Unity is used for almost every mobile game for a reason. It makes no sense to argue that UE is more performant.
Unreal Engine is not magic. It has the same issue with draw calls and overdraw just like any other engine.
@@St4rdog 100% agree, this is accurate
Wow! This is what I need. A beginner's journey and review on these 2 engines. Thanks.
It's been really helpful to me bro! Thank you for this breakdown, coz I'm just starting my journey as a game dev and it's actually so hard to stop on one of the platforms without such guidance:)
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.
After weeks of searching I've finally found a super helpful video as I continue to dabble around in game design. Thank you so much!
So which engine up chose?
@@becauseiambatman2019 I chose unity because:
1) My uncle's a Game Dev in a company and he uses unity. To get potential work, I should try out Unity, plus I'd have guidance.
2) More coding, tbh I wanna learn C# well.
It is a rare thing these days to find a video on this subject that comes with a subjective (as is always the case) but honest opinion on the strengths of both engines. Congrats.
Damn dude, you killed it. Good job.
I have to disagree, I floundered with unity on and off for 2 years with nothing to show for it but with ue4 I feel like I can figure out anything easily and work on my own after just a few months.
To each their own though :) most people would agree with you
Thats cause u cant code shit..... Jk
because Unreal barely requires knowledge to get something done. Unity is harder to setup but gives you more freedom to make awesome stuff. Unreals pipeline is also pretty limited, most productions utilize the barebone frame of unreal instead of what you use, developing it into a partly custom engine. Even Epic themselve build from that a custom unreal engine because it isn't possible to do fortnite with the out of the box engine. In unity it can be easier done.
@@CptBlaueWolke Thats really interesting, thank you for letting me know. I'm going to look in to what you're saying some more :)
i found that learning blueprint in unreal is really hard not good enough documentation. With unity i was able to set up simple drag race between two car in an hour . Make no mistake unreal is good at level designing as compared to unity but documentation sucks
@@ajitteshballoria4852 you are so right!! I have been mentoring someone in unreal and their blueprints we're all messed up between the bad docs and the outdated tutorials. I never would have learned it without paying for quality tutorials and always making sure that things I read are up to date.
I have no idea why though, but unreal just clicked for me in a way unity didn't. I do understand that it's a much steeper learning curve, but I would still recommend people give it a shot at least.
I really appreciate this video and you being fair to both engines!! Awesome vid!
Very much useful bro. I am really interested in getting into game development but as like you I just finished computer science engineering, and i had no idea on which one to choose from. But I am aware of both c++ and c#, so think I'll start working with unreal
My biggest tip as I too approach this from a non traditional background: there actually IS a ton of information on Unreal Engine. In fact, I'll make the perhaps unpopular statement that you should rely on what Epic Games releases to begin with. How you name things, structure your game, all of the design aspects are so crucial to the game running correctly that you may pick up bad habits (even from some of Epic's own videos). The key is to approach their videos as a thought process, what are the specific tips on how to do things, but also how does what they're explaining apply to my own ideas and design structure? It's a pro and a con: Unity probably allows you to get away with more as a beginner, but if you're perfectionistic and want to do it right, Unreal essentially FORCES you to do so. It impedes on the concept of just sitting down and making something, but knowing you did it right is worth it, at least to me. Unity also seems to import 3D objects without as much complication as Unreal, however, this is purposeful by Unreal to ensure stability throughout a much larger application. Pain in the rear if you just want to get started, entirely necessary for a professional level project. Totally agree that Unity is more approachable. I just think Unreal feels more worth it and forces you to learn industry relevant concepts on software design and game design. Totally depends on one's own goals. Unreal C++ is not regular C++. Don't spend 2 months on traditional c++ like I did. It will help, but if you only read the chapters on inheritance, references, and pointers, basic classes, unless you're doing really technical programming thats all you really need prior to diving into Unreal specific programming.
Best introduction for a beginner for both game engines. Thanks Asura. I too am trying to figure out what game engine is best for me. Videos like this and tutorials are a massive help to people getting started.
First, this is a great breakdown, and very fairly approached. Obviously, these are the opinions of someone with no bias at all; rare thing. Also, great points. I agree on nearly every point, but I would actually recommend UE to a beginner. I used to say I recommend UE to anyone who will take the time to learn, but I've realized since that anyone who isn't willing to take the time to learn can use whatever because they aren't going to do much before they quit anyway. The one key difference that I believe make my opinion different that yours is a blueprints-first mentality. I've actually done software development for years and I love CPP. I love C# more as the language alone is concerned, but if I could use only one for everything I would choose CPP. For years I scoffed at UE because the whole idea of blueprints looked like a more cumbersome way of building CPP code, and I didn't understand why someone would take the time to hunt for those nodes as apposed to typing code, just to be limited to what the lego blocks offered them. I got pretty comfortable with Unity, and I liked it and I worked around a lot of the little bugs and such and I thought I was happy. Then I decided to learn UE; I mean actually take the time to learn it. Never looking back. However, the biggest surprise is how little I use CPP and how much I like working with blueprints. These days I only use CPP for things that I can't do in blueprint, like polling the state of the caps-lock. Performance isn't as good as CPP, but, as you mentioned, it doesn't tend to be a factor in the games I'm building. Anyway, I believe that UE and Blueprints is actually easier to get good results from than Unity and C# for an absolute beginner. Which is easier to get started with depends on which type of thing someone learns easier, but C# gives beginners a lot more rope to hang themselves with, and very little help compared to blueprints, and UE is far more developed, tuned, and reliable than Unity, so they're much less likely to get hooked by something that the engine does to work against them.
Last year after I got my associates I finally descuides I wanted to go into game design. I took a course in coursera that was in unity. It all was confusing and the lessons working in unity didn’t stick too well. While the unity lessons didn’t stick well, the lessons on getting into game development and business/ jobs was very insightful.
I learned I wanted to be a programmer. It’s gonna be hard I just wanted to know if it’s the right decision for sure.
Epic games has lots of paid internships and they’re known for using unreal and c++ I think (don’t quote me in that). But I’m still learning the basics and have been feeling a little unsure if this is the right direction for my life.
Thank you for the video. It was very insightful and made me feel more sure about learning c++ and unreal engine.
Epic games is the creator of Unreal Engine
Like a boss! best discussion on this big decision I have found. I'm leaning Unity, you gave me a bunch of insights nobody else has articulated.
Good video. I’m a unity dev and understand where you are coming from. Unreal is more for games but Unity gives you more room for business projects, mobile, AR, VR, and all the new headsets like hololens.
6:09 so as that says and use Live Coding. Allows you to compile changes to .cpp files in a matter of seconds and do it while your testing your game as well to make changes on the fly. This doesnt work well with headers but from what I've heard UE5 is set to implement that as well so it should be a nice time saver! Unfortunately the slowness at compile time comes down to the language itself, so normal compilation will always take awhile.
Where heave you heard about it? Header support for live coding has been talked about since it was originally added
if you think unity compiles quickly then you've never had to deal with compiling shaders
Good video thanks! Just to note, you can make unity scripts as big or small as you want for a single game object, you can have 1 big script doing lots of things or 10 single scripts doing specific things, it is up to the dev. You can also do the inheritance stuff, just like C++, it is not an Unreal thing.
True! It's actually recommended to break up classes into smaller one more often than not. It's basically just good coding practice. It's also not necessary to make all classes into Unity components. It's entirely possible (and easy) to have one component that uses 10 different classes without cluttering the Unity inspector. However, the Unity inspector is a mighty debugging tool that I'd recommend using to speed up development in any case.
Thanks for the video, was very interesting to watch. Good luck with your future endeavours.
Good video and good results for several months. As a Ue4 user, I want to add a few pluses to the side of ue4 that were not mentioned, but which are very important for game developers.
Ue4 provides good multiplayer out of the box, you can also do multiplayer on blueprints.
And probably the most significant plus is the opportunity to get a grant for the development of a game, I don't know if it will be issued in the future, but now ue4 has been giving grants for several years and I think this is very good support for indie developers when you want to do game development seriously and plan release the game.
If I was asked for advice on how to approach the study of ue4, then I would answer to start with blueprints, and switch to c ++ after understanding the ue4 network, because after the network you better understand the difference and the need for controllers, pawns, actors and other classes, especially them logical purpose.
I don't know English, it was translated by a translator
Can you recommend a good UA-cam video tutorial of how to do multiplayer with blueprints? Would really appreciate it
I think you've mistaken on one certain point. Complex gameplay and system is not tied to triple A games. If anything, it's the exact opposite. The difference between triple A and non triple A games are mostly in the graphics. The most complex gameplay and system are almost always found in the most graphically crude games, like Minecraft, Terraria, Rimworld, the original Dota, and even the games of the classic roguelike genre with no graphics at all but only ASCII instead. Where I don't think visual scripting like blueprint will be able to handle that level of complex game design.
The specific scripts for Character Actions or Functions.. That can be attached to an Actor in Unreal.. Are called "Interfaces" and "Components" 😉
Another problem with UE4 and the community is it is mainly used by AAA developers who are not going to be so open about things like best practises to use and tips and tricks of the industry.
Only two months? Impressive. Thank you and... Subscribed.
Unity released its Unreal leveler, the rendering pipelines. I use HDRP and URP with some awesome results. I agree Unreal has things built-in like post processing, whereas Unity you been to bolt on a lot of things using the package manager, but that approach allows you to hone the project from the start and not carry lots on unnecessary features right from the start. I create my own templates depending on what I may want to do, that saves time, but you are right, Unreal assumes you are going to do something right away.
I used to like that approach in Unreal, but now I specialise more, I don't want the clutter.
From the editor point of view, there are quite a few mundane tasks that are required that need automating like Redirects, having to resolve them manually in Unreal and some of the settings are quite hidden. I compare the editors, I feel Unity is more set for business whereas Unreal feels a little cartoony. The Grids in the scene and object editors annoyingly flash in Unreal, unchecking them is not sticky. In Unity, some of the floating windows are also not sticky, both annoying points.
As I sell a lot of packs on both engines, Unity wins with that process hands down, Unreal is more DOS like and manual Create a zip file of the project, open the zip, delete a bunch of folders, check all meshes are prefixed with SM_, materials Mat_, textures Tex_, upload to a cloud storage and provide the link. Unity is click a button, browse to the project folder, and click another button.
I think the choice of Engine is dependant on your needs, there is no right or wrong.
@ 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.
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.
As a unity dev there is some misunderstood on video but it's normal bc unity has some issues when they advertising their product.
You can find free first and third person character package (everything included like animation, code model, camera etc) and made by unity but it's hard to find if you don't know it. Unity has so many tools to making video game easier but if you don't search, it's really hard to find. Unity tries to support old system, i can understand them but newer ones don't know difference between old one and new one. Most of time i even don't know which is new.
In fruits example, it's basically oop and inheritance. And c# supports it. If I understand correctly, in unity, you need to make that hierarchy.
I'm trying to make relatively complex project for indie (shooter-rouguelike) with Unity for 1.5 years already. And Unity choise was a bad... No. !BAD! decision. Why:
1. Mecanim is bullshit. Anim state machine quickly become overbloated and uncontrollable. In UE4 you have more options to control and built exactly what you need out of box.
2. No animation / fx support (like UE4 AnimNotify). Want to play particle system or sound in the middle of animation and shut it down at some point in time? Implement your own system with Animation Events.
3. No physics/anim blending. In UE you can just do procedural hit reactions out of box with blending physics and animation. In Unity you have to use IK or third party solution.
4. Pure audio system compared to UE4.
5. No gameplay framework. Even no normal character (capsule) controller (like UE4 CharacterMovement). Implement your own or use third-party crap.
6. No UI framework. Unity's UI is not a framework, it's 100% pure pain.
7. No AI. No sensors, no behaviour trees. There'are third party solutions, but their quality in 95% cases vary from 'bad' to 'totally garbage'.
8. Bad pathfinding system.
9. Visual Scripting (ex-Bolt) is relatively bad cause there is no easy support for C# events to build solid flow for async logic.
On the other side UE have a battle-tested solutions almost for any feature you may want in your game out of box.
90% of time I implement gameplay engine features and extensions instead of creating game. Ask yourself, is that what you want?
Thanks for this.
so sorry for your pain...a moment of silence
To be honest, i'm using Unity since 2015 and not trying to be rude, but 99% of your arguments are wrong...
@@umapessoa6051 If I'm wrong please tell me your arguments against #2 and #3 in details.
@@enikey87 You can literally press record on the animation and do the things you said by unchecking boxes. No need to write your own fancy solutions. Also nowadays there is things like Timeline to better control these things.
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.
Unreal Engine also has its own bastardisation of C++. Entirely non-standard.
The 'fro is baller AF; thanks for sharing your input!
I'm finding Blueprint an easier system to learn programming with than trying to learn programming concepts and C# syntax at the same time. I'm a perpetual beginner coder so not coming at this with much experience, but I must say Unreal for me has been a much nicer experience than Unity, having primed myself on Unity for a few months first.
There is a bit of a weird thing with Unity tutorials/guides out there that probably helps make things easy to understand when beginning, but also hinders "noobs" a lot:
The typical approach most tutorials have with Unity is to assume that every bit of code is going to be a *MonoBehaviour*; this is what you describe when you talk about "attaching lots of small modules to an object".
A *MonoBehaviour* in as simple words as possible is code that is attached to an object in the world. And most guides I've seen assume that all or nearly all code should be attached to an object in this way. This means that in order to have a game system, you'll usually attach some bit of code to something and that will result in the system working with that bit of code.
This works fine, and I'm sure entire games are created with this approach but as I learned to use C# while working on a game, I slowly figured out that it is not the easiest or most effective approach by far!
Instead, the way I now look at it is the following: a *MonoBehaviour* is an *interface* (not the technical C# term) between an object in the world and the code. The code itself mostly resides in standard C# classes that aren't really "somewhere" like game objects are... it's just there in the code base, ready to be used when called upon.
So I no longer have 50 scripts attached to each object so it will do what I want; instead I might have 2-3 that hold that object's specific properties (like movement speed, appearance, etc.) and whenever something needs to be done with the object, some bit of code not attached to an object will exchange with these object-interfaces to get info or affect its properties.
Why is this important?
Well first of all, having a thousand small things attached to each object in a game makes it extremely messy... as soon as you have more than a handful of "things" in the world, remembering where the bit that controls X is held can get confusing! On the other hand, when things are "held" on the more abstract code side of things... well they have a name, and you can find them in an instant; plus things like F12 and Shifr+F12 in Visual Studio mean you can find all the places where they are *defined* and *used* in the blink of an eye.
But more importantly, when you are debugging your code, you don't have to spend hours scouring information in Unity and looking up what each value is on each object: Visual Studio has incredibly powerful debugging systems built-in that will let you see stuff happening in real-time or in slow-motion (line-by-line through the code!). And if there are any errors in the code (something that is not assigned, not "connected" properly... well it will usually come with a precise comprehensive warning instead of the dreaded "Null Reference Exception" that plagues all beginner unity debugging sessions!
My point with all this is that your experience coding with Unity, and the drastic difference you saw with Unreal is in large part about how tutorials/guides approach things; and not entirely down to how the system itself is designed; and those "standard" approaches are geared towards keeping things simple to learn rapidly, *not* towards making things easy to actually *use* in the context of a real project. In a way, Unity tutorials are using something that could be compared to Unreal's Blueprint system if you stretch things a lot: it's simpler to understand, but ends up limiting what you can do and often requires a lot more work as soon as things get a tiny bit complex.
PS: For anyone looking into Unity, learn about *ScriptableObjects* and *Inheritance* early, and get comfortable with them... they are amazing! You will miss-use and over-use them when you start, but that's just part of learning.
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
Good choice! Especially for someone who's not from software engineering background, unreal engine has enforced some best software engineering practices like design patterns and project structure for you out of box. Bluepring visual scripting is easy for beginners. Good graphics out of box. Remember it takes time to master coding, I'm talking about a couple of years. However, regardless of which engine you choose, even with blueprint scripting, you will still need to learn how to code. You won't go far without knowing how to code. 2 cents from someone spent years using unity but switched to unreal and never look back.
post processing is very easy to add in unity to make it look just like unreal. There's some easy tutorials on making unity look like unreal. I'm very happy using C#, and I think I can get more done with unity. And I have tried both engines.
I love UE BluePrints because I don't like typing or looking at code, BP feels so much more creative to me.
interesting to see a novice viewpoint describing basic programming concepts (inheritance, etc) through the lens of a gaming tool rather than the underlying language.
The problem is scalability. Unreal can be tweaked by the developer itself and add functionality if you know what you're doing. Also, it's performance is better in the 3d environment.
Unity is great for low-scale projects and prototyping, Unreal is more powerful but you need the knowledge.
not true at all, both can get great performance. maybe that was true of Unity like 5-6 years ago but not anywhere close to true today, it really comes down to the knowledge level of the person coding and not really either engine.
Btw unity recently added new coding guidelines to utilize automatic parallelizing of tasks. Which allows even smaller dev teams to have highly multithreaded games.
UE is using the C++ approach here, so you are on your own when it comes to your own logic.
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 :(
I think Unity's script components being broken up is more of a community based thing. Unity has built it's brand as a free entry level to game development for much longer than Unreal, it's community was built from the ground up to try and accommodate beginners, so multiple interchangeable script components for users to identify and understand in bite sized chunks has been sown into the culture. There is nothing stopping you from putting it all into one script like unreal. But you'll find that component system when you are working with the asset store.
Oh, I must stop you there. C# also is an object oriented programming language. So inheritance, etc does work with C# too.
thanks for the roundup man!
Considering your primary job, this was a great recap. Thanks from 🇵🇦
Clearly you missed the "Learn" tab in the Epic Launcher. lol. It's nowhere near as good as Unity's lessons, but it does exist. I think your point is very good - the framework you get with UE4 is just so much better to hit the ground running with. Granted, coming from UDK (UE3), I think UE4 is SUPER bare bones. It pissed me off how much is missing that they used to have in UE3. If Unity is worse than UE4, I'd never touch it.
I found the tutorials before this video. My problem is it loads you up with a lot of touring the interface before getting to the "how to create [your goal]." I'm stalling out, wishing the tuts would do interface teaching while creating something. And the guy I'm watching flashes his mouse all over without highlighting where he is.
yes there is a learn button but some of the lessons are so old that things have changed or moved. a few lessons i tried to do the free assets didn't exist any more.
c# vs c++ is wrong premise, since UE uses blueprints for these things. (you just don't get cpp part of unity with unity).
UE hierarchy could be implemented in Unity and "Unity scripts" can be implemented as components. Both are just ways to organize code.
Generally speaking, I agree with your video.
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.
unity 3d has 7000 employees. i guess 6800 of them work in marketing
Not sure I agree with the view on small specialized scripts in Unity vs. a big script in Unreal. Unity has GameObjects and MonoBehaviours. A MonoBehaviour is a script that you attach to a GameObject. You cannot actually inherit from or modify a GameObject, you can only expand it with attaching MonoBehaviours to it.
On the other hand, Unreal has Actors (also more specialized subclasses like a Pawn) which is pretty much the equivalent of Unity's GameObject. The Unreal equivalent to MonoBehaviour would be an Actor Component. You can attach as many as you need to your actor class and can perform any kind of task that your character needs to do from there. This is probably a more reusability friendly type of approach, and while you certainly can just stash everything in a subclass of Pawn using components is probably a lot more Unity-like.
lol nice man, thats the video ill be linking to people from now on hehe
I tought the same, Unity is the one i usually reccomend to people because the comunity has sooooo much to offer to a beginner, its really insane, and its definately a engine i like to mess around and hopefully develop some small project, maybe even relase a solo indie game in the future; while at the same time, Unreal is the one i wanted to pursue more seriously, because of the kind of projects i want to be able to work in the industry, and its the one i am more invested in and buying courses for, in a more professional note rather than personal on Unity's case.
It was nice to see your experience and i wish you the best in your journey! o/
Unity's HD Render Pipeline is getting closer to Unreal every year, but I'll agree that Unreal is better for certain types of 3D games. Unity gives you a bit more customization, which I need currently, but I've definitely been tempted by Unreal more than once. xD
prolly the most balance comment section ive ever seen respect to both engines and more power to game developers.
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!
I can’t get over how awesome your hair is. Awesome vid thanks for sharing your experience
So c# also has parent/child relationship and it’s called derived classes!
for me it's simply the whole philosophy and pipeline behind each engine Architecture , I find Unity logic soo understandable Unreal is so confusing and restrictive . In unity if you don't know what you are doing you will make a mess but it's still a thing if you know what you are doing then everything is fine. In unreal if you don't know what you are doing then probably you can't build anything .
You‘re awesome, thanks bud
!
f*ck this video is GOOOOD!
well, my thoughts on your video may be heavily biased because we share the same opinion 😅 but yeah, I hate that people say that unity IS the go-to engine for new indie devs, when there are an f ton of reasons of why one should choose unreal over unity... who says that completely misses the point that for a lot of people coding isn't something desireable, sometimes even actively avoidable... and blueprints are RIIIIICHHHHHH. they are basically plug n' play snippets of scripts that will work and do the magic for you. blueprinted scripts can easily and quickly compile for any platform, and depending on what type of indie game you want to make, blueprints WILL suffice you.
unreal is in fact harder to master, because of the c++, and it is all that pain you mentioned in your video: poor documentation, a crappy compiling, the workflow can be annoying... but for indie developer using blueprints only, unreal works clean af.
anyways, thank you for your video :D good luck on your learning process! :)
you probably heard this before, but have you tried unity's BOLT?
@@ciixo8510 It does need some polish to be honest.
I wanna mention that in Unreal u got this option to convert your blueprints into the special c++ almost as native as c++ hand coded and the performance even with 100k+ rendered actors is so small in so many sections that its incredibly accesable even with huge projects to make games using blueprints, altho most of ppl who make games in ue are using blueprints and c++ but each for specific task etc
Yeah but its not same optimization level like if you write it yourself, also its harder to read if you want to edit something later inside.
That feature is going to be removed in UE5
I would love to see this same perspective from a professional game developer with extensive experience in both.
18:46 and you just discovered OOP, it's probably easier to notice if you're taking the developers way first instead of the Unreal path it helps understanding these concepts, but I can understand that coding isn't pleasant for everyone (even for me and that's my job....)
Whatever game you imagine is where you will go. I haven't tried Unreal much. I've been happily using Unity for years. But if it ever drove me to Unreal or Godot I would jump engine.
from 17:10 what he is basically explaining is called inheritance (for any non coders out there)
No! Both c# and cpp are oop langs which means that inheritance pattern you were mentioning is also applicable to c# its just ue somehow expose it as an editor feature? Its weird but in c# classes do inherit base classes and implement interfaces to manage similar tasks which brought us to polymorphism you can swap objects (instances of classes) implementing or inheriting a common interface or class
Only problem with Brackey's vids are they're like 4-5 y.o. and using old versions. Difficult to overcome as a beginner at times
Half the fun in developing is troubleshooting. But yea, as a beginner it is rough when you are having to troubleshoot from the start and don't know what you're doing at all.
omg this was so nice. thanks for sharing. could you tell me where did you get the animation and modeling lowpoly tutorials for blender to put in unity? and unreal too? i mean what you did there is pretty good , considering you're not an aritst.
Hi i just wanna say that in a part of the video u said that u bought a move assest from the unity assest store, but there are a lot of free stuff in there, like the move character assest for free (I don't know if it's as efficient as the one that you bought) Ur video was really great, thanks!
Solo developer here. Does any game use the Unity HDR pipline for games?. Have used Both engines for the last 5 years and keep coming back to Unreal. Getting to the stage where I know enough to complete my VR Flying game ( I hope!!!) in Unreal or Unity, choosing Unreal as I find it more polished in terms of work flow and consistency. Also EU5 nanites are great (VR is not ready though). Using Houdini to import terrains and find its much easier in Unreal. Both great engines though .
Bro, I am also thinking to learn UE but have some hesitations about mobile side. Everyone around me was using unity and there are tons of tutorials related to Unity. But UE has less tutorials, less examples, less mobile... So what do u suggest to me? Which side should I jump into? I want to focus on VR especially in the future.
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 UA-cam 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.
Love this. Thanks for sharing.
Great video!
Unity is for developers, Unreal is for designers.
Unreal Engine has been making a push to cut coding out of game development for years. This is a good and a bad thing.
The question of whether Unity or Unreal is right for you is more of a personality thing. One will clash with your personality and one will sync. Do you want control over how your game gets implemented? Go with Unity. Do you want to follow a structured and effortless pipeline? Go unreal engine.
Unreal Engine is not true open source. You are allowed to modify it to fit your needs BUT there is virtually NO support to do so and the developer's will branch off new versions on their own. It's not a collaborative open source program. Debugging and coding in Unreal Engine is an absolute nightmare.
Your first point reminds me how that kind of thing exists in many industries. Example, the old wisdom is UCLA film school is for artists, USC film school teaches you more businesss.
@@hermes6910 Source access to a game engine is overrated. If you need to go into the source to implement a feature...the game engine sucks.
I wouldn't recommend anyone go into the source on unreal engine for two reasons. One, coding in unreal engine SUCKS. You have to literally recompile the engine sometimes to see if your code works...and that's when you're NOT editing the source... It's also written in c++ which is great for collaboration but even large studios don't have many people that are that involved in coding so C++ just becomes a pain in the ass. Two, you now have to update your engine changes every time UE releases a new version.
"Unity is good for mobile" is such an outdated and misguided philosophy. Quite frankly, it's just blatantly ignorant. Unity has had a (very slight) edge in graphical capability for a few years now. Unity is capable of running with the same performance as Unreal out of the box and much better performance in specific test cases with its DOTS framework (if you have large numbers of programmed objects). Like I'm sorry but if you think Unity is only good for mobile, you have no idea what you're talking about.
I'll remind you subnautica was made inside Unity. A lot of people might chalk subnautica up as a small indie project but...it wasn't. It's one of the first games ever to take place almost entirely under water. No game engine is equipped out of the box to handle this (pathfinding for instance is usually done with navmeshes which assume a 2D plane). Neither Unreal nor Unity at the time was built to handle large open worlds. The devs made the decision to go with Unity because it's MUCH easier to adopt the engine to suit your specific needs. If you're making a FPS or a classical third person character game, Unreal Engine has those presets built for you out of the box. If you're doing something more unique...Unity is MUCH easier to work in.
That's actually why Unity is more popular among Mobile users. Mobile games tend to be very different from one another.
You literally have no idea what you’re talking about do you?
@@hermes6910 It sounds like she's not using source much. Source code isn't just c++ it's modifying the engine source code directly which is generally unnecessary. In the select few cases where it is somewhat proper...I still don't recommend it because it can make updating to a new engine version a nightmare. There's just not a lot of benefit to working with the source code unless there's a engine level bug or something...
I coded in UE primarily too over blueprints. It is just objectively terrible compared to Unity. I'm talking like literally 10x faster iterations in Unity compared to Unreal and next to no performance difference.
If UE were made from scratch today...I imagine they'd go with C#. For the longest time there was considerable advantages to using c++ since its lower level but that's not really true anymore.
@@hermes6910 lol...
Lumen is a mess right now and I wouldn't recommend anyone use it. Nanite and Lumen are both experimental within ue5 which no one serious about game dev would recommend because ue5 is in early access. Additionally...it's often overrated. Nanite is essentially a replacement for LODs which is nice but LODs also work pretty well. Nanite is only remotely useful for extremely large open world projects.
Blueprints do have faster prototyping and I really didn't argue against that. Regardless most people will move a lot of code into c++ and that's where ue struggles.
The phrase "Unity is good for starter/mobile" is where I just immediately know the person I'm talking to has no idea what they're talking about. That's all marketing and community driven presumptions and is just absolutely not true. There is next to no performance difference between the engines. There have been demos for Unity that are just as good or better than unreal. The highest end graphical performance demos actually tend to favor Unity (Arch Viz).
It is true that Unity is more commonly used for mobile but that is not because it is not suitable for AAA games. Subnautica was a Unity title and one of the smoothest and most impressive games ever made.
If you think Unity is just for small or mobile games you are completely lost.
Also, I have never and would never claim Unity is "better" than unreal. They have very different advantages and disadvantages.
Great honest video!
One big difference between them is that the UE compiler only recompiles stuff that it needs to. Unity doesn't have that. You're recompiling the entire project every time something changes. This might not make much difference in enthusiast level machines, but when every single change requires waiting a couple of seconds, it becomes old fast.
If you set up your assembly definitions, that isn't a problem. Unity also only recompiles what's necessary - unfortunately, most people bundle all of their scripts in a single mega-assembly which means that you have to recompile everything when part of that assembly is modified.
I've actually found Unreal much slower, but I'm not as familiar with it, so I may have been missing similar functionality.
new subscriber. i loved this video, hope to see more vlogs or videos from you=)
very good video. thanks
See where you're coming from in terms of accessibility to people new to game creation, however I feel the important thing to get people sticking around with their project is making something happen on the screen. Unreal has that out of the box, you can have a shooter working in Unreal in what, quarter of an hour? In Unity you have to implement your own input system, implement your own movement system, etc etc - it takes a long time before someone gets the "wow I made this" that is likely to keep them around and fired up to learn.
Unity however monetises their product through the marketplace primarily, so it intentionally does not include basic systems required to make an actual game in the hopes you'll hop on the marketplace and buy the systems one by one so they can claim a percentage. My blood runs cold at the thought of prototyping new ideas in Unity because I know I'm going to have to start from scratch on movement, animation, health systems, physics, AI, and so on. C# is a huge advantage in that it's pretty much human readable for the most part, and pretty intuitive. But outside C#, and certain specific genres (mainly certain types of 2d games) Unity is in my view actually less accessible to a complete newcomer.
About the performances of blueprint, isn't nativization a solution for most of that issue ? I mean, i've seen comparisons between C++, blueprint and nativized blueprint and the results are impressive, it's in the ballpark of C++.
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.
Unity documentation is "better"? Thanks, I needed a laugh.
Awesome video
When you comin back bro we need more videos of you
Very important video thanks
c# is oop with object inheritance as well ;) good work tho
It was..... a game changer. Nice.
unreal here too, As a person that used unity for quite some time I know how painful it is to manage stuffs and some functions or systems even have to develop from scratch which isn't good if we talk about long-term development. Meanswhile most of basic functions and systems has been laid into the base UE4. One day I'll make a game that's much complicate and hard to handle which is too big for basic unity, of course there is counter messure if I want to use unity which is to develop my own systems for those stuffs. Also it's not a pain to reference objects in UE4 compared to unity.
Actually, unity has a lot of object oriented programing too. For example, most scripts are children of the monobehaviour class.
Unreal 5.0 will have C# baked in, but you can already put a C# plugin on Unreal. So the coding should not be a problem.
Yea but how well does that plugin work? And is it feature complete for something like console development? I highly, highly doubt it.
Wait, what? Does it work well? Cause I know c#, but I like unreal and I don’t know c++ at all.
@@hermes6910 the issue with that is that while blueprinting is good and im really good at it, it adds a lot of overhead when running the game and makes it really bad for medium to big games. I plan to finish a few small games before moving to something much bigger and blueprints just wouldnt be optimal for it. On the other hand, I know next to nothing about c++ and I know a ton about c#.
@@saltyman5603 Learn C++ then. And make sure to use Rider IDE.
@@saltyman5603 It's a huge risk to code in a language nobody else uses and can help you with. I really wouldn't recommend it, just because the slight syntax differences between C# and C++. If you already have experience with Unity and C# and know your way around the Unreal API through Blueprints, learning C++ really isn't that hard.
oh darn.. but i wanted to know which should be used so i could ignore the other one!!! it's so case specific one really has to take a look at both and see which one will do the thing you want...
I've always stated, Unity is like Linux. You have to set up everything to get the results you want. Unreal is like Windows/Apple, everything is ready and polished. You can get good graphics out of Unity, examples are Book of the Dead, Escape from Tarkov, Ori and the Blind Forest, Ori and the Will of the Wisps, and yes also Hollow Knight. Unreal has a lot of the features and polished look you need with just a few clicks. As a game developer, I prefer Unity over Unreal, however they both have their pros and cons.
Side Note: Unity also has visual scripting. You just have to download/enable it through the package manager.
Thanks for a great vid! Im starting out in Unreal...do you think I need to learn C++ in unreal first or learn blueprints first and then learn c++ when blueprints are not enough?
I've found that blueprints are a much easier way to start learning Unreal Engine. There's a lot of good tutorials out there, and I find learning by doing works well. WIthin a day of effort, you can make a simple endless runner, or random maze game. I picked up the basics doing those two. There's also huge tutorials like CodeLikeMe open world tutorial, which stands in excess of 440 vids. When it comes time for fine tuning the performance of the game, then you'll find C++ to be your friend. It may be more complex, but it's incredibly powerful.
Personal opinion, blueprints are great for designing and testing. I prefer C++ for the final work. It's almost always quicker to execute C++ code vs blueprint interpretation.
Definitely start with Blueprints! I'm a software professional, and I genuinely think Blueprints are fantastic. As you say, use them as your main scripting tool, then approach C++ later if it becomes necessary.
immediate like for the hair (braveness)
17:36 i think that's inheritance, c# has it too
Nice video👍
great video. Thank you.
Thanks bro, this saved me days of research