Unreal definitely isn’t the easiest thing in the world but it’s not ‘bad’.
Could there be improvements? Definitely. Especially when it comes to error messages.
I think Epic has done a great job at making the C++ experience easier thanks to macros and generated code. I used raw C++ for DirectX11 at uni - not the most fun thing.
Sure, it’s not C#/.NET level of usability but it’s better than what it would have been.
Keep in mind that when making games with Unity, most of your ‘advanced’ code will be .NET as opposed to the Unity API. C++ simply doesn’t have anything on the same level as .NET so Unreal has to step in.
There’s definitely a fair number of roadblocks in Unreal, especially when you get into the more advanced stuff. But once you learn of the certain limitations of the engine, you can plan for it next time.
For simple things, likely what you’ve been doing, it’s probably more of an issue with you not bothering to learn the ‘style’ of the engine. You shouldn’t be experiencing issues with ‘gameplay’ code. As for crashes, that sounds more like you don’t understand how pointers work. For either of these issues, you will get better at it through time.
The only thing that annoys me about Unreal’s “C++ experience” is their need for a custom non-standard build system, which just sucks and is the root of all problems you encounter when using Unreal, especially if you try using something other than Visual Studio + Windows.
And sure the documentation could be better but on the other hand you have the full source code, which is invaluable. And all those macros are annoying I suppose.
What part is non-standard? They generate standard Visual Studio projects. Ctrl-B in Visual Studio still builds the project. Seems pretty standard to me. (If you think “generated visual studio projects instead of carefully hand-crafted manual project puzzles” is non-standard, I disagree – every place I’ve been at that uses Visual Studio, uses some tool to generate the projects.)
Using a tool that parses some source files and generates some other source files is also pretty standard in industry. Almost every compiler in the world uses some kind of grammar/lexer tool or library to describe the language at a higher layer and generate source code to execute it. Tools like lex/yacc or flex/bison or ANTLR are frequently used similarly to the unreal header tool.
Now, do I sometimes have frustrations with build setup? HECK YES! Because, standard or not, build systems are generally second-rate citizens in most organizations, and don’t receive the tender care and love that the main codebase does. Which is a shame. That’s not a result of “non-standard,” as much as it is a result of most engineers not being build engineers (or most organizations not prioritizing/promoting build engineering.)
But those VS project files are not a build system. Those are basically just definitions that collect a bunch of files and declare how to view them in the IDE. If you press Ctrl-B in VS then it will build your code, but it uses the completely custom made CSharp build system that Epic wrote themselves. There is nothing standard about it.
I totally understand why they are doing it, I am just saying that I would love it if Unreal would create for example CMake files that would let me use whatever build system I’d like, for example Ninja or MSBuild or Make. These are build systems, not those VS project files.
And before anyone says “but if you generate CLion project files it will generate those CMake files that you want?!”: Yes it does, but it still uses the Unreal build system to build the project, meaning this doesn’t change anything.
Anyways, as I said I get it, I just wish it would be possible/feasible to go for example full CMake + Ninja, but we are not living in a perfect world. My point was that these are the parts that vex me about Unreal C++, but not the C++ code itself that this thread was about.
I guess I read “build system” different from you, which is fine. I think “msbuild” is a build system, just like “make” or whatever. I understand your point now!
I think we should look at all this from time investment perspective. For example: I like some engine, it’s features and things, but it will require ■■■■ year or more just to get understand it, should I spend my time on this or not? Speaking of UE - it has really great features and stuff, do not need to describe it, but learning curve is also super-hard. Is UE easy to use? - nope, it is ■■■■ hard, even for seasoned C++ developers. You need to spend months and even years to just understand how engine works! But should I know how ■■■■ thing works? I highly doubt. At the end of day it is simple question - are you ready to waste year on learning engine, that may allow you have some advantages, like better graphics and such? On the other hand, Unity is much easier to use, but making AAA graphic is either impossible or takes much more time (I mean modeling and such things - especially hairs modelling), than UE4. Everything has own advantages and disadvantages - everything depends on what you are going to do with engine. If you have to have photorealistic graphics, the only solution is UE atm, especially taking into account sad state of Cryengine. Maybe one day we will have rapid development tool that will not require years investment in learning, but I highly doubt it will be unreal. Epic certainly has different philosophy. You can just look at how they unnecessarily complicated things in UE 5.
The only thing that really sucks assz with unreal is the C++ documentation, this forum is not enough either, the Q AND A board was so much better, you get get answers there, whitish color simple to read and use with hundreds of results on filter search. This forum produces like 20 results when I search with filters.
The doc page from unreal regarding C++ is very bad, there are very few c++ tutorials with steps, step one do this, this represents excetera, now step 2 these represent this this and that and so on.
A lot of the blueprint documentation is kind of handholdy, and assumes no prior experience.
The C++ documentation is written with the expectation of prior experience with C++ in mind.
In many cases, knowing how something works in blueprints will make it rather self-explanatory how something works in C++.
If you are not experienced with C++ and want to get started deeper into it, right now, in my experience, the gap is best filled with third-party paid C++ courses. Pattuzzi (Gamedev.tv) / Tom Looman are the people you might want to look up. I’m not affiliated with either. The courses won’t break the bank at sale prices.
Let’s be honest, most of us are not C++ gurus, it takes around 15 Years, to become god like at C++, we do understand the functionality of C++ to a level till it gets complicated, after that we have to have some proper documentation.
Complicated flying api code is also a problem that is part of some complicated module like the AI module, you have to dig into the module, spend time to understand it because there is no C++ documentation.
The C++ documentation does not address an advanced C++ user, it only addresses the good and the expert since it is very mechanical, I find the C++ doc page very rude , no tutorials, no examples, just what coresponds to what as a list.
The existing C++ experience means experience from other game engines.
Unreal does not use all of C++, it only uses a subset of it. C++ as a language is more like a general-purpose pick-what-you-need-and-forget-the-rest sort of an affair.
Unreal Engine does limit the complexity by i.e keeping the gameplay code single-threaded by default.
I do recommend the third-party courses if you are not proficient at C++. They are more suited towards those who do not have C++ experience and like to go from using just blueprints to incorporating C++ inside their projects.
In many cases the only difference between writing BP code and C++ code for gameplay is the syntax. There are a few gotchas and such but once you’re familiar with the syntax and have at least a cursory understanding of how a computer works they shouldn’t be too overwhelming.
And everyone told me on this form it’s the other way around JoSf, that Unreal is a great way to learn C++ and it is one of the reasons I got into unreal to get better at my C++. One of the reasons I wanted Unreal besides my artistic mind set and what I can do in Unreal.
I think Unreal is a great way to get started with C++, because you have the robust BP Visual Scripting side of things to quickly come up with functionalities that work, and then later on figure out how to replicate those visual scripts in written code
The tutorials for BP → C++ are kind of lacking, but that gap has been filled with the third-party tutorials.
It’s what I’m saying, there a gap betwen Beginer and Good at C++.
Betwwen these there is the intermediary level user and then the advanced user and most of the people here are maybe just advanced C++ users with a few years of coding in C++ and it becomes a drag at some point because there is no support for these type of users.
I do not get it, Epic is such a big corporation, it would not cost them much to hire a few people just to make a better documentation regarding unreal c++ with exaples, tutorials, detail explenation on each component, a preview explenation of the code overview and what it does.
Blueprints is not the future of this game engine, it’s potential is in it’s c++ side of things.
IMO part of the issue is that the script layer is collapsed into the native layer and it’s easy to confuse the two.
A long time ago, in the UE3 days, there was UnrealScript… And a clear delineation between gameplay “scripting” and engine “engineering”. The serialization, reflection, etc - all that was generally “script layer” type business.
But UnrealScript was very limiting for those used to C++, etc, and as people requested more and more features be pushed into UnrealScript - eventually Epic was like “efff it. We already have C++, why are we reinventing languages? Let’s just use that for the script layer, too.”
So, what you see when you look at a project in cpp is sort of two layers collapsed into one, and they’re two completely different ways of thinking. If you’re not acclimated to BOTH sides (engine vs gameplay script) then the other half looks like a mess. In general, where you see all the UPROPERTYs and UFUNCTIONs, that’s the old script layer, now expressed in C++ instead of UnrealScript. But the two layers intersect unless purposefully kept apart, which makes it confusing.
IMO it’s an improvement, even though there’s no forcing function to separate the script logic layer from the engine layers that was the UnrealScript/C++ boundary back in the UE3 days.
Programming at engine level, if required, would probably assume project scope (and in part, funding, or at least interest from Epic’s part) that would come with UDN access. Not too many people need to write code at that level.
I don’t think they ditched scripting languages in favor of C++, rather, they implemented blueprints instead. And if you can mix and match C++ and Blueprint it does bring out the best of both worlds. Your blueprints graphs won’t sprawl too much when some of the functionality is tucked into a BlueprintCallable C++ node, yet you can still quickly iterate on the design. That’s why I don’t agree on saying that blueprints aren’t the future, because they are very much an intended way of using the engine and for a lot of things, blueprint scripts are the preferable method even if you know how to do everything in C++.
The documentation isn’t be-all end-all for everything, usually the search of new stuff starts with a search engine and someone might’ve written about the experience they had with implementing “X”. Like the replay system, there is documentation page that kind of gives you an idea how it works (relies on replication to store the needed information) and then there was a third-party wiki page on how to do it in practice. The wiki page was old and not usable as-is, but going between error messages and the source code, there were just a few things that needed changing.
There are plenty of tutorials to get you accustomed to using the UE C++ for gameplay programming which teach you how to use the macros etc. For the more advanced stuff the training wheels need to eventually come off and stop relying on tutorials. Even experienced developers write test code and functionality to figure out how things work.
After using this engine for a few days, I have a running MP game going. Powerful tool, but like Adobe Photoshop, the placements of items is not logical. Either stick to being appealing to indie devs with no experience with the GUI or focus on the folks who have prior experience and make the tools stronger. As it stands atm, the amount of control is great but most often is not needed and just takes a longer time to do simple tasks. Again, great engine but when the developers are students from school brought in to code the engine, they only know the flow from a text book and its missing a intuitive experience that Quake, Unity, MultiMedia Fusion, Java, Python provide.
The listed engines above offer what I would call a “common sense” of where to find items of detail and control. Anything additional is expanded in a sub-menu if needed, not presented in (default) dark - stacking menu items that most of the time aren’t being controlled. I do enjoy how much you can do, but we don’t need to see or be forced to use these controls unless we want to expand on them (Example, Tile Sizing). With that being offered, the naming convention to find the items would need to be improved as well. Radius of sound for most engines is “Radius” while in Unreal, it has been I believe named Sound Attenuation (I’ve been using Unreal Engine since the '99 days of UT). A very basic example of having to re-interpret common phrases into it’s own particular naming. Not that bad, but stacked with every item needing this makes the experience tedious in the beginning. My personal view on the engine might not reflect that of another user, but if I am to change a PFX color - blueprints demand more complex motions for simple items, while a menu options on a corner that is visible for quick eyeing would make the editor faster of a process. In other words, too much templates enforced which is great for new beginners and control. Maybe another GUI would be ideal to cut the fat off what can be controlled so we can blaze through the proto type stages.
Different things. Although attenuation can affect a radius. Unreal has an absolute mountain of properties that can be set to affect the attenuation. If an engine just has a Radius option (as perhaps Unreal 1, 2, and probably 3 did) then it probably doesn’t have any of the more advanced attenuation that Unreal has. Attenuation is what it’s actually doing. Radius isn’t a description of the process, it’s a description of where the process affects.
Just commenting on that example, since I understand it, and I don’t the others.
