if I may offer some advice as game/engine programmer.

If you want to get hired at a company as a programmer, make really really small things, like tiny games. I am talking start with hangman, then sudoku in the console. Then move on to minesweeper and tetris. If confident do space invaders. At this point maybe get started with 3D? Maybe Unity and Unreal?

There's SO much stuff you'll learn making those games. Maybe you end up making a fancy menu, or adding sound effects. Maybe you come up with some basic particle effects. It doesn't really matter, what matters is you went through it and have something to show.

Don't get side tracked with big projects and trying to be a designer at the same time. Keep it small.

If I am interviewing you and see some solid and polished small games and we can talk about stuff you found cool you're already punching way above most entry level coders.

This idea is extremely prevalent in the games industry and I'm really not a fan of it. It doesn't matter how good of a developer you are, what complicated projects you're working on or have shipped, if you don't have a portfolio of games you've made then you might as well not bother.

Which if you think about it is a real issue. Imagine applying at a courier company for a developer role and they keep asking you about the tracking software you've built, parcel measurement integration you've done etc., instead of asking you about your development skills. Having done those things is of course a huge bonus, but excluding 100% of people that don't have that experience excludes a great majority of candidates that could have been a great fit.

The problem is even bigger than that if I think about it. In this example they don't want to know about individual pieces of industry relevant software that you've built, they are expecting you to have shipped enterprise wide solutions that fit the criteria and that doesn't match your skillset. The role they're advertising might be a senior tech lead/developer, but you're not being hired as a programmer, you're being hired as a game maker. They want you for the games you've shipped, not for the code you've written.

Does your little games have "juice"? That's going to get you hired 100%, but mainly because of your skills as a designer, artist, tester, audio engineer etc., coding only made up 20% of that package.

I agree. It is better to finish a small project than start a big one and never finish it. I have seen a few people, and a few groups of people, who had big impressive plans... and never delivered. It is easy to imagine big: this game should be 3D, full of action, but also logical puzzles, and strategy, with an AI opponent, and also multiplayer; perfect graphics and a great storyline, but also allow complete freedom of movement... and then, five years later, you have five characters made in Blender, a map of the world where the story is supposed to happen, a list of fifty magic spells divided into multiple categories, and a tech demo where one of those characters is walking across an endless green plane.

If you can't make a small game, you can't make a big game. So make the small game first; it should take much less time than the big game, so if you are afraid that doing the small game would waste too much of your time, you are definitely not ready for the big game.

Even the small game requires a lot of work to make it look nice. Consider minesweeper: after implementing the minimum mechanism (click on a field to expose it, you either die or not, the number of adjacent mines is displayed), you are not even half done. You need the recursive exposure for fields with zero adjacent mines, editing the flags, showing the unflagged adjacent fields. Preventing the first click from being a mine. A hi-score table, where you can write your name, and it gets automatically saved, and loaded at start of the game. A menu to choose between simple, medium, and hard version of the game, maybe also custom dimensions. Should the game pause when minimized? All these details matter for user experience. Maybe also an installer?

On the other hand, if you can do the minesweeper right, you can easily create a new interesting game by tweaking some details. Maybe, play on a hexagonal map? Or play on an infinite map that scrolls to the right when you completely clear the leftmost column (except for the fields containing mines)? Add some bonuses (that you can collect by clearing a certain area) that allow you special moves, such as eliminating a mine, or reshuffling the existing mines? Would it be possible to create a version where you can have more then one mine per field? (Just a quick idea I had now, I don't even know whether that makes sense.) Maybe add some time pressure, like you need to make a click before the timer runs out, or maybe every twenty seconds a new mine is added to the plan (make sure it is not right under the user's cursor)? Or just make some non-functional feature, such as displaying a pretty picture in the background, and you get a new pretty picture when you complete the level.

I'm finding that dedicating yourself to working on your own game can be a detriment to finding an actual job in the industry? It feels like employers are wary about your intentions and whether or not you will stick around.

Employers also don't seem to take home-grown experience seriously? Even if you know more about the niche side of things like networking, graphics, AI programming. If you don't have exact experience in whatever tools/framework they use (UE blueprints, Unity, etc), they think you won't be a good fit. Even though tools are just tools and concepts are more important.

How is this relevant in 2025? Gemini one-shots all of those. You have to be able to do something LLM can’t.