The process for hiring a programmer is fairly standard, regardless of the programmer’s specialty (gameplay, graphics, network, engine, etc.). It usually goes something like this:

1. We get your resume somehow (either from your submission or a recruiter or something) and decide we think you have enough experience doing the work we need someone to do. Those who we think have sufficient experience get called back. Those who don’t do not. We usually only have enough interviewing/team bandwidth for so many candidates, so we typically pick who we think are the best of the batch and discard the rest. 

2. One of our recruiters/HR people calls you to see if you’re actually interested in the job and to ask a few basic questions - are you still looking for a job, your career goals, whether you’re willing to relocate, what kind of salary requirements you might have, etc. They’ll also answer your general questions about the job and working for the company if you have any. Not everybody wants to work for us - sometimes the job isn’t what they expected or they just have different career goals.

3. Assuming you want to move forward with the application, we usually then move on to the screening process. This is either a technical phone interview or a take-home programming test (sometimes timed) or both. The take-home test usually has some number of general programming and/or math questions and asks you to write some code. Our engineers will look over your test answers and judge them for correctness (whether your answer works), algorithmic complexity (whether your answer solves the problem quickly), and clarity (how easy it is to read and understand what your code is doing). 

The phone portion of this step is where you begin talking to actual devs who are on the team, typically senior or lead team members who are there to assess your skills. We usually ask two kinds of questions at this point - questions about things on your resume like why you made certain decisions and specific things you did, and short-answer technical questions to gauge your practical programming knowledge - data structures, algorithms, familiarity with concepts, and so on.

4. After passing the screening process, we move on to the face-to-face interview portion - typically the last step before we decide whether to extend a job offer. Usually this involves meeting with the team and the leadership. You will usually be asked technical questions but from more of an architectural perspective - to determine how you design systems and arrange data, rather than the smaller nitty gritty implementation details. This typically involves solving whiteboard problems while other engineers observe you and answer questions about the problem you might have. The problems here tend to be more open-ended in order to assess how you approach problems and think about them.

It’s worth noting that the testing process for (and therefore criteria for passing as) a junior programmer is much more forgiving than a mid-level or senior position. That is how we usually assess results - after everything is said and done, we estimate what experience level we think you are and whether we think you’re a good fit with the team. If you do well enough in step 4 to demonstrate you’ve got the skill set we expect and that you can communicate with our team, you usually get an informal job offer from the company within a day or two. This is where you get to negotiate things like salary, benefits, start date, etc. if you wish. If you tell us you’re interested, you’ll get a formalized offer letter to sign and return within 24-48 hours, and then you’ll start working for us on your start date.

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

I’m attending some meetings away from home base this week, so you’ll be getting a selection of reposts I like instead of new answers. I’ll be back next week. Cheers.

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

That's an excellent question. You may remember the term [Decision Paralysis] used before on this blog. It's when a decisionmaker is presented with so many choices that they refuse to make (or put off making) a choice out of fear of making a mistake. Decision Paralysis affects everyone, including game developers like me. We can get so wrapped up in finding the perfect solution that we never commit to any one, for fear of that's solution's drawbacks... even though any solution that we commit to will have drawbacks regardless. This lack of commitment has side effects down the line - because we can't commit to something, we're afraid of our work being wasted or thrown out so we won't commit our best effort to it.

As such, pressure like a deadline naturally pushes us towards what I've taken to calling decision commitment - when we are willing to lock down a choice and accept all the benefits and tradeoffs that choice entails, rather than continuing to circle the options and never commit. It is closely related to what Mark Darrah likes to call completion urgency - the pressure to finish what we're working on. Decision commitment is necessary to make actual progress. Without any pressure to commit to a decision, dev teams can (and do) burn indefinite amounts of dev time and resources going in circles and end up with very little to show for it. When we've got a hard deadline, we know we have to buckle down and commit. That pushes us to give our best because we know it won't be wasted.

Lack of (or late) decision commitment really hurts craftsmanship and quality because we aren't actually committing to what we're building. If we are always keeping the back door open to drop whatever it is we're working on and changing our minds on the direction we're going, it always feels like a potential waste to do our best work. The quickest way to burnout is to feel like your work doesn't matter and your effort was wasted. Why polish, optimize, and improve if we're going to go a different way next week and throw this work out? No one likes to feel that way, so we naturally hedge our efforts with the minimum viable effort if we aren't sure whether it will be used.

This is all a long-winded way of saying "Yes, I absolutely do better quality work when I'm under pressure. Since I am confident we're doing this thing, I can give it my all." Without the pressure to deliver, the back door is always open and it's extremely hard to commit to the decision and give my best. If I know that we're absolutely committing to what I'm working on, I will build the best feature and content that I can. I believe that many other devs share this feeling for similar reasons.

