5 ms·

(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 a

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

HellDunkel 5y ago
>> 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++.
- void_mint 5y ago
  > 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.
  - HellDunkel 5y ago
    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.
    - void_mint 5y ago
      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.
- klodolph 5y ago
  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.
  - dragonwriter 5y ago
    > 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.
teamonkey 5y ago
> 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.

HellDunkel 5y ago

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

void_mint 5y ago
> 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.
- HellDunkel 5y ago
  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.
  - void_mint 5y ago
    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.
klodolph 5y ago
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.
- dragonwriter 5y ago
  > 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.

teamonkey 5y ago

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