Ask HN: How to move from traditional tech into game dev?

I worked in gamedev for 20 years. In retrospect, I could have made a lot more money selling ads for cat pictures. But, enjoyed the chaos of being at the intersection of art, tech, design and commercialization.

My advice to everyone wanting to enter gamedev is the same as for everyone wanting to start a startup: Be realistic about failure. It’s a high risk, high reward business with tons of uncertainty. It’s easy and common to be so enthusiastic about working hard to succeed against impossible odds that failure become a “Voldemort” term that shall not be spoken..

But, if you are realistic about the fact that “risk” includes the possibility of failure, you can be realistic about what failure means and what you plan to do when it occurs. If failure means your family will literally be homeless and starving, don’t take that risk! If it means your dreams don’t come true and you’ll have to go back to some boring desk job… Well that’s a bummer. But, it’s not anything to be afraid of.

Be sure to have enough money in the bank to pay the bills if you suddenly, unexpectedly have no job and need to find another. Be a coworker who people want to work with again because people who leave your company before you are how you land your job at the next company.

Not in gamedev (and not planning to change that), but this is excellent advice applicable to many other domains.

Backend. Do the game backend stuff for online/mobile games.

Everyone and their sister wants to be the one that does the pretty graphics and UI with Unity or whatever. Nobody wants to be the one who does the backend code that actually makes the game work.

It's actually challenging when you work with games that might have a million daily users or even more. If it's a competitive game, people will try to cheat and you can't trust anything the client sends you. The code also needs to be cost-effective to run, if your game makes $10k a day, but the backend costs $5k a day to run - that's kinda bad.

Also especially mobile games need a custom frontend for customer service so they can do refunds, check player purchase history etc. Those are done with JS and Python etc.

Source: Moved from traditional tech to making CS tools and backend for games. My salary went up hilarious amounts, as did bonuses and options.

>Nobody wants to be the one who does the backend code that actually makes the game work.

This is only true for a certain class of games that rely on multiplayer. Many games are singleplayer where the meat exists on the game engine. There's two sub sections of this as well. Real time and non-real time.

Realtime means streaming updates from all users. Games like fortnight or pubg are like this. Non-realtime means like checkers or multiplayer chess. If you are doing the later rather then the former I would say you're still in traditional web development where shit is still relatively easy because an HTTP server is good enough.

The former is what is really hard, and that kind of thing is what I would refer to as backend game development. If you are doing that, then likely you're not a traditional web developer anymore.

Typically in both cases Backend as a role will refer more to people creating and running services like server orchestration, matchmaking and so on. So the real-time/non-real-time distinction doesn’t really matter. The engine level role is usually Multiplayer or Networking Engineer and the actually making the game role is Gameplay Engineer.

It does matter. For real-time the person will likely need a custom solution. That means coding the entire server in C++ or some other zero cost language with custom protocols.

For the non-real-time, it means using a pre-existing backend server.

Many backend engineers don't know how to write a custom real time server from scratch. It's two completely different levels of skill. If you are hiring for this role and put out of job ad for typical backend engineers you won't get the right people for the role because, again, backend engineers typically don't have this skill.

Right that’s what I’m saying, the game server and associated protocols will be designed and written by the engine team in close collaboration with the gameplay team that will be making the game.

Are there any billion dollar game franchises that lack an online component? Feels like a safe bet to me.

God of war, Cyberpunk 2077, witcher 3, skyrim, fallout, Zelda, Tomb Raider, Metal Gear, Final Fantasy (not the mmorpgs), Assasins Creed, there's tons.

I wouldn't say they are billion dollar game franchises but I would say billions and billions of dollars in total are part of games where multiplayer is not the central aspect. This sector is huge.

I think games with a huge online component tend to be bigger franchises but fewer in number. Overall online gaming as an industry is bigger then single player gaming but they are both huge enough in size that they are comparable.

Actually game graphics people are hard to find but no one is going to hire into that role with no experience.

That said, you can leverage your normal tech chops to get a foot in the door. Games do need backend and database people, etc.

We've never had issues finding artists, much of the bulk work is outsourced anyway.

Cloud infrastructure/devops, data analytics, backend code, data storage all need people especially in mobile games.

> We've never had issues finding artists

I think they meant graphics programmers, not artists.

"Graphics programmers" are historically some of the highest paid and hardest to hire programmers in gamedev. But they're probably less of a thing in the age of Unity and Unreal.

Yea, nobody needs a "graphics programmer" unless they're making their own game engine.

In the mobile world very few companies bother. If they do, they're either so old that Unity mobile wasn't very good and already have their own engine or they're doing something niche where Unity doesn't make sense.

