taby said:

Well, graphics, graphics, graphics then. ?

Make them drool a bit.

LOL. Yeah, maybe that is the best route to go. There is a lot of interesting math in graphics for sure, but if I want to do gameplay and AI I think I would need specific skills for those areas. I've been thinking about writing a game engine (haven't we all) but at the time when it would be presentable I would have advanced so far in my career that transitioning to gamedev would be pointless. I feel it's kind of make-it-or-break-it over the next few years for me when it comes to getting into the gamedev industry. It's definitely more of a young man's industry than regular development and getting into it when I'm a middle aged man I think I would feel completely out of touch.

perry_blueberry said:
There is a lot of interesting math in graphics for sure, but if I want to do gameplay and AI I think I would need specific skills for those areas.

That's a common issue. People and skills aren't interchangeable.

You may be an amazing graphics programmer, but if they are looking for a networking specialist you're not getting the job. You may be an amazing gameplay engineer but they're looking for a tools developer. You may be great at AI systems, but they need a console platform specialist. Or you may have amazing skills at physics systems, but they need a generalist.

Similarly, you may be an amazing environment artist but they need a concept artist. You may be able to produce beautiful character models, but they need a UI artist. You may have amazing skills as creating buildings, weapons, and vehicles, but they need a technical artist.

Sometimes you don't even know the specialties they need at the time of the interview, they might not even consciously know themselves. They may have an open head count, and as resumes are coming in they feel a push toward a specific need, that's the need they're going to be looking for during the interview.

Present your best self, whatever that is. Do what you can to show that you can do the job and show that you're passionate about games. That's the part that is in your control. You don't control what their actual needs are, or what their thoughts and feelings are, so don't worry about those.

