[quote=“TacoShank, post:7, topic:106719”]
[li]For example, you can comment and un-comment a piece of code very quickly. The equivalent in BP sees you detaching nodes but often times you can’t have multiple of certain node types. So then you need to delete parts to get your BP to compile and there’s no quick visual separation like in text. It quickly becomes a mess if you are trying to test two different algorithms and you forget to reattach your code the right way or add back in what you needed to take out to get it to compile.[/li][/QUOTE]
BP has a Node disabling option. Its still experimental (Right-Click disable Node from Compile). It works better in Kismet (UDK) tbh. But its also easy to make up for any limitations by just adding a dedicated Bool and leveraging color-coding for branch / sections that are optional / duplicate. A kind of Blueprints #IfDef etc… Taking advantage of color-coding is one of BP’s biggest strengths in visual programming, because you can use different colors for sections with duplicate paths / minor differences. Then the human eye can quickly differentiate and skip over those sections…
Overall, the ability to use color customization in Comments + Nodes + Wires is huge… But not all devs make full use of it. The brain works better with visual stimuli. So for example you can plan-out a color-coded strategy for all your calc / logging / debugging code that’s different from UI / Menus which in turn is different from the more active nodes that push the gameplay forward etc. There’s no way to do that in text based languages to my knowledge. There’s no real way to ‘promote’ text code that’s more critical or important etc short of using a lot of // or /…/ etc. In addition you get to play around with shape and shaping code sections. which is also positive for the way the brain naturally responds. Personally I find I remember what BP code does faster than working with the equivalent in text, when both haven’t been looked at in a while.
[quote=“TacoShank, post:7, topic:106719”]
[li]Then there’s the fact that if you want your BP to look nice and not be literal spaghetti code you need to put a significant amount of time into moving things around visually and rerouting connections. I often felt like I spent too large of a percentage of my time changing the aesthetic of my BP instead of actually getting work done. Then when you need to add something to your nicely formatted code you worked on cleaning up for a couple minutes you will need to add some large chunk to the middle of it and do all that work over again. It gets old fast. With text Visual Studio automatically formats your C++ to look nice. With text you hit enter and start typing a new line to add a large check of code to the middle. You spend your time solving the problem. Sometimes I have lost my train of though and forgot how I was going to solve a problem because cleaning up BP takes so much fiddling.[/li][/QUOTE]
Lowering ‘wire’ spline curve settings or even using straight lines instead of the default settings, means you don’t have to keep moving as much BP code around. But there’s a few points to consider. If you rely on ForLoops with 5-10 lines stretching out from the index, or Array-Get with 5-10 lines carrying the same actor, that can be pretty hard to follow and force lots of rearranging and unnecessary Reroute nodes as well. Personally I favor using temporary Array-Actor variables and ForLoop-Index variables to cut down on a lot of re-org. Duplicating variables too is better than dragging multiple wires off them, as it helps clarify things. I trust Nativization to compile out all this extra node-bloat…
[quote=“TacoShank, post:7, topic:106719”]
[li]Obviously version control (which everyone should use) is made a lot easier with C++. Because BP’s are treated as binary files if you ever have multiple people coding on your project you will be limited to one person “checking out” and working on a BP at a time. This is a major problem for collaboration. Text-based languages are a god-send here.[/li][/QUOTE]
Agree. The BP diff tool is more a gimmick than an everyday gem too… Devs like TheJamsh have suggested offering a BP text input tool. Epic seemed to like the idea too, but that was a while ago. But it would allow devs to use text to input BP sequences. That would obviously help with diffing and presumably cut-out BP corruption permanently. Presumably it would also help with Collaboration, as it could allow merging of changes into the same binary BP…
[quote=“TacoShank, post:7, topic:106719”]
[li]If you are familiar with other text-based programming languages they will help you understand C++ and vice versa. BP is actually quite a different programming experience from traditional languages. I do enjoy it, but transferring logic from BP to text-based languages can be really tough. It’s hard to explain exactly why unless you have a lot of experience working in BP. If you try both BP and another language like C# or C++ out you will see what I mean. You simply think differently in a visual programming language.[/li][/QUOTE]
You do encounter some peculiar / surprising ‘oh, that’s how it must be done moments’ in BP. Flow control in BP feels odd.
Your instincts might be to add an inline delay to a For-Loop. But the loop will be already finished before the delay kicks in.
Whereas if you use a Multigate node, with a delay off each branch etc, that works to delay ForLoops as you would expect.