[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's a lot easier to get hired back (as a contractor or not) with a former employer with which you have a good and established relationship. The contractor already knows the dev team, already knows the kind of games they make, already has experience with the franchise, pipeline, tools, and workflow so there's very little ramp-up time. If the cost of contracting the leader's company for the work is reasonable and within the game's budget, there's little to be lost by hiring them on. This also helps establish legitimacy for the lead's contracting company - having a list of established and satisfied clients looks good to other potential clients, which makes it easier for the contracting company to get hired by other companies in the future.

Contracting at that level also pays a lot more than a salary job working for the studio. A lot of things are open for negotiation when it's company to company, including a percentage of the game's revenues. In many ways, it allows the contracting company to change the risk - reward ratio. The contractor can also take on more risk (e.g. less money paid up front) for more reward (a larger cut of the game revenue once it ships). Masahiro Sakurai of Sora Ltd. does this - he takes no money up front and gets paid entirely based on how well the game he contracted on sells.

[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

Voice acting has a lot of associated costs. Specifically, getting the voice acting requires us to pay for:

• The voice actor's time
• The recording studio time
• The voice director's time
• The developer time

These can add up - we pay union voice actors about $2000 per day each according to the current [SAG-AFTRA interactive media contract rates], and we spend at least that much for studio time. We also need to factor in the time the developers are away from the development studio and are at the recording studio because they aren't doing their normal tasks while taking care of this. It isn't uncommon for voice recording to cost over $10,000 per day, all things considered.

In addition to this, voice actors are often quite busy. They often have many roles already scheduled that they have committed to. This means that they might have only one or two days they can commit to recording, then be unavailable for months after that. In such cases, it means that we can't make any modifications or changes to the script after the recording is done because the voice actor isn't available to do those lines anymore. For example, take a look at [Aleks Le's IMDB page]. He did a lot of voicework for games like Persona 3 Reload, Street Fighter 6, Octopath Traveler 2, etc. I count 18 separate projects he recorded for in 2023 alone. If he's one of my voices, I probably wouldn't be able to get him back in the recording studio for several months since his schedule is so packed.

SWTOR is especially difficult to record for because player voice lines need to be recorded once for each character class. That means aligning eight different actors schedules before a hard deadline, and that can be extraordinarily difficult. Anyone who's tried to schedule events knows this - things happen, people change, agreements fall through, things get pushed back. As such, it's a small miracle they're able to keep putting out fresh voiced content like they do.

[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 think it entirely depends on how you view Early Access. The point of Early Access is to get additional funding from interested players to pay for the rest of the game's development. Without enough money earned during Early Access, the "full" game is not going to happen. When I worked on an Early Access game, we didn't earn enough from the players buying in to finance the remainder of development, so the game was delisted and we were all either let go or transferred to other game teams.

As such, I don't think it's unethical. The developers need the money to pay for the rest of the game's development. We are not pretending the game is "complete" and the players/customers know the game won't ever be "complete" if we don't secure enough money somehow. The full scope of the content is known at the time. The risks are known at the time. Players have all of the information they need to make a fully-informed purchasing decision. If you think that the risk of the game not making it is not worth spending for, you can choose not to spend.

[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

As with the vast majority of game design questions, the answer is "It depends". Imagine a game like Legend of Zelda: Link's Awakening. There are a significant number of items in the game and each one does something completely different. Each item has a specific ability, animations, effects, etc. associated with it, each would take a significantly longer amount of time to develop than a chestplate in World of Warcraft that gives +150 stamina and Strength.

The general rule is that the more that an item/ability/feature/etc. does, the longer it takes to build that item/ability/feature/etc. In a game where we expect players to go through lots of items, then we need to make lots of items for them to play with. Since we have a finite total amount of development time to spend, we need to spend relatively small amounts of time the average item we create. Not all items are created equal, either - we can churn out a bunch of the vendor trash items that players will use until something better comes along very quickly, and we reserve more of our dev time for the subset of "interesting" items like the ones that have special procs or abilities or whatever.

Design has some input on art for items but not a lot. The amount of time it takes to build art and VFX is significant, so item designers and artists are often given the same broad strokes for a batch of items (e.g. "This is a water dungeon, so think general water themes for your cool items") and we each do our work in parallel. Most of the time it works out, but sometimes we end up with some wires crossed at the end.

[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 think you have the wrong idea about what game designers do. We're not project leads that pitch entire games, we're [content creators] that build the bits of specific content in games - the spells, the monsters, the fights, the classes, the races, the quests, the environments, the stats, the companions, and so on. Your typical AAA dev team has hundreds of developers, including dozens (or even hundreds) of designers there to create the items, quests, abilities, enemies, fights, crafting recipes, and other content that players engage with.

There are times when studios will solicit pitches from the rank and file, but these are few and far between. Everybody from the oldest of the old to the newest of the new have their own game ideas that they want to get made. Only those who have amassed sufficient experience and influence with publishing executives are typically given this opportunity, often because anyone who leads a new game's development is being trusted with hundreds of thousands, if not millions, of dollars.

[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

Even if you can't show the game you worked on, you can still talk about the tasks you completed and the things you learned from your experience working there. Talking about what you did and how you'd improve the process given the chance to do it over again is the best way to convey your skills. We hiring managers will be able to recognize it when we see it. Game recognizes game.

There's a well-known cognitive phenomenon called the Dunning-Kruger Effect. It's most well-known for describing how people who are not good at a skill tend to vastly overestimate their own skill at that skill, but the converse is also true - because the ability to estimate one's skill is directly tied to the skill level itself, it means that those who are skilled are easily able to identify others who are also skilled. Talk about what you did, the tradeoffs and issues you had to consider, why you ultimately made the choice you did, and what you would consider doing differently if you had the option to do it again. It's really hard to fake that kind of experience in front of experts, even if you don't have a playable game to show for 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

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

In-game economies are entirely different beasts than real-world economies for one major reason - total currency is not zero-sum. In the real world, it is (mostly) zero-sum - individuals cannot create money out of nothing, so any amount of currency I spend is transferred to someone else and the total amount of currency in the system is preserved. No individual can buy real gold bars infinitely, they'll run out of money to buy the bars eventually and the price of the gold bars will increase as the cheaper sellers are bought out and remaining sellers raise prices. At the ultimate end, there is only so much gold on the planet, which means that even an individual with effectively-infinite money has an upper limit on the total amount of gold she can buy.

In most games, a player character can typically sell as many wombat testicles to the NPC vendor as she might have, creating new currency out of thin air for each testicle sold. There is no limit to the number of wombat testicles she can sell and there is no limit to the amount of currency the NPC can generate for her. Similarly, any currency spent on NPC vendor goods or services (e.g. training costs, equipment repair costs, resurrection costs, consumable costs, etc.) is completely removed from the system. This is called a "faucet to sink" design. The NPCs that generate currency are the "faucet" from which the money comes, and the NPCs that remove currency in exchange for goods and services are the "sink" in which the currency is removed from the system. When the faucet and the sink are generating/removing roughly the equivalent amount of currency from/to the system, the system is in balance. When the faucet outproduces the sink, more players have an ever-increasing amount of currency which is inflation - too much currency chasing too few goods. When the faucet underproduces the sink, we have deflation (which is much rarer) - too little currency chasing too many goods.

In order to reduce in-game inflation, the solution should be fairly obvious - the designers introduce new "sink" options to remove additional currency from the system. This usually takes the form of new consumables, gear options, or benefits from NPC vendors that cost a lot of currency to utilize. Since players will want these new benefits, they'll start spending more currency instead of hoarding and inflation will fall.

[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

Two jobs isn't really a positive - game dev can be taxing in terms of time and effort, so the main concern would be an employee that works a second job would be more exhausted and less able to complete her tasks. If that candidate can persuade the hiring manager that she'll be able to do the job we're hiring for and that her other job isn't directly competing with us (e.g. working for another game studio at the same time), then everything should be fine. If you've got a side hustle in an unrelated field (e.g. selling plushes on Etsy), it won't be held against you.

Any hiring manager will reasonably expect a candidate to quit her job at another game studio to come work for us if she accepts an employment offer. It's a pretty standard "No Moonlighting" clause in the employment contract.

[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

Steam could do that, but that would make it a much more strongly-curated platform similar to the game consoles. This would ultimately result in games that had a higher quality bar, but also a lot fewer games in general because there's no way to automate testing games like that. Further, it would also significantly raise the cost of publishing games due to needing workers to do the vetting and quality assurance - they would have to test every game that gets submitted to make sure they comply with Valve's theoretical regulations and either pass or fail those games. Paying for those costs would have to come from somewhere, either cutting into Steam's margins or raising Steam prices.

[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

Any company that wants to release a premium game console basically needs to make an enormous investment that will probably not pay off for years. There are three major requirements for this process.

First, the company must develop gaming hardware. This is generally an expensive process - building anything physical is costly, time-consuming, and is a moving target because competitors aren't stopping either. The hardware must be manufactured and factories equipped and set up for mass production.

Second, they must develop software development tools for both themselves and for external developers to use in order to build games for that console. This requires a significant internal development team to build drivers and software interfaces. Beyond this, they likely need to develop their own flagship game (or more) to launch with the console. That generally costs at least $50 million for a AAA-fidelity game and at least two years of lead time to build alongside the hardware development.

Third, they must secure investment from third party developers to build games for that console. Using that $50 million price tag for a game, we'd need at least four or five additional games to launch with in order to entice players to buy in - no one buys a game console without games to play on it. If they want four launch titles to go along with the console launch, that requires at least $200 million in investment from others.

There are only a handful of companies in the world that have the kind of money, technology, and resources needed to make such a thing happen and some of them already have game consoles. The others look at the market, at the cost of entry just to compete (not necessarily even to pull ahead), at the expected returns on investment, and it's no surprise they choose to invest their money in other opportunities that seem more likely to bear fruit.

[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

You're correct about how developers getting promoted or moving to other studios can affect things, but it goes further than that. Honestly, it is because whole teams and individual team members change over time. People age and grow, life priorities shift and move. Becoming a parent, for example, radically shifts a person's priorities. Any of the game's major decision-makers becoming a parent can drastically alter the direction of the game. The longer a game or franchise runs, the more difficult it becomes to maintain the singularity of vision.

If we hire somebody completely new to take over, we lose that singularity of vision because the new leader will bring a new perspective. Even if we hire longtime fans of the game to work on it, the ascended fans' decisions will emphasize what they liked about the game and de-emphasize what they didn't. This can take a game in a direction that portions of the playerbase dislike - the players who don't share the same likes as the ascended fan. Think of what would happen to the Dark Souls franchise if the new leader was only a fan of the difficult boss fight aspect and chose not to spend those resources on the ambience and world building aspect of the game.

To some extent, yes - developers and influential stakeholders will move around as part of their careers or lives. Developers will grow and change over time, they'll take new jobs, retire, have kids, and their lives and priorities will change. New decisionmakers will join the team and will have different visions for the franchise than their predecessors. Beyond this, even player tastes will grow, change, and evolve over time as well. The old stuff that was super popular before won't cut it again if there isn't anything new to offer. If the directional changes meet the collective players' (both new and returning) tastes, the franchise will continue to see success. If they don't satisfy, the franchise will struggle.

[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

If keeping the beat is the most important thing in the game, then you build the game around keeping the beat. There are many different ways to approach the problem, but if I were building such a system myself, I would start with a system to handle a data-driven beat (e.g. this level/song sets the beat to X, that level/song sets the beat to Y) and then build all of my visuals and gameplay on top of that. The key component to making this work would likely be an animation system that could scale animations faster or slower in order to match the timing of the music.

On the data side, this would mean all animations would be built so they could be sped up by dropping frames, or slowed down by holding certain frames for additional length. All animations would also need to be the same length (or a multiple of a standard length), so that I can ensure the animations will fit into a standard musical measure. If I wanted to have a variety of attack animations and hit reactions, I would probably also establish a set of rules that each attacking and hit reaction animation must always be the same number of frames. I could further standardize each attack and hit reaction active frame happening on the same frame each time.

The code side would then play my animations to those musical measures along the beat. It would do so by scaling the animations longer or shorter based on the beat. The system could add or cut animation frames so that each animation can play in sync with the music. Once I've got the animation system integrated with the beat-keeping system, I can then ensure each animation should start playing on the appropriate frame to keep the beat. As long as the animations are scaled to the musical measure and the music keeps the same beat for its entire duration, the animations should always sync to the beat of the music.

[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

While it's true that many game developers are tech savvy, there's more to IT than just keeping a workstation running. IT at game companies does the same thing that IT does at any tech company - they set up, maintain, and make decisions about tech solutions for an organization. That might mean choosing whether to use Discord or Slack, Jira or Trello, Zoom or Teams, and integrating all of the various elements into each other, like being able to launch Zoom from Slack, or integrating Slack bots to pull data from Jira to post it in the chat channel. They are also key in operational security by setting up software solutions for protecting against (and taking care of) viruses and malware.

Basically, having some experts to give direction helps free up the rest of us from having to think about IT and able to focus on our own work. We might be able to do some of this, but it's better to have it set up for us consistently across the studio than leaving us to each try our hand at countless inconsistent versions of the same workflow, especially since screwing it up could sacrifice a lot of productivity while the IT issues get ironed out.

[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

I don't think the emotion we feel is bitterness so much as it is a bit of sadness. Prices falling is normal and unavoidable. It is unlikely the games I worked on early in my career could be sold for anything today. I have mixed feelings about Steam sales in general.

I think there is a valid and growing concern among game developers that Steam sales are devaluing games as a whole. Instead of finding a great game at a bargain and appreciating it when playing it, Steam Sales have become this seasonal event where players buy a large number of games that they rarely play. The games we buy are just text lines in the library. There's even a pile-of-shame tracker that tells people how many unplayed games they have in their Steam libraries.

What I care about as a game dev is that players enjoy playing the games I worked on. I feel sad when I think about players who may boot the game up for a few minutes, give up, and throw the game away, never getting to see the work I put into it. I feel sad when I think about the amazing games I got to play that were so formative for my career, and how many players today would ignore them since they're old and cheap. I think that's the real tragedy of Steam sales and the like - if it doesn't cost you anything for a game, there's very little reason to invest yourself into it. We ultimately build games for players to enjoy. Steam sales perversely make it both easier for players to see my work and harder for them to actually enjoy 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

Production makes the final call on bug prioritization, but they take the advisement of the other departments under consideration while making those choices. You are correct that the bugs that stop people from working are the top priority. Below broken builds, live issues that allow players to exploit or grief others are often top priorities. Other than that, it's a jumble of completing the remaining tasks that need to be done for our next release (especially those that allow others to work) and fixing the bugs that come in. Things that are mission critical are more important than things that are good to have, which are more important than things that are nice to have, which are more important than wishlist items. These get ranked against bugs that ruin experiences, bugs that bother players but don't ruin experiences, bugs that are annoyances but not real bothers, and so on.

[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 is some truth to it, but it is a notably incomplete truth. It is true that new offerings are often nearer to the higher end of the power curve when released. This is by design, an underpowered new offering is easy for players to ignore and we don't waste resources making post-launch content nobody wants. We want players to keep playing the game and that's only going to happen if the content we add, both paid and free, is compelling.

This leads us to the rest of the truth I was talking about before - the actual goal of adding new content isn't making new stuff strictly stronger than older stuff, it's to offer a new and interesting way to play the game for our players. The new offering is never strictly a power boost over existing options. Instead, it generally fills a new niche or playstyle for players to explore. You can see this most clearly in competitive games where we add a new player character or class. Overtuned or not, new characters and classes always play notably differently than existing ones, thus appealing to different groups in the player base.

Any new offerings must offer enough new gameplay, player power, and appeal to interest and engage enough of our community. If the gameplay is amazing and the appeal is great but the offering is underpowered, nobody will be happy with the result. We try to avoid overtuning new offerings to the point that the new content invalidates other gameplay styles and pressures competitive players to switch since that hurts the overall community, but we also want to avoid undertuning new offerings to the point that no one cares about the new thing. Finding a healthy power band in which to launch new content is part of the goal.

[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

Recently, Katsuhiro Harada of Tekken fame posted a [lengthy tweet] where he talked about what happened to the Soul Calibur franchise, the team, and the less-visible effects of companies growth and change over time. Harada is a good guy and I very much appreciate his candor and willingness to talk to the public. His English tweets can be a little difficult to parse though, so I thought I would offer my interpretation of what he said, based on my own understanding of game dev, the industry overall, corporate politics, and economic trends.

The [initial comment] Harada responded to was “Soul Calibur needs a director as loyal as Harada. You can see this via the game mechanics that came and went in the Soul Calibur games”. Harada responded by pointing out that there are many games with great mechanics that didn’t survive the test of time. Game mechanics aren’t really what make or break a franchise like Soul Calibur or Tekken. A lot of great games and franchises were unable to make the transition from earning their keep one coin at a time in arcades to providing sufficient value to players to buy a high-priced game for home use.

Soul Calibur did not have this problem - Harada saw firsthand that they made a strong transition from arcade revenue to home consoles. Soul Calibur had a strong leader named Yotoriyama (who also worked before with Harada on Tekken, and Harada on Soul Calibur). The Soul and Tekken teams established a strong rivalry in the early days of the polygon game era. While the Tekken team were known as an argumentative bunch of renegades, the Soul team was highly regarded as elite, the best of the best at the time.

In Harada’s opinion, it is actually strong leadership and clarity of vision that maintain a franchise. Many franchises have died because key leaders have left for whatever reason. Yotoriyama was exactly the kind of director that the original tweet was talking about - the team was focused, driven, and producing great results. Tekken was the top earner in the arcades, but the Soul Calibur was outperforming Tekken on the home consoles. Unfortunately, the corporate landscape changed as the company grew and is what eventually and inadvertently killed Soul Calibur.

As companies grow, the focus of the top leadership shifts from “make great games” to “manage the organization efficiently”. This basically means that endgame game developer career paths eventually evolve away from “making great game content and features” into organization management positions. Greater emphasis was placed at the corporate level on broadening one’s skillset instead of mastery in a particular field. This also meant staying on a particular franchise for a long time was bad for each individual’s career. As member after member of the Project Soul team either left to broaden their skillset or was promoted out of developer roles into management, the core vision and direction of Project Soul weakened. Harada faced a similar situation with the Tekken team - he was promoted to being head of the Global Business Department, but it had little to do with game development. All of his reports were marketing people and not game devs.

Harada decided to go against orders and lead the Tekken team anyway, despite the orders from above, in large part because he believes that the fans of any game can only depend on a dev team that has the necessary drive and vision to deliver. Harada’s decision to go rogue was only really possible because the Tekken team was already full of renegades who weren’t willing to listen to the corporate management. This was the largest difference between the Soul and the Tekken teams. The Tekken team remained driven and focused on their core vision because they were unwilling to take orders from the corporate level, while the Soul team slowly had their drive and vision whittled away one team member at a time. Harada ended by saying he believes that there are still some who have the will to resurrect Project Soul, but they need uniting in order to make it happen.

[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

Some random dev kit trivia:

• Dev kits can’t play retail games at all.
• Dev kits have much bigger system specs because we have to be able to run debug builds. Debug builds are much less optimized because of all the debug information that’s kept in memory.
• Dev kit software can do a lot of things like simulate online and/or disc latency, handle remote network connections, record game screenshots/video and controller inputs, and profile resource usage.
• Current gen dev kits require you to provide Sony/Microsoft with a whitelisted IP address. They won’t work if you aren’t connecting to the dev network without a recognized IP address. This has caused a lot of problems due to everyone working from home. Before the PS4 gen, this wasn’t the case - we could take our dev kits home if we wanted (and the company let us).

• There’s the beefy (and expensive) dev kit, and then there’s the less beefy (and cheaper) test kit. Dev kits have more features and better hardware.
• There’s a separate developer’s version of PSN and Xbox Live networks. This is so we can do things like test network stuff, locale, achievements, etc. without them going live
• Most of the time, the company is very careful about dev kits because they cost a lot. I’ve had dev kits chained to my desk before.
• When we had family events at the office like Halloween trick-or-treating, we had to cover up all of our (still under NDA) dev kits so children and family members could not see them.
• The Xbone’s Developer Mode Activation does not actually turn your Xbone into a dev kit. It still has the retail hardware specs and it doesn’t have all of the features or access to the special dev network.
• Last gen dev kits are a lot cheaper than the newest ones. You can probably get a PS4 or Xbone dev kit for under $2000 now.

Cheers!

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

Somebody asked for trivia and/or pictures of dev kits, so I thought I would reblog this. I don't currently have a dev kit assigned by my current employer, so I reblogged my old post from a few years back with photos I took of my dev kits at my former office along with my stuffed baneling plush.

[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

Even in walking simulators, there's still the active element of moving around the environment and examining each item. The player retains agency in exploration games, even though there aren't too many other overt actions to take.

Consider a "walking simulator" like The Talos Principle. The actions that the player take include exploring environments, collecting puzzle pieces, avoiding obstacles, jamming obstacles, moving boxes, climbing boxes, using boxes to obstruct enemies, and that neat time recording feature. The Talos Principle primarily interweaves the exploration and narrative elements with puzzle solving.

Another "walking simulator" is The Stanley Parable. In it, there's really only exploring and interacting with the environment, but the presence of the narrator enables two major actions the player can take - obey or disobey the narrator and see the results. It is these decisions and actions that provide the engaging gameplay - the players get pulled in by seeing the results of their choices.

The important thing about the actions that the player chooses to undertake is that every action a player does must cause the game to react to that player's specific actions. Moving from point A to point B shows the player more of the world. Choosing to interact with a door means the door opens, revealing what was behind it. Allowing the player to jump should allow the player to reach places that would otherwise be unreachable without the jumping. The actions a player can take must be acknowledged and recognized by the game. This creates a sense of agency and ownership that places the player in the game world. The player experience changes from "Kratos pulled the head off of Helios" to "I pulled the head off of Helios". These active choices cause a sense of self-insertion that would otherwise not exist if everything just happened while the player passively watched the scene unfold.

[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

If we're developing a cross-platform game, we aim for the best performance we can squeeze out of our lead platform. If we're targeting PS5 as our lead SKU, that's 16 gigs of RAM, 8 cores at 3.5 GHz, and so on. We aim the majority of our dev time for that first and then we adjust up/down for the other platforms we're building for to stay within reasonable performance specs.

If the game is targeting PC exclusively or as the lead platform, I've seen two different general approaches. The first of these is the "enthusiast" approach where the team is purposely aiming for high visual fidelity and high spec machines as a selling point. Crysis is probably the ur-example of this approach, though it has somewhat fallen out of favor recently. This approach usually aims for near the top of the line when we're finishing up pre-production, which usually means it'll be targeting hardware specs about a year older than the latest by the time we launch. We can't really keep moving those goalposts because top of the line is always a moving target. Instead, we need a target set during production where we're doing the majority of asset creation, so we generally lock in our goal around the time pre-production ends and stick to it.

The second approach is the "broadest possible audience" approach where the target spec is good performance on the common spec at PC cafes in Asia, because that is the largest number of potential players. Blizzard was pretty famous for adopting this approach to their PC game development. By making the game able to run well on potato settings, we remove barriers to entry for as many players as we can. This generally means we can't put in as many pretty effects and visuals, but it also means we have a broader target audience.

[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

Sure, I can answer both.

1.) when making a game what’s the best place to start?

Always start with core gameplay. What will the player actually be doing? The player must be an active participant in whatever is happening in the game. If players are just going to sit and watch passively, they aren't playing a game at all - they're watching a show. What makes something a game is the active participation of one or more players to drive progress and make choices. In order to figure out how the player participates, you need to think about the various things the players will be doing and how those things are fun. A good rule of thumb is to list the actions as verbs. In a game like Call of Duty, the player verbs would be running, jumping, aiming, shooting, and throwing grenades. In a game like Street Fighter, the player verbs would be punching, kicking, jumping, blocking, crouching, throwing, walking, and performing special moves. Think about the actions player will be doing in your game and how you will build that out.

2.) most have their brand/developer names, but do you need one to publish games?

You don't absolutely need to have a separate brand or name to release a game - several solo devs have gone the route of full transparency. However, having a brand name does help to establish a separation of your work from you as a human being. That kind of association is pretty much permanent because the internet never forgets. Having the game, its community, and anything you post indelibly tied to any of your other public-facing actions on the internet (including personal social media posts) can be a double-edged sword. Having an intermediary name/entity be a shield can help a lot when you need it, and going 100% public is something that can't be taken back.

[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

Typically it takes more than one milestone for a publisher to decide to intervene. If the publisher believes that a project has gone off the rails there are two major options available. If they think the project is too far gone, they'll cancel the game and reallocate the workers, have a big layoff, or some combination of both.

If they believe the project is still salvageable, the usual process is to replace the team's leadership (or assign them a new boss) and send in their [rescue operators] to take up key team positions and try to save the project. The publisher's rescue team tends to be very experienced and very good at triage. They are there to take a hard look at what is currently going wrong and change the development trajectory to reaching minimum shippable status within the time given. This usually means replacement of the team's existing leadership because the project needs major directional change. The goal is no longer "make the best game you can", because that goal is now unreachable. Instead, the goal becomes "get the game to ship".

At this stage we don't have the resources to get new assets or significant code changes, so most of what we need to do is cobble things together that fit within the existing frameworks and work well enough to be a (mostly) complete and cohesive experience. Features and content that aren't up to snuff get cut or repurposed quite quickly here. Entire levels that are too far behind schedule to reach completion by the deadlines will be cut, set aside for potential DLC repurposing, or scrapped for parts/assets to be used elsewhere in the game.

Not all rescue operations are successful. I would say that one in ten or twenty rescue operations ship something pretty good. A good one third or so of rescue projects fail outright and get cancelled. The rest of the time, the project ships and then either get savaged by critics and/or players or get the 'mid' 7/10 game ratings that are so often quickly forgotten.

[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’s been a few days since the Dragon Age Veilguard gameplay video was released. I posted a challenge for aspiring developers to identify as many specific features and systems as they could spot. My expertise is in gameplay, so that’s where I will be focusing. Expertise on visuals like lighting, rendering, shaders, etc. should be directed elsewhere.

0:22 - In-Game Cinematic with moving cameras
0:30 - Seamless cinematic transfer to gameplay, quest tracking UI element, different walking speeds
0:36 - Interactable element with UI
0:43 - Camera movement - orbital motion, but likely not detachable
0:53 - Party member movement, including waiting for the player as part of an escort sequence
2:08 - Uninteractable NPC actors perform animations
2:13 - Scriptable terrain changes/destruction
2:18 - Scriptable interactions with multiple actors
2:29 - Uninterrupted conversations when transitioning from gameplay to in-game cinematic
2:39 - Context-specific traversal method with special traversal animation (balancing across a thin beam)
2:50 - Small sequence that is likely unloading the last area and loading in data for the next environment. Likely also locks players off from returning to the previous area.
3:22 - Conversation wheel with “personality” icons and paraphrased words
3:39 - Dynamic inventory in game cinematics, show player’s items
3:46 - Scripted Player equipment change during cinematic
4:04 - Quest variables (e.g. player background) result in different NPC response
4:27 - Combat UI including current target (four red dots), Combat log
4:30 - Player can jump
4:33 - UI Melee danger indicator for incoming attacks - silver for enemy attacking, gold for shortly impending damage
4:35 - Player can dash/dodge
4:39 - Event log - Items/Loot notification
4:42 - Shooting UI including hit/miss indicator (red reticle), time scaling, arrow charging (rounded purple bar above arrow count), arrow refill cooldown
5:03 - Some kind of special charge/jumping attack
5:09 - XP gain UI, Quest objective completion UI, Quest objective map indicator UI
5:12 - Auto sheath weapons
5:15 - Potion use/Health recovery
5:18 - Recover potions from the environment
5:40 - Quest objective indicator change on approach
5:49 - Ranged attack danger indicator
5:51 - Defensive action (player reflects damage back on ranged attacker)
6:06 - Enemies can be knocked off edges when fatal
6:10 - Destructible objects in combat, can be scripted
6:16 - Some kind of “special” dodge skill with VFX, likely a rogue class skill
6:51 - Second context-specific traversal method (sliding down a slope) also likely a second “can’t go back” type of lockoff
7:01 - Action/Command UI (party/self ability commands)
7:06 - Specific skill used, skill cooldown, enemy debuffed + UI (weakened), resource used (purple bar at bottom of screen)
7:07 - Quick use button mapping, likely for controller face buttons
7:09 - Resource bar refills on its own and on attack damage
10:47 - Different kinds of health bars (likely magical shield and armor)
11:59 - Boss UI with both magical shield and armor bars. Not sure what the number 4 there indicates
12:15 - Telegraphed danger zones projected onto the floor
12:22 - Quick recover timing event
14:45 - Conversation option for branching cinematic
14:51 - Follower approval UI event log
18:49 - Destructible object with health bar and UI highlighting

Each of these elements is something that would need to be designed and implemented by someone on the gameplay team working with UI, engineering, and art. See anything I missed? Which did you get?

[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

Valve is pretty notorious for being an industry unicorn doing their own thing. They're a privately held company, meaning they have no shareholders to answer to besides their own founders. They make money hand over fist because they own a major distribution platform that maintains a plurality of customers on PC, meaning that angry player feedback has significantly less effect on their bottom line. Valve is also notorious for allowing their developers to work on whatever they want to work on. In aggregate, these factors combine into a company whose devs can basically do whatever they want, without needing to be beholden to any external pressures to do this or that.

Many gamers mythologize this kind of "perfect game development environment" where the devs aren't beholden to shareholders or publishers or politics or whatever else. Well, this can also be a double-edged sword monkey's paw kind of situation as well. Such an environment also makes the devs not beholden to the players of their games either. They can choose whether they want to listen or not, and the TF2 players can choose to take their business elsewhere. The unfortunate truth is that Steam will continue to pay Valve's bills for the foreseeable future, which gives them license to ignore the TF2 players for as long as they want. Unless the players can somehow persuade enough of Valve's developers (and the right developers too - a character artist certainly isn't going to write bot detection code) to drop whatever they've chosen to work on and switch over to fixing TF2, it's probably not going to happen unless something major changes.

[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

Looks like they released the Dragon Age: Veilguard gameplay reveal today. Aspiring developers, here’s a homework assignment. Treat this as a video of a vertical slice. Make a list of the individual features and systems you observe working from the video. I’ll work my own list and post it on Friday. If you’re feeling confident, tag me and we’ll compare lists!

If you need an idea for what such a list might look like, read my [Vertical Slice Glossary Entry].

[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

The most common answer in all of game dev is always "it depends". Most game development falls along a spectrum with one extreme end being "well-oiled machine" (i.e. a project where almost everything is already well-established) and the opposing end being "no idea where they're going and holding on for dear life" (i.e. everything is new and vision/direction is constantly changing). Qualities like clarity of vision, team leadership, and total team experience will determine where on this spectrum each project falls.

If the development process is disciplined and things are proceeding to plan, the demos we show to the executives are not far removed from the final versions we release to the public because things are proceeding as expected. The better-established the game and its feature set, the easier it often is to develop. Franchise games like Madden, COD, or Assassin's Creed, or long-running games like World of Warcraft have a well-established formula, very experienced teams, and a deep tool chest that allow games and game content to be built very quickly and efficiently. They are well-oiled machines that don't often have to reinvent the wheel because they've been using and improving on that process for many years already. They know exactly what they are building and are very good at delivering it. Any demo they build to show off work in progress will be very close to what will be shown in the final version of the game. Very little work will need to be redone.

If development is troubled and the team is having difficulty hitting their goals and milestones on time for whatever various reasons, then the demos will reflect that. Most troubled development executive demos tend to be smoke and mirrors, with a lot of hacks and demo-exclusive assets that are held together by bubblegum and a prayer. These kind of demos can cause the team to enter into a death spiral because cobbling a bunch of hacks together for a demo actually puts the team even further behind schedule because we can't use those kind of hacks in real production. This means that these teams need to build almost everything twice (at least) - a hacky rushed way for the demo and then the "real" way. They constantly need to "catch up", but the hacks they put in place often cause instabilities and [technical debt] that must be addressed later on, which puts them further and further behind. This is commonly known as development hell.

These are, of course, the two extreme ends of a single spectrum. Most game development projects fall somewhere along that spectrum. More experienced and established franchises lean towards the "well-oiled machine" side because they've had all the bad practices beaten out of them over the years. Most new IP and experimental gameplay tends to lean more towards the wild-and-crazy side of the spectrum, because there are too many [unknown unknowns] on projects like that. If you ever find yourself repeatedly behind the 8-ball crunching to put together many demos in a row with lots of hacks, you may wish to consider parlaying the firefighting skills you've learned into a job elsewhere.

[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

Most of the time, it is because they have game ideas they want to make. Game developers tend to be driven by the need to create. I got into game development because I wanted to make my own game ideas into reality. Almost every developer I know had some variation of the same motivation - they wanted to make their own game ideas into reality as well. Everyone, from the freshest junior hire to the most experienced veteran, has their own game ideas that they want to make.

Unfortunately, the actual opportunities to your make your game ideas a reality are few and far between. Game ideas are cheap and plentiful; everyone has at least one and many of us have far more than just one. Building out and developing an idea, however, is expensive. It takes time, it takes money, it takes a lot of experienced and skilled people working very hard together in order to make it real. The cost (and therefore risk) of building a game is often so great that such opportunities are only offered to the most trusted of senior developers. The number of games that the biggest publishers put out each year is several orders of magnitude smaller than the publisher's number of game developer employees. Big publishers will employ thousands of developers and yet often put out fewer than two dozen new games in a year. The opportunities to even be allowed to pitch are typically reserved for a very select few.

So... if you aren't one of those "most trusted" developers to the publisher executives and still yearn to create your own game, what recourse do you have? If no one will give you the green light, you make your own green light - you take the risk on yourself (and maybe some trusted experienced game dev friends), persuade some external investors that you're trustworthy, and you try to build your idea out. That's often the reason for the creation of a new studio with a new game project.

That said, there are also other reasons for veterans to start a new studio (albeit usually without as much fanfare). Some studios start because their founders are skilled but tired of the individual crunch and the grind of working for huge corporations. Instead, they build their own studio and offer consulting/contracting services to their former overlords, getting in on some of the ownership while retaining their own freedom and company culture. These contractor studios often specialize in certain fields (e.g. [rescue operators], art asset creation, porting an existing game to a new platform, etc.) and function as squads of game dev mercenaries brought in to fill specific gaps in the development team of bigger projects.

Starting a new studio is generally an opportunity to do things the way you want them done. This can mean working on the game idea you want to make, setting the inclusivity policies you want to set, establishing a worker-owned collective like you want to establish, have the work-life balance you want to have, fostering the company culture you want to foster, and so on. It's an opportunity for a fresh start. I'm sure that you can see why grizzled veterans might see that as a risk worth taking.

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

askagamedev:

Welcome to Harder Than You Think, a series about things that seem fairly easy to an outsider but can rapidly spiral into extremely complicated or expensive behaviors. Today, we’ll be talking about ladders and how they can cause all sorts of weird bugs in a game.

Ladders are another common game feature that tend to cause all sorts of animation and game state problems. Unlike elevators, ladders do not require a complex state machine to govern. Most ladders only have one top and one bottom, without needing the player to exit the ladder in the middle somewhere. Ladders are often variable in length but not totally variable in length - you can’t have a ladder that’s shorter than the characters climbing on it or the animations wouldn’t work, but you can have a ladder that can be as tall as you want. 

Ladder interactions generally consist of three game states:

1. Mounting, when a character transitions from the standing state to the “On The Ladder” state. While in this state, player input is typically taken away from the player and a mounting transition animation occurs.
2. On The Ladder, when a character can loop through climbing up or down animation cycle to move. While in this state, player input is typically limited - players can only navigate up and down the ladder and may have limited ability to engage in combat or take damage.
3. Dismounting, when a character transitions from “On The Ladder” back to the standing state. Like the mounting state, player input is taken away here.

One of the big potential bug generators with any kind of game dev is when we take player control away from the player. In any edge case where that control is not restored to the player at some point, we have a soft lock. If the game state changes or there’s an unaccounted-for issue (e.g. the player is not flagged for invincibility while mounting or dismounting), an enemy that attacks and knocks the player out of the (dis)mounting animation or kills the player, player input must be explicitly returned or the player will probably soft lock. Further, all of these types of interruptions can cause animation issues as well - a character getting killed while on the ladder will likely require a specific “damaged or dying on a ladder” animation, which can start ballooning scope depending on additional factors like the direction of the damage source and type of damage. Some common solutions to these problems are making sure there is no combat near ladders or making the player immortal while on ladders. 

Ladders are also incredibly bug-prone if AI can use them. The ability to knock enemies off of ladders, for example, can make the AI look terrible and create invincible choke points in the level design. AI on ladders can cause weird interactions with other systems like if, for example, [the player starts a cinematic]. But the worst case scenario we see most often with AI on ladders is when a ladder traffic jam occurs and we have two entities who want to go in opposing directions on the ladder blocking each other. We could let them clip through each other, but that often looks hideous. If the player has more than one AI buddy, we often have to let the AI buddies teleport to the player in order to bypass these kind of potential traffic jam issues. 

As you may have surmised, ladders will also cause issues in a multiplayer environment. Many of the issues with AI also apply to other players. Further, there are potential griefing issues if players cannot clip through each other and decide to block off ladders physically. 

These are just a few of the potential issues that can show up due to the ingredients it takes to make a ladder. Each ladder is a blend of taking varying amounts of player control away and returning it, clipping and blocking issues, AI issues, level design issues, and potential bad interactions with many other game systems for a seemingly innocuous system. These are some reasons why making ladders work in a game is harder than you think.

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

askagamedev:

Welcome to Harder Than You Think, a series about things that seem fairly easy to an outsider but can rapidly spiral into extremely complicated or expensive behaviors. Today, we’ll be talking about elevators and how much of a rat’s nest they can be.

The first thing to note about elevators in video games is that many video game elevators are actually not actually elevators at all, but teleporters. When you walk up to the button and press it in game, it often gives you a list of floors you choose from. Upon choosing it, the screen fades to black, and then it fades back in with your character at the new floor. There may be a pause and some sound effect played, but there is no actual movement across space. The elevator is merely a facade for a teleportation button. I’ve heard these occasionally called Wonkavators because “ …elevators only go up. The Wonkavator goes up, down, sideways and every other which way you can think of going.” The teleporter allows designers to conveniently sidestep issues of making environments have to fit within a contiguous space, and instead magically join two discrete points, potentially within the same environment, just physically separated so that the teleporter is the only way between them.

One major reason for this is because non-teleporting elevators become an absolute nightmare in multi-user environments. Since there are potentially multiple people who could all try to use the elevator at the same time, we essentially have to construct an actual elevator with a queueing system where users at different floors request a pickup, and then users inside the elevator request floors to arrive. The elevator itself has to remember its movement direction, and all of the requested floors in each direction in order to decide which floor it needs to go to next. As a coding exercise, try writing an algorithm for common elevator behavior in a ten-floor building. It is no trivial task! One studio I know would use this as a programming test to see how well engineering candidates could parse the nuances of a complicated control scheme.

The vast majority of non-teleporting elevators in games are one of two types - they either only have two locations they can visit, or they will only cycle through their various destination heights over time without player input. This is because things start scaling out of hand if the elevator can reach multiple destinations from each source. In most cases, each elevator floor can (usually) reach every other elevator floor except the one it is currently on, which means you have a N(N-1) number of connections to set up. Two floors is only two connections, but connecting six floors requires 30 different combinations and ten floors will require 90. Moving elevators can also cause all sorts of weird physics problems because the character is no longer on solid ground. The elevator must move the characters smoothly, which has its own set of simulation and physics problems.

Finally… elevators are often not particularly engaging gameplay. In this situation, an elevator is the thing that moves players from point A to point B. The majority of the time players are not going to find anything interesting or compelling about interacting with an elevator. It’s often just a means of gating the player to keep them from reaching some other element of the game until a certain point, and these kinds of gates should probably not suck up a huge amount of your development resources when they could much more easily be spent on the content and systems actually meant to be engaging. It’s hard to make an actual elevator fun. Most of the things we can do to make elevators more engaging involves gameplay elements other than the elevator itself, which still requires a reasonably significant amount of complexity. This is why elevators tend to be extremely simple and basic in games.

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

Sure. When designing a puzzle, a designer must think of the process by which the player interacts with them. Specifically, there are four steps:

1. The player sees and recognizes the puzzle goal
2. The player discovers the clues/objects needed to solve the goal
3. The player associates the relationship of the clues with the puzzle and each other and works out potential solutions
4. The player solves the puzzle with the proper solution

The designer must make it clear to the player what is happening and what to look for each step of the way. This means that the designer needs to clearly establish context for all four of the elements above. More specifically:

1. Show the player the goal - a locked door, a treasure chest, an object they want, etc. - but also clearly show that it is not immediately attainable.
2. Place and advertise the clues to the puzzle goal within the environment. This can be subtle or it can be obvious, depending on whether the puzzle is optional or part of the critical path. 
3. Provide a way for the player to experiment and learn how the clues interact and behave. This doesn’t have to mean that the player can make attempts until they succeed, but it does mean that they get enough tries with the puzzle to learn the rules.
4. Create a solution for the puzzle that isn’t too difficult or too easy for the challenge level the designer has chosen.

These are the basic elements that a designer must create in order to make a good puzzle. Missing one of these elements is a recipe for player frustration, and that is something we always want to avoid.

The second layer of designing a puzzle is deciding on the distribution. Puzzles have two primary elements to them - discovering the clues, then using clues to solve some sort of pattern. Some puzzles are 100% clue-finding, such as “find the key to unlock this door”. Some are 100% pattern-solving, such as the Tower of Hanoi. Many are a combination of the two - e.g. the player can play around with this pattern, but is missing a critical piece to finish it.

When designing the pattern, make sure that the pattern is clear and makes sense once all of the pieces are known. If the designer presents a pattern or set of rules to the player for a puzzle, it’s a promise that those rules will be followed. A good puzzle design will let the player make certain assumptions and have a way to test those assumptions. The solution should require some kind of non-obvious, lateral thinking that still satisfies the rules that the designer has set. If the solution breaks the rules or pattern, it will be extremely frustrating to the player.

A good designer will also use multiple solutions to the same puzzle judiciously. Under such circumstances, it’s important to communicate to the player that there are more than one solution and which solution each clue belongs to. Otherwise, the puzzle can cause frustration by making players think that they are missing something when they aren’t, like the nagging feeling one gets when there are leftover parts when building something. One good strategy in puzzle design, in my experience, is to provide a secondary optional bonus puzzle that uses the same rules as the puzzle on the critical path, but provides some additional content or reward to the player for completing it. 

Remember the fundamentals of puzzle design when constructing them. They might seem obvious, but it can be extremely easy to skimp or skip in the creation of one or more of those basic elements. It’s important to get playtesters who aren’t familiar with the puzzle to test it, especially noting any frustration points. Show the player the way first, point out the necessary elements to complete it, and then let the player make those connections and solve it.

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

• Spend money on paid DLC and microtransactions if they have any.
• Talk to your friends about the game
• Post about the game and any new content that comes out on social media.
• Engage with fan and official posts on social media.
• Leave a user review of the game.
• Draw and post fan art and/or fan fiction.
• Make and post cosplay.
• Play the game a lot

Basically, what every dev is looking for are players who will spend on the game and players who will continue to engage with the game content outside of the game itself. The more people the game can reach organically, the more likely they'll get more players, more paying players, and more overall success.

PS. Conversely, if you want to do your part to kill a game, just don't engage with it at all. Let it rot, pay it no mind, and don't engage with it even if you hate it. Hate posting is still engagement. The only way to win is not to play at all.

[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

When we're trying to craft an experience for the player, it's almost never one big element that sets the experience. Instead, it's the combination of many small details and decisions that all pull in the same direction and combine into a single, cohesive experience. For example, let's say we wanted to convey that the player's character is feeling dehydrated while walking through a 3D space. What could we do to make the player feel that sensation? We might...

• change the walk cycle so that the player is stumbling slowly instead of walking normally
• have ambient audio of the character with ragged breathing or panting
• have the environment be very parched - lots of brown colors. Place lots of rocks and sand, with any plant being withered or cracked with no leaves
• add a heat shimmer post-processing effect to the screen
• add a lens flare near the sun
• add specks of dust and sand to any wind effects on screen
• add a clothing shader to show sand/lightly colored dirt building up on the character's clothing

Now... in such a situation, what kind of bounding volumes would help convey this experience? Walking through the bottom of an empty ravine or canyon with high walls might do the trick. Walking across a narrow land bridge over a desert gorge could do as well. However, any water-related visuals would likely take away from the feeling of dehydration. Walking along the beach, even if it's a desert beach, just doesn't convey the same feeling as walking through a desert with sand as far as the eye can see.

Ultimately, all of the elements of environment art and level design are tools for us to craft the kind of experience we want. The choice of invisible wall, debris field, cliff, crate, railing, or whatever is up to the designers and artists trying to convey a specific experience. Each individual element only moves the needle a little bit, but having all of them together at once moves the needle a lot more.

[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

After being collectively yelled at on the forums for so long, I've developed a thick enough skin that none of the feedback really bothers me anymore. I don't get the emotional engagement with it much anymore. To me, there's really only two kinds of feedback - actionable and not.

If the feedback is actionable - if it's actually within the realm of possibility to do - then we'll consider it, figure out how much work it will take, prioritize it, and put it in the backlog to get worked on if/when we have time. Actionable feedback would be things like "Pastrylord doesn't feel very engaging to play", "The Buttery Doom ability feels overpowered", or "The Cappucino Plateau is a boring area". These are issues we can legitimately investigate and try to address.

If the feedback is not actionable, then we'll probably file it away somewhere. Some of this feedback is pretty obvious, but there's also some feedback that will never go anywhere. Trying to assign blame among the developers or our business partners for some shortcoming in the game, for example, is never actionable. Asking for a complete redesign of the game (or major game systems) is almost never actionable. Giving us unsolicited content ideas (e.g. posting a design a dungeon for the game you like) is not actionable for legal reasons. Realistically, little will actually come from this kind of feedback - we can't do it in the current game we're working on and we have plenty of our own ideas for things we want to do in other/future games. Never say never, but often say "probably not".

[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 developers in the trenches like me or my team, it's a fairly common occurrence that individual contributors will not be able to finish certain tasks by a given deadline. Sometimes the estimates and the actual work needed are nowhere near congruent, sometimes there are dependencies that took longer to work out than expected, sometimes there are unpredictable events like system outages or developers needing to take a medical leave of absence. In such situations, we adjust what we're delivering for this milestone and that task and any of its dependencies usually gets "punted" to the next milestone. Individual tasks can often shift back and forth without affecting the overall milestone too much.

It is actually possible for an entire milestone to slip as well - if the mission-critical deliverables for the milestone aren't done in time for whatever reason, the milestone isn't going to be accepted by the money people. Remember, the milestone schedule is originally pitched by the studio and agreed to by the publisher. It outlines exactly what the studio needs to deliver and demonstrate at each milestone and when each milestone should be there. Independent developer studios are often paid by the milestone, so missing or delaying a milestone delivery can mean that we don't get paid until we deliver.

When studios start missing milestones, the publisher often steps in to "meddle". Missing an entire milestone by a significant time frame is a big deal and often means the entire delivery schedule needs to be re-negotiated and re-planned. It's a sign of development hell and a project in a lot of trouble. From the publisher perspective, this is saving the project - things are already off the rails and need fixing or the entire project will need to be cancelled and the studio cut loose.

[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, there are only two requirements to avoid an acquisition:

1. The studio's controlling stakeholders/majority owners want the company to remain independent and do not want to cash out
2. The company remains financially stable enough not to need a bailout

If the studio ownership decides they want to retire or cash out, they will be open to opportunities to sell. This is usually something of an inevitability - we are human and life priorities change over time. Things might be good for a few years, but a life-changing experience like having children, the death of a loved one, or other life-altering events could easily change circumstances.

The vast majority of the time, it's because the company is already in dire financial straits and needs a bailout. If the company can't afford to keep things running, they'll either look for a bailout (typically in the form of acquisition) or they'll be forced to shut down and lay everybody off. If the company can't earn enough to pay its debts, employees, and overhead costs, it won't be in business for long.

That's really it. All acquisitions happen when either the first or the second requirement (or both) is no longer being met. Either the owners decide they want to sell or the company is in desperate need of money and must either sell or close. Many companies don't even get to secure a buyout, they often die because they can't find a buyer (or other new source of funding) and run out of money.

[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

They're not wrong in that building such things isn't free. However, you're also right in that we on the dev side should be thinking about better ways of doing this - there isn't only one solution to these problems. Whatever final solution we implement doesn't have to be the most expensive means of doing so. It's actually up to us to think of better/more efficient ways of doing the things we want to do. Adding accessibility options is often a worthy goal, not only to the players who need those options to be able to play, but also for general quality-of-life. If we're making changes after the fact, of course they're super expensive. If accessibility options are a production goal that we plan for, they're much cheaper because we don't have to redo work - we do it with accessibility in mind in the first place.

For example - let's say that we're working on UI and we have this system:

Let's say that we want to improve things for colorblind players. If we wanted to make this more accessible, instead of just using color to differentiate the choices, we could also add different border visuals to provide additional context.

In such a situation, the difference in choices is still obvious if you're colorblind and it helps legibility for non-colorblind players as well.

These kinds of UX changes can be expensive if we decide to do it after the fact, but if it's something we decide is important to us from the jump we can compensate for those costs by creating efficient and smart solutions early. Remember, the cost of any change in game development is directly proportional to how close that change is to shipping the game. The earlier the change is made, the cheaper it is. Furthermore, we make resource allocation choices based on our goals. If we want to make a game more accessible, we will figure out a way to do so that fits within our budget and provides a good player experience. Players don't really have a say in how we allocate our resources and that kind of armchair producer talk isn't particularly constructive anyway. Telling us what's important to you and why (including accessibility requests) is really the best kind of feedback we can hope for. Don't sweat coming up with the solutions or fretting about where we spend resources, that's our job.

[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

The good news is that the PS5 and the XSX aren't too far away from each other in terms of hardware power and architecture. Further, developing on XSX also mostly works out of the box with DirectX, which means it is easy to also get the game running on PC. It's relatively easy to build a game out of a generic system and task our engine programmers with getting that generic system working on each of our target platforms.

The difficulty in multiplatform development comes from trying to get the same generic system to run on drastically different hardware power profiles or architectural differences (commonly known as the Nintendo problem). If we have a game that assumes the player's hardware have at least 16GB of RAM and an 8-core 3.5GHz CPU and we suddenly have to fit that game into 4GB of RAM and a 1GHz 4-core CPU, we've got to make a lot of drastic changes in order to get the game running at all. I'm fond of saying that porting PS/Xbox games to Nintendo hardware is trying to get an entire Honda Accord to fit inside a Mini-Cooper.

The general rule when estimating the cost of making a change is how early during the process the change is made. The earlier in the process the change is made, the cheaper the cost of the change. Making a change to a movie before it's cast and shot is much easier and cheaper than making a change after the filming is complete. Making the decision for a project to go multiplatform from the jump means that the entire project will be built with maintaining multiplatform stability as a major goal. This means that further decisions will be made with that goal in mind - the team might spend those resources elsewhere instead of optimizing for certain platform-specific hardware features.

As for why Square-Enix decided to go platform exclusive with FF16 and the FF7 Remakes, it is likely that Sony offered them a seemingly-better deal. Most third party publishers get a standard deal with the platform - the platform takes a 30% cut of all of the game's revenue, the game must pass certification, the platform gets some kind of exclusive content for that version of the game, and so on. If the platform wants to get an exclusive, they offer a better deal than that - maybe Sony agrees to pay for some of the marketing of the game, maybe Sony takes a smaller cut of the revenue, maybe Sony waives the certification costs on the publisher's next five Playstation games, and so on and so forth. These concessions and incentives are certainly worth considering. Sometimes they work out well for the third party, like Insomniac's Spider-Man games. Sometimes they don't.

[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

Of course a studio can delay the launch, but a launch delay will have its own set of consequences. Remember, no game launches in a vacuum. Timing is the key factor.

The most obvious consequence goes back to the adage "Time is money". The developers working on the game need to pay rent and buy food. The studio needs to pay those developers during that time to keep them employed. Those costs don't go away when the game's launch is delayed - they will still accumulate. If the studio doesn't have the money they need to keep the lights on during that delay, it won't be able to make payroll for its employees or pay its bills/debt. In such a situation, a delay is impossible - the company will die without money from the game sales.

The second consequence is about the state of the gaming world over time. Imagine that we delay our game to dodge Hades 2. What happens after Hades 2? Will we need to dodge another big release? Will we need to dodge another competitor in our specific game genre? Will the market still be good for our game? Will the platform still be good? Remember, Facebook was a major gaming platform for years and then it wasn't. Imagine spending two years and millions of dollars to develop a major Facebook game only to have the platform die out from under you before launch. Things always change over time.

These two consequences feed into each other - every day we delay, more things change and new problems arise. Every day we delay, costs build up that we need to pay for somehow. Every day we delay release, our income on the game remains zero. At some point, the game will need to launch or the company will assuredly die.

[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