When looking at an introduction to Blueprints as well as mention of C++, it’s said that Blueprints is very “robust” and then “why use C++ if it’s easier/etc”; the response being you would use C++ for something you couldn’t do in Blueprints or use C++ to extend Blueprints. Well I have very little experience in both.
What is something that I couldn’t do in Blueprints?
I assume I can do anything (reasonably in the hardware’s capability) with C++ but I don’t need access to create a super security ai bot for a multi-server online game that links to your phone or whatever, I need/want to make a game…with stuff >_>
I came from GameMaker learning GML over the drag-and-drop functions and I really enjoyed typing the code over dragging a bunch of boxes; this makes C++ really appealing but it’s far too complicated for me to really care to get too into it since Blueprints works well enough (based on multiple showcasing of blueprints-only).
So, what I want to know is what kind of example would be something I just couldn’t do, or would have a really hard time doing, in Blueprints that I could do in C++?
This question is completely subjective and difficult to answer. I would take a look around the marketplace thread and you will see tons of items created completely in Blueprints … so the options are pretty limitless.
Having said that … Epic doesn’t support C++ items in the Marketplace … yet … so the items in there are subjective to that.
Would I use Blueprints for Data Connectivity? No
Would I use Blueprints for Security and/or Encryption? No
Would I use Blueprints for almost everything else? Yes and then some.
I would say, learn Blueprints, get to know what it can do … if you come across something you can’t do … learn to do it in C++. 8-}
So are you saying that anything that I would actually care about right now could be done in Blueprints and you can’t think of anything that couldn’t but just in case I run into the jackpot, I should be prepared to learn C++ to overcome that rare diversity?
Yes sir … I am yet to encounter something I couldn’t do in Blueprints.
Having said that … you may do something in Blueprints … optomise it … realise it it can’t be optomised anymore in Blueprints and decide to redo it in C++ and optomise there. Anything you do in Blueprints can be done in C++ … so you are covered there. 8-}
First, C++ is up to ~10 times faster than blueprint, so any logic you are running that is very intense should be done in C++. This is case by case, so you can do it in BP and if you need the performance move it over.
Second, there are a number of things that BP can’t do, and they are mostly niche things that not every game needs. Also, there are other things that C++ simply has more access to. Most cases of blueprint inflexibility just need a few functions from C++ exposed to BP. Here are some of the things that come to mind:
You can’t currently create procedural geometry in BP.
Spline meshes are available in BP, but with limited ability to tinker with their properties.
You have limited access to world browser and streaming in BP(important for procedural content streaming).
Navmesh has limited exposure to blueprint(though anything that Navmesh can’t do for you can be done in blueprint with enough work).
Anytime you seriously want to change core functions of the engine require C++. IE; rendering, tools, adding new UI functionality that UMG doesn’t already have, etc.
Blueprint can pretty much handle any kind of game logic you need to throw at it. There are certain tools that it needs more power over, but generally you can get what you want out of it.
Blueprint also does not handle any kind of file I/O, so that would need to be done in C++.
I do most of my work in blueprint and only when I encounter something I can’t do in BP do I move over to C++. Other situations are fringe and rare, like a blueprint bugging out or situations where performance is actually limited by BP. Again, these situations are extremely rare, but they do happen.
When I first started working with Unreal Engine, I took a Lynda course on C++ because all I really knew was Unity-level C#/Javascript. It turns out that this was never really necessary - outside of syntax differences between C++ and C# (of which there are few), Unreal’s interface layer for C++ is really, really easy to use. I toiled for weeks trying to learn vanilla C++ and it was hard. Very hard. I couldn’t get my head around a lot of it. I thought I’d be relegated to blueprints or Unity forever. But really, I never needed to learn about half the stuff I forced into my brain. I still run into some things that I have to guess at (like passing by reference for some things such as converting FString to FName) but it did not take long at all to transition.
I used GameMaker a lot when I was younger to try to get into development and got a handle on the old style GML. If it’s the same kind of voodoo, it really won’t help you much learning C++ in Unreal. I’d definitely recommend what another poster suggested - learn Blueprints first, then start small in C++ if and when the time comes that you need to harness it. No better way to learn than by doing.
It’s a question of scope really - if you’re just making a local user game with pre-determined assets (like a Chess game), Blueprints is all you probably need. If you need more advanced features, like multiplayer, asset streaming, or seamless server travel - you’ll need to delve into C++ a bit. I’ve been sticking to Blueprint primarily for my prototype, but I’ve had to expose quite a few events and functions via C++ to continue. The reality is there’s a lot of advanced functionality that simply isn’t exposed in Blueprint (yet). Don’t expect to whip up a AAA title completely in Blueprint, but your typical Mobile game is probably pretty do-able.
I needed to use C++ to add a Navigation Node so my AI NPC’s could pathfind to jump from one nav section to another.
C++ is faster to work in because it’s just typing, and I find it easier to figure out what is going on because it’s text. But, for my Cat Lazer game the only C++ code is to handle jumping.
I was interested reading your reply. I have been learning C# for Unity, which I find straight forward. It just seems easy assigning a script to each object, look up the syntax, boom. Easy.
I looked into C++ tutorial from Unreal & I was lost from the word go. The girl tutor knew her stuff, but there is so much more that seems to need to go in to each simple step. I gave up. I figured if I wanted to move to Unreal that I should go down the BP route, but I don’t want to move away from coding. Can you give me any tips on your transition, as in which tutorials etc?
I know what you mean, it seems daunting but it isn’t, really. I definitely do not recommend using the Epic C++ tutorials. They are very outdated, so if you use them you WILL have compile errors and very little information about how to fix them.
I should clarify that while C# and Unreal’s C++ are quite similar in terms of usability, Unreal is a very different engine from Unity and does things in ways worlds apart. In Unity, every class you create is a component that can be attached to a GameObject. In Unreal, Actor classes ARE GameObjects, so you need to get a handle on inheritance and the like. This is why I say start with BP because it really does operate the same as C++, just in a friendlier way. This is especially true with the release of 4.7. Once you know how the engine operates through BP, it’s just a matter of learning the syntax differences and grasping how to set up objects.
While you’re putting together BP scripts, every once in a while you should take a little time to right click on a node and choose “Goto Code Definition.” This will show you the C++ callback for the node and expose to you exactly what code is running under the hood. When you feel the time is right, try to reconstruct a BP node from scratch, using the source as a reference. Soon you’ll learn how UCLASS(), UFUNCTION(), and others work. It’s something you should learn by doing.
And you can always ask in the C++ forums about things that don’t make sense, or feel free to PM me or (even better) one of the resident C++ gurus. The kinds of folks you see answering questions on AnswerHub and the C++ forum.
Your reply is of fantastic help, thank you for taking so much time!! I have been snooping around the forums, have to say that this is THE community. I hope to some day help others as enthusiastically as I have seen so far.
Right, I didn’t mean to hijack this thread, I’m away to read through those excellent links
Start with blueprints, when you get hang on blueprint communication, api function names, how stuff works, you can start with small things, like translating some most intense loop from blueprints into C++. Or making some utility blueprints instead of macros.
For eg my game happens on “orbit” (no real Kepler mechanics, just sphere around planet). So every time i want to move “left or right” i get right vector multiply it by some distance. But that introduces some “drift” of distance from center, so i need to snap back my location. First i made macro for doing this (it was all over my blueprints), but someday it became first piece of code i translated into C++ in unreal. It uses just few variables and returns single vector.
Crazy that you’re unable to do this. I haven’t even started in UE yet and still know how crucial it is to be able to create your own nodes. Just from my relatively little time creating nodes in Blender. When it comes to actual programming and making objects that interact with others, you would think this would have been implemented with v.1 of Blueprints.
