I think learning any skill is always worth it (especially in computer science), but you aren’t limited to either a C++ or BP project. You can mix and match the two as much as you feel comfortable with. Many of the indie horror games and such made with UE4 are BP only from what I’ve seen. Plus you can always prototype something in blueprints and then try your hand at moving that logic into C++ later (that’s actually a great way to learn the internal UE4 architecture).
So, the long and short of things is do things however feels most comfortable to you according to your goals: If you want to just make a fun game prototype and aren’t strong with C++ - stick with BPs. If you want to brush up on your C++ and feel like making a game is a fun way to do that - go with C++.
I would just advise that whatever route you go, make your project a C++ project rather than a BP project. A C++ project can still be 99% BPs, but going from a BP project to C++ project is a bit of a nightmare IIRC.
I’m not a seasoned programmer like many of the others, but I have been working with UE4 for over a year and from my perspective as someone who had to learn at every step I would say that some C++ is essential.
I do the vast majority of my work in blueprints, but some things, for example passing arguments from the command line (not the console) to the game, require minimal C++ and cannot be done any other way.
There is a lot more that you can only do in C++. Proper loadingscreens, most of the network stuff (Session like), a lot of useful functions from common classes that aren’t exposed, creating DataAssets, etc.
You could probably live without all of that and stick to Blueprints, but if you have the chance to learn C++, please do it. Once you got good enough at it, it will help you improve your game by A LOT!
And you are also able to reduce the chance of nasty Blueprint bugs (Structs are totally buggy in Blueprints for example).
And despite the UE4 things, learning C++ gives you a good feeling for all kinds of coding languages, which means you can learn Java, C# and such thinks in a blink of an eye.
So you would generally benefit from learning it.
Blueprints are like training wheels on a bicycle. You can ride a bike and you probably won’t crash and fall over, but you’re still riding a bike with training wheels…
Coding in C++ is taking those training wheels off. At first you’ll be pretty wobbly and unsteady, probably will crash a lot, probably will skin your knees and get a lot of frustration, probably doubt yourself a lot, and be tempted to give up, but with a lot of persistence and practice, you’ll eventually get really good at it and you’ll be way better off for it. Getting good at C++ is a skill which is transferable to other applications and programming platforms outside of gamedev and UE4.
When it comes to UE4 dev, I personally prefer C++ for a few reasons, mostly due to hidden drawbacks of blueprints:
-Blueprints can quickly turn into visual spaghetti, especially with crossed lines and stuff.
-It’s hard to see at a glance what is happening with blueprints. Well formatted code is much easier for me to read.
-Blueprints require maintenance to keep them aesthetically appealing and readable. That means managing the node positions, making sure lines don’t cross too much, trying to keep nodes aligned, etc. These are overhead costs you have to pay for using blueprints, and if you don’t pay them earlier, you’ll pay for them later when you have to come back and maintain them. It’s very similar to code comments…
-Have you ever wanted to copy a bunch of functions from one blueprint to another? It’s a pain in the neck. You have to manually go and recreate each function, set the input and output parameters, and then copy/paste the node graph. With code, you just copy/paste the code and change the class scope. You can be done in a minute (using find and replace).
-Native code has faster performance (but it’s generally not important – algorithm choice is much more important!)
-Code debugging is way better because you get to use the power of the visual studio debugger. You can set breakpoints on any line, traverse up and down the call stack, set watch variables, step into functions, etc.
-Code is a lot cleaner than blueprints. Try to do this in blueprints and see how long it takes you:
Another way to put that possibly is to ask: should you study Mandarin or Arabic to learn about hybrid car engines…
Because its understating the objects in a game engine and making them work for you, that’s key to making games…
BP / C++ are just tools, different perspectives or paths to the same or similar solutions: albeit high-level / low-level.
Its good to take similar games or demos apart to appreciate the game you’re trying to make to grasp all the moving parts…
If your game idea is really simple, then you can realistically learn C++ at the same time and this will definitely help you later.
But if the gameplay becomes complex or intricate, you stand to lose more time battling extra challenges if you solely use C++.
Making a game in C++ means dealing with more code-base changes more regularly than Blueprints alone generally entails…
That means more reworking. Read a transition thread by Rama, what has to be fixed this month, what’s gotten broken etc…
That’s enough to make some devs give up and quit right there, because making a video game is hard enough of a challenge.
Also many experienced C++ devs actually end up becoming part-time game-engine-designers whether its a conscious act or not.
So what’s of greater interest: Making games or tweaking game engines? What’ll help keep you motivated / make you happiest…
That type of dense C++ is a lot like legalese, the kind that fellow lawyers struggle over due to the meaty text…
Its not unusual and is cleverly succinct, but its also a PITA to read and a greater PITA to debug if things go south.
With so many holes in software already, is this such a good direction? Who knows you may curse yourself one day :p
Overall, both C++ and Blueprints don’t deserve many prizes for clarity, but hey they’re the hammers we have today…
Nothing unkind about it, it’s reality. If you’re going to update the engine that underpins your game then you’re going to have to do some work, same as any software development project, you don’t change a core dependency mid-cycle unless you absolutely have to.
Spoken like someone who works at a big shop and has the luxury of specializing in engine code pretty much exclusively
But the OP is just a solo dev trying to make a game, and getting locked into a specific engine version early on is unwise.
What if the OP’s game goes on to became Multiplayer and they then need MP-Origin-Shifting from 4.13 / 4.14 / 4.15 etc? @OP, My advice is, stick with an interface that changes the least, which is probably Blueprints but there are alternatives…
While I see your point, migrating engine versions is potentially a bit easier with Blueprints vs C++, I think it’s a relatively minor point set against the various downsides of Blueprints that have already been aired.
If you’re starting out with UnrealEngine and C++, my advice would be to start a C++ project. Start learning how the engine works using just Blueprints, then when you’ve got a feel for things, start building a few simple C++ components and learning how they can be leveraged in a hybrid C++/BP project.
That’s the key thing, neither C++ nor BP is better, but using either one in isolation is definitely not making best use of the tools at your disposal.
Thanks guys for all the help, after reading all your posts I think I will opt for the idea of starting a C++ project, starting mainly with BPs for the project and dabble with C++ as well when I get more comfortable with the code, and also learn how to make the BP and C++ work together.
It’s probably better for you to use C++ if you need to, such as if you want to do something that is either very difficult or can’t be done in Blueprints and otherwise just stick to Blueprints. It may be very frustrating for you otherwise. You can always add a C++ class to a Blueprints project later, even rebase your existing Blueprint onto the new C++ class.
Yeah, my code is a bit unreadable. I intentionally compacted it a teensy bit to illustrate that I can write four lines of code in two minutes to do the same thing that a full screen of blueprint nodes can do. I honestly think it takes more mental effort to create a blueprint node graph than it takes to write the equivalent code. Just for kicks, I did a blueprint version as well. This took about 8 minutes and looks intimidating. At a glance, I would have no idea what’s going on. I could spend another 5 minutes straightening out the lines and stuff, but that’s overhead costs, which again serve to illustrate my point
True and on the flip side you stand to win university code competitions for the least lines
Ok, surrender, I’ll take your condensed C++ any day. Definitely nice audio-cable ‘pasta’ there.
Forget re-route nodes Epic, what we need here is dedicated Blueprint TV / Audio cable ties…
For all its faults, one of the things Kismet did well was to help differentiate code from variables…
Code flow was generally geared from left to right, with variables situated at the bottom of nodes.
That meant that execution flow lines were easier to follow ‘for the eye’ versus ordinary variable wires.
But now its a free-for-all… In an effort to differentiate everything nothing has clarity, its pure visual chaos…
There was a thread recently about changing graph background to a cat pic, but how about real BP customization…
Let users pick the color scheme for code, variables & variable wires: dashed, colored, toggle-hide wire option etc.
Key point here is, time saved initially & intellectually using BP, is often lost later shuffling BP wires / nodes about.
As somebody who inheredited a 2300-class BP-only project:
Make your baseclasses in C++.
I had to do a massive rewrite of the project’s internals in C++ because the BP compiler started to **** itself at the circular references.
And BP interfaces suck. They really, really suck.