Everyone else just uses Unity and Unreal, because trying to launch a new game is hard enough without having to build everything from scratch.

Not to mention graphics is way harder then web. Let's be honest... Web, which encompasses frontend and backend is significantly easier then graphics programming.

It depends. If you're implementing something like K8s or Spark it's just as hard as a rendering engine, and you only need one K8s and one rendering engine. These days unity, unreal, or Blender can't really be beat.

If you're just working on top of a platform, it's trivial for sure.

No spark and k8s are configuration problems. Hard but you are not creating the tool, just configuring it. It's more of a dev ops /sys admin thing and, though I agree it's very hard, it's a very left field comparison IMO.

With engine creation you are creating the tool. It's programming through and through.

Though I can see how a lot of backend people are taking on the role of "configuring" stuff so it's hard to delineate backend programming away from it completely.

Still even when taking this into account, it is of my opinion that a rendering engine is significantly harder then even K8s or spark.

You are right though that with existing game engines graphics programmers are not as needed anymore.

Easier in terms of less math for sure, but there is still plenty of complexity with web. Async, constantly changing environment, and specific device quirks to name a few.

I've done both. Graphics programming is significantly harder. It's both harder to program for and harder to learn. Make no mistake, they are different, but in terms of challenge, Web is trivial compared to it.

You'll get a lot more people in Highschool who know Web simply because of how accessible and easy it is and a lot less people in Highschool who know how to create a physically correct rendering engine or a realtime graphics engine. It is brutally harder.

I thought game dev salaries were bad, but people still applied because of the thrill.

In a team of 20 making a mobile game, you have 17-18 people who don't do backend and 2 people who do.

Those two are the ones that are invaluable, there's a literal queue out the door to fill the sexier positions of game designer/producer/2d/3d artist/unity developer and whatever.

You can just pretty much plug in a new Unity developer to the team, since the skill set isn't that hard to learn.

...but finding someone who can do 1M+ DAU game backend that's reliable and cost-efficient isn't something you just hire off the street.

Those would be the roles that “everyone wants” as alluded to.

Question is, is it moral to work on that kind of game? You're describing the predatory IAP fests.

Edit: although I suppose it's equivalent to working on "engagement" algorithms in social networking.

Nobody is forced to buy anything in mobile games, it's bad business to do so.

The reason mobile game companies have hordes of data analysts and data scientists is to figure out the optimal point where enough people pay to speed up progress so the game is profitable, but not so much that non-payers stop playing because they feel they can't progress without $$.

Nobody bats an eye if someone spends $80 on the latest console, but everyone is sharpening their pitchforks if they spend a similar amount in mobile game IAPs. Even if the hours played and enjoyment received are perfectly equal.

Most people who buy IAPs exchange money for progress in games, they work 8-10 hours a day so they don't have the time that a Monster Energy Drink fueled teenager has to grind equipment. But they have money they can use to catch up somewhat so they can enjoy their evenings playing the fun bits instead of grinding for that 1% drop like a second job.

You're somehow assuming all computer games involve grinding for some 1% drop.

You're basically describing old single player games that did rare drops to pad gameplay time, then the first MMOs where grinding was there to keep you paying for the subscription, and now the IAP fests where the grinding is there to make you pay something.

However, there still are games that do not involve grinding out there. Even some AAAs. You do not have to be predatory to enjoy some success making video games.

Edit: I missed that: "Even if the hours played and enjoyment received are perfectly equal."

They aren't equal. Do you call grinding for rare drops equal to enjoying a story or developing and applying some skill?

And how is hours played a metric of enjoyment? If you count hours played, the game i spent the most time in ever is Minecraft. Paid all of $20 for it.

As a former game dev turned regular old swe, I highly recommend just going the indie route (i.e. nights and weekends). Game dev is just doing software engineering, just harder (oh those trig classes matter! calculus has a purpose! linear algebra all day! ), that pays less,with the same or worse politics (studio bosses instead of eng/prod directors), and in most cases doesn't result in a playable game. Sorry, I'm jaded, left that industry at 27 and never looked back. One of my old bosses once told me that new 22 year old CS grads were "meat" for the grinder, and after even 3 years I knew why that's true.

I'm not as jaded, I've been lucky enough to work at nicer places, but having made the same jump I would strongly recommend the same thing.

Either nights and weekends, or after a few years as a SWE you could just retire somewhere cheap and go nuts on your game dev passion.

What would you recommend for someone who thinks the math part is interesting (and yes I know in normal game project Unity or Unreal Engine would handle it), but isn't that interested in in promoting their indie project?

