Comment by void_mint | Hacker News Reader

Comment by void_mint | Hacker News Reader

Parent Full thread

(I am not a game dev but work at a games startup with a bunch of big industry people) 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. The same is true for pretty much any game engine - the ability to make games beats the ability to use editor features.

If you're looking for entry level work, I would say having a wealth of items in your portfolio is helpful (across several genres/styles, meaning get some work out there that isn't VR/AR related). Also remember that paying gamedev work is usually nothing like making games for yourself. Think hard about what and why you enjoy making games. Are you comfortable working on something like a desktop version of Candy Crush? Or a poker game? In my experience (on the internet) you hear most about A.) AAA Crunch, and B.) Massively successful or massively failed games. The middle is where most employment happens. Mediocre games making modest sums of money.

If I was interested in working with UE4 for games I would kinda just tailor my resume to working at Riot. Valorant is written in UE and they're a huge name/very established business, so you'll be shielded from some/most of the garbage of the games industry.

The job market is good. Lots of AAA studios are moving away from custom engines into UE/Unity because of the advancements in the engines making them more hireable/popular.

Just my 2 cents, and I'm certain others have wildly different experiences.

>> 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++.

> 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.

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.

> but relatively frequently blueprint devs can't transition to C++/"raw" game code.

I agree that if you are looking to become a gameplay or engine programmer, demonstrable C++ (or C# for Unity) is essential. Bear in mind that js or python, and sometimes even C# are often considered as scripting languages for non-programmers.

Other roles might be closed to your skillset though. Some backend/server /tools stuff might use python. Some engines use a streamlined form of javascript to drive the UI. Or there's UI/UX design roles.

Reply on news.ycombinator.com