@frob I guess you are right. I'm not a specialist in any gamedev programming area or any software engineering area either. I'm a fullstack embedded dev (if that's even a thing), but I feel a bit lost as to where I want to go further in the embedded space since I'm not really that good at hardware and I don't have passion for Linux embedded. I'm definitely a generalist but I figured gameplay or especially AI were things I could become quite good at considering my background and how interested I think I would be in those areas in particular.

frob said:
Present your best self, whatever that is. Do what you can to show that you can do the job and show that you're passionate about games. That's the part that is in your control. You don't control what their actual needs are, or what their thoughts and feelings are, so don't worry about those.

I've been debating with myself for a long time now whether I should chase the gamedev companies and learn skills I believe they are looking for. I'm not passionate about games in general or the gaming scene; it seems a bit toxic to me. There are some games or genres I would be quite happy to work on but I'm not likely to work in the companies making those games since they are in other countries and likely seek experts. This has led me into the popular game engines and trying to create games on my own which leads me into 3D modelling and other parts of gamedev since the games I want to make can't just be made of code, but then I get stuck somewhere and give up because it's such an overwhelming task to create a game on my own.

I think the gamedev technology is much cooler than any other part of programming I've tried. Most of it is CRUD or UIs outside of gamedev, whereas gamedev cares about perfomance and has tons of algorithms. There seems to be infinite need of better programming in games, whereas outside of gamedev the programming is often not as critical or it's only critical to get it good enough. The only other companies that care about algorithms and performance to that level seem to be big tech, but they don't have their offices anywhere around these parts.

I don't think I'll come up with a solution to my conundrum anytime soon but it's at least nice to talk about it, even if (almost) no one is listening.

Did you try starting from the other end?

Instead of finding something game-related "from scratch", start from what you have (ie embedded dev work). What in there is something you like, something you would like to pursue as global direction? Then see how you can squeeze that subject into games.

For example, maybe you like coding algorithms or inventing new algorithms, or getting stuff optimized. Surely some jobs in those domains would exist in the game industry?

Alberth said:

Did you try starting from the other end?

Instead of finding something game-related "from scratch", start from what you have (ie embedded dev work). What in there is something you like, something you would like to pursue as global direction? Then see how you can squeeze that subject into games.

For example, maybe you like coding algorithms or inventing new algorithms, or getting stuff optimized. Surely some jobs in those domains would exist in the game industry?

If you mean in the sense that I tried to point out the things I'm already good at and how those things can help me find better ways of solving problems in gamedev, then yes I did that. But gamedev is such a specific field that skills from other domains don't carry over that much. Also the people in gamedev generally have little idea about what coding is like outside of gamedev, so they probably don't know what to make of my previous experiences.

The reason why I went into embdedded was because I didn't want to pursue web development and I thought working with hardware would be cool. But then it turned out my natural abilities are much more geared towards software and not hardware so I went down a blind alley. I've certainly seen some interesting embedded jobs involving more algorithms, and I did work with one. But what I've realized is that the algorithm work is usually handled by people with a math/physics background. CS folk like me get to do the integration of components and manage the data. Hence, I've become more an integrator and forgotten the algorithm parts of my CS knowledge. Obviously there is a lot of integration work in gamedev as well but the ratio of algorithms/integrations is much higher in gamedev from what I've seen.

The transferable skills I have into gamedev are software engineering , low level programming languages, real-time systems, UIs and creating APIs. I have knowledge in other areas as well but those areas are not transferable (like Linux and protocols used in embedded). I think I'm the very definition of a generalist. As such I can imagine it is very difficult for someone in gamedev to even estimate my skills and when my skills in gamedev are not higher than those of a recent grad they probably think I'm just technically incompetent in general.

Many game programmers transition in and out, so we understand those things.

Many of us have done various business software, some coworkers I have worked with have covered insurance billing, medical scanning, various embedded devices, banking, post terminals, and more. You don't need to review many resumes and CVs to see it is common to take gaps for work in other industries.

A good programmer is smart and able to solve problems regardless of the industry. The difference is what you enjoy. My brother loves ETL tasks but I find them boring, he looks forward to a 200ms SLA where I look at it and am bothered by the unused CPU. If you enjoy the challenges you have today then stay there. If you want to try the challenges of game development, go for it. The interviewers will understand, there is a good chance they have done the same.

All of the things you described as your work history are things that need doing in games. The skills are transferable and the need is present. Just apply, make your background clear. You can't know exactly what they are looking for beyond what they tell you in the job listing. While you might not fit for one job, for another you may be a perfect fit.

frob said:
Many game programmers transition in and out, so we understand those things.

Many of us have done various business software, some coworkers I have worked with have covered insurance billing, medical scanning, various embedded devices, banking, post terminals, and more. You don't need to review many resumes and CVs to see it is common to take gaps for work in other industries.

I understand. It was just meant as a general comment based on my experiences. For example gamedev mostly seems to use C++ and C# whereas I've been on projects using 5+ languages and I've had to work a bit in all since the I've worked in startups mostly. Also gamedev doesn't seem to adhere to best practices such as unit testing, that are followed religiously in other parts of the industry. But my interaction with gamdevs is mostly based on what I've seen online and I only have a couple of real-world experiences with them in interviews, so I cannot say for certain that it's a general pattern in the industry. The times I've interviewed I did get asked about if I'd implemented algorithms and knew linear algebra but not about general software engineering so that definitely colors my perception.

frob said:
All of the things you described as your work history are things that need doing in games. The skills are transferable and the need is present. Just apply, make your background clear. You can't know exactly what they are looking for beyond what they tell you in the job listing. While you might not fit for one job, for another you may be a perfect fit.

Maybe so, but that's not been my initial impression so far. I guess I will see in a couple of years if I have finished some hobby projects and can find jobs to apply to since there are so few opportunities in comparison to other industries. It would be nice to come into a job knowing I've done a lot of similar work in a hobby project vs “I am a good engineer but I need to learn most of this stuff on the job”, although getting the chance to learn something new is a major perk in any job.

For those projects that do not have graphics, there may be ways of using statistics to analyze your code's complexity. Wouldn't hurt to make a histogram or two. Ever try R?

@perry_blueberry Also gamedev doesn't seem to adhere to best practices such as unit testing, that are followed religiously in other parts of the industry.

Actually this is a solid business decision.

Unit testing ensures permanence, not correctness. The high upfront cost is anywhere from 75%-200% of the cost of the main code, but has a potentially very long tail of reduced risk of breaking things with change side effects.

Game code does not have that long tail, so has no long tail to recover the cost through benefits. Game code is also under constant change, negating the benefits. It is far more cost effective to hire a small army of testers at the end.

Game libraries at larger companies do get automated unit tests, especially when they are tech shared across projects. The benefits there return, the long tail exists again, and permanence in libraries is more important than change like game code.

It is one of many “best practices” where you must understand what makes the practice “best” to see it implemented well. Not only for engineering, the same with performance techniques, what was good elsewhere may not apply to your architecture.

@frob That's very interesting. No one I've talked to about unit tests in gamedev has given such a clear response as to why they don't use unit tests.

For myself personally unit tests are a great way of making sure my code works in the present as well as doesn't regress in the future. When QA reports bugs in a feature I've developed that's a bit shameful for me and the turnaround time is longer than if I had just written a test for it upfront. I think I would have trouble adjusting to a mindset of not writing unit tests. Visual parts are difficult to unit test, but basically for all logic the benefits outweighs the costs from my experience.

Edit: I think in a startup there would not be a long tail as well since time to market is so important. But what I've seen is that unit testing can slow down a project in the beginning but speeds up the development later on. Different code bases might require different quantity of tests though so I'm sure what you say is true for the projects you've worked on.