I put some thought into this and I really didn't like the conclusion I had to draw from the evidence. AI is fairly even across the board in what it does - as I said before, AI is like a super confident, super fast junior developer that is often wrong in ways that can only be detected by someone with significant experienced in that field. Since we depend on junior developers leveling up to become seniors with that experience, the fields that are the most at risk overall are most likely the fields that are rare and hard to fill. Specifically, I mean the junior "unicorn" roles like technical artist, VFX artist, graphics programmer, audio programmer, etc. are the ones in the most danger.

Studios can turn to AI as the "backup" if they can't find a candidate for those roles. They're already difficult enough to hire for, but with AI being a low-hanging kinda-ok alternative and without enough senior talent out there to keep the AI honest, I think we're looking at a significant loss in dev diversity for the next generation.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

The onboarding process is a little of everything you say. Whenever I start a new job, there's the new hire administrative tasks I need to get done like signing paperwork and doing harassment/DEI/office safety training and there's the actual "this is what they hired me to do" learning process where I learn how the workflow works so that I can start being productive. We'll ignore the administrative stuff and focus on the productivity onboarding.

The first thing that any new hire has to do is get the project synced to the latest safe build and get the game running. Without being able to run the game, we can't make or test any of the changes we will inevitably need to make. This often entails fiddling with a bunch of workstation and network settings in order to make sure all of the files are where the game expects them to be, all of the necessary software is installed and ready, and so on. Getting an in-development game running can take quite some time (I've seen whole days lost in some cases) given how much disk space these games can take (and therefore how long it takes to download all of those files from the depot) and how complex the workflow can be.

Once the new hire has the game up and running and has familiarized herself with the game's controls and such, it's time to start reading documentation for the internal tools and workflow - how the content is made, how the work is done, what the working process is, how to check your work, who to contact in case of questions. At this point, the lead usually assigns an introductory task or two to the new hire - a small task for her to get her feet wet and to provide some guidance while looking through the system and making some actual changes.

After this initial process of learning > making changes > testing > submitting the fix, the process repeats with newer and more complicated tasks as the new hire's lead deals out new assignments. As the new hire completes more tasks, she learns more about the tools, the workflow, and the team. That knowledge and experience is then considered when increasing the scope of her tasks until she's reached the level of productivity expected of a dev in her role.

If you think this sounds a lot like the [minimum competency for joining a team] post from a while back that I wrote, you're absolutely right. We use this exact process to bring a new hire onto our team because it's the same goal - we have someone who (we hope) is dedicated to working on the game and helping us carry it to completion.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

While most game devs do play games in some form or other, there are plenty of developers who are much more casual in the kind of games they play, and some who don't play any at all. The ones who don't play are usually the ones who are further removed from the gameplay aspects - network engineers are concerned about the flow of data over the network, graphics engineers focus on the renderer and the frame rate, security experts focus on operational security, UI artists create icons and buttons, sound designers create and mix sound effects, visual effects artists create visual effects, texture artists create skins for in-game models, prop artists create in-game objects to make environments feel alive, and so on and so forth.

These experts aren't focusing directly on making interactable elements for the player to play with, they're focusing on the kind of technical challenges that must be solved in order for the game to function and the interstitial building blocks needed to make the game. A graphics programmer might not play a lot of games, but we're not paying her for her gaming knowledge - we're paying her to improve the game's frame rate and rendering capabilities. A server programmer makes sure that the data is stored and recalled correctly between the player's sessions.

Large game dev teams are full of experts in specific fields. Our fields of expertise might be more player-facing, where having a depth and breadth of experience playing games helps a lot. But not all fields are player-facing - some are more technical, some are more artistic, so the additional context of playing a lot of games isn't as helpful.

PS. Community Managers tend to be very well-versed in games (especially the game they are managing the community for). Their job is to convey the players' feedback to the dev team, so knowing the context around that feedback is incredibly important. Knowing the game and its details are very valuable for community managers.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

