@taby Yes but there are performance problems compared to C++. Also as a developer, companies expect you to know C++, idk if blueprints are enough on their own.

Liquifire said:
idk if blueprints are enough on their own.

Can't be.
Relying on only such things puts you on the bottom level of creative options, having only the options the engine maker gives you. It may suffice, it may not.

With C++ you can extend the engine so it does what you need. You can replace some of its systems eventually, or just do your own engine entirely. You can do anything, in theory.

So a need for C++ programmers won't go away (i certainly hope, expect and predict at least).

JoeJ said:
Relying on only such things puts you on the bottom level of creative options, having only the options the engine maker gives you. It may suffice, it may not.

Ok, but thats the same with every scripting-language, and even C++ used in an engine itself. The c++ that Unreal gives you only gives you access to the things that Unreal wants you to have. The only way for you to access everything, or change fundamentals would be to modify the source-code.

Now trust me, for writing large-scale engine-side code, I prefer C++, but for gameplay, I tend to favour visual languages. I have worked on two professional unreal-projects now, which are 98% blueprint-based. Only things in C++ are certain parts that eigther can't be done, can be done cleaned in c++ (complex mathematical formulas), or are using external plugins which are mostly in c++. Blueprint is not like the 4-pages of event-commands that an rpg-maker gives you, its a powerful visual-scripting language the gives you nearly the entire toolset needed to create a game.

JoeJ said:
With C++ you can extend the engine so it does what you need. You can replace some of its systems eventually, or just do your own engine entirely. You can do anything, in theory.

In theory, yes. But in theory one could conceive a visual-programming language which could be used to create an engine. Blueprints already can be used to create large-scale systems; my own blueprint-variant in my engine has a ton of extensions which make it more viable for this sort of thing. Theoretically speaking, there is no thing that gives c++ the ability to extend/replace and visual-languages to don't. I'm not saying thats a good idea BTW, I repeat, I prefer to work on engine-stuff in C++, but it could be done.

JoeJ said:
So a need for C++ programmers won't go away (i certainly hope, expect and predict at least).

I do hope and except that too, but I also see the need to expand C++ toolset with other languages, since C++ is not the best language to express everything. Especially in Unreal, where the c++ seems really dated (no expections, no references, …), is also one of the points why I prefer blueprints whereever I can.

Juliean said:
The only way for you to access everything, or change fundamentals would be to modify the source-code.

That's what i meant. Contrary to Unity, everybody gets the full source code. (How practical that is is another story, as updates might become constant pain.)

Juliean said:
but for gameplay, I tend to favour visual languages.

I can imagine, but i made only really small games.

So i'd like to know what things you'd classify to be such game play code. You work on your own scripting language - for what do you use it?
(I assume it's required for something like an RPG, to implement all those abstract mechanics, quests, etc.
But for the kind of simple action games i have in mind, i guess it's not worth it for me.)

JoeJ said:
That's what i meant. Contrary to Unity, everybody gets the full source code. (How practical that is is another story, as updates might become constant pain.)

Yeah, fair enough - thats totally a great benefit for Unreal! Even if you don't modify the code, simplfy being able to step into a function in the debugger and see why its not doing what you want is such a huge improvement. Modifying is practically is, as you already assumed, a different story. We had one problem which I could have fixed by modifying the source, but we decided against it as distributing the modifying engines is a bit of a pain.

JoeJ said:
So i'd like to know what things you'd classify to be such game play code. You work on your own scripting language - for what do you use it? (I assume it's required for something like an RPG, to implement all those abstract mechanics, quests, etc. But for the kind of simple action games i have in mind, i guess it's not worth it for me.)

Yeah, in practice it isn't always clear-cut whats better to be done in code and what to do in script. I can give you a few examples:

• Specific interactions, like quests, npcs are obviously all done in my own variant of blueprint-scripting, thats where I think it really shines. For something that is only used once, I really don't want to make a c++-class of any kind
• More general things like player-controller and enemy-AIs, I also do in the visual-scripting. This could be a point of contention - I can see people really preferring to do this in code, with state-machines and all. Enemy-AIs are a good thing for me to use my visual-scripting, as its coroutine-like nature synergices very well with the (also visual) behaviour-tree - where most tasks can be described as one method in the visual-scripting, that is then placed in the behaviour-tree
• Anything that is more system-like, requires extensive editor-tooling etc… is done in C++. For example, the map-system for dungeons is mostly C++. The rendering of the map is blueprint, but the maintaing/editing of the map-data etc…, C++ is just more well suited

But I'd agree - for a simple game, its not that worth it. The game I'm working on has tons of custom content - pretty much every single map has some scripted behaviours in it, thats where visual scripting pays off.

Oh, did I forget to mention that a big fat public GitHub account doesn't hurt?

instead of wasting time on c++, java, rust, python, c#, random engines like unity, and other jokes (which regardless of the fantastic job ads, will not bring you anywhere except to the homeless shelter), learn the good old C language properly, and try to write code thats simple, easy to understand by everyone, functional, portable, and fast enough. it will bring you from A to B.

if you dont like taking risks, dont have an enterprenour-type nature, or for some reason C is not an option for you / you just dont like the language itself, then go with html/javascript. NORMAL javascript is a very potent and sought-after language nowadays (not the frameworks for iq 40 people) and will always lend you jobs, works, as web gaming will stay for long time.

Geri said:
instead of wasting time on c++, java, rust, python, c#, random engines like unity, and other jokes (which regardless of the fantastic job ads, will not bring you anywhere except to the homeless shelter), learn the good old C language properly

Isn't C the grandmother of almost all those languages? Meaning, you know one of these, you basically also know C already anyways? (Details like pointers aside, eventually)
Which game is still written in C nowadays? Which serious engine is not written in C++?
Why should C++ be a waste of time, but JS not?
What's your argument here? And isn't it highly subjective, and should be presented as such? (The job offers i read always require U engines experience, C++ pretty often, but never C)