So You've Decided to Move from Unity to Unreal Engine
impromptugames.com
impromptugames.com
> Blueprint actually rules. Look, I get it - why would a visual scripting thing be good? They're all shit! I agree.
> Blueprint is the only one that's any good. It's amazing. It will also help you learn the engine. Everything you do there will be applicable to C++. No matter who you are, you should start in Blueprint. It's 100% true that you can build an entire game in Blueprint. Yeah, with multiplayer. Yeah, performantly. Yeah, maintainably. It's not just for rapid prototyping.
> Be a snob about Blueprint at your peril. I've helped a lot of people get good at Unreal and get hired for it, and Blueprint-related recalcitrance is the number one way people screw themselves - without realising, they sentence themselves to months of wasted time and frustration only to mould themselves into the type of Unreal user who sabotages any team they're on. Swallow your pride and look at some nodes.
Best advice in this page. Blueprints are excellent. They make the engine API extremely discoverable. You naturally gain a deep understanding of the classes and components and how they interact. They are performant. They can do 95% of what you want.
The C++ engine API is fine but it doesn't lend itself to learning the engine. I don't recommend using it unless you identify a specific need.
- Find and replace a variable
- Change a variables type
- Merging changes from multiple commits
- Refactoring
- Finding all references
I'm a fan of visual coding and use it extensively in YWDHT but have found the above challenging. I'm curious how Blueprints solves these issues, especially for larger teams.
When entire teams are using visual programming tools through the entire dev lifecycle (incl. refactoring and maintenance), wake me from my cryogenic freezer!
But they're definitely referring to learning by doing stuff in blueprints. I would agree with this. Figuring out how something ought to be done with the engine in blueprint and then re-implementing it in cpp is the more pleasant experience imo.
> - Find and replace a variable > - Finding all references
I think the basic search tools are pretty good. I can't say I expect find and replace to be super common. I would prefer to do such things one at a time.
> - Change a variables type
I would say you really shouldn't be doing this too often. It's compiling to statically typed code under the hood so this will frequently cause a lot of breaks. You can do it, and it will highlight all the areas where this breaks things (maybe more easily than c++ might tbh). And if the types are compatible, that might mean you have to do the annoying step of redrawing lines to the same var with a new "node" representing the proper type.
> - Merging changes from multiple commits
This is hard and not good. The most difficult part about blueprints.
> - Refactoring
I tend to think this is pretty easy. Maybe easier than in code. I'm a big fan of collapsing all nodes into subnodes. So every individual step becomes one high level node. You can also "collapse nodes" into a function itself. You want to minimize the number of nodes you're looking at any given time so it kind of encourages good practices on itself if you're competent.
This seems like a very strange thing to say. I presume you do text-based coding as well? Multiple cursors, search/replace, bulk refactors and other semi-global operations are a huge part of my normal workflow and I can't quite fathom how visual coding would change the need for that.
Regarding refactoring - I'm not sure what you describe really is "refactoring".
I can't say what you're saying resonates with me as familiar. I've always been confused at why people ever feel multiple cursors is useful if not just begging for disaster. You can, for example, rename a property in a blueprint class, and that will flow through to all references to that property in other blueprints, if that's closer to what you mean.
When I think about refactoring I think about taking some logic and making it into a more reusable function; or abstracting it into a shared component. I would say the former is what I was saying, and the latter is more of a capability offered by the engine than the tooling. Reparenting classes to compatible alternative parents and moving properties and logic to component classes is relatively comfortable in my opinion.
Merging is essentially as banned as we can make it; we use Perforce, and set all .uasset files (Blueprints and other UE assets) as Exclusive Checkout so only one person can edit them at a time. This is recommended by Epic. When we do need to merge things, it's mostly a manual process of opening the Editor on two branches and duplicating all of the changes.
All of the refactoring-related questions, again, mostly manual effort. There are some constructs that can help keep things DRY which reduces the problem, like BP function and macro libraries. You also get inheritance and interfaces. UE also lets you redirect property, class, and function names to new names using "Core Redirects"; you can do that and then resave all packages to effect a bulk change.
Finding all references: Search All in UE will find a string anywhere; that means in property details, BP function calls, variable names, comments, anything. There's not exactly a "find references" as you might expect from a normal IDE though.
Really, the ultimate solution to dealing with these and the general "visual scripting spaghetti" problem if they're on the verge of becoming acute is to stop using Blueprint. We try not to use Blueprint for any complicated systems. It's nice for simple presentation-related things (e.g. "play x sound when y happens"), or places where we want designers to have some control for tuning or prototyping, but even for something that seems "straight-forward" like GUI code it can very easily end up spiraling out of control.
Blueprint also has a performance cost and it's hard to profile. UE5 dropped UE4's main attempt to fix this with "nativized" Blueprints, i.e. Blueprints that got compiled into C++. There are ways to improve Blueprint performance, but you really shouldn't even get yourself into a place where you're leaning on it so heavily that you can even worry about that.
BPs are amazing for discovering how to use the engine - they provide a sort of guided exploration of things, especially when you don't know what you don't know.
For us they really, really, really broke down when it came to version control, multiple people working on the same BP, code reuse, and refactoring. Arguably, at least some of this was our fault - I think you're "supposed" to do the major coding not in BP and then use BP mostly for really high level stuff, and we didn't always do that.
Anyway, it's been wonderful not having those issues anymore. Gone are the days of changing one thing and then git saying that 100 files have uncommitted changes!
Blueprints clearly delivered negative ROI. In general they probably do. This is the worst time to be advocating for visual programming, considering the first truly groundbreaking application of AI is going to be in writing code.
The real question is, did C++ give you any real ROI either? Probably not, it probably only got in the way compared to the way Unity is architected.
> Gone are the days of changing one thing and then git saying that 100 files have uncommitted changes!
You're using Unreal, but not with Perforce? Get back into the time machine buddy!
People's expectations about this extremely clunky engine are way too high.
We actually moved most of everything that was in BP (and a good bit of what was in C++) to Python, so it addressed all of our issues while also speeding up development and, somewhat surprisingly, giving us a decent performance boost too.
> You're using Unreal, but not with Perforce?
Yeah, definitely not going to use Perforce, haha - might as well be using SourceSafe!
> People's expectations about this extremely clunky engine are way too high.
Unreal absolutely does have its warts, an almost overwhelming amount of complexity, and we've run into our share of issues. Sometimes you're amazed at how quickly a feature can be implemented, and then other times you spend days on something you thought was going to be trivial. We replaced the replication system with something better suited to our needs, for example. That said, on the whole we're pretty happy with Unreal (both the renderer and the materials system are very impressive).
LLM’s can spit out code without understanding the problem, but understanding the problem is 99% of gamedev
I wish they offered like a "Bluescript" language or something, that just maps 1:1 with blueprints but lets you write them out as code
Either that or the ability to use 3rd party editors so competion and innovation can happen in the same way it has for textual code editors.
Blueprints run at least 100x-1000x slower than equivalent c++.
This isn't even discussing working with multiple coders and version control, which is also a disaster.
If you are making a simple game then they can work. If you aren't then they are not great.
they are slower but unless you are doing literal math in the blueprints this is a huge exaggeration... which is exactly what one AAA game I worked on did. sigh. And they wondered why we couldn't hit 60fps (tho, that wasn't even the biggest detractor to performance).
Now, BP's in general usage when you're not doing literally everything in them is about 10x slower. But when you properly use blueprints, you can mitigate this a lot. BP's in a large project work best when you expose existing c++ code to BP and make sure any designer code is piped through c++ first. The main exception tends to be UI code, but UI is rarely a performance bottleneck in large 3D games to begin with.
>This isn't even discussing working with multiple coders and version control, which is also a disaster.
yup, that's my 2nd biggest gripe. Nothing worse than trying to submit code and the BP you changed one node in is locked, with the owner of the lock being out for the day.
I'm not saying never use BP, but everyone should realize the performance cost of using BPs is quite high.
https://youtu.be/8gVixDglpQ4?t=75
Blueprints are extremely slow vs C++
Reading other people's blueprints and understanding them is much harder than doing this with the equivalent code - having to follow the wires everywhere is a nightmare with all visual noise. I often jokingly call it a write-only language. Not to mention the part where you must have compiled the project and be running Unreal Editor with all the assets loaded to do this in the first place.
And then you can't even properly diff or merge them without using some special tool that doesn't properly integrate with your version control and only works reliably half the time.
Blueprints are fantastic for familiarizing yourself with the engine, since you can quickly discover all the things to do from the context sensitive search. They're also great for people to get started with their projects and prototyping. They're not at all suited for production work in a large team.
I really wish Unreal Engine supported a proper scripting language so the choice isn't between noisy node graphs hidden in binary asset files and raw C++ code. People keep shooting themselves in the foot with both of these.
That's apparently what UE's new Scheme based language, Verse[0], is aiming to do. But this is very new tech and currently used in the Fortnite editor part of UE. It's not quite something to use in the main engine yet.
[0]: https://dev.epicgames.com/documentation/en-us/uefn/verse-lan...
Have they said explicitly that it has ambitions beyond fortnite?
yeah, because the UE documentation is absolutely horrid (and it's not like Unity is better at this). I have lots of gripes, but I think the meta issues involve how BPs cause so much community knowledge about the c++ API to be buried. Absolutely fatal if your game cares about performance.
>They are performant
They are performant... IF you know how to weave between them and c++. Shame that courses don't really seem to emphasize that and you simply hit that wall once you're working on a project.
It sounds very fair to me, what are the general thoughts here?
https://www.theverge.com/2021/5/3/22417447/fortnite-revenue-...
With numbers like that, collecting a half-million dollars from even ten blockbuster games per year is probably not even worth the time and energy it would take; that would be 0.1% of their revenue, which, relatively speaking, is basically nothing. That whole business wouldn't even show up on the balance sheet.
I don't think that's in the right ballpark. PUBG has generated about $15 billion in revenue over 6 years or $125 million per year in revenue for Epic.
Jedi: Fallen Order sold 10 million copies at full price in its first four months, netting Epic ~$20 million.
Even an indie game like Stray netted Epic ~$2 million in one month of Steam sales.
https://vgsales.fandom.com/wiki/PUBG
https://en.wikipedia.org/wiki/Star_Wars_Jedi:_Fallen_Order#S...
https://www.gamesensor.info/news/stray
* assuming all these devs have the standard 5% deal and chopping 30% off for marketplace fees where only sales*price data was available
I can't imagine it being chump change.
https://www.cinemablend.com/games/2454545/the-insane-amount-...
For Unreal, I think it fundamentally comes down to:
1. We want to be the biggest and best game engine out there
2. We want everyone to use our technology if at all possible
3. The vast majority of our money is going to come from the top 1% of the huge players in game dev (CD Projekt Red, The Coalition) and not from anyone else
4. The more people who use Unreal to make games, the more Unreal devs there are in the world, and the more Unreal devs there, the more likely those huge companies (or potentially blockbuster indies) are to choose Unreal for their projects because talent is readily available (see point #3)
Edit: Per their court case with Apple:
https://www.theverge.com/2021/5/3/22417447/fortnite-revenue-...
They made over $5bn in profit from 2018 to 2019 from Fortnite, and $5.1bn in revenue in 2020.
Creator payouts from building games and experiences within Fortnite builds loyalty and encourages further development from kids going, "Ooh, I have an idea for something."
It's incredible.
Also I don’t think they have that many people working on the engine (they have less than half the employee count of Unity) and it’s probably subsidized by Fortnite revenue to some extent.
Tencent isn't just a mobile game company, they are basiaclly Chinese Microsoft for how many parts of the industry they are entwined in in their home country.
Also, they made their blood money on Asian markets not here.
>Also, they made their blood money on Asian markets not here.
sure, but Asia took a while to adapt to mobile as well. Tencent and Netease were still riding out the flash Web hype with stuff like MapleStory and Dungeon Fighter in the very early 2010's. Think it was also the tail end of MMOs too.
Unity was trying to squeeze water from a rock.
If your game doesn't earn a million dollars, it doesn't matter to Epic, because all those (many!) tiny games in total don't earn enough that even a much higher pricing would move the needle.
However, if the low-end pricing structure means that one more (or one less) blockbuster chooses this engine, that makes all the difference, because they are going to pay the full rate out of the billion dollars they earn.
Unity has over 3x as many employees as Epic, much lower margins, is publicly traded, and they've been losing money hand over fist. Everything is subject to change until they make money, shut down, or are acquired.
Should Unity still be entitled to the same cut?
But to answer your question, they are royalties on top of that one mobile app, not your entire revenue. If you distribute it for free, you might pay no royalties; if it somehow is tightly related to your main revenue-generating product then you’d sign a custom licensing agreement with them.
> Blueprints suck! Not really. Think of Blueprints like python. Its good for routing and keeping track of things at a high level. Think of C++ as handling things at a lower level.
> I heard you need to start with blueprints. Not really. After going through the basic tutorial that Unreal Sensei has on YouTube (https://youtu.be/gQmiqmxJMtA?si=TqBiiIe12M5hiCda) , it is better to do a mix of blueprints and C++ if you have any programming background.
> I don't know what to use for the IDE. I used Rider for Unreal Engine and it has good integration into Unreal Engine.
> So when do you use C++? When I was doing data vis of census data, I needed a way to load in 10,000 data points into memory. The "out of the box" tools for Unreal didn't support this, so custom C++ was the way to go.
> But really, if I just want to get started with Unreal and want official tutorials, where do I go?
After going through Unreal Sensei, I looked at at https://dev.epicgames.com/community/unreal-engine/getting-st..., there are a ton of tutorials there for game developers.
Also, a year ago I put together an online course that looked at how to ramp up on Unreal Engine. The course ("Data Visualization in the Metaverse") is ideal if you already have a programming background. I put the course out on YouTube for free (https://www.youtube.com/playlist?list=PLKH3Xg62luIgPaB4fiFuT...) and happy to answer any questions about it.
Don't forget Visual Assist! It's more flexible, is faster, uses less memory, works on uncompilable code, etc. (I work on it.)
https://www.bloomberg.com/news/articles/2023-09-14/video-gam...
Unity changes pricing: [ we riot ]
Also, these are children or the privileged who are complaining about video games on thee internet. They have no issues with rent.
"If we make changes to this Agreement, you are not required to accept the amended Agreement, and this Agreement will continue to govern your use of any Licensed Technology you already have access to."
You potentially lose access to epic services of various sorts, but it's a far cry from the Unity situation.
https://www.unrealengine.com/en-US/eula/unreal (Section 7)
"Unity silently removed their Github repo to track license changes, then updated their license to remove the clause that lets you use the TOS from the version you shipped with, then insists games already shipped need to pay the new fees."
https://old.reddit.com/r/gamedev/comments/16hnibp/unity_sile...
Is it just me or is this an unviable learning strategy? My approach for learning anything has always been to follow small tutorials, build an intuition, and only consult docs when I need some specifics.
For me, the ideal thing is a book, and great docs can feel like this. Something well thought out, comprehensive, deep, and importantly error checked/reviewed. The downside is books are increasingly rare and get outdated really quickly.
The docs about the concepts are better, those are worth reading.
It's only on the second pass that I am trying to go through each section carefully and make sure I really understand before moving on, including seeking outside help or resources if I feel confused or stuck.
This feels fun for me, and the casual first pass makes it easy to figure out if a book or language truly appeals to me.
I also feel, strange as it sounds, like for me it save time compared to learning in small increments through tutorials. It lets me more quickly absorb the basics for things that are already more or less familiar, and then I can focus on exercises and examples only for the tricky stuff.
When I first started studying computer science, in high school, the biggest productivity gap was between the students who tried to work only with what they were directly taught in class by the teacher and the students who decided to go explore the language/stdlib API docs on their own. There was a lot of 'wow, how did you do that!?' from the former group and a lot of 'it's built in, check out this part of the manual' in response from the latter. But somehow no amount of exchanges like that could convince the former group to take some time to RTFM in a comprehensive or unguided way, so it stayed that way.
Some of it is a matter of it being hard to even have the language to know how to ask the questions you have, so a bootstrap or quick start to let you just get in there and start looking around helps a ton and makes the full documentation a lot more accessible.
While I basically tend to learn like this - (solve my current problem and move on, since I have limited time to spend on things) - I find that this type of learning can miss some things. Like when the documentation says this is important etc and you never know about it/find out about it the hard way when your stuff doesn't work properly.
Nonetheless for just getting to your goal and not becoming really good in something this is not necessary or can be done later
For example, a lot of C++ programmers miss the full spectrum of std::algorithm. A lot of Python+NumPy programmers miss out on some useful indexing tricks.
I'm still suffering from not taking a rigorous approach to unix shell.
- read high level architecture docs, - try to do some small coding - get confused and google until I get my goal done - go back to reading high level architecture docs
You're (or at least, I will) never absorb and become productive in all that material in a first pass. But at the same time reading the intro for the mentality of how the big picture works helps a lot to scope into what to focus on.
A popular game made with Unity, called Rust, always gets a lot of shit from players because GPUs don't do anything except give a couple FPS. I'd be glad to see Unity die with these pricing changes.
With Unity, you can use C# for everything, from the simplest 'spin this object around' script to customised rendering pipelines and complex in-editor tools.
Performance was clearly good enough for the engine to become wildly successful, particularly amongst indie/mobile developers making smaller games, and experienced users learn to avoid the main performance pitfalls.
It takes effort to release a well performing game using either engine if you have a non-trivial amount of "stuff" going on. Luckily Unreal comes with fairly advanced profiling tools so you can find where the problems are.
"Let me be clear.. the cost isn't a big issue to us. If everything worked out, the tracking was flawless and it was 10p per sale, no biggy really. If that's what it costs, then that's what it costs. But that's not why we're furious. It hurts because we didn't agree to this. We used the engine because you pay up front and then ship your product. We weren't told this was going to happen. We weren't warned. We weren't consulted. We have spent 10 years making Rust on Unity's engine. We've paid them every year. And now they changed the rules. [...] Let's not make the same mistake again, Rust 2 definitely won't be a Unity game."
I'm an aspiring graphics/engine programmer. I don't really care about making games, I'm more excited about improving the tools available. My feet are wet enough with C++ that I think it would be good to start digging around in/ modifying/ contributing (likely merely attempting 'small' stuff like bugfixes) to the Unreal codebase. I've been doing so lately with Blender's codebase lately with some success, so large software isn't totally new to me. Blender is mostly C though, hence my interest in seeing how things are done in Unreal.
Any tips/ resources/ advice/ quirks I should know that you can share would be greatly appreciated!
But wrt UE, it depends on if by "contributing" you mean "making plugins" or "contributing to the codebase at large". From the sound of things you want to do the latter. Unreal is "viewable source" but you first need to sign up with an Epic Games account: https://www.unrealengine.com/en-US/ue-on-github
From there, there are instructions on how to contribute (the contribution documentation is actually on a public page: https://docs.unrealengine.com/5.3/en-US/contributing-to-the-...)
There is probably some official Unreal Engine community as well (probably on the UE forums), so that can be a place to ask for any specific pieces where devs need help. Best of luck.
Yep, I just want to cut my teeth on bugfixes for now, maybe a plugin down the road. I'm running into some trouble finding much in the way of a bug tracker. The official issues page:
https://issues.unrealengine.com/
only lists the last 5 bugs. I'd love it if I could browse them all, & perhaps filter by module. Unfortunately I'm not sure that listing exists publically.
> Unreal and Unity are not game engines in the same sense.
This is mostly a true description, but
> It's the same way with Unreal, except you're not getting "whatever Epic ended up with when making Gears of War"
No, a lot of what you're getting is "whatever Epic ended up with when making UT, Gears of War, Paragon, and Fortnite". You can very much feel their previous games in it. This is good and bad; good in that the tools you need to ship a real game are all there and the engine is actually battle-tested; bad in that the tools you need to ship a game that doesn't fit that mold might not be and there could be a lot of stuff that will get in your way if you decide the Epic Way doesn't suit your project. UE4/5's adoption does help a lot, things were rougher earlier in UE4 and in the UE3 days.
> Porting to consoles isn't an outsource job here.
Nah, we needed help to ship Chivalry 2 on console and WinGDK. Many smaller teams do outsource or contract for assistance. It was months of multiple programmers and tech artists, it really wasn't one person x one week.
> Upgrading to the latest version is not a big deal.
If you're a tiny, Blueprint-only indie / side project I guess this is probably true. It takes us weeks though.
> Unreal introduces new systems carefully.
We and other teams I've talked to had a policy of waiting for the first hotfix revision of a major UE4 update before attempting an upgrade, though.
> I heard Blueprint sucks!
See my comment https://news.ycombinator.com/item?id=37512356
> I heard Unreal is geared towards first person shooters and it's a struggle to make something in my genre!
As above I don't totally buy the rebuttal. If you're doing something way out of left field you can do it in UE, you might have to bypass a lot of Epic's way of doing things though.
> What if I don't want fancy graphical bells and whistles? What if I'm not making something in a realistic style?
I've not worked on VR or mobile but I've heard that Unity scales down better. Some of UE5's nice stuff (nanite, lumen) also doesn't scale down well.
One of my game is multiplayer, the whole gameplay code is completely Unity-agnostics to run server-side without any Unity code.
Not to say they didn’t consult with the major Unity players, but it seems plausible that they didn’t based on the carelessness of the rest of the rollout.
Technically you couldn’t even use Personal or Plus if you made over 200k a year. It doesn’t really make much sense to stay on the personal tier now anyway, as long as you manage to make at least over $10k per developer in a year.
Ultimately, the recent wave of enshittifications of major products - Unity, Twitter and Reddit off the top of my head - It's a hard reminder that lock-in and governance matters. Software is a long investment, so it's time to start thinking very hard about how the software you use is run, and how much control you have if it all goes sideways.
I realize that OSS options like Godot aren't really comparable, but since Unreal's main competitor is Unity, it feels likely that Unreal could do something similar since they don't have a competitor keeping the pressure on about price anymore.
Unity could never get into that piece of business and Unreal Engine is barely scratching it.
While Unreal entered that market from the opposite direction (offering a proper, supported high-end gaming engine to replace in-house engines of AAA gaming companies) they both converged into the same market when it came to selling to small players.
Like Unity pricing model. And then Hashicorp and what ever does competing product or offering mean...
When something has momentum it takes a lot to slow it down, but that does not mean doing so is impossible.
Unity is a different case though. Unity is retroactively applying these new terms to existing licensees, even if their game already shipped years ago. Unlike Twitter, they are directly hitting their customers wallets in a very nasty way. And unlike Twitter, Unity isn't the only well established player in its market. Already in-development projects might not switch, but this is sure to give studios pause when evaluating potential stacks for future games.
Even with the new pricing model Unity should still stay way cheaper for anyone who make more than $2-3 per user.
If Unity would've said that now any games built using whatever the most recent version of their engine is subject to a new TOS that means a fees per installs it wouldn't have nearly generated the amount of backlash it has received (no one is going to use Unity for a future project regardless of the fact that the fees per install is for the most majority a much better deal than 5% revenue).
Also from a technology standpoint it is miles behind Unreal Engine.
Some high profile UE4 games released on PC at launch either didn't precompile shaders, or didn't do it well enough, and there was frametime inconsistency when that shader was first encountered as it was compiled. It caused very disruptive stuttering.
Stray and The Callisto Protocol were the two that I think of most. TCP was virtually unplayable. Stray at launch was... less than ideal... for a lot of people.
Not all of it is necessarily directly from UE shader compilition on the fly, nor where the root blame lies. But it certainly got a reputation.
I'm not a game dev, so it's probably a little light for you so I suspect this is a bit too basic for you but [DF](https://www.youtube.com/watch?v=Kr7RGkFuPdQ&t=112s) did the best quick look which may give a direction to look further.
Amazes me the short memory of the dev community. So many studios and publishers could not take the risk of Unreal being kicked off and had to switch to Unity.
Unity is still cheaper for vast majority of cases too.
[1] https://www.macrumors.com/2020/08/17/apple-terminate-epic-de...