The shortest amount of downtime between projects I had was two weeks. We shipped the game, I took my comp time, and I came back and started on a new project. We weren't going at full speed yet - it was mostly just exploratory preproduction work for the new game - but it was still work. The longest amount of downtime was indefinite. The project finished, didn't sell well, and almost everybody got laid off as a result.

Normally what happens is that we get off-the-books comp time, usually some factor of how much time we crunched before launch, and then we come back for a few weeks/months of taking it easy, doing retrospectives, and brainstorming new ideas for what we want to do next, and then ramping back to a normal work week after that.

[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
• Frequent Questions: The FAQ

Many large studios have internship programs - I believe EA, Riot, Activision, Microsoft, Ubisoft, and Take Two all have internship programs. When we're thinking about what kind of tasks we assign interns, there are some constraints that we must consider:

1. Interns are entry level in terms of skill
2. Interns are limited in how much time they have to give to the project - a summer intern won't be around after the summer ends, a part-time intern will only be available a certain number of hours a week

Because of these constraints, interns are given tasks that their lead believes a junior dev could reasonably complete within the duration of their internship. These tasks must also be self-contained without significant outside dependencies - because it could take a long time for an intern to finish the task, there shouldn't be any major tasks that need the intern's task to finish before they can begin. Ideally, interns are given tasks that will be visible as part of the game they're working on but also won't hold up any other development on the same project.

For summer interns, that usually means working on some task or feature without any major dependencies that's doable at the entry level within two months or so. This is often translates to handling a small feature like making achievements, implementing a simple mini-game, or working on a combat ability. For full-time interns, it'll be normal junior dev tasks - e.g. build out this feature under another dev's supervision. It is rare for dev studios to hire part-time interns because it's really difficult to find tasks that both fit within our deliverable schedule and can be completed by an intern spending 10 or fewer hours per week.

[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
• Frequent Questions: The FAQ

It sounds a lot like you're dealing with burnout. One of the quickest recipes for burnout is putting all of the value on the results of the work rather than finding the work itself inherently rewarding - valuing the explicit reward instead of an implicit one. These two aren't always causal, which can result in this disjointed feeling and lack of motivation. Since you're not seeing any results from your work, it feels like a lot of wasted time and energy.

The quickest way to provide that explicit reward is to see players enjoying the results of your work. This doesn't have to be through a shipped game, it can be through your own personal projects as well. One of our Discord members enjoys posting his own personal playable game projects to our indie channel, where people can try them. These are not massively scoped games, but they are fun and the play testers do appreciate them. The feeling that your work is not wasted is important to getting validation that your efforts are worthwhile.

A longer-term solution to switch to implicit enjoyment of your work is to embrace a sense of detachment from the results of your work and focus on doing tasks that you enjoy doing for their own sake. I don't focus on what the results of my work will get me when I go into my job at all. I focus on the part of the work I find inherently rewarding and interesting - I treat my tasks like puzzles and I solve them. The feeling of solving a puzzle is rewarding and interesting to me on its own, I would feel good solving problems and puzzles all day long. The other stuff - the rewards for doing well at work and the promotions and whatever - are obviously important and there is some long-term meta-game strategy, but the day-to-day job satisfaction is entirely based on doing the things I find inherently engaging to begin with.

You might not find that to be the case (or even possible) in your current place of employment, or even in general. What is job satisfaction worth to you? Perhaps you could find a new employer that matches your needs better? It's difficult to say for sure. I also suggest talking to a therapist about this. Therapists are there to advocate for and provide context to you in the field of mental health. Pursuing a career that is more engaging is certainly a reasonable goal that a mental health professional should be able to assist with. A good mental health professional should certainly help you identify and work through the feelings of burnout you've expressed.

[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
• Frequent Questions: The FAQ

There seems to be a lot to unpack here. I'm reading several different elements that each warrants its own response. Here's what I'm seeing:

• You aren't feeling job satisfaction with what you do any more

This happens from time to time and likely needs some soul-searching to seriously answer. If you just want to provide for your family, there's nothing wrong with doing what is expected of you and no more. If you really don't like game dev anymore, you could always try finding a job in a game-adjacent field - simulation, gambling software, user experience, education and training software, and so on. Most technical problems are fairly fungible.

That said, sometimes all it takes is a reminder that there are players out there who really do appreciate what we do. I get a tremendous amount of job satisfaction seeing players enjoying the parts of the game I made.

• You're feeling some imposter syndrome in your current job

Imposter syndrome is very normal, especially for where you are in your career. It never really goes away, and it will always tell you that what you're doing is scary and that you can always give up and go back. If you're really concerned about your performance on the job, you should talk to your manager about it. Ask for a one-on-one and discuss it. If you're doing fine, your manager will tell you so. If you aren't, your manager will also tell you and likely suggest ways to improve. And, if you really want to take a more junior position, your manager should be able to help you transition to one of those too.

• You want a new job with less responsibility

There's nothing wrong with this per se, but accepting a demotion will probably take a toll on your long-term career. At the very least, it is likely that you will be asked about it at any job you apply for in the field, and you may get passed over for roles because the hiring managers consider you too senior for it. This may not matter to you but you should probably consider your long-term vs short-term goals and what it is you want to do with the rest of your career and life. If you've taken the time to consider the ramifications (especially with your family) and still feel like it is the best choice, by all means do it. I caution against making such a long-term decision hastily.

[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
• Frequent Questions: The FAQ

For those who haven't read it yet, here's my old post on a [typical day as a game designer]. When we're crunching, we just have a longer work day. Tasks don't really get more difficult or time-consuming when we're crunching; we still need to be able to complete each task in a reasonable time frame. Instead, during crunch the number of tasks we need to work through increases significantly, so the "identify the problem, iterate on solutions, try and test solutions, submit a fix" process just happens more often each day.

Normally, I can get called in to prioritize new tasks as they come in, get assigned a new task, or ask/get asked for help about an existing issue during the work day. During crunch, that time frame increases into the evening (e.g. late breaking bugs/issues) and sometimes into the wee hours of the morning. In addition, the bugs that must be fixed during crunch get a little weirder because not everyone is around or available at all times, so I would often fix bugs outside my area of expertise. There have been occasions where I got assigned a critical issue for the sole reason that I was still awake and at the office. That kind of trial-by-fire experience is what hiring managers are looking for when a job description asks for shipped games.

[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
• Frequent Questions: The FAQ

Honestly, I felt completely numb to it in both cases when it happened. That's because the game getting cancelled meant that the team was also getting laid off so I immediately had to go into survival mode. At the time, I shoved all of those feelings about never seeing my work into a tightly-sealed jar to process later once I had secured my own survival. Most of the things I learned from those layoffs (and subsequent layoffs) have been crystallized into my [Gamer's Primer to Practically Dealing with Job Loss]. I didn't have any time to mourn for my lost work because I was too busy trying to secure my own living situation. I did process eventually get around to processing it, but by then it was much later and the scar tissue had already grown.

[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
• Frequent Questions: The FAQ

Over the course of my career, I've worked crunch hours (10+ hours a day) on at least ten separate games, two of which never shipped. I worked weekends on nine of them. Some crunch periods were intermittent (crunching near the end of milestones to make the deadline) and others were ongoing due to overly ambitious schedules and constantly-moving goalposts. Crunch period length was determined primarily by the project - some were short (shortest: two week crunch periods and not more than four weeks total over the entire year) and some were long (longest: eight months of sequential crunch leading up to launch).

I like Mark Darrah's perspective on this - crunch often brings completion urgency, which is the feeling that the team must make final decisions and commit to them, rather than second-guessing and redoing work or just not deciding. Significant amounts of work are gated by committing to large decisions - and crunch is one of those things that tends to force commitment. The longer major decisions go without commitment, the more work piles up on the other side of the decision commitment, thus often necessitating crunch to finish. Looking back on all of the games I've worked on, the projects that committed to the big decisions early were the ones that had the least issues with crunch.

[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
• Frequent Questions: The FAQ

How do they find that many bugs? Consider - in AAA games, we bring on entire teams of QA to test every day during production. Imagine 50 testers each find only five bugs a day from a full eight hours of testing. That's logging a combined 250 bugs daily. In a week, you've got 1,250 bugs. After a month, that's 5,000 bugs. A year would be 60,000 bugs. Most testers can find more than five in a day, especially early in development.

To give you an idea of what things are like in the trenches, take my example. Two days ago, I personally fixed bug number 522,096 on my current project. I'm currently working on bug number 474,991. These are not randomly generated numbers. When I joined the team (roughly two years ago) I started working on bugs and tasks numbered in the mid 30,000s. QA finds and logs a lot of bugs.

[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
• Frequent Questions: The FAQ

From an individual worker's perspective, I think that most of the people who were let go (~70-75% or so) will find new jobs in the industry within the next year or so. There are definitely studios that are still hiring if my inbox is to be believed. I still get plenty of cold call recruiter emails from both independent and well-known AAA studios, so I think there are still openings for people. I think some folks (~20%) will churn out of the game industry and quit for greener pastures. This is also normal, lots of people realize there just isn't a professional career for them in game dev and either go hobbyist or find something adjacent that pays a lot better.

Thinking about things from a corporate perspective, I think that we'll see things continue to grow, but much more slowly than before. The big game publishers (EA, Microsoft, Sony, Square-Enix, Nintendo, Take Two, etc.) are still larger today than they were was in 2020 even after factoring in all of the layoffs from 2023 and 2024 (so far). I don't think that the industry will get smaller - there's more to the game industry than AAA games after all. I think that there's going to be a bunch of indie studios get founded in the wake of the layoffs. I think AAA games will grow more slowly for a while as the big companies circle the wagons and focus on the safer bets.

[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
• Frequent Questions: The FAQ

There are certain things that studios and companies can ask us not to do but have a real hard time preventing, especially if the company is going through a death spiral process. Keeping a personal copy of stuff I worked on, especially in an age of remote work, is one of those really hard-to-prevent things. If the company or studio is going under, almost everyone is losing their jobs and the motivation to maintain operational security is very low. Nobody in security cares when their main priority suddenly shifts to finding a new job. In these situations, leaked stuff happens a lot more often since there's little motivation for enforcement.

It's much harder for workers who are let go from a company that remains alive, since breaking NDA would result in being liable for a bunch of damages. However, if I don't disclose anything and just keep stuff private, the studio cares a lot less about whether I have those files. They don't really do much forensic analysis of the workstations of former employees, they mostly just wipe them clean in order to protect the company from potential liabilities from accidentally finding left-behind personal files of the former workers.

The thing about old game projects (especially for cancelled games) is that there's really only so long that the old stuff is even viable. The inevitable passing of time will decay any knowledge of the project and its workflow. If we release information and development stuff about games that were cancelled, say, two console generations ago, it is unlikely that the current IP holders and leadership would be super angry about it because so much time has passed. This is considerably different from releasing information about a game that was cancelled this year, where things are still raw and legal action is still a very legitimate threat.

The main benefit to holding on to old projects is primarily for personal education. There's a lot to be learned if one can go back and study the way things worked on an old project. How did they set things up and why? How can I learn what decisions my seniors and leads made, and why did they make those decisions? How did they solve these problems? Can I use those same techniques? There might be some element of internet influencer points if old stuff gets released to the public, but that typically gets glossed over the way trivia is treated. In my opinion, the real value in old project assets is in the educational content it can provide.

[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
• Frequent Questions: The FAQ

You're talking about downtime. Whenever I have downtime I try to be productive if I can, but the type of downtime determines what I can do. There's two main types of downtime - when my workstation is still usable and when it isn't.

If my workstation is still usable (e.g. the build is broken but I can still look at code/script/assets/etc.) then I notify my team that I've got some bandwidth and downtime to help out as a second set of eyes on any tasks my team might need help with. I can do code, design, or asset reviews for teammates and I can look over the various Slack discussions on other in-progress bug fixes and features to comment if I feel like I can contribute something helpful. I might not be able to run the game to test or validate anything, but I can still contribute my skill and knowledge to others who aren't having downtime.

If my workstation is unusable (e.g. all system resources are dedicated to building the game, building assets, compiling a level/lighting/etc., network or VPN down, etc.) then I really can't do much. I can't do reviews or join those conversations. In those situations I've traditionally done things to pass the time like listen to music or a podcast, scroll through social media, or think about what to write next on the blog. More recently, I've been focusing on leaning away from the social media scrolling and being more mindful so I have been taking the opportunity for mental and emotional "digestion" by not focusing on anything external and allowing my mind to process the normal emotional experiences in my life. It was difficult to start, but has definitely helped with my focus and my attention since I've started doing it.

[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
• Frequent Questions: The FAQ

I've actually worked on and shipped more than one annual sports title over my career and I want say for the record that the idea that annual sports titles are "mostly minor tweaks and roster changes" is absolutely and categorically false. Annual sports titles absolutely do not have the same scope as AAA games with multi-year dev cycles, but they do absolutely have significant breadth and depth of scope each year beyond "minor tweaks and roster changes".

The majority changes that occur each year are spread out because they must be - there simply isn't enough development time within the ~11ish calendar months between launches to rebuild everything, so decisions must be made about what gets added/updated this year and what waits for next year. That means that, besides roster updates and minor tweaks, this year we're committing to change our animation system, these eight specific stadiums/arenas, these three game modes, update the commentary system, and rework the stat simulation. Next year, we're committing to these other eight stadiums/arenas, these other four game modes, the physics system, the VFX system, and the AI logic. This sort of round-robin approach is necessary - the dev team often isn't large enough to sustain working on everything each cycle so we need to pick and choose what we can do each year within the time we have. It also means that players who only engage with some of the game likely don't necessarily see (or notice) all of the changes we make each time around. This doesn't mean that we didn't do it or that the changes aren't there, but it can certainly look like not much has changed if the player isn't playing those parts of the game.

To your main question - The primary reason that annual sports games haven't transitioned to a live service model is because of inertia. There is a well-established and financially sustainable annual sales model that works. There would need to be a significant and tangible gain to be had by switching to a live service model other than novelty - all of the current existing tools and systems are built with the expectation of delivering a new retail game each year, and all of the dev experience built up is for delivering a new retail game each year. Switching over to an ongoing service would come at tremendous cost. There must be a gain to outweigh that cost in order for the publishers to do it.

[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
• Frequent Questions: The FAQ