Oh, yeah, game mechanics or game physics engineering is amazing, but understand it's about 1% (if that) of what makes a successful game. I was watching my nephew play Fortnite over thanksgiving and thinking to myself "gee, the graphics are shit, essentially low-poly with some nice shaders!". And CoD Black Ops puts the physics to shame (and thinking that old timers used to tell me the physics of that were bad compared to e.g. PubG/Battlefield). But Fortnite is super colorful, and for a kid just coming off Roblox, it's accessible enough to play. So the HUDs and UIs and leveling and map dev and a million other admin tasks are where the majority of your game dev experience will be. Even doing some (gasp!) web dev, for things like in game stores and so forth. The gameplay mechanics and physics math of particle engines or calculating missile intercepts or inverse kinematics (jacobian matrices anyone?) for skeletal animations are mostly solved problems, but they can still be interesting to reimplement.

To me it sounds like someone's still making a living from R&D even though the big money is at casual games and selling diamonds or hats in in-game stores. The question is just how to get that job.

Wouldn't you just use an off-the-shelf rendering and physics engine instead of working on your own?

Back when there was no commoditization of game engines, every team starting a game had to do their own engine, tools etc.

Now that you have unreal and unity etc, you can actually concentrate on game design and gameplay instead of worrying about the engine and tooling.

I agree though writing a game engine and physics engine is very interesting. I used to work for the R&D team of a casino games manufacturer. We created our own in house game engine. It was fun, but adding any new feature would take a very long time. In the end we shifted to unity.

Actually there’s still quite a bit of math involved implementing gameplay mechanics and it can be quite a bit more off the cuff and experimental which people might find fun. The equivalent of writing shaders rather than a rendering pipeline.

Exploration geophysics, remote sensing, satellite navigation, etc.

Fugro, Siemens, et al - Earth visualisation, medical imagery, etc.

The emphasis in these fields is getting visualisations and computations correct rather than convincing.

ie. The math part is interesting.

In remote sensing you might find yourself doing a continous pipelined SVD reduction of 500+ dimensions from a spectrum sensor to some three axis RGB like space to create a viewable image from a non visible part of the EM spectrum.

There's not so much of taht in game dev.

I've made my own simple physics engines and used linear algebra to do things like projecting from 3d to 2d space. None of it was any good but it was a lot of fun. This was back when I was most comfortable in Java and the performance was horrible. I don't know what methods of collision detection real engines use but Runge–Kutta is not a good option for real time games.

I don't know how to do it and make money but I would recommend playing with the math. It's like magic, you setup the formulas and things just start moving on the screen. It was so much fun.

After decades as a EE / SW Engr, every single person I've known who worked in game dev has told this story.

More work, less pay, more irrational management...

After the tens of thousands laid off in SW over the last few months, the sweet spot is in embedded, more than ever...

This is the first time I’ve heard someone be optimistic about embedded. Better than game dev or EE but that’s only one step up on the work/pay ladder. I find my work interesting but I would have made a lot more optimizing the search bar on the Facebook android app or whatever.

The stories about embedded I've heard is that they've got outsourcing partners in India and China delivering shit-tier code and hardware that they need to fix themselves, on top of their actual jobs. YMMV though.

(Mobile) game jobs aren't a more work less pay environment in the least, the successful ones make so much money that the companies want to keep the teams who made the game at all costs. The companies also recognise that it's the people who make the games, so the pay and bonuses reflect that.

And because the successes are so big €€€-wise, most companies can afford to spend time making the next big game instead of forcing people to crunch and sleep under their desks.

PC/Console gaming is a whole different world, don't know much about that.

Few weeks back, others were talking about embedded getting paid less than web app development. What would you say, true? I understand that they aren't getting laidoff, there's a big gap in high demand and low number of experts in this field.

Definitely true. You’re not gonna starve, if you doing embedded at $BIGTECH probably 200-300k TC, but there will be a discount compared to the regular software engineers wherever you’re working.

Where are 'regular' swe's getting more than 300k? Or even, where are embedded engineers getting 200k+?

Do you want to make games or do you want to make game engines? A lot of people have the two confused. I would caution going into game development in general... If you just want to make game engines it's a much smaller world and much harder to break into.

If you really want to make games there's a huge universe of types of game development. A broad approach would be to just start making games - pick Unity say - and while working at your regular job - make some games on your own. Nothing helps get your foot in the door more than showing initiative, creativity and a get it done aptitude than having some samples we can talk about.

I see making games as an art, which would barely pay. There's a reason why they call most artists starving artists.