When we finish preproduction and move into production, we've essentially finished figuring out the bones of the game. We've got the outline for what we want to do, and the remaining task is filling in the gaps, putting flesh on the bones, and coloring in the blank spaces. These tasks, large and small, usually require additional help in order to finish. The leadership figures out how much work needs to be done to finish the game out, how much the team as it currently stands can do, and the difference represents how many additional people we will need to hire in order to finish the project.

The specifics determine the kind of roles we need to hire - the cinematics team might need several animators, the quest team might need two narrative designers and a gameplay engineer, the item art team might need a VFX artist and a technical artist, and so on and so forth. The needs of the project determine what kind of roles we need to fill. These requests then get sent up to the executive level for approval - they want to make sure the team isn't going to break the game's budget.

Once the openings are established and approved, it's up to the recruiting team to find candidates to fill the open positions. Usually this is a combination of recruiting events, reaching out to candidates on social media, posting to job boards, crawling LinkedIn networks, hiring external headhunters/staffing agencies, and collecting referrals from current employees. From there, the recruiters collect and vet candidate resumes. The recruiters then set up calls with promising candidates to gauge their interest in potential employment, answer basic questions that the candidate might have, and (assuming that the candidate wishes to proceed) [start the candidate process]. From there, depending on the availability and impressiveness of candidates, we start hiring developers and bringing them up to speed on how the work is done.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

This is a real potential rabbit hole of a topic, so I have enlisted longtime QA expert and manager [KynetykKnows] for his expertise on the topic. I have my own thoughts on the matter, but I think that firsthand experience is better than second. His answer is as follows:

The first thing to realize is that no two QA departments (particularly in gaming) are going to be exactly the same. The bulk of testing is, by its nature, a reactive discipline that comes in at the end of the development pipeline - you can't test something that isn't built yet. That means the testing has to accommodate whatever the needs of that project/pipeline/team/company happen to be. As a result, there are a range of different approaches from deeply integrated white box test engineers to no internal QA at all relying on third parties to black box test with limited direction.

Most places aren't going to have all white box testing. This would incur more cost than would make sense for a lot of teams. It's much more difficult to find candidates that fit the requirements, the candidates would cost more to hire, and so on. Much more often you'll have teams built of black box testers. This alone doesn't necessarily result in a horror show. In fact, if a tester has technical savvy and initiative, they can often get into grey box testing and possibly full white box testing on their own. The team wouldn't be built around this, but it can still be a value add for the team.

The horror show element of this has more to do with the respect that QA gets at the studio. If the studio holds respect for QA, then everything is fine. If QA isn't respected (i.e. is treated as an unskilled position that you just need a warm body for), you'll wind up with toxic, exploitative environments. QA can be an entry level position, but it isn't an unskilled position. QA skills aren't something you can easily demonstrate with education or experience alone. If team leaders don't understand that distinction, it is an avenue for toxicity to creep in.

In my experience the smaller the team the more thinly everyone is spread and the more valuable additional skills on each dev become. The team hiring also has to take the team structure into account and scale can impact that. For example, imagine QA finds a serious bug but can't find solid repro steps. It's happened more than once on different hardware on a couple of different builds so it's clearly not some fluke. If the team has 100 engineers, QA can present all the info available and say "Here, you figure it out, we're here if you need more" and move on. Engineering probably has enough resources to continue the investigation without needing or providing further context. On the other hand if a team has 3 engineers and 1 QA, then in that context it can make more sense for the engineer to show the tester the code and maybe the tester can figure it out. With this in mind, a small team may put a premium on finding the most skilled candidate available to do whatever might be needed, whereas a large team may not have the luxury to be so demanding and needs to maintain a higher head count. Notice how this comes back to unskilled vs entry level.

As for personal preference, the first thing I should point out is that I've been around long enough that a dismissive attitude to QA doesn't survive me. I'm either not going to work at a place that does that, prove that it isn't true, or (if coming in on the ground floor) establish that this isn't how QA is to be treated. In general, I think it makes sense for not to require engineering skills for QA. There's a lot of good testing skill talent that you will cut off if you require enough technical skill for full white box testing. Furthermore, there may be a conflicting mentality. QA is out to test, break, and point out problems, not to fix them. I don't trust when an engineer says "this should be fine". If a tester has put in a code change, then I'd want a DIFFERENT tester to review the change. There's a reason authors need editors. But that's just my perspective, and to go back to the top, this all has to run in the service of needs of the specific needs of the engineering team, the project, and the company as a whole.

