I Made the SAME GAME in Unity and Unreal!!! THIS is What Happened
Vložit
- čas přidán 4. 06. 2023
- unreal... unity... no unreal... what engine to choose?! For those who have been following me, i started game development in unreal but also explored unity for a handful of reasons, and now we're back to comparing the 2 engines on a new skill level, and the results... might be different than last time...
Join the discord for any help you need! : / discord
support the channel and development over on patreon : / thegamingcaves - Věda a technologie
I love that you weren't scared to switch from visual programming to learning C# and C++.
Once you know these, the sky is your limit ;-)
it also really helps to create a better understanding of a lot of programming concepts. especially c++ forcing me to read up on pointers
I am constantly torn between Unreal and Unity. The work flow of Unreal clicks better for me but C# feels so much more intuitive to me after years of using it and I just find C# more enjoyable to program in, probably because I don't have to think as much since I haven't used C++ nearly as much. In Unreal you get so much out of the box that just works whereas to get the same amount of features in Unity you could easily spend more than $1000 in asset store add-ons or spend countless hours coding them yourself (granted no single game needs all those features/add-ons and there are plenty I have never used but they are just there in Unreal if I ever want to). The whole editor user interface in Unreal is more pleasant and intuitive to me though plenty of people like Unity's. At the end of the day though I will use either one but lean more toward Unreal every day.
in the end I agree, both are perfectly fine but now that i'm a few months deeper into this I can confirm that deciding to dedicate more time to unreal was and is worth it. and while c++ might take a little getting used to, it's not as intimidating as it sounds for unreal since all the scary stuff that usually comes with programming in c++ liek memory management and such, are 99% taken care of by the engine, the only thing that really is important is understanding what pointer variables are, but even then, when you actually do and don't have to use them, the engine will steer you in since functions return types or parameters will just need you to use one or the other (usually it expect pointers). beyond that, I personally dont feel a very big difference going from c# to c++ (at least within unreal ).
of course, a bunch of the functions you know and love using in unity will have different names in unreal, need to be called different ways through different classes etc. All that can be a huge pain but if it is specifically c++ you're worried about I think you'll find the way it feels to code in it using unreal is pretty tame :)
i developed depression learning c++ as an artist and troubleshooting errors through unity community is way easier to me. unreal feels more niche and way harder. One thing i can say 100% sure Unreal animation system has no match once u get used to c++. Accessing things u have on script binding functions etc feels so smooth.
Welp, no more
@@mercerwing1458 Yup. I have used Unreal exclusively since I made that comment and I don't regret that decision at all, especially now.
@DireSwift Unity wants some $0.20 per install
The problem that you described with rocks needing to call a function on the player to stop mining is a good candidate for an event dispatch. Like you said, giving every rock a pointer and hard-coupling rocks and players together is silly. What should happen is you should essentially think in terms of messages being dispatched out by certain objects, and whatever objects need to know when something happens simply become subscribers to those messages. This way you are not having certain objects call methods directly on other objects, requiring them to know about each other, you simply say "Hey, this thing happened, anyone that cares can respond to it now". This could be a player not mining anymore, some UI being updated, etc.
100% wouldve been the way to go for the most part!
That said, in this specific case I do think there is an argument to be made for a system that does directly talk to the player, at least in unreal. In unreal's animation system you have "animation slots" which are just a slot in your animation logic that can be filled by (more or less) any animation. that way you dont have to write a whole state machine or logic for every animation you could possibly ever do, instead, anything that you consider an "action" like attacks, or in this case mining, can be triggered through this slot. so if the rock would have played the players mining animation on that slot, that would make for an easily scalable system where a tree can play the woodcutting animation, a river can play the fishing animation, a door can play the "open a door animation" and so on.
For that a direct pointer to the player would be needed, which I agree, generally isn't the greatest way to code thing but if you have a good reason like this, I think it's a better solution in the end to do that compared to having to overcomplicate your animation logic and it'll also save a lot of work if you have many objects you can interact with, since you dont have to go back and change something in your animation logic every time you add a new item to interact with :)
A proper message system would be better than just an event dispatcher as it further decouples the system, and can allow you to more easily implement priority based messages. That way your “events” can have a higher priority and be handled immediately while lower priority messages can be handled later as needed.
@@anwaraislingI think you might not understand the differences between events and messages clearly enough. Messages are targeted towards specific recipients, whereas events are generally broadcast to anyone who is interested in a particular event. Clearly we're trying to get away from specifically targeting one system or another, but rather we want to emit an event and have any interested recipients respond, this is how you truly decouple different parts of a game/application. As for the priority aspect, you can certainly have an event listener respond to events based on priorities, just as you would with a message queue.
@@thegamedevcave you can do the same thing in Unity using AnimationControllerOverrides tho. I'm doing exactly that in my RPG where I just set the animation clip based on what I'm interacting with. Even works with weapon skills, like each of my weapon sets has a defined set of abilities with unique animations, etc. It also works with Netcode too.
All my NPCs and players are "agents" (my own system) with its own override instance to the same humanoid animation controller. Pretty easy in Unity too in my opinion.
@@Stunex i dont think this particular comment thread is really about what unity VS unreal can do, this is about the way i set my code up to begin with being not very scalable and kind of just slapped together. I am aware of animation overrides and have used them in unity before.
Someone said, simply, a complex and long task takes fewer nodes than code but also, a simple task takes more nodes but fewer to code.
Thank you. That was very helpful. That's the only you can settle this issue. Great video.
Looks like you face some challenges in software architecture rather than engine, I’d look up architecture patterns (event driven, dependency injection, etc.)
I wont claim to be some sort of coding wizard by amy means but the rough code in this video is on large part due to making it hp as i go and more importantly, thinking of something i could easily reproduce on both engines at the time. So yeah, the engine switch is a big part of all that here.
This was a very nice video and look forward to your progress with the Unreal Engine and your game. I am in the process of teaching myself C++ and debating if I should just take a side course that focuses on C++ by itself or just use an Unreal Engine C++ course to learn it. What would you recommend? +1 Sub
personally I also struggled with that but after learning more about unreal c++ i can say this :
while it's good the have a decent grasp on c++, understanding this like pointers/ references at least on a basic level, you'll likely learn that when learning c++ for unreal too and since you're already working with a whole framework created by epic games, you don't actually have to worry too much about memory management (something which c++ is notorious for). so spending a whole bunch of time learning how to deal with vanilla c++ will for sure improve your grasp on using it but all together isn't the best use of your time I think, you're way better off just learning it's use in unreal engine itself, although it'd help if c++ isn't your first language. I followed a specific c++ for unreal course over at gamedev.tv which I can recommend very much! the courses tend to be pretty expensive but they are offered in things like humble bundles or sales decently often if you wanna save some money on it.
@@thegamedevcave Good to know I have a few C++ courses already just have not devoted the time to learning it since I have been busy learning other stuff for my current job and career field but I more and more want to spend time learning development and real so I may allocate more time for it. Thanks for the advice.
I'm an artist and I used Unity for over 10 years at my last job and hated every min of it. I taught myself how to us C++ and blueprints and never looked back. I've pretty much used every engine out there and I've never used anything as good as Unreal 5 most people are just to lazy to learn it.
people are intimidated by unreal's reputation of being a really hard engine to work that's only for big AAA games with but it's really not that hard. I would argue in some ways it's easier than something like unity. Especially as an artist though, i can 100% see why you would prefer unreal. I, as a solo developer also love it!
I give to Unreal a shot every year since 6 years and still a no. I don't understand the workflow of this engine.
Thanks bro
@@thegamedevcavewhat if I wanted to make a complex 3D like GTA 5 but way smaller map and sacrifice graphics so it looks like GTA 4 but runs smooth ?
@@mr.johnson3889 that's a very complex topic to talk and think about. I think using unreal with all it's included tools would help you out a lot and building a whole city like that, with this like nanite and it's built in world partition system, youre likely to get better performance with less work in unreal.
Piece of advice from a novice who has not shipped a game yet, but heard this multiple times: "A game has to be fun, regarding of the graphics. If the game is fun, the graphics will be a nice plus. But the graphics will not make a boring game into a fun game".
only party agree with that, the sentiment is right of course, but as with most of these (generally great) catchy wisdoms, it tends to be oversimplified.
of course there is games like Undertale which stick with people despite looking very basic and a whole heap of AAA games that look amazing but are bland as hell.
a game looking "good" doesn't need to mean photorealistic, it means it succeeds in it's art style. so what you need, indeed aren't just a bunch of things that make a game look like real life, there are more and more examples of games that look photoreal and aren't interesting. but instead, you need a set of tools that helps you deliver on a vision, both in fun factor (gameplay) and artstyle (graphics). There things one engine is better at than the other of course and it's not like either engine makes anything really impossible but I feel that Unreal engine gives a developer more tools to start with to deliver on a vision.
That can be either a positive or a negative though, depending, there is a lot to be said for starting with a clean slate and making everything yourself :)
@@thegamedevcave Completely agree with this
This aged like wine. And also i saw unity lacking in some features and documentation on the preview feature rolled out that broke the whole workflow
I didn't found that info in video, You used standard pipeline or HDRP for Unity? Because standard pipeline indeed looks basic, but HDRP out of the box looks nice, so I'm wondering if You factored it
This is using HDRP , the standard render pipeline is outdated anyway and even the URP I dont see much reason to use (aside from development for maybe mobile games?). Shouldve made a point to specify that but even with the HDRP, out of the box the looks are somewhat lacking in quality comparatively. I know using the HDRP you can make fantastic looking results of course though
@@thegamedevcave ok, good to know, so yeah, looks like unreal looks indeed much better straight out of the box, that's interesting! thanks!
THanks! That was superinformative!
Glad you enjoyed it!
You could use the C++ coding method that Ue gives you the ability to replace with blueprints when creating a new game
But thats only if you prefer coding over blueprints
Surprisingly the first programming language I ever learned was c, followed by c++. It was afterward that I discovered that people considered it hard. Needless to say, knowing c++ made learning new languages super easy. And also made Unreal my engine of choice, after I was done spending a few years playing around with SDL2. What can I say, I just love coding. Code just looks so beautiful, and yes. Even I think that's weird
My university made us learn C++ at the very beginning, and it made learning languages like C# so much easier as its really simple to grasp what a garbage collector is for, and how pointers, and references work under the hood in other languages. Really a great language to know, even if you don't end up using it. I do love it though :)
I just started in C# one day, which is still a bit of an oddity in web development. It wasn't until years later that I found out I should have like 3x the payscale I had, because it was considered that much harder. I just started and never looked back, lol.
Well, I mean, eventually I did go back. But that's just because I disliked Microsoft.
at my university, the first language I learned was c++.
They really throwed us to the deep end with no parachute 😅
Thank you for sharing this!
you hit the nail on the head, I have spent a lot of time trying to get unity looking the way that I want whereas in Unreal It's done pretty much instantly. So In my case Unreal saves me tons of time.
I like unreal blueprints even though c++ was my first language.
I still also use blueprints a decent amount! I'm programming all the object functionality and system in c++ but the actual implementations on specific actors, level blueprint,, even mostly anything to do with widgets, i feel more comfortable with using blueprint to script out those things. It's the combination of both that is so damn powerful.
So you want it a generic 3D look and it was easy because Unreal looks that way out of the box or what is your point exactly?
@@Mikefiser My point is that Unreal is giving me EXACTLY the look that I want and saving me a LOT of time in the process
@@Mikefiser You can always swap out the models, textures or shaders later. Per electricity bill, your average Joe does more with Unreal.
The mining game could have been made in 10 minutes in unity. You made that way more complex than it had to be. a rock class with an int for the 3 colors and a simple list for the inventory. OnMouseDown calling start coroutine dig function, and a simple bool to tell the player to stop digging.
that is effectively what I did though... a quick and dirty, badly coded game 😅
you could have made it in 10 minutes, but unlike unreal unity will take a lot of money from you literal greedfest from the stockholders
@@Exhalted1unity devs (I am not one) and c# devs (I am one) are hoping that unity will get better, since they sh!tcanned the ceo riccitiello whose greed was just too obvious
@@zimriel nah unity said they aren't backing down from this new permanent cut they'll be taking
They believe and they might be right that kinda like apple and headphone jacks if unity starts to eat good from the new cut then unreal and cry etc. will also start doing what unity is doing now.
@@Exhalted1 Right now Unity taxes are capped under Unreal taxes, what are you talking about? And are you doing over 100.000$ / year? buy the license. You do over 1.000.000? No need to worry, you still pay less than you would with Unreal. Maybe they are going to change the taxes again? How do you know that Unreal won't do the same, now that Unity has higher taxes than before? You only pay more taxes for Unity than unreal if you are in the 100K - 1M bracket (and even then, you just need to pay the license)
I don’t know how you put things together and of course you would have your reasons for doing so, but I would think the rocks don’t need to know about a player’s existence at all. They could have an interact method that is self contained and returns a resource. This could be reused for every kind of interactable object, with none of them knowing about the player at all.
Oh without a doubt that would’ve been a way better way to do it. I kind of just jumped in without a plan and it shows 😅
@@thegamedevcave that’s often the most fun way to learn things though! Thanks for making the video
Currently on a smoke break. Been 7 years now. Hoping to make it to death.
That thing of "telling the player to stop minning from the timer on the rock" I believe is just a mistake you commited... let me explain.
You call an event on the rock object which has a timer that does a bunch of stuff (it hides the crystals, it adds the material to the player's inventory, and it also makes the crystal visible again after some time). And you assume you have to control the player animation from within that method. Now, my way of thinking it would be:
The player object will control it's own animations and will do that based on data recovered from the different elements on the game
so it basically would go like this
1.- The player starts interacting with a rock
2.- The rock will have an internal variable indicating if it is currently minable or not and will have a way to retrieve that variable
3.- The player will retrieve that variable to know if it can mine that rock or not
4.- If it can mine it, then it will call a method on that rock object to let it know it's been mined and will start a loop (as long as the mouse button is down, or the keyboard key is down) which will retrieve that variable and as long as that variable indicates the rock is minable it will display the minning animation, at some point, that variable will change so it will stop displaying the minning animation and add the mined elements to the player inventory.
5.- In parallel, in the rock object, a method will be called which let's it know it's been mined so it will start a timer to decide when it is not minable animore and will change that variable
6.- While that timer hasn't reach it's time, it will continue indicating it's mineable hence the player will keep displaying the animation
7.- Once the timer ends, it will change the variable indicating it is not minable anymore, it will also hide the crystals and start a new timer which will regenerate the crystals and reset the minable variable.
No need to have a reference to the player on the rock object.
A lot of people have come up with ways to improve this. The way I did it in this project leaves a lot to be desired, although I still do think that there is something to be said for the intractable object (the rock) being the one to tell the player to play an animation. that way you dont end up with a massive state machine with a bunch of animations once you also add trees to cut down, fishing spots, and so on and so forth. just keep a slot on your animation code for "action" animations and have the objects run their animations on that slot. Unreal even has a built in system for things just like this.
So yeah, the code in this video is real bad for a good list of reasons but I don't think running animations on the player from a different object really is an issue.
@@thegamedevcave well you made it look like it was an issue as there was not an easy way to obtain the reference to the player from the rock in order to execute the animation loop... I think is more optimized if the Player object is the only one that deals with it's own animations and just check values or states on whichever object the player is interacting with that would require an animation change.
Hi, i am also made last Week a small game for a jam with unreal. It feels good yes, but at the end I had a feeling of "overload". And also the final package for the customer was very big, for my little game (1,25 gig). That feels like a massive Payload for my small game. Can you maybe package your two dummy projects and tell the final package sizes? I think this is also a point for the decision which engine to use in my eyes.
best wishes
Alex
ah i already archived the projects for this video but you're right, unreal packages tend to be a fair bit larger than unity, especially when it's on small scale games like a gamejam game, although the difference becomes smaller as the scale of the project increases. certainly a factor to take into a count though when choosing an engine!
You can just delete “Library” folder and it will be 60-90% smaller
@@vklymenko nice! thanks for this info
Heb je een discord!
Ive had some experience with both and i still struggle to commit to one in particular. Unity i love for the breadth of knowledge available and how flexible it is, but i cant stand having to buy so many plugins.
On the other hand unreal feels bloaty and less flexible, bur has a lot of really cool features. I just wish it felt quicker to use.
Do you still love Unity?
@@MangaGamify nope, they've lot my trust pretty much entirely.
didn't read other comments
but in unreal you can reduce a bone to 0 and it will basically "remove" the axe, from what I know it can be done in the animation blueprint, anim graph section
the issue was that the axe was part of the skeletal mesh instead of a separate static mesh that was parented to a bone. I still wanted to use the bone to hold something else. but on import it seems like unreal combined the 2 meshes into 1 skeletal mesh where unity kept them as 2 separate meshes.
Solution : dont rely too much and stock materials and make you won damn models XD that fixes things
brilliant insights. I'm a unity developer with an open mind, not planning to leave but good to see what I'm missing on the other side.
Thanks! Unity is perfectly fine and has some major upsides to it that unreal is lacking in. all about the best tool for the job after all :)
@@thegamedevcave until you have to pay to use it
@@notinusesoon4975 i mean i dont trust unity to invest time into learning for the long term after what they just pulled. they walked most of it back of course, but it's a matter of time waiting for the next big moneygrab.
that said, as it stands right now, if you make more than like 1.3 million USD on a game (which most people wont of course) unreal is the more expensive option.
Personally, i think that's fair though, most people , even if they hit an indie success, won't get even close to that 1 million USD mark and even if they do, paying a bit more for an engine that offers just an insane amount more features makes perfect sense to me. if you pay 1 or 2% more on anything after a million, you just have to ask yourself, does this engine make my development more than that 1 or 2 % faster? and the answer to that very likely is yes.
@thegamedevcave
I'll assume the role of defending my toolkit in Unity. Trust is nice to have, not essential - we don't trust our government yet we participate in everything. What matters is the quality of the tools, and for you Unreal is better, for me highly customized Unity with my army of purchased Asset Store goodies and a HUUUUUGE CZcams Tutorial community gives me an EXCELLENT foundation to create. Yes a big part of my bias is that I'm already schooled up in Unity and it would take me more than 1 year to completely switch, granted.
Definitely agree the small amount of money isn't a big deal in either case, we're talking about a max of $0.21 per game sold for Unity, this is only a problem for 'free to play' games, which is the primary overlooked 'side case' being revised by Unity. I'm selling my game on Steam for $5+, who cares if I pay $0.21 or nothing? It's not important compared the effectiveness of my tools. No doubt Unity made a hasty mistake trying to stay alive, panic from not having a profitable business model while Unreal makes & sells games for money as primary income.
I feel the Unity community over-reacted hugely, aah we're all going to leave because of temporary pricing problems even though it's being fixed quickly. I can't say I understand my peers very well, but I literally have the most incredible power ever at my fingertips and am happy to fill the void.
Technically, I am of the opinion that creating advanced game mechanics with C# in Unity is better and faster than using Blueprints. Unreal Blueprints are sort of a shortcut template for commonly used functions, but I'm not making a clone ;)
Would anyone be able to suggest somewhere to start if i want to learn coding and 3d moddeling for making mods and possibly my own project one day?Im trying to learn with cd project reds redkit but lack of tutorials and the redkit itself being so specific for the one game has me wanting to learn these things sooner than i first thought.I know this sounds ambitious but i have no delusions on how long this will take to pick up (especially for a bloke like me)
I think bethesda mod kits are usually pretty well documented so maybe making mods for skyrim and fallout would be a good start? Personally i just jumped into unreal engine right from the start XD so i dont know all that much about modding
@@thegamedevcave Thank you
Is the left side Unity? I like the lighting and ground of the left scene more, but on the right the model textures/materials look better.
Just wanted to mention that when you're talking about having to access the player from all instances of rocks. You could have used a static player singleton in order to have the rocks be able to reference the player without having each rock save a reference to the player. You could also save the inventory in the player and access the inventory through the same static singleton variable.
For a multiplayer game this wouldn't really work and you would instead have to use events to determine which player clicked on the rock, but you could still do something similar by passing the player variable when they clicked on a rock. The singleton methods is better for single player games as there will only ever be one player object.
unreal simple has a static function in their library "get player character" which is effectively what you explain here (although a bit more flexible as you can also pass in an index for which player's character you want a pointer to in case you're making a multiplayer game.)
For this specific situation, i should have just done that, and realistically I would have but as I explain in the video I ran into something I didn't understand in how to use timer-delegates, so rather than taking the easiest way out (which again, in this case would've made more sense to begin with), I wanted to use this mechanism to ensure I learned how it functions and how to use it in the future, when I do need it.
since then I have had a few situations where I did need to use this in other scenario's where it makes more sense than here.
@@thegamedevcave mmm I don't have much experience in unreal but in unity you can pass parameters with coroutines. So if I wanted a delayed function then I would pass the player as a variable into the coroutine which can have multiple yields of waitforseconds(x), so you can then get the animation time of digging and wait until it's complete to trigger adding the items to the players inventory and switching back to the idle animation, or whatever other behavior you want. you could even add a loop of the digging behavior that can be interrupted, more similar to how it works in Skyrim.
The main benefit of coroutines is that the do not run on the main thread and allow other logic to continue to execute while they are running.
@@bradjones7491 yeah thats prettt much what i did :)
I appreciate your opinion on why you took up C++ programming. I didn't look at Unreal in that perspective. I'm using blueprints and should probably learn to C++ instead. Nodes are great and all, but I want more versatility and integration of my ideas into a video game. My issue is I feel I've wasted so much time learning nodes and then I learn a new node that just solves my problems. There's just so much to work with, but not enough resources to actually learn what's available for me and it's tempting to just pick something off of the market of something when I should just write it myself. Those are my thoughts on it, but perhaps the reality isn't what I think C++ would be like.
the issue you mention here isn't really different between blueprint, c++ or anything you have to learn really. Growing any skills takes 2 components : knowledge and understanding. You have to learn what building blocks you got to work with, and how they work. that's something that just takes time and lots of reading (or watching videos of course ;p ). So don't be discouraged, doing something the hard way, only to find out there is an easier way is a very natural process of learning and means you're getting better!
As far as blueprint vs c++ goes, I personally feel that using c++ helps with the understanding part of growing as a programmer, but aside from that it's largely a preference thing. you like code? c++ is great in unreal! if you don't like code and prefer blueprint, that's a 100% valid way to work on a game too!
@@thegamedevcave I don't mind learning to code, but not if I can stick with Blueprints mostly for grammatical reasons. I tend to blow things up by leaving a letter out and blueprints seem much cleaner. I think what I'm more interested is Blueprint syntax and also, an index of nodes. I'm trying to learn and understand the capabilities of everything I have offered to me so I can break my own plateaus. Like right now, I'm trying to figure out some old calculus and trig I learned and how to apply it into Unreal for Procedural meshes, etc etc. As much as I've appreciated the videos available to me, even places like Udemy lack the learning of more advanced uses of blueprints. Like how do I form Quadtrees? How do I create voxels? And I'm concerned if something like that is limited to learning C++. I'm not discouraged as much as I'm concerned if something is realistically applied. Anyway, thanks for the fast response.
@@AB-fg4mh there is very few things that you need c++ for that you can't do in blueprint. your specific need I am not sure on, could be a c++ only thing but there's a real good chance you can do it in blueprint. finding out how though can sometimes be tricky for sure.
I think blueprint work just fine. C++ will be needed if you going to do tools
correct me if I am wrong but I think you can use code and bleuprints in UE in the same project so you could actaully safe some time by using blueprints for stuff like making inventorys or the rock to mine from but use code to save some times on other tasks
you can, althoguh usally you wouldn't really do it for something like this, since blueprint can access what you make in c++ but c++ can't access anything made in blueprint so I couldn't make something in blueprint that I then want to call in c++.
The way those usually get used is all the system programming is done in c++, then anything that's needed for more game design based scripting is exposed to blueprint so it's quick and easy to make variants on a class, like you make your enemy class in c++, and then make a bunch of different blueprint derived from that c++ class that have their own implementation of that c++ code.
@@thegamedevcave thank you for your answer 😊
8:20 Why not just use in C# an Interface IClickable?
UE has all post-processes out of the box working automatically while in Unity you have to add and activate them but for sure UE is better from a visual point of view.
Megascans are also great. And Unity has a terrain tool and texturing working and looking like made 20 years ago and are not even close to modern solutions UE has.
i'm sure that could've been a good solution if I wanted to expand the game wider than this little test. probably also more performant than the way i describe in the video honestly
Totally agree. I did just that in my own game for anything the player can Interact with.
for your rocks example.. the way to solve this is to use events / delegates. this way the player can register to receive the event and unregister when they mine.
this approach works in both unity and unreal
yup that wouldve worked much better. still, my original alternative of having a parent class with a "i've been clicked" method that child classes can override is still a decent alternative I think.
Either way the code I slapped together in an afternoon while exploring a new engine, yeah that was real bad XD
@@thegamedevcave Im currently doing a similar activity.. learning Unreal after the Unity TOS changes.. Enjoy the journey and good coding to you!
i thought unreal was more different before i started it using much. currently i think both engine have quite similar flaws but also different ones.
(for example i still think working in unreal is slower...) so for each project im gonna pick a different engine for now.
(i thought the water tool works fine in unreal but no foam, no caustics out of the box... values are there. impact is not. very unity like)
I would like to point out that once you really get into the meat of developing a full game, there's a lot of things that can even the scale between the two engines in terms of time and effort saving.
Unreal works so well because it gives you many tools to simplify or automate what you would already do in a standard pipeline. There's often little reason to go against the grain, especially in the early stages of development...these are processes invented and refined by the top developers in the industry and used across hundreds of studios. Furthermore, it takes an approach to rendering and post-processing which is refined and middle ground. Likely it will already look how you want, and if not, you can easily tweak it from there.
However, that doesn't mean that a 3D game project will always take less time and effort in Unreal. Platform compatibility and optimization can be a big bugbear for both engines. But it's easier to work these things out in Unity because so many components of the engine can be exposed are at your control. Customized graphics or functions that vary greatly from the 'standard assumptions' made in Unreal are also generally easier to work out in unity. For example, we built a complex anime-style shader because it was very much dissatisfied with store built options, and because we needed it to work in complex ways in different environments anyway. Because we used Unreal for rendering certain pre-rendered cutscenes, while we built the game in Unity, we had to make a similar shader in both. The unreal one ended up taking almost 4 times as long to work out in Unreal, and still gave us many problems throughout production. Unity's was fast, and we even had time early on to switch from Shader Graph to the store asset Amplify (for future project compatibility reasons, not because we couldn't do it in shader graph). This shader work included modifying SRP components, which let us get the lighting to work exactly how we needed, and was the source of most of the aforementioned production problems in Unreal. (In hindsight, building the same shader functionality in two game engines was a stupid idea and waste of resources, but I was conned into agreeing with it, since my lead programmer came from an Unreal background)
It really depends on your project. Though I would say, you also should only try to specialize in one. So you have to be knowledgeable about the kind of games you want to make, what they need, and which engine is going to give that to you, from start to end. If you don't know that, you don't know enough about the kind of games you want to make.
certainly! neither engine is strictly objectively always "better" , they are tools that lend themselves better to one thing or another.
For me personally, unreal offers up what I want, as someone who works solo, and can't see myself even in the future growing beyond as much as a small team (I really like being solo honestly), unreal feels more comfortable and while I feel like my current main project is pretty ambitiously scaled, that is in the context of a small 1 man team. I will likely never work on actual big scale production.
Because you hit the nail on the head I think, the larger scale your production is, the less all the useful things unreal offers really make a difference, either because you'll want to create your own implementation for it or simply because a large portion of the Dev time is going to using those tools to create the actual game, and the upfront time spent developing those tools is relatively small. I'm happy to see you seem to be validating that view since I of course dont have a great view on scaled up game production (I have a background in film though, so I know more or less how media production in general will scale up and how much more time and manpower is exponentially needed when that scaling up happens).
so, long story short, I think the conclusion we both came to is the wise one, it's good to have a working knowledge on both I think but you can only become an expert in one or the other and there everyone has to make their own choice on what their games, their career and everything they want fits more, for me, that ends up being unreal but by no means will I ever look down on Unity as seems so common among unreal purists
@5:45, would it be better instead to use the player to check if the rock is valid on each mine.
there's lots of ways to do this, in the end, the way this works now isn't ideal but it's not too far off from a reasonable solution if I had just used an interface instead. The thing you want to prevent is to put code that references a bunch of different classes all on your player, because if you do, your player now needs to include info on all those classes, which can get really problematic.
So either through inheritance, having a parent class like "clickable object" or through the use of an interface where the player doesn't need to know what it's clicking on, just to send a message to the other object which that object can then do something with would be a good solution instead.
there's a lot of different ways I could've gone about doing this, in the end the right choice very much depends on the bigger picture for your project, which in this case, I didn't have a bigger picture besides just making what I did here :)
I'm not a game developer, and I only tried Unity a long time ago, but I remember you could add an invisible volume around an object, each time a player got inside that volume you could trigger an animation, for instance if you got near a door it would open.
Couldn't you use something similar in Unreal Engine to trigger the mining/stop mining animation?
Once there are no more rocks just remove the volume that alows the player to mine.
Those spaggetti references are giving me nightmares.
Not an ideal solution either but without a doubt better than the setup I have here
Yes, Unreal Editor has many varieties of volumes available for the dev to use.
@@thegamedevcave It was actually the official way to trigger actions.
Edit
It's trigger colliders.
czcams.com/video/m0fjrQkaES4/video.htmlsi=rhUtt32xea2Q5rgm
@@andresilvasophisma of course you can add a collision box like that, and that works fine but i still don't think setting up a collision box is more suited in this case than simply checking the distance from the player to the target object.
My code in this video is without a doubt really messy and bad though, that's for sure. But even in a better thought out system, i dont see myself using collision for this.
As a java developer with some 20 years or experience, I find C# much easier to comprehend than C++. It's as if C# is a sibling I haven't met for a few years, but whome it takes but a few minutes to get up to speed with. C++ on the other hand is like the brilliant but excentric uncle. You never quite know what he's up to, and whenever you think you've got him figured out he does something absolutely bonkers to confound you.
That said, what are your recommendations for getting better att C++? Because I really want to put some of them blueprints in the bin 🙂
it sounds like you're baing yourself of just vanilla basic c++ which, for the most part is a whole other beat compared to c# or something like java. I'm not going to claim that unreal makes c++ 100% as easy to work with as languages like that but it takes care of a lot of the bothersome things about c++ like memory management/garbage collection. With those taken care off, it's pretyt much a matter of getting used to some syntax things (like there not being a specific for each loop, rather making a for loop with an array just works as a for each loop, the dot operator is split into 3 different ones, you use a dot for objects an arrow -> for pointers and a :: for static classes).
which also brings up that you'll be working a good bit more with pointers and references. i dont 100% recall how things work with c# or java in this regard but if you have a fuction with a paramater, running that function will use a COPY of whatever you pass into it, so if you make changes to that parameter in that fuction, it won't actualyl chance the variable. Say you have a "add 5 to float" function like :
void AddToFloat(float VarToAddTo)
{
VarToAddTo+=5;
}
this wouldn't do anything, because you would need to pass in the memoery adress of that variable instead, that way you can change teh actual values on a variable inside of a function. Again, c# or java might do this the same way , but I seem to recall that the above example would work in c# where it doesn't in c++.
all that said though, getting into c++, at least for me, turned out to be way less scary than I hyped it up to be. I have a video on the channel going over a few basic changes between C# and c++ for unity devs and also a whole series that's still being released in which I go over making the basics of a game, and covering some of the most important things all in c++ which might both help you look into it :)
Thanks for the reply, some great insight! Good to know that UE takes care of garbage collection and memory management. That makes a huge difference to me, at least mentally. It's not that I couldn't learn it - it's that I really don't want to xD
Good to know about the functions as well. That is indeed different from Java, where a change to a variable sent as an argument to a function truly changes it. I've got to say I probably prefer the C++ way of it, treating the argument as a copy. Don't know why, but that is how I've always thought it should work.
Will take a look at your videos, might be just what I need to get over the threshold :) @@@thegamedevcave
@@the-nomad-show There is a lot to read up on on unreal's garbage collection, i dont fully grasp it myself but unless you want to keep specific objects with values to not be collected for whatever reason, it's a pretty "set it and forget it" kind of deal.
I also do like the way a function makes a copy of whatever arguments you pass in. it used to give me a massive headache but once you know that, it then allows you to easily write functions that actually do what you need :) If you got any questions about unreal or any c++ weirdness (i dont claim to be a c++ expert but I can manage well enough by now XD) I'd be happy to try and help :)
Suddenly, this is very interesting...
And the character animations are played better then unity animation system?
nothing that can't be fixed most likely but the animations imported very strangely into unity compared to how they imported into unreal indeed
NIce investigation.
I wanted to stop and leave a note on good for you for finally learning C++
People don't think it's relevant until they code it and find it rocket fast.
The only thing faster is some C and of course assembly.
This isn't 1989 anymore. Processors today don't let you take risks on overheating the hardware. C++ today doesn't run on assembler; even assembler doesn't run on assembler.
EDIT: exceptions to be made for coding on tiny dedicated processors, like for thermostats or sensors or sh!t like that. I'd suggest RUST for those; the compiler protects you.
@@zimriel very cool response.... certainly hardware is more complicated. And although rust is popular is has not gained huge adoption in production code yet.
why is it that unreal always is laggy in the editor
the unreal editor is unreasonably taxing on your system, especially if you , like me, dont have a lot of VRam. Which in my case that's made much worse by the fact taht i'm also recording my screen. if you're on old or low end hardware unreal's editor is a real issue
@@thegamedevcave I saw your reply on other comment saying how serious developer put a lot of time and effort and look at you here talking how your pc is not powerful enough.
Unreal is a heavy software no doubt but the amount of improvement unreal is making in gamedev is immense at this rate unity will NEVER catch up to unreal
@@shujin6600 it's actually a bit more nuanced than that. Aside from a lack of VRam my PC is actually quite powerful, the only reason unreal lags for me sometimes is my low amount of Vram. something that On the one side, I am not alone in, and is an issue for many small starting indie devs who simply can't afford to drop thousands of dollars on a workstation capable of running unreal smoothly. But on the other side, if you're serious about wanting to be a gamedev, I also don't think it's unreasonable to expect a dev to have hardware more powerful than the average consumer to work on.
I happen to have a decently powerful PC, because in my day to day work I need that, the only lacking thing is my 2 generations old GPU.
On top of all that you're passing by the main point of this comment, which is that unreal ran like shit in this video because I was also running a screenrecodring, another thing that taxes the GPU, which already is the weakest part of my system and without that, unreal runs smoothly without issue (within reason)
5:47 Why does A ROCK need to tell the player to stop mining? 🤔 Interfaces exist, where you can point at something, says it's a rock, then you do something that pertains to the rock.
8:24 Why? If it's an action that the player can do, of course it should be present in the player class/blueprint. If you interact with a door, the door shouldn't remotely trigger animations for the player to step through it.
the way the rocks work in this project are straight up stupid in how I coded them. as for the door, i can't help but still disagree with the idea that the player needs to hold functionality for literally every single object it could intact with. Taking runescape again as an example, all the player needs to know when you click on something is to move toward it, but imagine if the player needed to hold the code for literally every object in the game and how to interact with it? No thank you, instead like you mention in your first point you can use interfaces or delegates for the player, the player will know it needs to do SOMETHING but there is no good reason for the player to end up with 1000s+ lines of code all shoved into the player class. Instead, it should listen out for what the object you interact with tells you to do, that way it's super quick and easy to create new objects with functionality as complex as you like without overstuffing your player class for no reason.
Why did not you use HDRP in Unity?
Thats the thing, thus is hdrp
I was hoping to see some late-development stuff, like optimization and "weird things that should not happen, but do happen".
Cause Unity does its own "unity things" from time to time, and Im sure that so does Unreal, with its "unreal things".
that's a little more difficult to show in a video but you're right, any engine you're working in is going to have it's own weird quirky issues where you as a developer go "why in the world would they ever make it work like THAT?!" unreal is no exception, in fact I suspect unreal may have more of that going on with how it has a more strict framework you're working in compared to unity, which is somewhat more open-ended for devs to work with however they want.
@@thegamedevcave
Unity open-architecture style is a double-edged sword, as it allows for the most shitty architecture possible... But having a rigid one is also... :D Tough luck.
Going in depth for every topic would require making a whole series of movies, including:
Code Heavy Games ( eg. Oxygen Not included or Cities Skylines )
Graphics Heavy Games
Implementing various systems like: Localization, Multiplayer, Saving, Achievements etc.
Creating totally unorthodox genres of games and so on.
Finishing touches and weirdnesses
Still, it was a cool intro to the topic. Maybe consider trying out such a series one by one, as a kind of a tournament? XD
It looks like unity editor is in low resolution and quality setting is low quality, also the direct light position is very off, but what is the target pc or mobile, for pc urp or hdrp from unity is recommended, and I really doubt that unreal scene will look this good in Mobile and still keep performance and size low
i mean, the resolution really doesn't factor too much into this, yeah it's a smaller resolution, it's also smaller on screen. pixel density stays the same.
In Unity I am using the HDRP, since that's the most fair to compare to unreal's render pipeline. and the directional light isn't in any weird spot really, it's got a pretty low angle like it's a sunset, i can understand that makes the image a little darker but that by no means explains the huge gap in visual quality.
If you're focused on mobile platforms I do agree unity likely is the better option though. unreal can build mobile games but i dont see it as a main selling point of the engine more of an "oh it can also do that" it's clearly not meant to be used for that and I personally have little to no interest in publishing for mobile.
@@thegamedevcave Well, if you are more experienced with Unreal I think you made a good choice sticking with it. Because I guess you really suck at doing proper lighting and textures in Unity.
@@everythingcouldbesimplify818 think you kinda missed the point of the video if that's your takeaway but sure, i do agree that the outcome being unreal is better for me
I am watchin on 4k 55 inch display, not sure if people with lower size screen can see the texts easy 😉
Unity is y-up . Unreal is z-up. And Unity uses OpenGL coord ( in 2d , top is 0 ). Unreal uses DirectX coord ( in 2d , bottom is 0 ). It means Normal map's Y channel is converted in Unity. also Your tangents are break.
ah right of course, that's totally on me, i 100% overlooked that Unity's up axis being the Y would also mess with normal maps, that explains the weirds ass lighting on the character model!
I've heard about how Unity was better than Unreal or how the same could be same on the other way around... Honestly I'm torn. And maybe a bit biased since I'm more familiar with Unity and know nothing of Unreal Engine at the moment.
in the end, both are tools and it doesn't really matter very much which one you use. for a lot of the reasons I gave in this video, I like unreal, it provides more tools and more cool technology, but it having more to offer also means it's got more thing you need to learn, which makes it a bit harder to get into I think. If you're more comfortable working in unity, you should use that and the other way around.
Personally I feel that making something look and feel nice is much easier in unreal but Unity is, for example, much better for developing for mobile platforms and as far as I know, handles 2D games a fair bit better
@@thegamedevcave Thanks for your input. I'll watch that video later tho'.
With zero coding experience I find the blueprint system easier to work with.
blueprint is really nice for less experienced programmers to get into it for sure!
I have an idea for a game in my head for years and know some PS and Cinema 4D. Lets make EA2 :D
Thank you.
I feel like it should also matter a lot how the performance is.
If unreal is easier to make beautiful, you'd have to wonder whether this affects performance negatively or positively, right?
I myself am a micro-optimizing fool. I hate overhead.
Now, there's only so much overhead you can prevent using a non-custom engine of course, but I'd still be curious. If a Unity game looks 95% as good, is 80% as easily made but runs 50% better, that'd be worth it over Unreal, right? And of course, this would matter less for smaller games and more for bigger games.
from my testing in comparing my own project when it was in unity VS how it runs now in unreal, there isn't a very noticeable difference. That is, when I compare without the use of Lumen of course, I decided to use Lumen GI for my project which does make it run at a lower framerate obviously, but when I turn it off, the performance isn't noticeably different while unreal does also give me the great upside of being able to use nanite on static meshes, actually improving performance in some cases.
Unreal also has very easily implementable graphic scaling options. I'm not sure how that works in unity, never got that far in but if you run into a situation where unreal's default render settings are too high, it takes little to no effort to add a setting menu to pull some things down again too.
Largly, the fact that a game is made in one engine or another isn't going to add enough overhead for a player to notice, assuming the devs know at least somewhat what they're doing. I will say this though, as the developer, unreal's editor itself adds a lot of overhead so your in editor preformance while testing will take a bigger hit while working in unreal than it does working in unity.
Tbh you used different assets in Unreal and Unity for the minerals. Those from the Unreal Store just look better.
that is part of the comparison though, I used only assets I could find on either marketplace for free and unreal engine comes with a huge library of high quality photoscans. personally, i dont really care about those but it's not something you can ignore either.
Zero chance of remaking it? Considering recent developments, you may want to come back and append this video.
i'm not sure what youre referring to? remaking what? where did I say that?
either way, with recent developments, my choice to prefer unreal is only stronger so no need to append anything?
I imagine Unity's recent nonsense has really made you thankful that you switched when you did.
Without a doubt!!
I don't really have skin in the game either way. But the comparison at 11:00 of "it took me longer in Unreal but it looks much nicer. If I took time in Unity I could make it look nicer" but then trying to say that doesn't matter because you could just also take more time in Unreal to make it even better.... even though Unreal already took you longer. It seems like a more apt comparison would be "what can I accomplish in the same time" not "Unreal took longer, but if I take more time in Unity I could just take more time in Unreal instead."
Idk, I don't really care either way, the video was interesting seeing the comparison. But I smell bias.
go back and listen again to the video and take in the context, some things took me longer in unreal purely to code, because I was still getting into learning c++.
the way thigns just look better in unreal have little to do with coding, and with equal skill level in both as far as coding goes, unreal wouldn't have taken me longer. matter of fact, i expect it might have taken me less time due to the crazy list of built-in features unreal offers compared to unity. all those features is exactly what makes unreal such a headache to really learn and get familiar with though.
For me, only Unreal blueprint since I can't learn c# and c++
can't? or won't?
@@joeman123964 I won't because I can't 🙂. Tried many times to learn different langages, but that is just impossible for me
Thanks for the very interesting video, I wish coding brought me some joy, as it seems to bring to you. But alas, it does not. It makes me sad to see a game, with clear direction, and no assets. lol. I know that you are just waiting to drop the assets after you have all of the main coding done. I am particular because I make game assets. If you need any custom assets, please, keep me in mind.
Yeah seeing a game with a bunch of temp assets , it has no real sense of identity, for my own games I use some temp materials but for the most part, when I add something new I do create the models and characters right away, I feel that it's important to have a good sense of what a world should feel like early on.
That said, for a large part of of the assets like particle systems, simple decorations and so on I do also put in a lot of temp or premade assets just so there is something there while I work on the code. Sometimes those temp assets from a marketplace asset end up being good enough and stick around, often times they'll eventually get replaced by something custom though, or changed into something else with the asset only serving as a base :)
Just be glad that you can code, it is the most difficult part and much harder to come by than temp or even custom assets. Especially if you have a creative idea, or some specific game mechanic in mind, that might be incredibly innovative. You can just parse and debug it yourself. I envy you. :)@@thegamedevcave
You can code C++ in unreal without using blueprints.
you can but it's best used together. in theory you never have to touch blueprint if you prefer but at some point you'd actually be limiting yourself only sticking to c++. same for the other way around. 99% of games you could make purely in blueprint but it'd be slow and clunky on a large scale, as well as a handfull of features being only in c++ of course. The engine expects both to be used together.
@@thegamedevcave But I'm saying this because the video is about leaving UE because it had blueprints and coding wasn't happening. But you can 100% code in ue if that's your bag and avoid blueprints altogether if they're bothersome to you.
@@bryanharrison3889 you can, but you shouldn’t. Use c++ for the most part but some things make more sense in blueprint, that’s the great thing about unreal, the combination of both!
Also, your player should query the rocks to see if it has anything to mine. The rocks should have no knowledge of the player.
100%, badly coded system for this project. XD
meaning you put effort in, while over using unity,
but almost none, when you were over in unreal engine.
both took about an equal amount of effort, the result in unreal is much better for the same amount of effort though. and honestly it would probably have been less effort in unreal if I was more comfortable with coding in c++ at the time. :)
Good to know. If I ever make a sequel to my game I've been giving Unreal some serious thought, because there are some serious gripes I have with Unity. And they are.... 1. Its 4GB texture data limit (I mean WTF?) 2. Their updates often consist of actually removing features that you've already hard grained into your game project and they can completely break your game project, leaving you with no clue as to how or why, so you can't fix it. And despite Unity allegedly offering you support when you pay them to, well no, they don't, it's a lie. You're on your own. >:(
I'm hoping Unreal don't do number 2 or at least they aren't as evil and sinister about it.
unreal seems a lot more stable in their featureset. every so often they do phase out things for better replacements but usually it leaves in the legacy options too to prevent things from breaking when you update. Like the input system, a while ago they updated it (the new one is much better) but you still have the option to use the old one.
That said, unless there is something you really need in an engine update for your game (I updated unreal to 5.3 because it has unofficial support for nanite based tesselation now), you should try to avoid updating the version you're working in for a given project midway through development if you can anyway.
@@thegamedevcave Indeed. I'm stuck with Unity 2017, because if I go any higher than that, it completely breaks my project and I have no idea why or how to fix it. There's not even any error messages. I guess like they say, if its not broken, don't fix it. Because other wise it can break anyway.
Another one thinking he is a "dev" after meddling with ue spagetti but cant even figure our an observer pattern in regular coding
not claiming to be an expert , but that's kind of the point here isn't it.. which engine is easier to work with and get into? Especially for someone without a software engineering background, that seems to be unreal.
Besides I do make a point in the video of noting that I am aware how horrible this code is, making a neatly coded game here while i'm still getting used to this engine, also isn't the point...
@@thegamedevcave yeah i understand your point is coming from an amateur perspective, but we still should dive deeper before making claims aren't we? i saw people commenting to your video saying they're choosing an engine by your experience. This can hurt someone aspiring to be a real professional.
@@gorkemvids4839 no, if other people as amateurs choose an engine based on my findings as a semi-experienced amateur that is by no means a bad thing. My perspective likely is much more valuable to somebody jumping into game development without any knowledge than seasoned developers who are over concerned about minute things. So I fundamentally disagree that
A) my insights aren't helpful to people who are at the same level or a few steps behind me
and more importantly
B) that people making a choice based on 1 video they watched and possibly regretting it down the line is in any way my responsibility.
Besides, you can't seriously be claiming that people picking unreal engine based on this will run into issues because it's not suited for professional work are you? Both engines are perfectly fine options for pros, I just think that unreal, while being somewhat complicated to get into, really helps out beginning devs in providing the tools needed for the job, and forcing beginners to think in a certain way when it comes to programming with it's more rigid premade framework you're working within.
The fact that I made 1 fuckup with some sloppy code doesn't invalidate any of this.
In Unreal you use gameplay tags and custom events so you don’t tick :/
Tick is just unreal's version of update in unity. For both you avoid usinf them whenever you can but its just a function that runs every frame. Lots of beginners but all their code there because its easy, thats why you always hear to avoid it, you can use it though. Thats why its there, just be careful what you put in it
can you write python in these engines?
no neither engine works with python usually, I believe there are community made plugins to make it works with python though, for Unity I can see that working, for unreal I am very doubtful on how well that would work personally
@@thegamedevcave thank you
Welcome to Source 2
Well this aged like fine milk...
I guess there is no reason for Unity anymore.
i'd think this ages more like fine wine, because it shows that unreal is kind of nicer to work with anyway
Once you think he is saying asshats instead of assets you can't not hear.
Now I can’t unhear it myself 😂😂
Interesting too see same but for godot.
I would always use the unreal engine. In my opinion the ai system in unreal engine is better an if you want a good game, you may want to have good ai. Otherwise you will stuck in sandbox multiplayer games forever.
You could also do the mining more simple. You said you created a timer stuff and all this complicated efforts... i think you are thinking to complicated.
You can instead give your ores health and everytime the player is mining, he will dmg the ore when he hits it.
And then you could give the ore a self regeneration function with a delay which starts automatically, when it got hit. So lets say your player hits the rock, it will lose health and fire up the delayed regeneration. You won't need to create other events who check if the ore is put to zero health this way.
But having a good event structure is also not that difficult.
Yh i can't tell you what is best practice, i just wanted to mention, that your stated issues are mostly self made issues.
Thats a pretty good sollution, altough is more or less runs ibto thr samr problems as this sollution in other ways, aside from passing through a variable through a timer , using a delegate, that part you could skip but all together, either of these options work fine.
Thatd the thing with coding though, problems are almost always self made. Very rarely do i run into an ossue that straight up comes directly from the engine. Thats what makes coding so fun, its a puzzle thats constantly changing and shifting around ! :)
hello my new friend
And you used C++ in UE why again? Blueprints would have gotten you to where you needed to go faster.
in the first place because blueprints can be terribly annoying and slow to work it, having to mess about with a lot of nodes to do simple operations (especially when doing math, and making games involves a lot of math). clicking and dragging is simply just slower than typing.
Then there is the fact that while blueprint covers about 99% of functionality in the engine, it leaves out some things too. Again, going with math here for the first example to come to mind, there is no += or -= node (why that is still the case , i don't know, it kind of blows my mind).
But i've also ran into some other issues before where I wanted to do something and blueprint simply didn't have the options. Sure, those moments are few and far between but limiting yourself to only working in blueprint means you're just screwed if you want something that's not pre-made for you, or you have to hope someone else has the c++ knowhow, ran into the same issue as you, and made a plugin, that is up to date for the version of the engine you're working in.
Far be it from me to say that blueprints aren't great, i love them and about half the work I do is still done in blueprint because that's how the engine is very much built, to use both C++ and blueprint together.
All my UI related stuff, level specific scripting, animation related scripting. all done in blueprint, the base logic of my classes though is done in c++, where it's faster to write logic, then exposing the needed variables and functions to blueprint to actually work with them.
runescape was nice but those f**ks perma banned my account for chat bot selling runes. all that effort gone.
I'm on a 7 years break of cigarettes :)
i can only hope that I one day can make it that long without runescape XD good going though!! keep it up :)
Unreal would be perfect if it would support any memory safe language like C#, F#, Python, Lua, Java... instead of only C++ which is basically a big footgun.
Just using a memory safe language removes whole classes of more or less annoying to debug bugs from the game.
Wonder why they don't like devs having an easier time to develop the code behind their game.
while i agree unreal should offer some more options for coding, many people seem to overestimate how complex c++ usage is un unreal. C++ as a language is a major pain in the ass but when coding in unreal with c++ the engine handles pretty much all the memory management BS for you, which ends up with a programming language that's just a slightly more spicy c#, while also allowing you to dig through the whole source code of the engine since that's all written in c++ too, compared to engines like untiy where the gamedevs work with c# but the engine itself is written in c++.
It's a minor thing most of the time but being able to dive into unreal's base classes to see how shit actually works can be a real upside.
I choose neither. Make your own engine.
with your own programming language on top i'm sure. It's a good fun project to exercise your coding skills and put them to some more advanced practice but it's not a productive use of your time if you want to make a game. unless you're making an inhouse engine for a large company whatever you make is likely to lag behind the major engines considerably in both usability and performance. Then, when it's done you can start making games but you also have to keep your engine up to date, slowing down your chances for game development even more.
Again, if you want to challenge yourself with a cool project like that you 100% should but if you're looking to produce games, it's a big waste of your time to do that i'm afraid.
Seems like Unity took the decision for us.
sadly yes :(
"I'm going to compare unity and unreal but I don't know how to use unity. Turns out , I think unreal is better"
this was after 6 months of using unity. if 6 months in I still "dont know how to use unity" that in itself is something that doesn't reflect well on unity either...
@@thegamedevcave couldn't possibly have anything to do with you
Basically unreal is prettier out of the box.
pretty much yeah, as well as having more prebuilt tools for a small developer to be able to use without needing to program all their own basic tools constantly
@@thegamedevcave yeah, as a unity user nothing makes me more jelous than knowing unreal users have an AI behavior tree editor right out of the box.
It's a necessity when you program complex enemies
@@thegamedevcave can you comment on performance? Of IDE and compiled executable.
Unity > Unreal. But so bad for Unity. Destroyed by John Riccitiello. I hope the developers will switch to Godot Engine or Source 2.
godot or source 2 seem like good options.
But i'm curious, aside from the compulsive need to hate unreal that many unity devs seem to have what makes unity better than unreal?
2 arguments that make some sense but I think are way overused are unrealbeing more expensive, it takes 5% after 1 million dollars. but Unity charges a lower perctange, starting at a lower pricerange too so unreal only becomes more expensive after like 1,3 some million dollars. way beyond anything most people will have to worry abuot, so in partice, for a lot of people, both are just free and unreal stays free for longer.
another thing I hear is people dont like c++, but that argument often seems to come from ignorance because, yeah c++ is a nightmare but the way you deal with it in unreal is pretty much just like coding in C# for unity.
so those 2 repeated talking points aside, what makes unity better?
Always too busy fighting the editor when i use unity. Also, their unityui is garbage, and uibuilder is halfassed
An additional point: the big thing about unreal, to me, is knowing when to use cpp and when to use blueprint. A combination of the two together makes things far easier to develop, IMO
I mean with unity a new shorty money hungry practices, we know the winner
Here's the one thing you didn't mention Unity loads up on my computer in about 5 minutes new project. Unreal takes 30 minutes to load up a new project and i can barely do anything. See unity will run on older less expensive computers, unreal forget it. Unreals requirements are insane, and if you want to make a game, well just remember your only going to get a small percentage of users who have decent computers to play it. Now if computer part manufacturers wasn't trying to bankrupt customer... I could upgrade my system.
you're mostly correct. The minimum system requirements for the actual builds of the game, while maybe a little lighter with the overhead from unreal, are way more sensitive to the actual game development and optimization. for low end games, unity may have a slight edge there but unreal can very much build games for platforms like IOS and android or the nintendo switch, all low powered devices. Unreal also offers up a whole load of scalability options that allows devs to easily make option menu's to allow for lower rendering quality. with all that, if an unreal games runs poorly on low end hardware, that's really the fault of the developer, not the engine.
Now, for the actual use of the engine as a creator, yes unreal's editor is ridiculously heavy to run and that is a real issue compared to unity and for many people can be a reason to choose one engine over the other, even with a decently power PC, i get lag spikes in the engine sometimes when i am looking around the viewport, real issue. That said, i also dont think it's unreasonable to assume that something that's made for prefesional use is going to be used by people who have a certain spec of system. It makes it a fair bit less friendly to newcomers who might not have a gaming PC, let alone a workstation , which means that a lot of people start by learning unity since their PC can run it and by the time they could switch over to unreal if they wanted too, so much time has been invested into unity that it's usually nto worth switching for a lot of people, that's certainly that's costing unreal engine a bunch of potential users.
30 minutes to load a new project in Unreal? Holy shit. What are your PC specs? On my PC, a new project takes literally 5-10 seconds to load.
Unreal does require better hardware but it is far faster compiling and entering/exiting play mode. Over time unity becomes painfully slow during domain reload.
ok
With Unity's recent kms move, there's a chatGPT movement being made to port Unity projects over to Unreal with minimal effort. You might try that to test your game.
ohh that's interesting, although I have a hard time trusting chatGPT with code any more complex than a simple function or 2. whenever I use it to generate any code it spits out a lot of BS, especially when it comes to unreal related code. trying to call functions that simply dont exist or with slightly wrong names.
That's all with GPT 3.5 though, there is a chance that chat GPT 4 does a better job and would make me feel safer dumping a whole project into it, Github Copilot seems to do a somewhat decent job of picking up on custom written code, so possibly chatGPT4 would too. Still, as an assistance, I am happy to use A.I. but just dumping thousands of liens of code in and then likely having to figure out what all went wrong seems like more of a pain than just rewriting it to begin with.
Is Unity's kms that much worse over Epic's LAs and ToC?
@Robluex even if it wasn't, Unity has proven that they're aiming to take advantage of people in a way that could destroy them. With all the information coming out about the people that are and will be running the show, don't be surprised if something like this recent drama happens again but sticks.
Why C# instead of C++ ?
c++ is generally seen as a more difficult language , unreal engine makes up for a lot of that though, as I found out when I actually started to learn it.
4 month old video buttttt have you tried godot?
I haven't.. from what i've seen of it it looks like a nice engine but doesn't really seem too attractive to me personally
@@thegamedevcave that's fair! Just saying something about it with the unity fiasco and the upcoming changes to unreals monetization
@@YourLocalRaccoon unreal's changes won't impact game devs luckily, just the people who have been, up to now, using it for free like movie productions like the mandolorian and such :)
@@thegamedevcave ah I see I see. That makes more sense then, thank you
Aged well 😂
From my experience as a "gamer". As soon as I see a the unity logo, I know it will be a "meh" game.
as much as i prefer unreal, this is also not quite an accurate take to judge unity on. you only see the logo on games that are made with a free license, any game made by a decently serious dev, who has a paid license, you won't see the unity logo on, you only see it on games made by people who aren't investing a lot of time and effort into it and are on the free version, that has fucked unity's reputation real hard.
That makes sense. @@thegamedevcave
@@DevilsKings all that said though, if you do see the unity logo, that is still a good indication that you will be uninstalling the game in about 15 minutes because of those exact reasons XD
Yeah that sounds like a gamer alright
I always find my way back to picking that copper in RuneScape, spent my whole childhood there and more and more adulthood as well.
Runescape is pretty much jsut a clicker game for me. be it rocks or trees, that's what I do when i play runescape XD I'm about due for another 2 month memebership and then leaving again for half a year soon i think
unity is not even close good like UE!
Can't see the difference in the final comparison, both look like s**t. Anyway, for a fair comparison you should have used identical assets, terrain materials, post-processing effect and lighting. For programmers C# is the easy choice., my experience with C++ about 7 years and I still hate it. Graphically Unreal wins (thanks to Lumen and Nanite), but graphics is not what determines the value of your game for gamers.
this video isn't just about what the render quality of both engines is. that's a point of the discussion that's often focus on and has been beaten to death. comparing both engines also is very much about it's feature sets, access to assets and ease of use. Only a small portion of the video was commenting on visual quality, which unreal does have a benefit in but choosing an engine purely based on that would be a horrible idea.
ahaha je moeder
C++ and C# have difrent usage but generally C# is derived from C++. C# will be better for more abstract programming while if you want to go down closer to the driver layer or even go hardware mode - C++ will be a better solution (and you can also implement some asm code easier in C++ than C#).
true, but for this we're specifically comparing unity c# to unreal c++ and unreal has build such a solid framework around base c++ that is practically just is slightly more spicy c# for the user. giving all the benefits of c++'s more optimized performance without giving the developer a headache about having to deal with all the low level stuff.
I would not characterize C# as derived from C++. C# was Microsoft's replacement for Java.
@@potato9832 Java's syntax is borrowed from C++.
Fortnite creative is really easy. You have enough followers to get a creator code too. You are creative enough to do a banger game in Creative.
unreal is cool but buggy , no thank you
i am not touching unreal and it c++ , i am staying with evil corporation UNITY
I'm not sure what experience with unreal has lead to the idea that the engine is buggy. it's a pretty rough engine for your GPU and such, that I can agree with but in my experience it's pretty robust, abuot 95% of the time when I run into a bug it's a flaw in my own code, not some weird quirk of the engine I have to work around.
C++ is a pretty scary idea though, i feel ya there, but it's worth actually looking into it because working with c++ in unreal engine is much closer to coding in c# than it is actual c++
Unity 2021+ is like crashing 5 times every min...
@@MinhNguyen-vl7jj
nah i installed 2019.4 and 2020.4 and 2021.3 and lastly 2022.3 at the #same time for #regular use , i rarely got crash , except once a week when i miss with +4gb project that have some big +1.6gb asset
Good choice it turns out
i shouldve bought a lottery ticket the day i made this choice too!
Just came here to downvote after watching your clickbait thumbnail. Try to learn Unity the right way and you will be able to create at least the same that you can create in Unreal. Instead of engine hopping for some CZcams upvotes, try to dig deeper in the engine of your choise. At least - that'S what the pro's do, to achieve good results.
I worked with unity for 6 months before I did this and felt the desire the go back to unreal, I’m not just hopping onto an engine I’ve never used before to make this video. At no point do I say unity is worse, just that I personally prefer unreal. Maybe try watching content before you start being an asshat in the comments 👍
Try to create nanite in Unity and it will take you so much time (in case you need it). Yeah, Unity is great but for me in 8 years using it, it doesnt feel like a game engine when compare to Unreal. It is more like a sanbox for making your own game engine because it lack so many tool and feature...
@@MinhNguyen-vl7jj that's actually a great way to put it. unreal has a premade framework with game modes, player controllers, playerstates, etc. very much game focused thing, unity, while obviously a game engine too, does indeed feel closer to a more general toolset sor developing "software" (i mean you wouldn't make a webbrowser in unity, but i can see people use it for non-game apps very easily!).
Very insightful angle!
Sure Unreal makes nice interactive painting, but so show un the destructable enviroemnt and voxel ....
pretty niche and specific usecase request. i'm not sure about voxels but unreal does have some pretty good destruction features built in I believe
@@thegamedevcave "niche" yes, games like minecraft are really small niche. :P
@@michaelholopainen2822 relativly speaking. yes, minecraft has a lot of players but there isn't that many games that actually require this niche feature. besides, a quick google/youtube search will show up with a bunch of people making their own minecraft clone in unreal. the engine certainly isn't made for that, but that is a VERy specific need
skill issue
Unity is a great start in the game dev experience but unreal is vastly better in pretty much every way!