I am glad you shed lights on Blueprints, I have been talking to a brick wall sometimes when I talk to other newer Unreal developers about what they are capable of. Virtually the entire engine is exposed in blueprints. There are a few instructions that are not currently exposed to Blueprints that are available in C++ and its because Epic's engineers add new engine features in C++ first. C# acts as a scripting language for Unity that compiles ontop of the engine, C++ in Unreal compiles directly into the engine making it superior for speed. But a VAST majority of gameplay logic does not require that kind of speed. Epic built Fortnite using mostly blueprints, keeping netcode logic in native C++. When they wanted to release Fortnite on the Nintendo Switch and Mobile they had to convert some of their heavier blueprints into C++ in order to get the game running at 60fps on both platforms. There are a lot of indie and AAA games that all use 100% Blueprints. Epic themselves have given comprehensive talks on Blueprints vs C++ and Blueprints have a much larger performance hit when playing in the editor. This happens because Blueprints are essentially uncompiled code and a virtual machine interprets and then essentially compiles at runtime. When you actually build your game, Blueprint code is "Virtually" converted to C++ and the actual runtime performance is about 5-10% slower then native C++ in massive projects and about 2-3 percent slower in small projects. The slowdown occurs because of code bloat and how Epic likes to organize the data, but its minimal for 95%+ of all games that are made in the engine. Some baked BP functions can be 1000 lines of code where as a skilled C++ developer can fit the desired effect in 100, because they know exactly what is required. Also Blueprints are single threaded. So you will notice a big difference if you're running an Intel i-9 12900k with a nutty 5.2 Ghz base clock speed vs say a Ryzen processor with 32 cores 64 threads and a 3.2 Ghz clock speed. You're going to have a a better development experience on the Ryzen probably, faster builds, light bakes, better particles, better compile times etc so a lot of people use high core count AMD CPUs then are like, but my Blueprint or particle system is kind of slow. But you just have to realize that PIE performance does not reflect real world performance of a fully baked game. The Witcher 4 is probably going to use 70% Blueprints and 30% C++. I would say thats what my company is doing and its because for a vast majority of tasks, there is literally no difference between writing the game in native C++ or Blueprints. Literally no difference. Also, Blueprints are exposed across the entire engine and all the tools Epic adds to make game development easier. Control Rig, MetaSounds, Animations, Niagara. All use some form of Blueprint Code. I would say 70% Blueprints and 30% working in an IDE is pretty common for a software enginner/programming working on an Unreal Project. You're going to be debugging in the editor, you're going to be working with tech artists and design leads. You're going to build systems in blueprints using C++ classes as a base. ----Long post on Blueprint tips for new Unity Expats I found useful switching to Unreal-- Some things to watch out for is Casting, Ticks, GetAll"Anything" functions and For Loops. Casting is an incredibly powerful way to have two different entities in the game to talk to each other and share data. But when you cast to something, the entire blueprint is loaded into memory. The most common mistake for people when they are new to Unreal engine is overcasting, in particular, "Cast to PlayerCharacter". Lets take an AI example. On the AI Script, you go Cast to PlayerCharacter - > Get Player Location -> AI move to player Player Location. This will work, But lets say you add 30 NPCs and they are all running that AI Blueprint, Cast to Player Character. Each instant of that cast had loaded the ENTIRE Playercharacter, its meshes etc into memory. This can cause some performance issues. You have 30 AIs running that Blueprint, you have 30+1 Player Characters loaded, You have 100 AIs running that script, you now have 100 NPC actors and 100-1 PlayerCharacters loaded. You now have 201 Actors loaded when you just want the 100 NPCs and the Player. How you want to solve it is to on the PlayerCharacter, Say every 0.5 seconds, GetLocation ->Send that world position to a Blackboard and then have the AIs instead of Casting to the PlayerCharacter, just reference the ever changing variable of PlayerLocation. So in the AI script, you assign the PlayertoAI Blackboard, Get Blackboard Variable, PlayerLocation, Move to said position. Second is Ticks, A lot of people find it easier and faster to use Tick functions in gameplay logic. But Unreal doesn't handle them well and should only be used for very specific tasks. Tick functions and logic are piped into the render frames. Unreal Renders graphics and then throws on Ticks. Ticks directly effect your FPS, be careful when using and only use ticks when required. For example a Health/Mana/Stamina bar in an RPG. You can just use a Tick function that looks at the players health values and when the player loses or gains any value the bar will automatically update. But a vast majority of the time, the Player isnt going to be taking damage. So you're wasting compute time still updating the Health bar every single frame. Unreal really favors Event Driven Design. In order to achieve the desired result, you want to make a macro called UpdateHealth() and every single time the player takes any damage or heals, you do your logic and then call the UpdateHealth() macro. Like a regen spell, every 6 seconds the player gains 6 health. Timer, 6 seconds, add 6 to the players Health var, then call UpdateHealth. Boom, same desired result, but 95%> more computationally efficient. Same with damage, Deal your damage, get the result, UpdateHealth() You should probably write your death conditions into UpdateHealth() as well that way whenever it is called it will be the primary controller of if you die or now and propagate across the UI etc. Another common mistake is GetAllActorOfClass or any GetAll function and For Loops. These functions can be very memory and computationally intensive. You really need to think about why you are using these things and try to develop around them. They still exists, but the only for loop in my Indie project RPG is when a player picks up, crafts, or loots an item. It scans the inventory for an empty slot and places the new item inside the empty slot, else return inventory is full message. Or lets say you want to destroy all rocket projectiles fired by the player at once, GetAllActorsOfClass RocketProjectile, you want to have a limit of say ammo to limit the number of rockets that can be fired etc. Because if you have say 30-100+ rockets in the air, GetAllActorOfClass has the potential to lag a bit while the engine is scanning the games memory for all references of RocketProjectile. The better way would be to have the rocket detonator fire off an event dispatcher to the projectiles and have each projectile listening to the event message. That way the logic is already loaded into memory when they are fired and has zero performance loss. Your limitation will be the number of explosion particles and meshes you can load vs performance of your logic. One final protip for Unity Expats is using the Game Instance. The Game Instance is the actual Game Client itself and it always exists as long as the game is running. It also can be referenced by pretty much any object type in the entire engine library because everything in the library exists in the Game Instance. This can be incredibly powerful for a lot of different things because the Game Instance can only hold data, no meshes, no effects, just Data. It is ALWAYS loaded, always referenceable. So think like a players Inventory. or anything that would be useful in a save file. Passing critical data between levels or worlds. Character Creator, the player selects what they want to look like, then you want to load the player character and drop them into the world. You send the characters appearance data to the game instance to be stored, then when the player loads into the level in the construct script you reference the game instance and pull that data down and bam you just passed the characters appearance data from the Character Creator to the actual actor in the level. The same would go for inventory, if a player is dying or traveling around your game all the time, you need a static reference as to what items they are holding. Or for Dialog options. Lets say you want to have NPCs greet the player if they completed the Quest "Heroes of the Elves" Well then the player completes the quest, have a bool in the GI called ElfHero? then on the NPC actor when the player starts dialog, check the value of the variable ElfHero?, if true say "GREETINGS HERO!" if false say "Greetings Stranger". Then for saving, think of the GameInstance as a Database for your project, everything from score, to progress, to locations etc etc. So when you start thinking about a save and load system items that you want to start saving should probably be in the database Long post but I was a Unity Developer for well over a decade, I switched to Unreal 5 in 2020 when my employer did. I absolutely adore Unreal Engine now and blueprints are literally amazing. You're going to learn both even if you are a I ONLY CODE type of person.
Good tips! Are you sure about "cast to" loading a fresh new copy even if there's already one in memory? That seems like an easy engine-side optimization.
I just loggin RU-vid account just to give you a like, I think you should make a blog/article. Just sharing in the comment like this is not a good way. Btw, are you sure every time we call cast it will load a new block of memory. Afaik, the problem with casting is you get the whole object to memory (but after it is loaded, it wont load again), but only use one part of data, that's why we need to use interface, or caching reference... But I'm just a junior unity dev (with 2d games only), and start learning ue5
Thank you for this goldmine infos , men i was thinking of giving up on UE because C++ was hard for me , but reading what you said made me realize The Power of BluePrints , Thank you men for taking time to show us this , you are the true Hero that we need . oh yeah you said something about making your indie game
Blueprints are good start, but there are cases where you can do something in 3 lines of code in cpp that will take half of your screen in blueprints when using the exact same functions.
Sure, if you're doing something very unusual, it can make sense to use C++. But I think most folks are trying to make their own take on fairly conventional genres.
you should collapse nodes a lot, its build in a way that you can collapse stuff like folders in your pc and never have all nodes on a same level, this way you can have infinite space to work with and never care how much space they take
THIS. Graphical programming looks simpler on the surface (the automatic type checking when making connections, for instance), but it leads to its own complications. Unity wants everyone to use Shader Graph instead of writing text shaders... but a few lines of HLSL code takes up an entire screen in Shader Graph.
@@Lantertronics Yeah, no matter how much you put things in subgraphs it is always cleaner to have it in code. When things get complicated it's very painful to navigate large number of graphs.
What I’ve found over time is how Unreal can really shine by leveraging BP and C++ for their different strengths. BP is good for, as the name suggests, prototyping and quickly iterating until the foundations of the functionality you’re creating emerge. Then you separate out the core, constant functionality and make that into the base C++ class, and just expose the elements that are subject to design iterations to Blueprint. It cleans up the BP and runs faster, while still keeping the design elements available for quick iteration. Also Unreal is definitely more built on an object-oriented mentality vs. Unity where everything is a component, so it’s cool to see the different ways of thinking about things. Anyway happy learning!
Thank you for this Info , I appreciate it . Can you tell me or guide me to a video talking about when its better to use C++ and where its better to use BP . Thank you in advance .
I'm a first time learner of Game Dev and it's taken me a couple months to get to the point where I can start crafting some logic that I want. I've had to basically learn EVeryThing to do anything, try to practice, go back and learn everything again, practice, search for what I need to know, give up, remotivate, beat my head against the wall, etc.etc, Each time I get over another hump though I feel So rewarded and like I'm getting that much closer to where I can start Creating what I want. Cheers!
@@CraigPerko Thanks! Not sure If I can explain it right, but right now I'm trying to figure out a blueprint communication system where an NPC steps into the collision box of a house and owns that house, then anyone else who crosses, becomes an intruder; updating that NPCs Behavior Tree to chase them out, then have them be less forgiving when they have to chase you out a second time. Should I be dispatching from the House_BP to the Level_BP and then to that npc's controller, and then update blackboard from the controller? I've got so many nodes everywhere to try and make it happen, but I think I just need the general communication chain concept to know where to process the conditions
@@murnoth You're right: this is a matter of working out the general communication chain. In my case, I would have anyone entering the "house box" trigger the house itself to process them. If there's nobody registered, they get registered. If they're an intruder, the registered owner receives a command to chase out the intruder. There are some considerations here - for example, when does the NPC stop chasing the intruder? Can the intruder be hiding? What if there's multiple intruders? But the basic idea of "the house complains to the owner about the people going into it" means that the logic of "how does this NPC deal with an enemy" can be entirely contained within the NPC and reused for other kinds of situations.
I've known I have to switch for so long it's unreasonable to think unity is going to fix itself as this point. It will take some getting used to switching from code to nodes for sure.
I'm finally making the switch to Unreal... it's like ripping off a bandaid.. it's going to be tough at the onset, but I have to get pass this initial hurdle. I'm going to stick with it! One day soon, I'll be able to call myself an Unreal developer and drop the Unity Developer title.
@@CraigPerko they really have I just sat and watched your last few videos (gameobjects vs actors) and it helped so much. Thank you! New subscriber here!
Idk about the strictly blueprints thing, I actually prefer to use C++ when I’m making stuff in unreal, especially when building multiplayer systems where you get so much more customizability with your netcode, and speed in general for anything computationally expensive
I think most indie devs will feel more comfortable starting in blueprints, and many will simply stay there. The C++ can be used when they're familiar with Unreal enough to know they want something both custom and complex.
I found Unreal amazing too, the controls, the interface and everything really is better than Unity. I published two games on Google play store with Unity 3D but I am glad I gave Unreal a shot, it is so much better in every way. Even complicated things are super easy to achieve in Unreal and in Unity it becomes a jumbled mess as soon as you start adding features to your game. Script after script it gets super hard to find out where you went wrong, Unreal is a class of its own and I think a lot more Unity developers will make the switch in the upcoming month. Great video liked and subed
Why will they be "switching in the upcoming month"? Just because of social media pressure? I'm aware of what's going on in Unity, but it hasn't made me act like sheep to be amongst the cool kids. Apologies if I misunderstood anyone's intentions of switching engines, but my current impression still is that it's social media influence
Oh... I deleted a response because I misread it, sorry. Shayan, it's not "acting like a sheep" to want to use a product from a vaguely competent corporation instead of one that is run into the ground.
@@CraigPerko I don't see it being run into the ground yet. Engine's fully functional and usable. Until something breaks in the engine that makes it unusable, then i'd understand
@@CraigPerko yes acting like a sheep is a bit of a weird statement, I say use both engines and see which one you like better. Everyone is different and I am sharing my experience that Unreal makes things easier and as a game Dev that's exactly what I am looking for, Unity can't really compete with unreal but it's a great engine too I just prefer Unreal.
Yeah, this isn't a huge disagreement. I don't like the way Unity is going and a lot of folks agree, but it's not like continuing to use Unity makes you evil.
I always saw unreal as a bit of an intimidating engine, for some reason. I'm also scared to learn a whole new engine just to see their directors starting to make morally dubious decisions and then I have to run to another one again...
@@CraigPerko I'm afraid that in order to avoid evil megacorps I would have to become a hermit but anw I'm curious. Did you let unity go because of ethical reasons or technical reasons?
@@INRamos13 First they merged with a malware company, then later in the day the CEO said folks not abusively monetizing are, and I quote, "fucking idiots".
@@hkanything The layoff is terrible, instead of firing the bloated management team, they fired part of their core engineering team and AI team. And then they merge with a malware company? Yes, now Unity is an ads company.
"There's already a right way to do it" screams cookie cutter to me. What If I want the second jump to behave very different compared to the first? (which you would probably want in many cases). I'm interesting in learning Unreal Engine for the sole pleasure of expanding my knowledge. But I really hope you are wrong. Else I'll just pick any other engine.
I've been developing in Unreal for about 7 years now and sure the double jump is built in, but in my game I'm developing I've customized the double jump and even the gravity with the jump in Blueprints. Its not a cookie cutter. There are a lot of built in functions that are common in many games that the devs already programmed into the character actor. Things like having the AI sense edges, whether they fall off or turn around, character speed for walking, running, jump height etc. You can always write your own functions though or use the built in ones. You are not restricted, but think of them as really good jumping off points. In my personal opinion the built in Jump and double jump feel too floaty which is why I made my own version.
@@QuadPoly when you say 'made my own version' did you just customize what was there or did you literally just look at their version then build your own from scratch? I'm interested to know how much work would be required to customize existing blueprints. Thanks
I've heard people say a balanced approach would be using C++ for coding systems for your games. Use blueprints to then build on top of them and actually use those systems. Is that a good approach? Also, can you please do a video explaining the concept of Actors, how to set things up in the hierarchy, especially if you're coming from Unity. Thanks :)
This seems to be a popular question, so I'll do it. As for coding: I don't recommend coding in C++ until you already know Unreal pretty well. It's not a good way to learn. You can make the systems in blueprints for nearly all cases.
@@CraigPerko This actually helps, I get what you mean haha. I worked for a week on unreal (coming from 8 years on Unity), and it was hard for me to understand you actually don't have to create a character controller from scratch. Unreal has one and will probably be perfect in most cases. But coming from Unity, I feel a bit stressed out by this. If feel like that if I finally realize I have no other choice than creating my own controller, it will be much more complicated to do in Unreal than Unity. Or am I wrong ?
@@AlcideRouge I have lots of experience in unreal, here is how I deal with these things There is not any "right way" sometimes unreal has some pre-built stuff you can use, like movement controller for characters and it helps. Sometimes you can add unique features on top of those. Sometimes its just better to built stuff on your own. Like I don't ever use inbuilt "give damage" functions or "sight sensory" functions or expecially I don't use standard behavior tree, becasue its just horrible/buggy, and I rather build my own AI behavior trees using blueprints which never let me down
good video, but there's definitely a use for c++. Blueprints are nice for a lot of things however more often than not in multiplayer games, blueprints can be pretty expensive. But non the less blue prints are pretty fantastic. We had originally planned to do our whole game in blueprints and quickly realized it would run very badly replication wise, so we swapped to c++, also there is a lot that can't be touched at an engine level when it comes to physics and such, so this requires you to have a c++ source build.
I've been getting a TON of these Unity is dead, switch to Unreal, Unreal, Unreal is great, Unity merger is teh eval. All I was looking up was an inventory script O.O and a shader script yesterday... What the heck is up with RU-vid right now.
Blueprint is coding. I've argued this since it was still kismet. Anyone who denies this either has a fundamental misunderstanding of blueprint, or thinks because they know cpp theyre above bp.
@@workflowinmind Oh, after a long sequence of firing folks, they merged with a malware company and the CEO said extremely unkind things about anyone not making an abusively monetized mobile game.
This week i tried doing the opposite, just realized that unity u have to do everything, unreal have a lot of things build in already and that helps a lotttt. In 1 click u can enable gravity and that it. Gonna focus on unreal and c++.
If you still want to work with C# you can try to use UnrealCLR. It is a free plugin that natively integrates the .NET host into the Unreal Engine with the Common Language Runtime for direct execution of managed code to build a game/application logic using the full power of C# 10.0, F# 6.0, and .NET facilities with engine API.
@@CraigPerko I use blender but never cares about them, use zrbsuh but never even know the creator name, Why you want them to care about me ?? Ahh maybe you mean the way unreal do things free every month and bridge assets for free ? Well I really don't know what you mean by *cares about you *
The entire situation with unity which is making me think about switching to unreal, but I already have a project in unity that (while far from being finished) have a lot of progress made on it so far, if I switch I would probably have to restart. There is also another issue about learning unreal. I'm already very used to unity, so I'm not sure how long it would take to get used to a whole new engine. And the thing about blueprints. Am I able to make more complicated game mechanics with it? Or am I only able to make generic stuff like running, jumping, shooting, etc. I do kind of want to make the switch but I'm not sure whether it's worth it or not.
Trying to reboot your project in Unreal would effectively be restarting it, although obviously assets like meshes and textures are compatible. Aside from that, Unreal is pretty easy to try out: there's no reason not to try to build something in it. Blueprints are extremely flexible and capable.
That depends on what they are and when they need to exist. Actors within actors are reasonably common, but if you're coming in from Unity, you should try to do most of your nesting with components until you've internalized how Unreal works.
how's life treating you over on the unreal side of game dev? can you sahre the your likes and dislike of the engine? i tried it last year and i find it tedious to use the blueprint sometimes. however, the blueprint is in fact very intuitive way to think of coding. another thing i dont like about unreal is that the file tends to get too big. and the games i play that uses unreal are always giving me crashes like black desert online and blade and soul, i dont know why, but unreal gives me an impression of unstable game.
I like Unreal because it is very easy to do things once you know how to do them, but the downside is that it takes a lot to learn how to do them. I don't have any significant crashes - is your video card alright? You might have an old driver or some bad memory.
Man so many unity people are oblivious to this, they keep going on an on about how unreal is just a fad and unity can do all that too and unity is just as good as unreal like Unreal has shipped so many games that everything in it just work. Sure it crashes quite often but I has autosave and it doesn't fight you like unity does.
The interesting thing about Unreal crashes is that I find they only happen when I try to do something without knowing how to do it. For example, when I misunderstood skeletons and kept trying to cast animation controllers to other skeletons. I haven't had any crashes at all since getting the 5.0 release. Probably because I'm sticking to the well-worn standard paths.
I hate visual scripting and i have to do it. because compiling cpp is so slow and intellisense nearly doesn't work at all. blueprints are lit tho. i like it the more i use it. i hate every second i have to use unreal tho.
Really, Unreal advances so fast that tools like Nanite, Lumen, MetaHumans, WorldPartition, etc leave aside any engine but at the same time it takes time to train professionally.
Well, you first need to invest in Unreal (yes, RTX and fancy setup) And yes unreal is advancing? Ahh world partition I'm unreal? Ahh yes Occlusion culling in unity ?? Same things Ahhhhh lumen??? Ohh RealtimeGI (in unity) Ahh same things but different names Yes unity has no Metahumam or bridge to help devs with free things
Advancing more than Unity Yes... in terms of Graphics and Tools. But in Stylize Graphics i think Unity is better at it... (like Toon or Unlit). and no RealtimeGI is not the Same as Lumen in terms of Quality, thats like Saying Pepsi and Coca-cola are the Same, Yes they Both Are the Same Flavor but Different Qualities, From what i can see, Lumen Looks Better even to its much More Graphicly Intensive than RealtimeGI... in Bad News Department: a bunch of bad Rep which is making some People Un-easy about it... but TBH i don't think thats the Main Reason they are Leaving Unity... For me i Choose Unreal cause of the Tool it has out of the Box, soo many Interestings ones, Like the Textures Tab, its like the Shading tab from Blender or Substance Painter!, which im Down for... Unity has one too... but i haven't seen many People make Amazing stuff with it Yet, Theres also this Grass Placer thingy that i keep seeing people use, and it Runs Supers Smoothly and it works!, it simply Places Objects like a Spray, from what i see, it simply works out of the Box with Little Feddling Around, people tend to use it for Trees - Grass - Flowers - Rocks , etc... Unity does have this but i have not seeing Anybody Use it, or Showcase it... instead they use Code or some form Generation Algorithm to do it... which is another way of doing things, but i like having Craeative Control over Small Details xD... Theres other stuff... but atleast thats what Intrigue me to unreal... in terms of Code: they're both the same, you have to learn a Language and Bend the Rules to fit your Needs... and by Bending those Rules you will have to Eventually Bug Fix them...
@@pikachufan25 well, as I used both Unity has so many many books and tutorials about shaders or VFX But unreal no Yes unreal is damm crazy well maded, but you you need time to learn basics (you can learn the engine itself(without blueprints) But it will take time, As a 3d artist , importing assets to unity is faster than in Unreal. And unity is automatically sync with every software's Yes. You can make real time Gi in unity, it's just simple as in Unreal, But yeah as much as I earn income from epic market place and unity asset store... Hmm for me they are similar, But unreal require your computer to damm have high setups and RTXs, For unity I can use realtime global illumination (called lumen in Unreal ) with a normal computer Exporting game in Unreal take more time than rendering in blender In unity it take 20 sec People says unreal is better for FPS Till now, games are boring in Unreal, they are realistic as hell but no gameplay Another thing is, even indie unreal/unity devs make good game than everyone Making a shader in Unreal will make you compile things several times (trust me, it's frustrating ) In another hand, unreal handle well virtual texturing, yes, that is incredibly powerful Foliages and rendering (images or videos) yes unreal handle those stuffs well For films and animations, many people use whatever they have, unreal people will use unreal and unity people will use unity , Nanite, metahuman and world partition, yes By the way world partition , it's just a shortcut, Unreal devs nowadays tend more to relay on tools made for them (FREE) For unity, yes, they code their own stuffs And yes, I bet if unity devs had a free things like bridge or Metahumam, you could see many dev making huge stuffs Unreal is good (when you on udemy , skillshare....) and some RU-vid But majority of Unreal RU-vid's just tend to show off their computers and "if my computer can run 100000 high poly models) but they will never teach something interesting My fav RU-vid's -unreal -punisher(pvnisher I don't know) - Mathieu *a French RU-vid And some with good contents But many of them just making boring games (yes. 8k texture doesn't make them game good, just the visual will be good) In 2023~2024 I'll learn more about non games programmes (in UE and U3d) About godot.... nah.. I'll wait to see
Human nature like to brag themselves about certain abilities they process while the others don't. When it comes to program with code or node, there will almost always someone trying to say code is better than graphic. Because he/she knows the harder one, the better one. This kind of argument has been going on in all areas of human life. Basic , C, C++ C# Java Python, Maya vs Blender, Nuke vs after effects, Davinci vs PR. Machine code anyone? You know what, I have one word for all the braggers. Childish!
Dunno what the big deal is, Unity has never been better than ever, people in search of dumpster fire over a stupid talking head. I started with GMS moved to Unreal and then switched to Unity as a happy accident. Blue prints are garbage way to develop, maybe intuitive for state machines, but Unity framework gives me the freedom to in find new ways to solve problems, this is what being artist is all about, this is what gaming is all about. I've been a game developing for 20+ years before since Unreal was just a modding editor, tools are great, but the more you rely on Cookie cutter drag and drops, the more you loose your identity and what makes your game stand out form the rest of the _____ game template.
Welcome to the cage of "right way to do". Slavery is Freedom. What if i procedurally generate all my geometry with multithreaded function collapse in a galaxy-sized space, simulate behaviour of millions of characters on gpu? Will blueprints be sufficient for that? Or am i bound to make 3d person shooters about double jump for the rest of my life?
What are you talking about? The engine offers great default approaches that Actually Work for almost all common game systems, and can be used with no code. If you learn how to do it right, you can then decide to do it wrong. If you want to do it differently without understanding the engine, or want to do something that is super unique because you're a technical genius, then go ahead. Don't blame the engine for not supporting your endeavors. That's not Unreal being a straightjacket: it's the standard Unity experience.
@@neolynxer No, but I don't expect you to believe me. In the unlikely case where an indie dev needs to invent a new way to do something that already works in another, easier way, Unreal won't prevent you from doing that. But nothing will help you, in any engine.
Ok tried posting this 3 times now. Greg Wondra has some great courses on UE. So does Gamedev tv. Wondra is an industry vet with 12+ years in game dev. And Gamedev tv is made up of vets and indies with a lot of experience. Either or both are great places to start if you're new to UE.
Hah, RU-vid's been getting flooded with linkspam, so they automatically quarantine links. But you're right - there are some great places to start! Thanks for the tips!
Lots of Unity defectors now. It looks to me that Unity got itself stuck in a bad loop by going public. Now they go as the NASDAQ goes. Interesting to see if they recover, when the market turns.
The problem with Unity isn't the engine's capabilities, it's the direction the company is driving. 2D stuff is a sticky wicket, and it really depends on what kind of 2D thing you're doing. I might give Godot a shot, if I was doing 2D. But there are a bunch of 2D-specific indie engines you can try, too. Shame that the established 2D engines are also self-destructing.
Ok. Edit. Although there is many 2D games made in Unreal and most of the needed 2D tools comes with the engine - Unreal is not that prepared out of the box for 2D. There is paid plugins that fix those problems like "Pixel 2D for Unreal". From what I understand Unreal doesn't have that good 2D pixel collision/physics. Also from what it seems - the 2D animation features aren't that polished or on the level as the rest of engine. So in short - if you really aim for 2D games solely - maybe try something different.
@@LyubomirIko It makes sense that is not 2D oriented out of the box, they clearly focus on 3D, and they excel at it. Probably Unity's bigger problem is lack of focus, so no one can blame UE.
@@CraigPerko I don't know unity but I always have actors inside actors, spawning more actors, my game mechanics are incredibly complex but I'm not really sure what is supposed to be wrong with that according to video. It works exactly as its supposed to. You delete one actor, all its child actors get deleted, etc... parenting in world outliner you showed is not that importand, I never use that for example
I am specifically talking about how they aren't GameObjects. Since you clearly don't think they're GameObjects, do whatever you want. What I showed was the thing that made me bounce off Unreal twice.
Ok, I do admit that I'm worried about the roads Unity takes. And I'm even looking for this kind of video. But I'd rather switch to Godot. In fact, I downloaded it yesterday and begun to play around with it. Sure, Unreal might be a decent Engine, but I just try to avoid touching things that come from "epic".
@@w0nnafight I don't think it's videoworthy. Basically, it combines the worst part of Unity's freewheeling nesting and Unreal's dependence on scene components, without getting Unity's unlimited monobehaviours or Unreal's unlimited actor components.