Many thanks to KynetykKnows for his thorough and in-depth answer. 

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

The larger the team, the smaller the overall responsibility each developer becomes. This is largely due to the size and scope of the game and the limited ability for humans to keep things in their heads. Further, we’re usually divided by discipline. A texture artist would know a lot more about the game’s art assets than they do game system constraints. Gameplay programmers know about the game system rules, but not necessarily each individual quest. Leads have a broader view of things, but that comes at the cost of specificity. A lead designer will likely know how all of the major quest themes and zones work together, but will probably not know the idiosyncrasies of each individual quest.

The devs who know the most details about the game as a whole are actually the devs who interact with those details most often - QA. Since QA is all about examining and testing the game, they have the most insight on the ins and outs of the user-facing game. They might not know how it works under the hood, but they know every single facet of the game as players would interact with it. This should come as no surprise, they spend the majority of their time testing the game and seeing all of the content and systems in action. Compare this to, say, a technical artist who’s job is to create shaders for the game and there’s a stark difference in responsibilities. The tech artist would be the foremost expert on all shaders since she spends 40+ hours a week working on those shaders, but probably wouldn’t have nearly as much insight into the rest of the game.

The type of game matters a lot as well. For example, even though the team sizes for Uncharted 4 and Spider-Man (PS4) are within the same ballpark, it is much easier for a single dev to know all of the ins and outs of an Uncharted game than Spider-Man simply because of the scope of game content (linear narrative vs open world). The more content overall there is, the harder it becomes to know everything. Imagine trying to know everything about World of Warcraft, for example. That’s a staggering endeavor.

And yes - we devs (particularly specialists like the tech artist I mentioned above) are often unaware of the big things in the game happening outside of our individual work areas. Not because we’re not allowed to, but because we just don’t have the spare time. Design tends to be better informed on what’s going on than art or engineering, but I’ve personally been in a situation where I was completely unaware of major storyline changes that were happening because I was just too busy crunching on new combat system related content. 

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

What you really need for organization is a way to keep all of the project files in order so that you don’t accidentally break the project by accident, and then you need a way to keep all of the future work you need to do so you don’t accidentally waste time or forget to do something important. 

The first thing you really need is a revision control system. It’s a piece of software that manages and stores different versions of relevant files in the project. This way you have backups of each file that you can revert back to if something breaks. It also means that the team members can look at the differences between files to see what changes were made by whom over time, in case the project was working yesterday and became broken today. Keeping everything stable and everyone working from a common set of file versions is imperative for managing a project. One of the more common and inexpensive options is Github - it allows people to share code and assets over the internet. They even have a Unity plugin and setup for Unity projects.

The second thing you need is a task management system. This is a way of visibly splitting work up into discrete tasks and subtasks, tracking task progress, prioritizing tasks, and letting your team see who is responsible for which task. For example, if you wanted to add a Level Up system to your game, you’d need to break it into different parts. There’s the UI elements to display relevant information when you level up, a system that manages how much XP each character has, the formula that determines how much experience is needed to level, the defined rewards you get at each level up, and so on. Not all of these tasks need to be completed by the same person; if you have multiple developers, it is very possible to divvy the tasks up between them so that they can work concurrently. Creating, tracking, marking, and verifying tasks is an important organizational aspect of any project - so much so that we have an entire career path in the industry dedicated to doing it for teams. We usually call them producers. Many studios use software solutions like JIRA for handling this sort of work, but you can also use a spreadsheet or even a text document. 

Since we can’t read each others’ minds, much of project management is making communication between team members easier and assisting team members with remembering what they need to know. Most teams need this help for their files and for their tasks. These kind of tasks require a significant amount of time spent to keep on top of them but it is far better to spend the time planning than fixing a broken project, dealing with wasted work, or realizing that the work that has been done can’t be used.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr