> 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.
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.
Earlier this year we completed a huge refactor that involved, among other things, getting us almost 100% off blueprints (now we use them just for little bits of presentation logic in UIs).
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!
Hey, I've been working on something I think is pretty cool to address some of the shortcomings mentioned here. If you're up for chatting about your experience and offering some feedback, mind hitting my profile and shooting me an email (on my homepage)?
It's nice to hear from someone with real experience.
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.
> The real question is, did C++ give you any real ROI either?
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).
Blueprints are extremely useful in prototyping at the very least, not just in the initial stages of development but for adding new systems. There is nothing wrong with them and the idea that LLM’s are going to replace blueprints is ridiculous. Sure, you will be able to have them write a block of collision code, but gamedev is one of the most complicated fields in terms of having an understanding of what your state is and what references what.
LLM’s can spit out code without understanding the problem, but understanding the problem is 99% of gamedev
I've only been on medium-small teams, but I'll give it a shot:
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.
> - 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.
> I can't say I expect find and replace to be super common. I would prefer to do such things one at a time.
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'm a data scientist day to day, which is a very different feel from coding up game systems. The latter is a lot more intricate and intertwined. The text coding I do in c++ for unreal is probably more involved.
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.
Would you be down to chat a little about your Blueprint experience and take a look at a tool I've been working on? Check my homepage (on my profile) for contact info if so, I'd be very thankful :)
I'd prefer to just reply to comments but I'd take a look. You might find better perspectives asking the folks who sound like they've finished shipping a complete game though.
I think you missed the point. Yeah it isn’t code and it has downsides, but it is a GUI for discovering and learning to intuit the API. To not use it would be tantamount to refusing to read the documentation.
When entire teams are using visual programming tools through the entire dev lifecycle (incl. refactoring and maintenance), wake me from my cryogenic freezer!
But the original article and the post we're all replying to isn't arguing for using it for "discovering and learning to intuit the API" - they are arguing for using it for the bulk of coding tasks.
No I don't think so. You can. I do about 80/20 bp, gradually shifting some content to cpp as I need more specific network replication capabilities.
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.
A colleague and myself were just discussing similar issues with SSIS packages compared to just running the queries in a stored procedure on the server.
Blueprints are not performant, they are potentially the slowest scripting language to ever be used in a significant way, worse than python even. If you don't believe this, try implementing some basic number crunching routines in pure blueprints and see how long they take to execute. Though if you're just using them to configure and glue together C++ classes, like most gameplay code is doing, then it's usually fine.
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.
>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.
I think lossless roundtripping with a textual representation is essential if node-based tools want to escape the local minima they all seem to get trapped in.
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++.
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.
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.
Don't forget to use base classes in c++ though. It's massive performance hit to cast to bp only classes. The base class will help you move nasty bp stuff like complex calculations once you run into them.
A course that finally made Unreal "click" for me, after years of toying with it, was Tom Looman's 'Professional Game Development in C++ and Unreal Engine' course. The source for what you build (with the chapters available in the git history) is here. [1] It was based on a class he taught and so also includes homework, which I found infinitely more valuable than just following along in a 'Here's how to [x].' type lesson.
> It's free until you make a million bucks USD, and only after that is it 5% gross, and only in quarters where you made more than $10,000 USD. So most folks never end up paying anything. There are no subscription fees or anything. To clarify, if you make a million bucks, and then one dollar, you only owe them five cents.
It sounds very fair to me, what are the general thoughts here?
The arrival of Fortnite Money has meant that Epic can afford to spend a lot more and charge a lot less for everything they do. They opened a studio in Vancouver and started hiring whoever they wanted from other companies, e.g. The Coalition, with starting salaries that made jumping ship a no-brainer for the engineers they were picking up.
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)
I spend money on Fortnite roughly every month. Extrapolate that to an insane amount of players and it's not hard to see that they're in an excellent position.
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."
Just as in game microtransactions, it doesn't matter how much or little the median person is paying, because all the profit is in the minority of very big payers / 'whales', so you optimize the payment structure of the small payments to ensure that they don't prevent you from capturing the whales.
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.
Just remember how many AAA or big name titles use Unreal as engine. Those can sell millions of copies at 60 per copy. And even if they have much better rate it is still probably half a million to millions a game.
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.
FWIW basically no established game developer is using the standard terms epic provides. If you’re in a situation where you have a high degree of confidence you will owe Epic money it is worth reaching out in advance.
True, but I also imagine that Epic isn't bargaining down the rev share too low. Or, companies are fine paying 8 or even 9 figures upfront in anticipation of such success in a custom contract.
Technically if your game is not F2P Unity will still be much if your revenue i a couple if millions (even with their bizarre and convoluted per install pricing).
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.
in that regard I'm sure they will do the same with Unity. But Unity for the little guys that just a little bit too big suffer the most in this deal. At least Epic handles that edge case by letting those edge case devs keep the first million.
Tencent purchased a stake in Epic in 2012, years before the f2p mobile market took off.
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.
Shame, Chaos Rings trilogy was 2/3 games out by that time and excellent premium games. Stardew Valley would come a few years later. Infinity Blade would also have been a spectacle if you were on IOS. And of course, various console ports. 2012 was probably the peak of premium mobile games for me.
>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.
What happens when your business has a portfolio of products/services over multiple departments, spanning various platforms, and only one consumer mobile app uses Unity for an augmented reality component that's not a core offering (premium feature)?
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.
Epic is a highly profitable private company controlled by the founder. They have no incentive to mess with a business model that works; their margins are higher than Unity.
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.
Data scientist here who spent a couple of years working with Unreal (to produce high end data visualizations). Here are my thoughts
> 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?
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.
>Data scientist here who spent a couple of years working with Unreal (to produce high end data visualizations)
That sounds amazing, could you share some of your visualizations?
Also check out https://o3d.foundation and Godot as options... open source gaming engines should be at the heart of modern game development imho, just like Linux is the heart of many infrastructure things we do
What up with the gaming community? I get the the players being carried away or be from a special demographics but aren't the game professionals aware that they are doing business? Underpaid developers, death treats after some pricing changes. Wow.
"The gaming community" consists of an insanely large number of people. Some percentage of people on Earth are willing/crazy enough to use death threats to get their way. The gaming community is large enough that that percentage manifests itself in the form of death threats being used. The question isn't so much "what's up with the gaming community" as it is "what's up with this small percentage of humanity."
There is something interesting though that while the audience of superhero movies is super large and while there are a lot of overly toxic complaints and clearly a number of people who are super angry about various things, I haven't seen news reports of any offices at Warner Brothers or Disney being closed due to credible threats of violence.
I suppose you haven't looked hard enough, then: A 5 second google search for "marvel movies death threats" turns up multiple articles about threats against directors for killing off Marvel characters. To your point I'm not sure that they closed their offices over it, but how they react isn't really up to the people making death threats.
let's be real: there's good odds that the people doing this hail from countries where they feel they can be safe from legal avenues of (the US-headquarter) Unity.
Also, these are children or the privileged who are complaining about video games on thee internet. They have no issues with rent.
It's also worth noting that if you're concerned about Epic Changing the Deal and doing a rugpull like Unity, they've said you can simply not accept the changes and continue operating under your existing terms you agreed to:
"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.
I think Unity had that same provision? Until they changed it:
"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."
> Read the documentation on the Gameplay Framework. All of it!
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.
I think it's just different learning styles. My preference for learning e.g. a new programming language has always been to read a book cover to cover as the first step (if it's a language established enough to have a book anyway). Note that it's not important that I actually understand everything on this first pass. The cover to cover is mostly about getting the lay of the land so I know what exists, then, even years later when I have a problem that could be solved by using some bit of the language that I read about but didn't really understand but vaguely recall is a thing it springs to mind and I can do my deep dive on that aspect then.
I'm currently doing this with a few programming language books, and the strategy for me is basically to read the book in two passes. On the first pass, the goal is just to get through the whole thing and get a feel for everything it covers. If I don't understand it, that's okay— I just let it wash over me.
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.
As someone who recently learned UE: yes, this is completely unviable. The UE API docs are almost useless. Use Rider and its code navigation instead, you'll get much better results.
The docs about the concepts are better, those are worth reading.
Your style will get you through a project, but you'll miss out on useful but nonessential features.
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.
Everybody is different. It's certainly unviable for some people.
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.
Yeah I agree. For me personally the best combination seems to be a quick start guide to get me bootstrapped and let me get the gun poinTed at my feet, and then solid normal documentation for me to mend my feet each time after I shoot myself.
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.
> follow small tutorials, build an intuition, and only consult docs when I need some specifics
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.
depends. IME I tend to go through at least 3 passes of
- 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.
It sounds more like an intermediate strategy, if you're eager to discover some tricks you missed. First do some small projects to familiarize yourself with the basics. Reading the API before really knowing the context of anything you're looking at seems fairly pointless to me.
Unity never seemed like a good engine. It's CPU bound which is extremely aggravating for a GAME engine.
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.
"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."
C# support is/was its killer feature. Game dev without the pain of C++, and without being limited to non-standard scripting languages (or worse, visual scripting spaghetti)
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.
Unreal is similar. All of the gameplay code runs on a single thread. The game framework tricks you into building slow OOP stuff by default with far too much pointer chasing. You can easily make an Unreal project that performs worse than the equivalent Unity project. In fact, many do!
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.
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!
If you were working in Blender, Godot may hit up your alley a bit more as an open source community driven engine.
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
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.
> 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.
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:
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.
Some disagreements based on my experience working with UE for the past 11 odd years. Mind if this all sounds negative that I really like working in the engine and would recommend it for most game projects. I just think you should be aware of what you're getting into.
> 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 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.
Very true, for now, but the amount of tools / libraries / projects that will spawn / funded / contributions to move projects out of Unity is gonna make that more realistic eventually.
I seriously doubt it, as it requires embracing the game development culture that most FOSS folks are against to, and most commercial engines rather stay with compiled languages instead of having a R&D department in compilers.
I get the impression that Unity did not do a lot of homework before rolling this out. Several aspects of the policy they’ve waffled on, and when asked about who would pay the fee for GamePass games, they said the distributor would, but it appears the distributors were not consulted on this.
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.
Big big players probably don't care the Pro and Enterprise tier isn't too horrid. Or they have negotiate their own deals. For them 0.01 per install is probably magnitudes less than they pay on advertising per player.
> re the Pro and Enterprise tier isn't too horrid.
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.
I can't help but be reminded of the people who jumped from Twitter to Threads.
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.
Do not fool yourself here, Unreal's main competitor was never Unity, it was the different myriad of proprietary engines that exist in powerful studios, there is were the millions are.
Unity could never get into that piece of business and Unreal Engine is barely scratching it.
Yes, but Unity targeted the Indie market with "free for small unsuccessful projects and we take a small cut of sales if it takes off" first and then Unreal jumped into that market.
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.
That was always the impression I had, engines such as id tech X, Frostbite, Fox Engine, etc, in my view are some examples of more "direct" competition.
Twitter usage is down 30% and probably still declining, so I wouldn't say their enshittification saw no consequences.
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.
Game development is a very different space due to the extreme amount of middleware used and the fact porting between engines has been done since the 90's.
This may well be marketing, but it's good marketing. It leads with being open and honest that not everything is great with Unreal or Epic either. That's much more convincing than something which claims to be sunshine and rainbows.
They didn't retroactively changed the TOS of their engine so that a game you made years ago means you now potentially receive monthly invoices from Unity (and what about ridiculous new fees they will think in the coming years).
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).
Yeah that too. My initial take is clearly wrong to link the two of them. Shame Apple is partnering with Unity when Unreal seems to be the more popular/better looking engine.
Source 2 has been out since 2015, with tooling, but so far I think the only third-party licensee is S&ndbox. It's not so much a modern game creation platform as it is a collection of Valve's internal tools.
Also from a technology standpoint it is miles behind Unreal Engine.
I'm not convinced Valve is all that interested in pushing Source 2 as an alternative to Unreal or Unity, and their organizational structure would probably make them a pain to work with.
I think they did when they first announced it, and that it was going to be free (like Unreal/Unity). But that was also in 2015 and we've seen no public release of Source 2 since.
Is anyone aware of unofficial (and maybe illegal in some jurisdictions) releases of Unreal toolchain that strips off the Epic Launcher and can be downloaded without making an account?
You can just grab the repo off of github to use it without the epic launcher but you do at the minimum need an epic account to get access. I'm not sure why you would want it to be unofficial or be so stubborn against making an account of any sort.
for 2D or simple 3D games, sure. Godot should be able to do enough to enable a small team to launch a game. You just have to keep in mind that console support won't be as robust and smooth as UE.
Tell me more. I’ve recently (past two weeks) gotten more into shaders and I’d like to hear more about this story. What was the shader cache compilation stutter?
With consoles, you have exact(ly enough) known hardware and software so you can precompile the shaders so they're ready to rock.
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.
That is until round 2 of Epic vs Apple. Where Apple officially kicks the Unreal Runtime off it's store this time. [1]
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.
> 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.