Can you ever trust such a company that even attempts something like this? Trying to retroactively bill people for stuff they can't control and never agreed to? It's just galaxy level greed and Unity deserves to go bust over this as a warning to other companies (Like Epic) who might be thinking about doing similar things. I really think people should just be using Godot for most indy projects and if you get popular enough on PC then pay the 3k to a company for porting it, it's an honest one-time fee, you don't have to pay them again and you'll get your game on a console all the same, it's a fine use case for crowdfunding as well
As a beginning indie game developer, I was planning on working with Unity-then the news broke, and I’ve been lost since. All this to say, thanks for making this series, it’s extremely helpful to get input from an experienced Unity user on these alternate game engines.
hey there! I hope I can give u some advice, godot is pretty good to make easy/quick games, and for mobile games too; now unreal is more for computer/console gaming, id advice you to still learn c++ and c# (knowing c# will help you understand java) and learn python, it will allow you to work with gdscript; dont be afraid to learn and use the right tool for the right job, good luck!
same situation here, after 4 months of watching Unity courses and learning C# I was literally about to start this week and for my luck Unity decides to destroy itself. 😪
Hi! Great video! Keep it up! As a UE dev (and former Unity dev) I would like to point out some workflow errors (not necessarily "errors" but interesting choices) you made when creating the actors and scripting. My UE knowledge is slightly rusty because I have not used it in a little while but improving your workflow will make future development a bit easier. 1. You seem to have accidentally created an "ActorComponent" instead of an "Actor". An "Actor" is similar to a Unity GameObject, while an "ActorComponent" could be seen as a script that you can attach to a GameObject in Unity. What you did isn't necessarily wrong, it can be valid depending on how you structure your game logic, but it isn't the most straightforward way to script an actor. There is one big difference between a Unity GameObject and an Unreal Actor (if my Unity memory serves me well). Unreal Actors can be scripted directly without attaching a script/ActorComponent to them. You can script an inherent base logic on the actor itself and then EXTEND that functionality by attaching a ActorComponent to it. Think of an Actor as a Unity GameObject that has a base script permanently attached to it upon creation that is unique to that GameObject (cannot be removed or attached to any other GameObject). So you could have just (and this is the "proper" way to do it) created an "Actor" class (not "ActorComponent") by right-clicking in the Content Browser (the content panel at the bottom of the editor) and then it would have created a class for you in VS which you could script directly (without using GetOwner() like you did in the video, as you are now scripting in the "Owner" itself as this object has no owner, it can only own other objects, ActorComponents in this case). What you did was that you created a StaticMeshActor which you then attached a ActorComponent to. A StaticMeshActor is a child of the "Actor" class and this specific class it just supposed to be a static mesh with collision. You are not supposed to attach any logic or extra functionality to it. The base "Actor" class is the sort of class you should be scripting (it's basically a Prefab in Unity with a unique script attached to it). The StaticMeshActor which you pulled from the side panel is not a "Prefab" (using Unity terms here), which you can re-use. It is just an object template that is not saved as an actual file unique to your project. All your custom code and assets should always come from the Content Browser. 2. You can't just take a C++ class and just drag it into a level/scene as an actor (a pure C++ class should never appear in the Outliner). Instead, you need to right-click your C++ class in the Content Browser and create a Blueprint out of that class (this is your actual "Prefab"). This blueprint will now inherit your custom C++ class and you can now freely drag this Blueprint into your scene. An important thing to understand (many people get this wrong, don't worry) is that "Blueprint" does not refer to the visual scripting part of Unreal Engine. This is called "Blueprint Visual Scripting". The "Blueprint" itself is the object that the visual script is attached to (when you create a "Blueprint" a visual script is attached to it by default). If you double-click any Blueprint in your Content Browser or some actors in the Outliner (the Outliner part is sort of hazy for me, I might be wrong about this one, the "Open Blueprint" button might actually be in the details panel), it should open a separate window that shows you all the details of the Blueprint/Prefab (properties, hierarchy/attached components, event graph [this is the visual script] etc.). This view is where as the actual functionality and usefulness of the Actor lies. Think of it like this: Actor = GameObject, Blueprint = Prefab (sort of). I would recommend you read this documentation page specifically made for people who are transitioning from Unity to Unreal Engine: docs.unrealengine.com/5.2/en-US/unreal-engine-for-unity-developers/. They can explain this way better than I do (it's made by Epic Games themselves). Honestly, it's kind of a mistake to start of by creating C++ project in Unreal Engine as a beginner. It is much easier to start with a "Blueprint" project (which you can later add C++ classes to, converting it to a C++ project, you are not locked to Blueprint-only in any way, even if you initialize it as a "Blueprint" project) to learn the fundamentals. C++ on top of that is just confusing for a beginner (even if you understand how normal scripting and C++ works). I say this as someone, who, just as you, started out in Unity and later transitioned to Unreal Engine. Sorry for the long text, but I hope this clears some things up.
This is extremely helpful! I was going to check into the equivalent of prefabs in UE, but you got me covered. Thanks for taking the time to write up this detailed response.
@@outsiderealmgames on another note, there is nothing wrong with working strictly in blueprint visual scripting. It has slightly slower compile times, but when I say slightly slower, I'm talking milliseconds. There is nothing I have been unable to create while working in blueprints. The true power of working in c++ is your ability to create additional tools for the engine itself; but thats a very advanced topic that most developers never even touch.
I would not say that C++ project is bad for beginners. You just need to know how to manage Blueprints first and how to expose variables to them. I don't like programming at blueprints. It's kinda annoying and creates merge conflicts that hard to resolve. Every logic that were written on blueprints can be converted to C++ and it will be more easier to manage your code hierarchy. I believe Blueprint programming and yet you need to differentiate Blueprint programming and Actor's blueprint themselves(Prefab Unity). Two same words with two different meanings. And I believe Blueprints were designed to be like a replacement to script languages like Python or Lua. So yeah. I would consider blueprints as an script language. My advice to not use OOD using Blueprints
@SkitzSkitzVids you should avoid big chunks of logic in blueprints, they are slow (we passed our prototype logic from blueprints to c++ and the performance gain was noticeable) another thing is that hard references in blueprints make that blueprint way more chunky (memory requirements), while the same doesn't apply to C++ complex logic using loops and such is way easier on C++ if you're familiar with programming binding events and timers is way easier in blueprints online functionality is best suited in C++ as well
FYI: Unreal always starts with a basic map with landscape and lighting because you would otherwise have a black preview screen and you would assume something went wrong. If you really want to start from nothing you have to create a new map in your project where you can choose blank map (for real this time) where you would have to add a light source to see anything. Also in the project options you would have to choose your new (saved) map as starting map or else on next load of your project you would be on that default landscape map.
> Also in the project options you would have to choose your new (saved) map as starting map or else on next load of your project you would be on that default landscape map. This is factually incorrect. You only set map as the starting map to have it be the first map loaded by the engine if you build your game. In the editor preferences (Edit→Editor Preferences) in the General→Loading & Saving section you can set "Load Level on Startup" to "Last Opened" which would always open the level you were working on when you last opened your project.
33:35 as a pro UE dev, the reason the position values are large because UE uses centimeters instead of meters, these are called Unreal Units (UU) and you can modify this if you want for your project.
1. C# equivalent of var in C++ is auto 2. Basically Actor is a composition of Components. Every Actor have a Root Component. So when you first attached your New Actor Component to an Actor it was actually attached to the Actor but not the Root Component. So that's because it was under the line. You can't drag and attach UActorComponents to the Root or Other components. You basically need to create a component that derives from USceneComponent. Basic ActorComponent doesn't have any Transform relative things, so that's because you can't attach to any other components 3. Unreal Engine is a complex engine. I mean in compare of Unity or Godot. So when you learn more about it you gonna say - that with this engine it is way more easier to develop then in Unity or Godot. So yeah. Just because of that complexity on first look you think it's hard to understand. It's just have far more fundamental features in case like for example AActor in compare of GameObject in Unity. You have organized hierarchy of how do to things and you have far more functions to control when you actually want initialize your Object variables and etc. And it's an open source Engine, you can basically rewrite everything 4. So yeah. BeginPlay is after all initializations. You can override PreInitializeComponent, PostInitializeComponent, OnRegister etc 5. Documentation in Unreal Engine not very good I would say. So to understand more features I would see a source code, put a debug breakpoints and see how different features are working with each others. And source code is far more documented btw then in the website. I would only look on the website when I wanna see some fundamental things like Actor Hierarchy and Actor Lifecycle etc. There are not much things about specific features about how exactly this thing or another working 6. VERY GOOD ADVICE - I recommend this channel @AlexForsythe - you will have a beautifull first glance on how to work with Unreal Engine, particularly last four videos
@@milkman2516 I think Gaster meant that `auto` has the "equivalent behavior" of prompting type inference as `var`, as opposed to directly stating the type. Any other behavior of either keyword is coincidental, since they are interchangeable for the intended use of "infer the type of this variable".
Seems your experience with c++ is with the 2003 standard. Unreal supports the c++17 standard which builds upon the c++11 and c++14 standards each which have added more modern features to c++. I definitely recommend getting familiar with what the newer standards have added as it makes working with c++ much nicer.
@@thavrisco1632 That makes sense. I seem to remember seeing some engine stuff that sticks to c++17 because it doesn't compile with c++20 or something, but that probably doesn't affect the user's code, just those particular engine pieces.
I would like to welcome you on the Unreal side of game development. Just an advice: Blueprint is perfectly suitable for most of the indie games out there so you don't have to start a C++ project (Editor launch much faster with blueprint only project) Later you can still configure your project as a hybrid (Blueprint-C++) project.
Also, if visual coding using blueprints becomes a headache (totally understandable, it can get messy fast), SkookumScript is a gaming-specialized async scripting language that can be more performant than Blueprints and is a normal text file.
The only reason im not switching to UE is because of Blueprint, and because the programming side (C++) has terrible to no documentation and very little resources. I hate Blueprint and any visual scripting with a passion, but Blueprint especially. I have been developing and designing software for 14 years and yet i couldnt wrap my head around Blueprint instinctively - especially since once again.... tutorials are usually 1. outdated by the time you find them or 2. so basic they dont help you with much or 3. so specific that you cant take much general understanding from it. That was my experience trying to get into UE a year ago. Insult to injury is that they need togive many things their own special names in UE, which are all called the same thing in all other engines or in general game dev terminology. So even if you understand generalized components and systems, its not intuitively. You just have to know everything. Also, having to create and plug 6 things together for an extended if statement (especially with special parts once again you have no idea of) instead of just writing the line of code is beyond me.
Unreal always seems somewhat convoluted to me. Undoubtedly powerful, but just seems overly complex - at least for an amateur coming from Unity. (Great vids btw)
UE has always felt to me like it was meant for specific games, but was eventually pulled out to become a generic engine. The UI looks like something internal game development studios would use.
@@XeZrunner Yeah that's definitely how it feels. Another reason it absolutely sucks that the Paypal Mafia have decided to destroy Unity - it certainly has it's faults but the sheer amount of user support both BY Unity AND the plugins assets and community just made it feel somehow more welcoming to new coders.
Unreal Engine is indeed for specific projects, before I would say if you want something huge like an big Online MMO RPG game you would go Unreal Engine or relatively games like Cyberpunk or Starfield or Halo would require Unreal Engine and everything else would be just fine using unity. Now that Unity is gone, I would just replace that standard with Godot. I personally love and use Unreal Engine 5 but Godot is quite the interesting engine that you can evolve to be partly yours with your own custom features in it. In theory with time and leveraging AI to assist you learn, design, develop, you could make Godot your own custom Unity while having practically full ownership of it with no fees or anything attached to it. I love the concept of Godot, but for me Unreal Engine 5 is the only place I can do the work I want to, if you were using unity, then most likely your work is more aligned with Godot than the Unreal Engine, but its obviously up to you to decide.
@@XeZrunner It's very busy for sure. Lot's going on versus Unity, which looks like a blank slate when you open it. By default UE gives you a lot out of the box so it has everything there waiting for you to use it. It's also pretty heavy because of it.
@@apoclypse I respect UE for bringing current, state-of-the-art technologies to hobbyist and student developers, for free. The heaviness of the engine unfortunately means that it isn't really a proper Unity replacement for many, but if you're serious about game development, UE is a fantastic engine to learn and use. It is proven to be great, as well-known game studios use it for their flagship titles as well, including Epic themselves.
Seeing someone try to understand the clusterfuck that is Unreal Engines structure, is very amusing and also Aware inducing. If you ever want a full breakdown of UE, let me know.
You know this is legit the 4th or 5th video I have found where someone tries to navigate UE5 without any prior knowledge and I really wouldn't mind finding a perspective video from someone switching from Unity, but AFTER maybe learning their way around in UE first. I *do* actually want to look into it in an efficient way, and not just through trial and error. It does seem to be a popular video format lately though, just blindly trying to figure out Unreal (and I feel like this and Cry are probably the two most complicated engines out there, so it seems a little hopeless to learn anything this way. But that's just me.)
I studied game art at a university and had my introduction of the engine in a formal education setting, so I had a similar response about this video being "aware inducing." Having a structured step by step introduction to the engine was certainly valuable. I also feel that the addition of a partitioned landscaped as part of the default level makes things a fair bit more confusing than the original default scene with the little plane and some lights.
Or PCG, their procedural generation stuff is still pretty early and changes fairly wildly between versions, it seems, but it already does so much at a pretty abstract level and allows one to easily populate wide landscapes with foliage, meshes, anything. Their destruction and particle stuff is great too, in fact, all of it is pretty nifty in its own regard. UE is just a really great engine.
@@FlockersDesign A lot of people will not be existing UE level designers, given the mass exodus from Unity. Plus, if you can't see rendering triangle counts irrelevant as at all exciting, you lack imagination.
@@baitposter that has 0 to do with the state of nanite and pcg's and lumen Plus people will see that even with the unity changes thr are still cheaper over there than with UE
I'd like to like Unreal. Unfortunately, I utterly despise Blueprints, and every tutorial uses them. And the C++ is so poorly documented and unwieldy, it takes the fun out of everything.
Once you learn UE you'll never leave it, there's a million good things about it, Personally I came from Unity myself (4 years ago) and I never went back to Unity since, and I used Unity for about 6 years when I made that switch about 4 years ago, BP's, VS etc. is a little tricky to understand when first use it, but it's defiantly the better engine
I started in game development directly in UE4. Now I'm moving on to UE5 for my next project. I'd say it is really beginner friendly for someone who had zero experience in game dev. I love it.
Hey! Good to see you trying Unreal Engine. I have few tips: If you want to have a mouse control you can use Simulate instead of Play, you can change it by a little arrow next to Play button. There, you can also change so that Playing doesn't move you to PlayerStart location but instead uses editor camera location. BeginPlay is called when actor is created and completed its initialization. If it was on the level from the start then it happens to be at the game start. Default unit is cm that's why it was moving so slow :D 1cm/s When flying in the editor with RMB+WASD you can use mouse wheel to modify flight speed. Good luck with Unreal
You have to be gentle when using Unreal. Lots of items carry lots of data like when you open and view them. So organization is your bestfriend and roadmapping your goals is important once you begin imports, exports, blueprints, level blueprints. So remember to keep a backup.
Epic needs to take this train and enhance 2d features in this engine plus some kind of "simplified mode" for indie developers that want a alternative to unity. Its bluprint system would be very atractive to start ups if the engine had less convoluted stuff.
This was so charming to watch as an unreal main user. Youll love the networking aspect, it's mostly automatic with tick box replication lmao have fun and I will enjoy seeing your next video :)
Welcome to Unreal! From a friendly UE5 game dev - development on this engine feels sorta like Dakar Rally. You have to plan and prepare a lot in advance and everything you planned will fail, everything prepared will break. However, as soon as you figure out the flow, the pipeline of yours, sheer number of automated and drag n drop/visual interfaced stuff will make you soo happy to prototype. You will be basically playing big kids Roblox. With all big, hard shader/light/LOD/streaming/networking stuff taken care of :D
Unreal Engine works best when you use Blueprints along side C++, using C++ for more complex calculations and blueprints for the more common and simple logic.
Floating point precision errors are not that big of deal, especially not in ue5. They increased there precisition by…. 3 times? Or something like that. Which also makes vertex shaders 3 times more expensive (there are workarounds) but I guess on giaaaant landscapes you might need to reset the origin, however I think ue has a build in system for that
In Unity you can run into floating point jiggling problems a mere 2km away from the origin. It’s a big problem where I work, we’ve had to implement a floating origin system, which is a big hassle.
@@damienclassen2179 2km!? Wtf okey no lol tbh I never build big enough in unreal to reaaaaly run into real trouble. And if u did. just recenter, whatever
I tried Unreal Engine 5.3 but my gtx 1050 with 2gb VRAM just said "NO" - it has poor performance even in blank scene 😁so I decided to choose UE 4.27 to start learning basics
Godot is great, but it is not ready to fill the void of Unity. They need to step-up the development fast if they want that to happen and fill the void Unity left. Godot has by far the least features compared to Unity and Unreal. It needs more to be ready to spit out games as fast as Unity and UE can, which believe it or not is high on the priority list for developers and companies.
While this is true, it also is the case that a lot of people are satisfied with the features it has as well as ones you can add yourself. For at least 70% of people they aren't gonna miss anything major, it'll probably be enough with the community made stuff. For anything that's still unity exclusive I'm not sure, but not every engine needs to be a jack of all trades. Godot is mostly lacking in 3d at the moment which is covered by others like Unreal.
People still like to invent new string types, and it is no better with UE. FString, FText, std::string, of course, const char*, and more. I am sorry. Instead of `var`, you can use `auto`, and do not listen to the yelling of C++ gatekeepers. F8 is analog if Esc. One world unit in UE is cm.
I would love to see you try out the Blueprints in UE5. I think you will find it is a very easy way to prototype stuff quickly and the overhead costs of blueprints is extremely small nowadays.
Out of curiosity, I started learning Unreal Engine and I'm having a ball. It's a steep learning curve from the simplicity of Unity, but I feel like I am using a serious game engine as apposed to a toy. Unity doesn't even make games with their own engines anymore. At least Unreal does. I also can't stand Unity's CEO. He reminds me of the character on South Park during the BP crisis. "We're sorry.. sorry... so sorry," over and over again. This is the second time they made a major boo boo under this CEO and had to kiss developer arse. He's just terrible.
30:39 Recent versions of C++ allows you to do define auto variable like so: auto newPos = FVector(x,y,z); Though I only prefer using that when quickly getting some proof of concept done and then will change it to FVector newPos = new FVector(x,y,z);
Hey! I love this series because it shows the raw first experience coming from another game engine , which is always really interesting to see, and I think it also helps a lot of people. I think it would be *interesting* if you'd try out GameMaker Studio 2 next!!
If you are confused by this, I will tell you that this was pretty much my first experience with Unreal and I was unity dev since Unity 1.0 (before even because I was working in it when 1.0 had not yet been released. From the get go, Unity was very intuitive and easy to make stuff from scratch. I recently left a job of 2.5 years working on an existing game in Unreal and I still don't know how to start from scratch. In general, Unreal seems very complicated and it never really clicked for me. It might have been different if I had started at the beginning of a new game but most of my time was just trying to understand Unreal, blueprints and the actual game code that was already there. I was mostly debugging issues and a lot of that was in blueprints but some code as well. I didn't get to make a lot of new stuff except a bit of AI which was cool and fully featured in Unreal but also very complex. I also don't quite understand the way all of the built-in objects/classes work in Unreal. I still prefer C# to C++ and it is very easy to mess up memory things with C++. Blueprints kinda suck if you just wanna code things, if you need to worry about runtime efficiency and you don't like visual code editors. Most projects use a mix of blueprints and code and it is hard to find good examples if you only want to use code. Most examples were in the one I didn't want to use (Blueprints). I recommend using one of the starting points for FPS, Third person, etc because they set up a bunch of stuff that is not intuitive to do yourself. Also tutorials are a must for this engine, as it is way more fully featured to specific game types than Unity is. The starting points give you the ability to just jump in like you would in Unity. I wish you luck, all of you who have to work in this engine from a long time Unity experience. It is going to be brutal for the first few years.
There is no such thing as Unreal Engine without Blueprints. That would be like Unity without prefabs. Blueprints don't have to contain actual blueprint scripting. A blueprint can just be an instantiation of a C++ class.
Hehe, as someone who knows both, you can make a ton of mistakes if you accidentally do in C++ what you would in C#. Using the ‘new’ keyword accidentally in C++ and expecting it to behave like C# will lead to so many memory leaks etc.
and by the looks of it, He gave up on Unreal , honestly if I have to keep pushing C++ I'm better doing my own engine or create plugins to enhance godot
it's because he installed the engine version and it was his first time launching it next time he launches it then it will be much faster 1st time it takes a few minutes
It compiles all its default shaders the first time you launch it, it'll be *much much* faster the times after the first. For me it's almost instant, I have a pretty beefy PC though but I would think it would still be fast for anyone who is not sitting on a 3090 or 3080.
I just did the same thing a couple nights ago. Tried out the blueprints instead just to get a feel for it since I never do visual scripting. Just gave myself a similar task: use the 3rd person controller character, and jump on a cube that I made. If there's a collision between the two: change the cube material. Was fairly easy to wire up! It's gonna take a LONG time to get into the flow enough to plan out a large project the way I could in Unity. We'll see!
I’m not using c++ a lot (as it’s not needed) but let me ensure you, you will have a MUCH better time looking some into blueprints. you can still use c++, mobile or desktop related to the preset settings in the project setting (AA and stuff) The landscape is created inside ue itself it’s technically a empty project with just some generated landscape.
Other actors like the datalayer excist bcs “world partition” is on in that’s levels world settings. Datalayer are layers you can sort actors in, unload or load whenever. It has a window (like photo shoot layers) top left window datalayer.
Developer/engineers live in truth. You have to. So lies have an emotional footprint greater than with normies. Salesmen/managers simply can't understand this.
Now I learn UE and Godot D; Unity was universal. I miss Unity 😢 But it feels like Godot will be universal too as Unity in few years. Btw the start of the video shows as Godot is simple to install :)
I personally do not think Godot is ready. It has great potential but it is lacking *so many features* that Unity and UE has. It needs to catch up so definitely needs more time in the oven. But it has a place for sure, just not yet imo. UE and Unity able to handle any genre of game in mass-production. I don't think Godot can do this yet. Also UE is not hard to install, it might not be as simple as Godot, but if installation process is a hindrance or a wall to a *game developer* then maybe that individual is not as tech-savvy as they think they are.
@@jonteguyWhat features does Godot lack? Remember that Godot is FOSS, so the bigger the community, the faster it evolves and there's no risk of any policy changes like Unity. Moving to Open Source is the sustainable way for long term, and you can be sure that now that so many eyes are on Godot, it'll improve very quickly due to community support
That's the problem with Unreal Engine, it is not very self explanatory. It starts off with a template immediately, even when you tell it not to. You need to create a new blank scene, and don't save the one you started with. You also need to set your saved (the one YOU made) scene in the scene in Project Settings - Maps & Modes. Don't expect anything to work like you think it should; not even the colors. You gotta adjust or code every fucking thing to make it work right. You'll be spending a lot more time researching how to solve problems (with little to no results) than you will research how to do something. Expect crashes for no fucking reason; so save everything often, or you will lose it. You're working with DirectX based technology, not OpenGL, so your normal maps may need its Green channel flipped (which the engine gives you the option to do so). Also I don't know who the fuck thought it was a good idea to make the +X axis the forward vector. You will also work with DXF format when importing and exporting models. Also Unreal Engine uses centimeters instead of meters (like who is the dumb fuck who makes these decisions?). So that adds more trouble shooting to importing things. Also, animation is based around character rigging and bones. So it will take that much more time to figure out basic shit or how to properly import things, even when it has nothing to do with character animation (took me almost 3 weeks to figure that out). I'll give you a hint about fixing the colors in your running game, because the tone curve is a fixed amount (and wrong colors) in the editor. Add a post process volume in your scene. In Post Process Volume Settings, turn on Infinite Extent (Unbound). This will apply no matter where your camera is. Under Color Grading - Misc, turn on Tone Curve amount and set to 0. Now your reds looks like red, not orange. There are many other color and post process adjustments you can make here. You can do similar things on the camera itself. You can turn off Auto Exposure in Project Settings - Rendering. Even though I criticize this janky ass engine a lot, I am making progress in my simple small game; but it is taking way longer to get to the point I did in Godot. I like working in Unreal Engine; I just hate the jank and the instability.
I'm very amused that your first checkpoint for testing a game engine seems to be settling in to "create an object in the world and make it slowly slide in a direction".
The first thing all unitists do is go to C++ and try to do some basic stuff in it. As a long term UE user i have to say - YOU DON'T NEED C++ for almost all the tasks, except building your own plugins and adding some really specific tools to your project. Almost everything is perfectly doable with BP's. It's easy, it's fast and exttremely flexible. And that's the main reason why lots of artists, animators, narrative designers and other non-coders can easily build games in UE without having to learn the syntax and having a tons of problems with some case-sensitive variables and dozen types of different brackets.
And a hell to maintain or to work with more people than just yourself. BP is cool for prototype or try feature in a sandbox project. Beyond that, it's C++. And I'm not even talking about the issues in performance you can have if you are going full BP.
@@hermes6910I’d like to know more about this. Is it really so disastrous to use BP all the way? Would you say that using BP vs C++ would be 20% slower, 30% slower?
@@Cesar_M_RomeroIt's not really an across the board thing but if it is something happening every frame, BP can be as bad as 10X slower than equivalent code. Unfortunately, there are some things you just have to do in BP but it is hard to know which. Best rule of thumb I can make is: if it can be done easily in code do so. If it is some thing that a level designer needs to do let it be done in BP if they need it but keep an eye on what calculations are being done in functions that happen every frame or tick. Refactor those to code often.
Jumping from one corpo controlled game engine to another just seems like setting yourself up for the same problems farther down the line. Maybe that's just me tho 🤷♂️
Unreal's Licenses are per engine version and can't be retroactively changed. So the worst case if they decided to charge per install you would just need to not upgrade to whatever version has these licenses changes in it. So whatever UE version you choose you are locked in with that versions licenses there is no general overall licenses that can be changed at will like in Unity. It's why a lot of UE Devs will stick with just one version on the engine from start to end of a project and really only upgrade if there is some major feature you need. Not to mention the entire source code of the engine, every version and its daily updates are on git so that even if Epic was to go under for some reason you still retain access to the engine and can retain its use even without Epic Games being around.
starting from blank while learning unreal is a bit overwhelming, same for c++ project, you can add c++ later also, premade projects and samples are oversimplified, so take them with a grain of salt (some don't follow some future proofing recommendations, they are cool to mess around and learn)
What about iteration times? Do you have to sit around for minutes to compile a larger project, just to test a change? High iteration speed is probably more important to a project -to get something done- than some visual features.
Your C++ is a bit outdated. In modern C++ you should avoid using raw pointers in favor of smart pointers, which is basically a special reference counter class that automatically releases the pointer when all references of it go out of scope. Sure, you CAN still use raw pointers, and they are a tiny bit better in terms of memory and performance, I believe. But it's generally considered to be not worth the risk, because raw pointers are messy. I'm not very sure, but I believe Unreal Engine in particular actually has a pseudo garbage collection in it too, so it's worth looking into that, if you're planning to continue. Don't quote me on that - It's just a memory I vaguely have from tinkering with engines years ago.
30:49 Not true. The equivalent to C#'s var in C++, is auto. And the location values in Unreal are that high because they're specifically using centimeters as the unit. So a kilometer is 100,000.
hahaha this was so fun, as dev that has study with unity and now works full time with unreal is so fun seen you figuring out the engine by possibly the hardest way haha,, for me UE is much better in almost every way, i only miss the simpler coding of C# and a couple simplicity of the unity particle system, but for me UE is way more expandable and powerful.
you didn't accidently click the wrong thing for the blank project for some reason epic games adds a landscape to the blank project but you can just in seconds create a new map one that is blank and when you click play without any characters set to play with it will auto use a spectator class it's default so you can see what your stuff looks like when everything is playing also ignore a lot of the errors in visual studio that's why unreal engine has the live coding console that comes up you can quick compile the code and if there is errors in visual studios but the live coding console says it succeeded then unreal in right and visual studio is just wrong it's just visual studios intel sense that doesn't know most of the stuff for unreal
Watching someone use Unreal the Unity way is kinda fun but in all seriousness. Unreal is great, comes with a lot of stuff from the get go and you don't really need to use C++ for smaller to lower mid scale projects.
conclusion, really..seems like you got nowhere??? I think UE is capable, but the out of the box experience for a new user is horrible...to me, you seemed lost I would give this a big thumbs down...people get confused comparing the promise of amazing functionality(large worlds etc) and the ease of being able to actually get to that point...totally capable engine...just very convoluted way of doing things... liked the video btw...not a troll :)
It’s kinda a valid question because in Unity you organise your scene by creating empty games objects as containers for groups of other objects (so they behave as folders), so from our perspective maybe Unreal does the same but just uses a folder icon for those objects?
Once again a great video. Thanks for this first look at Unreal Engine. Unlike Godot and Unity I have no experience with it. It's very much like watching myself explore a new development environment for the first time. I've also loved, that like in your previous Godot video, the UE community have jumped in and given loads of really good pointers (pun intended) for anyone wishing to explore further.
It's crazy how good Unreal's in-editor modeling tools are, way better than Probuilder and that's without modeling tools plugin enabled. Not to mention so much is done for you here, as opposed to Unity, where you pretty much have to reinvent the wheel constantly. For example, making an open world game is just a couple of clicks and Unreal handles level streaming for you. Overall, I love the time I spent in Unreal so far, even despite the crashes I've been experiencing.
"Is this a subset of terrain? I think it might be a subset of terrain? Let's find out by deleting it!" - the most game developer phrase I think I have ever heard on youtube
Use F8 while in game to regain editor control, what you did pretty much expects a console command it that's why it also gave you access to the editor but F8 will just pull you out and leave the editor in play mode
Ahh that was brilliant. You are obviously way more advanced than me - but I was SCREAMING for you to hit the "Movable" button. Thanks - very informative to see your approach.
Well you got a new sub, let's hope for more UE5 content! Love the fact that you went with C++! UE5 C++ is not as bad as "raw" C++ so you can forget the traumas :)
I realize this comment is coming pretty late, but C++ does have type inference. You can use the `auto` keyword for that, and it's pretty much exactly what `var` does in C#.
The only reason im not switching to UE is because of Blueprint, and because the programming side (C++) has terrible to no documentation and very little resources. I hate Blueprint and any visual scripting with a passion, but Blueprint especially. I have been developing and designing software for 14 years and yet i couldnt wrap my head around Blueprint instinctively - especially since once again.... tutorials are usually 1. outdated by the time you find them and dont work or 2. so basic they dont help you with much or 3. so specific that you cant take much general understanding from it. That was my experience trying to get into UE a year ago. Insult to injury is that they need togive many things their own special names in UE, which are all called the same other thing in all other engines or in general game dev terminology. So even if you understand generalized components and systems, its not intuitively. You just have to know UE, thats it. Also, having to create and plug 6 things together for an extended if statement (especially with special parts once again you have no idea of) instead of just writing the line of code is beyond me.
I don't recommend any Unity to join Unreal Engine. What's like? pain in the ass. difficult to learn. you are not 20s any more. Unity is really cool. you write the script and drag in between character rigs. UI is much faster. it's right on the screen camera. First starter. UE you stuck in development hell. I have been using unity for 10 year. it's fun. UE is not so fun. I lost a lot of sleep. Blue print is hard to learn. you will get headache. screaming. beating your self everywhere. but if you stick with Unity.... Unity is blood. UE you have to learn . it take 1- 10 years to learn depending your skills in gaming. Development hell is real.
I don't know how good is unity, but I know few things about unreal. Unreal is complex, it looks fantastic, it can be good performance wise, but it is a HUGE pain in a butt sometimes.
When starting a Blank Project. Go to File - New Level. So you don't have to mess around with the stupid world partition level which is clearly too confusing for new people.
is unreal engine's inspector flexible as the unity editor? Best thing i like about unity is its easy to make customizable tools that makes your game development period easier and funnier. Does ue has these possibilities?
How did I realize that I started to get into UE4? It crashes during compilation and then during startup. Giving an error something like: bzbz something somewhere there...
Unity community moving to unreal will kinda revive it's programming community since unreal's C++ community has gone extinct and peoples just copy paste nodes from internet.
You asked about networking being built in. It is a fundamental part of the engine, as is multiplayer support in general. There is always a concept of server and client, even when running single player in a single process. The networking system is complex and an easy source of bugs if you don't use it properly, but it is powerful and handles a lot of things for you when utilized properly. You can also completely ignore it if you never plan to support multiplayer since server and client are the same thing in single player and things will "just work". But keep in mind that if you later decide to add multiplayer, probably a whole lot of things will be broken for the non-host player until you properly implement things with networking in mind. If you think there is any chance your game will want multiplayer, learn the networking and multiplayer concepts early (after you grasp the basics) and build/test a multiplayer game from the start. This will help you learn and form good habits for managing replication properly so that you don't accumulate months or years worth of code that won't network properly. And the same code will also work in single player without you needing to handle single player differently (from a networking perspective).
Hahahahaha im so glad that devs are not accepting crap from nobody. Unity just gave unreal and godot 90 percent of their customers. And when people try unreal, they will hardly go back to unity.
40 minutes going nowhere, yeah, that's my experience as well. Unreal's naming convention is a mess, making the learning curve much more steep than it needs to be. That's why I'm going for Unigine for the time being, at least until Godot starts feeling more polished.
