3 ms·

Try blueprints. Not because they're easier, but because they expose the engine API and make it so much more discoverable. IMO its a much better way to learn the

Try blueprints. Not because they're easier, but because they expose the engine API and make it so much more discoverable. IMO its a much better way to learn the engine. When I write c++ for unreal or c# for unity, I find I'm much more likely to end up time trying to implement a concept that the engine already handles, in a far superior approach than what I'm doing. Procedural animation isn't quite there yet, but control rig is slowly improving.

Agentlien 5y ago
On the other hand if you make blueprints without really knowing the engine you'll quickly end up with a mess of cobbled together poor solutions which sort of work.
- kwertyoowiyop 5y ago
  You can do that in C++ very easily too.
  - Agentlien 5y ago
    Absolutely, but I've seen it happen a lot more in visual scripting languages than in C++. Mainly because it lowers the entry requirements to people who don't understand what they're doing.
    - kwertyoowiyop 5y ago
      Agreed 100%. Then you have to bring in a Sr. Engineer to reorganize and rearchitect all the “not code.”
- spywaregorilla 5y ago
  That's fine. By the end you'll know the engine and be able to make it better.
  - Agentlien 5y ago
    That sounds fine for hobby projects but I used to work in a AAA studio where much of the game logic was made this way and a lot of engineering time went into identifying and fixing issues (both functional and performance) caused by designers or TAs working this way without asking help when they needed it.
honkycat 5y ago
My workflow tends to be: - Build it in blueprints for rapid iteration - Port it to C++ for refactoring and long-term code quality I was bullish on the node based programming, but over time I've liked it less and less. I've been a software engineer for 10+ years so I am very comfortable in the IDE and coding workflow. But yeah, discoverability in blueprints is out of this world. And the C++ classes use the same functions as the blueprint classes. Once you figure out how to find the C++ the blueprint is calling into, it becomes very productive.

Agentlien 5y ago

On the other hand if you make blueprints without really knowing the engine you'll quickly end up with a mess of cobbled together poor solutions which sort of work.

kwertyoowiyop 5y ago
You can do that in C++ very easily too.
- Agentlien 5y ago
  Absolutely, but I've seen it happen a lot more in visual scripting languages than in C++. Mainly because it lowers the entry requirements to people who don't understand what they're doing.
  - kwertyoowiyop 5y ago
    Agreed 100%. Then you have to bring in a Sr. Engineer to reorganize and rearchitect all the “not code.”
spywaregorilla 5y ago
That's fine. By the end you'll know the engine and be able to make it better.
- Agentlien 5y ago
  That sounds fine for hobby projects but I used to work in a AAA studio where much of the game logic was made this way and a lot of engineering time went into identifying and fixing issues (both functional and performance) caused by designers or TAs working this way without asking help when they needed it.

honkycat 5y ago

My workflow tends to be: - Build it in blueprints for rapid iteration - Port it to C++ for refactoring and long-term code quality I was bullish on the node based programming, but over time I've liked it less and less. I've been a software engineer for 10+ years so I am very comfortable in the IDE and coding workflow. But yeah, discoverability in blueprints is out of this world. And the C++ classes use the same functions as the blueprint classes. Once you figure out how to find the C++ the blueprint is calling into, it becomes very productive.