My path to being able to practice this art is to first reach financial security via a traditional job in tech. The pay in tech is pretty good all things considered, and at the same time you can train your engineering prowess.

You save, invest and move up the corporate ladder (or move jobs often) to ensure your pay is high, and do it for 10-15 yrs. Couple with making sure you don't overspend on consumption (a sacrifice you will have to make for the sake of your art later), you should be able to reach financial security before you're 35-40: a couple million in income-generating investments of various forms (like stocks/bonds/real estate).

Then you basically "retire" from tech, and focus on the game and live off your investment income. Don't expect this game to be commercially viable of course - it's your artistic output, not meant to sustain your livelihood. Then you keep doing it until you get sick of it, or truly retire as you get too old to type.

I run a game studio and we often hire people that worked in other industries before. In fact most of our staff have no prior professional games experience.

When I see people fail to transition its because they aren’t willing to put in the work to switch industries:

1. Learn some games relevant skills after hours to show that you are prepared and not expecting us to train you from scratch (unity or unreal are most common). The tools are free for personal and there are tons of free online tutorials. Build a small game — can be very small like a breakout clone. This will show the initiative you took on your own and what skills you’ve developed.

2. Don’t expect us to pay you as much as you’re making in your past industry because your skills may not translate and we will be taking a risk on an unproven gun.

If you go into the interview with those two it’s a no-brainer for us, but we also are a small indie studio so ymmv at a larger place.

>"we will be taking a risk on an unproven gun."

I don't think such a transition happens the other way around. It shows that game programmers are superior to web programmers. It's hard to swallow but it's true. There are web developers who aren't good enough to be game programmers and the reverse is unlikely to be true.

I say this from the point of view as a backend web developer.

"1. Learn some games relevant skills after hours to show that you are prepared and not expecting us to train you from scratch (unity or unreal are most common). [..] This will show the initiative you took on your own and what skills you’ve developed."

Are you evaluating also how much time it took to complete the after hour project? What if I complete a clone game in 2 years? This might be excluding anybody that cannot work after hours, for a reason or another.

> This might be excluding anybody that cannot work after hours, for a reason or another.

Maybe I'm reading into this but I see this type of response a lot on HN.

> A: You need experience. Get some after hours

> B: I don't have any time after hours. It's not fair

Like gees! What do you expect?

B: I wanna be guitar player in a rock band

A: Well, if you don't play guitar, take lessons after hours

B: I don't have any time after hours

A: So what do you expect me to do about it? I'm not about to add someone who's never played guitar and can't demonstrate the skills as a guitarist in my band. It's not my problem that you can't play, don't have the time to learn, and yet want to be in my band.

Same for any company: So what do you expect me to do about it? I'm not about to add someone who's never programmed games and can't demonstrate the skills as a game programmer in my team. It's not my problem that you can't code games, don't have the time to learn, and yet want to be in my gamedev company.

I have hired a bunch of people in game-dev, personally it doesn't matter how long it took. If you show me a demo game/project you've built then we can talk about it, problems you faced, decisions you made about the architecture, your pipeline, where you cut corners, etc.

I don't care how long it took (specially if it's a hobby after work kind of thing) as long as I can see you have a solid understanding and experience of what the work really is.

Not having time after hours it's a hard problem to solve. Gamedev problems are quite different to other software industries so previous experience might not immediately translate, this is specially true for gameplay programmers or things like tools and engine where you need to have experience with working with artists/designers and within the constraints typical of games (memory, performance, platforms, etc). But other fields like, backend, devops, data analysis I've seen often hire from outside the industry

Excluding everyone that cannot work after hours might be the intention?

How does a person who is curious about this contact you?

