Hacker News Reader

Comment by HellDunkel | Hacker News Reader

>> To be successful at finding employment in games with UE4, you have to be able to use create game systems without using their blueprint feature. It's insanely powerful, and people really like it for rapid prototyping, but relatively frequently blueprint devs can't transition to C++/"raw" game code.

You make it sound as if you would inevitably hit a brick wall when using blueprint. This is not true. Game design is different to programming and some coding skills are almost a requirement for blueprints. Lots of game logic is better implemented as blueprint than c++.

View on HN

If your only, or primary, experience building games was scripting systems in blueprints (or analogous visual scripting language), you wouldn't get hired as an engineer at most large studios. There is a role for that on those teams: technical designer. The (gameplay) engineer exists to build large systems that might have hooks that allow designers to script/customize the functionality through a visual scripting system. Engineers provide their value lower in the stack.

> You make it sound as if you would inevitably hit a brick wall when using blueprint. This is not true.

In my experience, devs that spent all their time with blueprints did not transition well away from blueprints. YMMV.

Maybe they should not transition away from blueprint.

I get that beeing aware of pitfalls and manage teams to do things „the right way“ can be very tricky.

I'm not really interested in arguing with you. There are times when Blueprints are insufficient, and if a team is comprised exclusively of Blueprint devs, that team will be unsuccessful. This post was about UE employability, to which I added my input that being versatile is important, which from an employability standpoint is pretty objectively true.

Blue prints are great! People should use them where appropriate, and use something else when not.

Visual coding is still in its infancy. We have decades of experience for how to design systems with textual code, and a ton of tools (IDEs, static analyzers, refactoring tools) that work with text.

The fact that some systems are better implemented as text is not an indictment of visual coding as much as it is a testament to the maturity of text as a language for coding.

Game design is only on part of the problem anyway—often a feature which is simple from a design standpoint is complicated to implement in code. This is why you don’t just hire game designers who dabble in coding, but also programmers.

> Visual coding is still in its infancy. We have decades of experience for how to design systems with textual code, and a ton of tools (IDEs, static analyzers, refactoring tools) that work with text.

Visual coding has been around since at least the 1970s; we have decades of experience with it, too.

And yet, in that time period, it has remained in its infancy.

Or, extensive experience has shown that it is best used as an adjunct to textual programming.

Exactly- you hire both and for good reason. The point is that there is absolutly no reason for somebody not to be successful in game design working with blueprint.

Ideally C++ programmers should know how to make blueprint components wrapping their C++ code, and understand blueprint programming enough to know how to make usable blueprint apis.

Reply on news.ycombinator.com