[=motorsep;541400]
I doubt that - look at Epic’s programmers. They use C++ in conjunction with BP to achieve their goal. If BP was that bad, Epic wouldn’t even bother with it. However, BP is not a downgrade. Just different concept (visual vs text). You can do everything straight in C++ anyway.
[/]
Epic uses BP because it’s good way for programmers to make a bridge to artists and designers. It’s also their main “marketing strategy” to appeal to the mostly-unexperienced masses (and I don’t mean that in a derogative way). But it’s not that great for programmers themselves, compared to scripting.
c++ works, but it’s not always ideal. When you just want to make an editor tool (which is impossible in BP), or a quick script, you don’t want to have to die of old age three times while waiting for intellisense to kick in, and for misidentified errors to disappear
BP was created as an artist tool, always helps to remember that.
I too find it pretty slow to work with at times compared to C++ but, I don’t find C++ very slow to work with at all - and a scripting language is highly unlikely to speed up my workflow personally. If it’s worth doing, it’s probably worth doing right (/ the most MLG way possible)
You can doubt and speculate all you want. Because Blueprints can be backedup with an actual C++ code base you can build your entire game with blueprints, it’s fast enough for most games and even AAA games can leverage them. Like or dislike of them is not a quantitative metric.
Since there are games built entirely out of Blueprints any argument about it being functionally limited is false, at least in terms of game systems. Where blueprints are limited is editor extension and development as you must use C++ for that. My suggested workflow (and this is leveraged a lot other places) is your core is built in C++. Then your game play specifics are built in blueprints. For instance you should not build every item in your game in C++, just your base item, the rest are blueprints. You can also quickly prototype complicated behavior in Blueprints, then refactor it in C++. These are not new workflows, these are tried and tested patterns used for many many years in the software industry.
Can Blueprints become a cluttered jumble of lines and squiggles… Yes but programmers also have a similar problem “Spaghetti code” and it’s not just a problem with “GoTo” statements. Interfaces and S.O.L.I.D. Principals and Design Patterns can also make Spaghetti code, but if used wisely they are powerful tools for re usability and maintainability. We have developed best practices over the years to reduce spaghetti code and the same needs to be true for Blueprints. Loving or Hating Blueprints is pretty much a personal opinion. I personally feel they have their place and need to be used responsibly and be well documented just like any set of code you write. Just as you can tell the rookie programmer by the mess of code he or she writes, so too can you tell the rookie UE4 user by the jumple of Blueprint Nodes and connectors he or she jumbles together.
But ultimately I am wrong, because the decision to use just blueprints or just C++ or the combination of both is a personal decision on your part as the developer of your game. If you hate Blueprints, don’t use them. If you do not know C++, that does not mean your game will not be awesome or responsive. Wish you had a different scripting solution, there are a few of those out there including a Javascript scripting engine for UE4.
Finally I will apologize for lending my aid to the resurrection of this thread, I spotted it at the top of the list, and did not see there where 15 pages of postings to it before plotting down my thoughts on the original question. Live you learn.
Since there are games built entirely out of Blueprints any argument about it being functionally limited is false
[/]
Would you say the fact that you can build a skyscraper with your bare hands nullifies all arguments that having tools and heavy machinery would be better?
Also, I didn’t mention this before, but another gigantic problem of blueprints is that they take the spotlight waaaaay too often. Good luck trying to find good UE4 c++ tutorials. Every tutorial is always in blueprints, even for things that should never be made in blueprints in a serious game
[=Philippe St-Amand;541426]
Would you say the fact that you can build a skyscraper with your bare hands nullifies all arguments that having tools and heavy machinery would be better?
Also, I didn’t mention this before, but another gigantic problem of blueprints is that they take the spotlight waaaaay too often. Good luck trying to find good UE4 c++ tutorials. Every tutorial is always in blueprints, even for things that should never be made in blueprints in a serious game
[/]
I’m pretty sure that’s a straw-man fallacy, since building a skyscraper has nothing to do with scripting languages. You may not be able to build a sky scraper with your bare hands… ever, you also can’t build a pyramid or a tower of babble as all some form to toolage was used for those as well. But you can build a game with blueprints. Further more you are aruging for the sake of arguing since you did not debunk my statement.
Every tutorial is in blueprints, okay, so write them in C++. It’s not that hard, and it’s a workflow that is encouraged, hence Prototype in Blueprint, refactor in C++. Do you need to know how to program in C++, yes. Do you need to know how to program UE4 C++ (basic UCLASS, UPROPERY, etc) yes. Don’t like them, don’t use them. Obviously they are not for you, you are a programmer, go program. But do not tell people who are intrested in them that they are not good.
I’ve been programming for over two decades in just about every language created since the mid-80’s (starting with GW-BASIC), and there are a lot of good ones out there.
If someone wanted a quick little business application with a GUI, I’d probably have VB, C# or Java as my first choice.
But if I were given the choice to code a game/engine/core in either C++ or any other language, I’d likely choose C++.
End of story.
These language threads always end the same way, so could a moderator please lock this one?
This is spot on! Comp Sci Major, graduating this year, C++ is great, iv taken courses in it but those pointer errors are frustrating even for the professors that are teaching the courses. Personally i love java with all my heart, but java is NOT for gaming and i agree that C++ has its problems but it is the clear choice for now. HOWEVER i don’t believe that it will be the game Development language of choice for professionals for too long. Java will never be a gaming language(except for strategy and some RPG, examples minecraft(original) and runescape(RS2)) that demand graphics. With in the next few unreal engines they might want to consider a newer, more powerful language that was built Object Oriented, and is very similar to the current OO languages syntactically. The only language i could think of that meets these parameters currently is a potential revision of C++ to C++17, or D. The revision of C++17 would have to be MAJOR to be more effective than D, but the C++17 would just have to come close to D, The reason why Java is so popular is because knows it(a little). Just like most people knows C++(a little at least). almost no one(including me, so far) knows D inside and out, or at lease no one in my programming community being teachers, students, etc.
Back to my main point, you nailed it! D would be great but will never happen because the knowledge demand( teachers that know it enough to teach it) doesn’t exist on a large enough scale like C++ does. That is what it comes down to. Java is 25 years old, c++ is ageless probe 30 years, D is only 8 years old. Maybe in a perfect world we could see D in 10 years but even that is a stretch looking at history.