I'll go with the trite advice of don't quit your day job. Making games is very accessible right now. Making money off games is not as accessible! I just released my biggest game Pine Tar Poker (https://www.pinetarpoker.com/) and I built it all during nights and weekends when I had another job. Making the game was fun for the most part, but it would have been a lot less fun if I was stressed on how long it took and how much it was going to make back.

My basic understanding of marketing games today is that it's a full time job to stand out in such a saturated market. If you're not posting clips on TikTok, vlogging behind the scenes on YouTube, or putting up your Steam page right now to collect Wish Lists, you're already behind the eight ball. Again, this stress goes away if you're just dabbling in it as a hobby.

Just like anything in life, you start by doing. You can maximize your experience by having the right expectations and goals going in.

As others have mentioned, game jams are a great way to dive in, get experience, and meet some people.

Edited to add: my original answer was colored through the lens of "going indie". If you're looking for a job in the industry, I think that's a much "easier" path. Start building a portfolio of completed projects (not just prototypes!). If you have projects that show your creativity, skill, and grit, that's a lot easier for hiring managers to understand than yet another PDF resume in their inbox.

I have a good friend who is a talented artist. We tend to look for styles that let us produce game content or marry existing content to the aesthetic with minimal extra work. Specifically, picking a good style and using shaders to achieve it can mean the ability to drop in Asset Store assets or models from other marketplaces and get them looking bespoke without much trouble. For Pine Tar, this meant my friend making a halftone shader that we could apply to all our materials.

Another option which I'm using on my current project is to go minimalistic and lean into typography and procedural visuals, so I don't need portraits or specific custom textures. This can work well for games like Wordle, where the game is meant to be front and center and the audience isn't looking for some heavy-weight theme.

I ventured into the land of game development almost exactly 10 years ago, after having spent 20+ years of my life being a "traditional" developer. I started out with Unity and stuck with it, because it lets me focus on programming (and C#, which I love). Unreal wasn't left untouched, but to me it focuses too much on style and design, which I have no feel for;

* Game development is _very_ different from "normal" programming. It's still just programming, and it's not necessarily harder, but _how_ you solve things is radically different.

* You will spend _years_ trying to get the grip on things, combined with your regular day-job to keep the grip on your non-gamedev life.

* You will never succeed, of course, but that's the same for everything. For game development it's harder to accept, because it's so easy to get up and running quickly, you are feeling like Sid Meier the first year.

Other than that, it's a lot of fun. :)

EDIT: About the "very different" part, which it seems like I portray as something negative; that's actually the most interesting part, at least for me. I learned how to appreciate composition this way, and in general learned how to approach problems in a totally different way.

When you say Unreal is too focused on style and design, do you mean the IDE? Did you just use Blueprints without any C++ underneath? I’m just surprised because having dabbled with both I’ve generally found Unity less code-centric, especially with the amount of stuff in the asset store etc.

I wish you the best of luck with this. I work in computer graphics in the film/tv/video industry rather than games. I work with several people who are former game developers. They all got out because the work was horrible. They loved graphics and rendering, but couldn’t stand the work conditions. As one coworker said, “One day I went into the office and realized I was the only person over 35 working there. Everyone else had left because of the work conditions, and I realized it was time for me to go, too.” So just go in understanding the conditions.

Another coworker said that until you’re more established they give you the shittiest jobs. One person who did an internship over the summer while getting their master’s degree was tasked with getting the intro screen (where you select which game you want to play) working. It took them about 2 days, but because they weren’t a senior engineer, the company never gave them anything else to work on. They spent most of their internship (after trying and failing to get the company to give them other work) surfing the web.

Over the last couple of years I've accidentally done sort of what you're after. I'll describe what happened and give you some thoughts. I'm not sure how useful it will be as I'm now in a business where game engines are used for non-game work and, as I said, my path was fairly accidental.

I took a job doing an interesting C# project where the front-end was being developed by another company (that mostly does cinematic work) using Unreal. It turns out that most Unreal developers love the shiny side of things but rapidly get lost once it comes to needing C++ - or even Blueprints in some cases. I took on the responsibility for the bit where our code meets.

When this project ended, I moved to a different part of the same international company where Unreal was being used for virtual studios. It was a bit of a leap as despite not having much C++ experience, my first proper C++ job was now working on a fork of Unreal's C++ source. That's one huge, unwieldy, undocumented chunk of C++! I sometimes work alongside some very talent Technical Artists who do stuff I couldn't possibly manage in Unreal, but can get stuck when it get down into code. It is more interesting that "standard" dev, but believe it when people say graphics development is harder. In my experience, the only thing that's harder is FPGAs.

Here are some thoughts / tips that might help:

- Get proficient where most game developers aren't - C++. There is some Python used, but good Unreal devs can manage this.

- Use Epic's online learning. Their documentation is awful but their training is good.

- Look at non-game use of Unreal as a stepping stone to game work - virtual studios, architectural visualization, etc.

- This non-game work seems to pay OK. I hear game work doesn't so much. Maybe stay here.

- From my experience, Unity just doesn't seem to have as much traction outside games. Could just be what I've seen though.

I hope these rambling thoughts have been some help.

I've bounced back and forth between gamedev and webdev/data science. What I did before my first gamedev-adjacent job (training sims for the Army) was learn unity and openglES on android. I put together a small portfolio of POCs I made while learning and used that as evidence I could do the job.

The trick's just to accumulate proof you can do the job you want to have, then show people that proof while asking to do things for them.

Another fun trick is to never stop accumulating proof and post it all publicly on some kind of social somethingsomething as you go.

I get dms for consulting gigs through twitter without having to ask now. I haven't updated my resume in years. I just create and publish.

Thanks! I've used Unity a little bit but will have a better look at it, I've been playing with Pygame but I guess it's better to use a proper tool to learn.

Any thoughts on Unity vs Unreal?

Pygame's cool. I had some pygame things in my portfolio in the very beginning, but I've never seen it used by people who have signed my checks.

I like the development workflow in Unity more than Unreal. C# > blueprints/C++ for me as a matter of preference.

Unreal has some graphics tech on the high-end that I'm envious of. Real time lighting from emissive materials/volumetric emission/nanite. Metahuman. Unreal also has a lot more/better free 3d assets.

I'm going to make a wild claim that Unity is better for making weird games and hybrid things. Partially because the .net standard library is bananas. (Shameless example ;D https://twitter.com/LeapJosh/status/1552977798452609024 )

> Any thoughts on Unity vs Unreal?

Doesn't really matter. There's a kajillion games made in both.

Unity is used by smaller indies and mobile devs. Unity is not conducive to large projects for reasons. Unity programming largely means C#.

Unreal has minimal use on mobile and is mostly used by larger teams. It's popularity over custom engines is increasing. Programming in Unreal largely means C++.

Of course backends could be anything. The above refers to game clients.

Games don't pay as well as big tech for damn sure. But companies like Riot Games pay decent. Big AAAA games that make lots of money know they compete with the broader tech industry for talent. Senior positions will pay north of $200,000. It's not all starving artist land. But big tech would pay 2x to 3x.

If you are sure you want to do it (see other posts!) then I would agree with others that getting your foot in the door with a webdev related role could be a good way to get into it, especially at a smaller studio with less defined roles and more flexibility for people to help out on other bits.

Personally I’d always been interested in music software development but my career was in webdev. I took a job at a music tech startup doing Node/React work, but was able to make a prototype using React Native to build the UI for music apps during the regular hack days we had there, which led to me teaching myself C++ and leading development of a new music app for them. I actually am not working in the music world any more but still do some for fun on the side, and found knowing both C++ and JS has opened up some really interesting job opportunities so it worked out well for me!

start making a games. a good demo is what got me in.

unity and unreal are ubiquitous and easy to use, if impossible to master. having some demonstrable experience with both will open up a lot of options, as well as give you and the interviewer a grounding for questions in interviews.

... and don't be afraid of the maths. you nearly never need calculus and statistics or anything that 'classically hard'. its almost all geometry and mechanics... most of it the kind of stuff you were taught at school, but grounded in heavily grounded in real world problems where your intuition can be helpful.

most gamedevs know nothing about the guts these days so being highly technical isn't as important as it once was - to an embarrassing level. the barrier to entry looks higher than it really is sometimes.... it certainly felt that way for me. the biggest take away from my first role, was how narrow and unpractised everyone's skill sets were - and how thats kind of a necessary feature of large scale game dev... you don't make many games very often, and you usually have very specific responsilbities that go unchanged for years.

I've been a web dev since 2002, and started contracting in 2013. I've been making games as a hobby in earnest from about 2016 onwards.

Tried a bunch of tech to see what stuck: phaserjs, haXe (fun!), Lua stuff like löve2d, unity (also with clojure). I settled on unity initially, but got burned (deprecation, docs/support, etc), and finally settled on Godot (I've got python skill, so gdscript felt natural).

With contracting, I make slightly more money than permies, so I can afford to spend a day a week on gamedev. With a view to phase in more gamedev days as I get more successful.

I just recently completed a masters in indie gamedev to fast track some of the skill requirements.

I'm happy with the approach I took to get where I am. It's low stress, I still make money, and I still have bags of fun. And the masters saved me some mistakes in the long run.

Do you mind sharing where you did the masters?

Similar to the rest of the tech industry, game dev is a very wide field, if you want to work on large games I would suggest you figure out where in the pipeline interests you most (technical art, gameplay, tools/engine, networking, audio, rendering, live Ops) and build projects that revolve around that domain. If you want to work on smaller games then you just have to start making games. To me, the only real difference between game programming and most other programming is the need for more complicated math so making sure you have a solid understanding of the maths used will serve you far better than learning any specific language/engine.

I think this is the key point.

Asking how you can get into gamedev is kinda like asking how can you be a professional musician. Sure, you need to know and like music as a base, but becoming a concert pianist, a jazz drummer, a metal guitarist or a hip hop mc are very different paths.

Similarly, there’s a big difference between working on Elden Ring vs a small indie or even one of the millions of match 3 mobile games.

I'm a full stack web developer and held 2 positions at game dev studios in the past.

The first one was very much a traditional full stack experience, developing front end features for the website and web based apps, as well as back end features for the web and games. We worked very closely with the game development team, so day to day I had to go into dev builds to see if my changes worked properly. I loved the job, it was the games I always wanted to work on, colleagues and management were great. But crunch was hard, ended up burning out which took a while to recover. Looking back at it, I would do it all again, I learned so much and I'm proud of what my team and I achieved.

The second job was as a UI developer, using the Gameface middleware, which basically renderers a web frame on top of the game, allowing you to design and write UIs with web tech. I was doing React there. The job was alright but the management was horrendous, a complete shit show at some points. Ended up leaving after a year and never came back to the games industry.

For both jobs, the salary was lower than other web dev jobs. And at times, it can be quite tough with crunch. But on the bright side, you meet great people and learn lots about game development even if you're not directly in the production pipeline of the game itself. I guess if your focus is to work on the game, you can easily transition within the company.

Your tech stack can be relevant depending on where you apply. Experiences wary greatly between studios, sometimes even within the same company. But I noticed a trend where working conditions and salaries are getting better in the industry, so maybe it's a good time to join. Have a look at career pages of game dev studios, you might find something you like.

Or maybe look at the indie route, working on your own game idea during your spare time. I'd highly recommend starting with Godot[0], the concepts of that engine are quite easy to grasp and you can produce really good results with it.

[0] https://godotengine.org/

From friends I've had who have made the jump, learn a game engine (unity / unreal / etc), make some small games (can be for a game jam or whatever) to put on a portfolio and mass apply to lots of different companies of many sizes. You may have to take a job title hit (i.e going from senior -> junior) / large pay cut.

There's a huge opportunity in gamedev to apply neural-networks to real games. Think neural-net controlled NPCs or generative storytelling. You can start doing small indie games with this approach and get some very valuable experience. There's not much people merging AI and games these days.

I've started this way roughly year ago. Here's what helped me.

1. Find an active community for the tech stack you choose (game engine) [I went with bevy and Rust]

2. Do a tutorial project such as simple table-top game, but do it really well [chess?]

3. Participate in game jams

4. Start contributing to engine development or infrastructure around it (plugins)

5. Do a novel environment for training AI

The standard approach to AI (training to maximize some sort of goal function) is rarely used in games because it results in AI acting robotic (non-human) and that can break the immersion. Having said that, I'd love to play against a ruthless, robotic AI in a Civ game.

There's a lot of non-trivial applications to AI in games:

1. AI-controlled physically-accurate character rigs instead of inbaked animations [1]

2. Conversations with AI NPCs (maybe lore-conditioned ChatGPT): think interactive Skyrim where you could actually talk to everyone

3. Evolving Neural Networks to control battle AI, but where Neural Networks get the same input as player (screen pixels, sound) instead of decision-tree based AI strategies. Then think how AI will learn along with player (Remember how PodBOT learned new maps in CS?) Current methods may work for any game, and bots may discover entertaining strategies by themselves

4. Multi-Agent large-scale simulations: there's some research [2] going on, imagine it applied to open-world games

5. Simulation for sim2real. How about testing a new robot prototype in the game before making it real

[1] ASE: Large-Scale Reusable Adversarial Skill Embeddings for Physically Simulated Characters, NVIDIA, 2022 https://nv-tlabs.github.io/ASE/

[2] Neural MMO: A Massively Multiagent Game Environment, OpenAI, 2019, https://openai.com/blog/neural-mmo/

Also, and this is the big point: AI is not meant to win. Being better at playing the game is not the primary directive of video game ai.

The primary directive is to entertain the player(s). An AI that loses every round is 100% compatible with that goal. An AI which always loses but makes the player feel like a genius for winning is not a bad AI: it is perfection.

If you have specialized in a sub-discipline, it can be an entry point without prior game dev experience or shipped titles. For me, my background in and love of audio and music programming made me desirable despite a lack of game dev roles. Turns out there is a severe lack of audio programming talent across the entire industry (we are looking for more at Naughty Dog as well!). Other specializations within graphics, physics and AI may also be ways to bypass the typical, Catch-22-like requirements for prior game dev experience.

The old generalizations about lower salaries and higher hours are no longer true across the board, by the way. As the industry is maturing, a lot of that is changing and the culture around things like crunch is changing for the better.

Does anyone have any source (books/videos/open source projects) on backend development for multiplayer games? The scale and real-time aspect of it seems like a fascinating subject.

I would say try out making your own very simple game first. Others are suggesting unreal etc but you can simply use your current knowledge to build something using webgl 2.0. See if you even enjoy that process first.

My path was to join a mobile game company and work server side. There is plenty of need for vanilla REST APIs, content management systems, build pipelines, devops, admin panel development, billing systems, and other code required to run the game. I've also seen demand for technical artists who write plug-ins for Unity and other tools that help 3d artists. Whatever path you use to get in, it's pretty easy from there to move around to other areas and companies.

What is it that you like about gamedev? Indie development is very different from AAA gamedev for example. There are also many disciplines within gamedev, each with their core responsibilities and day to day tasks.

Just make a game.

Game dev is actually one of the least credential conscious parts of the industry. If you can ship a game and get people to pay for it, that's all the experience you need to get hired somewhere. With Steam and all of the free game engines nowadays, there's really nothing stopping you anymore.

Suggestion: try doing it as a hobby before doing any major career changes.

> I love games

Many do, but game development can be tedious sometimes, or you might just discover that you like something else more.

# Game engines: Godot

For an easy start at putting something together, consider downloading Godot: https://godotengine.org/

It's a free game engine that's relatively simple, is open source, and supports both 2D and 3D, as well as has their own scripting language called GDScript (that should be easy to learn if you know Python), whilst also supporting C# (which is used more commonly in the industry). The documentation is pretty good, though you can also watch videos, like this channel for example: https://www.youtube.com/@Gdquest/videos

Follow the tutorials and try to put your own game together, see what working with maths/physics/things like raycasts is like, what it's like to deal with a game loop and scene trees, how logic that's attached to various nodes/objects interacts. Don't make the game anything complicated, start out with something like pong, breakout or snake.

# Game engines: Unity

If you want to focus more on what's used in the industry, rather than something that's just approachable, download Unity: https://unity.com/

You can do this as the first step as well, though you will have to use C# for the most part (though you can get Lua plugins, IIRC). This engine also has a rich ecosystem around it, as well as lots of different assets/plugins in the store, some of which are free. Do be warned that it's somewhat fragmented in the recent years (URP/HDRP, DOTS, networking and UI) so some things might be a bit confusing and it can get problematic to work with when you're dealing with larger projects. I recall Brackeys making some nice videos a while back, though apparently there's no new content: https://www.youtube.com/@Brackeys/videos

# Game engines: Unreal

Alternatively, if you're comfortable with even more complexity and lower level languages, go for Unreal: https://www.unrealengine.com/en-US

Admittedly, on the programming side of things it also supports Blueprints (visual scripting), but you'll probably be working in C++ with it as well. It can feel more coherent than Unity, but can also be more challenging to work with and some suggest it's optimized towards particular types of games. That said, the graphics and LOD solutions are excellent, so it's an especially good choice if you want something visually striking (though Unity's HDRP can also look good with some work).

# Game engines: other

There's also the option of looking into lesser known engines like Stride for example https://www.stride3d.net/ but while many of them will be interesting, you can't really compete with the amount of resources about Unity, Unreal (and perhaps more recently Godot) out there.

There's also the option of trying to write your own engine, but at that point you're most likely no longer writing a game and might not ship anything at all. For an example of someone's gradual descent into insanity (joking, sort of), look at Randy: https://www.youtube.com/@bigrando420/videos

# Other software

As for supporting software, for modeling/texturing/animations you'll probably want something like Blender: https://www.blender.org/

For image editing, GIMP is free: https://www.gimp.org/

For drawing, consider Krita: https://krita.org/ or FireAlpaca: https://firealpaca.com/

For simple audio editing, Audacity is okay: https://www.audacityteam.org/

If you just want ready made game art, consider looking at OpenGameArt: https://opengameart.org/ or something like that, personally I think that Quaternius has some nice ones if you're not picky about the style: https://quaternius.com/ or there are occasionally compilations of free songs etc. on various Reddit communities I think.

For version control, you can get by with Git, but please consider Git LFS: https://git-lfs.com/

# Summary

All of this doesn't mean that you need to release your own game on Steam or Play Store or wherever, merely play around with the tech and familiarize yourself with the different aspects of it all, to figure out what you like or don't like.

If you do decide to release a game for whatever reason, tamper your expectations and don't be afraid of failure. Consider what the launch of Brigador was like, despite it being an arguably good game: https://www.youtube.com/watch?v=qUsuusNLxik

After three to twelve months of this, you should be able to figure out whether you want to make the career change or not. At that point you already have a CV with past work experience on the programming side of things, as well as a little portfolio of demo projects and such, then it becomes a matter of networking and such. Building out in the open is also an option.