Ask a Game Dev

Sorry, no. Most of the bullying about nerdy interests went away after I became an adult. As an adult, I realized that I got to choose who I spent my time with and, most of the time, I didn't have to choose to be with people who I didn't want to be with. I learned to keep it civil in the workplace because I wanted to do well in my career, but even then my work environment tended to be filled with fairly nerdy people in general because I make video games for a living. There's a lot of really deep cut nerds at my office and we're all invested in keeping the workplace welcoming enough for us all to do our jobs with reasonably good morale at the very minimum.

If you're in a situation where you're being mistreated because of things you like and you can't exit, then your best option is to endure it. It won't last forever, I promise. Once you're able to choose what stays in your environment, you won't have to worry about it any 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

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

The interesting thing about design challenges is that we can still make damage over time work for the player in a way that is both intuitive and skill-testing if we're clever about embracing the constraints. Damage Over Time is not good for a direct toe-to-toe fight for the reasons I discussed before, but it does excel at one thing - continuing to deal damage when the attacker isn't there anymore. In the case of a Real-Time Strategy game, damage over time becomes compelling if it were utilized by a unit that could attack and apply the DOT to multiple enemy targets while moving. Thus, the unit would fill a well-established RTS role in a way that allows the DOT to shine - hit and run/harassment.

Imagining a fantasy setting, you could have a dragon unit that flies over an area and strafes the ground with flame. Enemy units in the flame would be ignited, causing DOT that continues to burn even after the dragons have left the area. For more fun (e.g. a potential upgrade path), you could allow the dragon fire to leave hazards on the ground or allow the ignited units to ignite other nearby flammable units too. In a game where a role exists for units that don't need to stay for the whole fight to be useful, damage over time makes a lot more sense.

We can lean into this concept in other kinds of games. If state is maintained over multiple encounters with the same enemy, applying damage over time so it may continue even in the player's absence can make it a compelling player choice. Consider a game like Monster Hunter. The MH monsters have significantly large time to kill and a hunter often needs to wear down a large monster over several encounters before finally defeating it. Applying damage over time to the monster before it flees can help weaken it for the next encounter as long as the monster doesn't get a chance to recover full health between fights.

This isn't to say that we can use it everywhere for everything, but I think you get the idea - there are ways and types of gameplay where we can use damage over time to provide a viable choice to the player. It's a tool in the toolbox that we used to think was a lot more versatile than it really is. It's good to re-examine our old ideas every now and then to see if we can figure out a new solution to an old problem.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

You're correct... kind of. It boils down to the developers wanting to give the players what they will play with. Our goal isn't to give players what they say they want, but what they will actually play with. These two things are often not the same. If you want to persuade the developers to make more of a thing, you need to show them that more players will play with that thing. If you want to do that, let's consider what would make them think that lots of players are playing with a particular thing.

If you were a dev, you would want to see a lot of players playing with that thing. If you want a specific kind of character, you would need to show a lot of different accounts (players) all creating that kind of character. A single account (and/or IP address) creating lots of that character isn't the same as many individual accounts each creating that kind of character. But it can't just be character creation either - to persuade the developer that players want to play with that kind of character, you would need to have all of those accounts actually play that character after creation. The further into the game each character and account get, the more persuasive it is. We track all that through our [telemetry] - every choice you make, every quest you take, we'll be watching you.

Also, worth remembering - player engagement is only one factor in the decision-making process. License, design pillars, project scope, technology limitations, all kinds of other constraints go into the decision-making process. Even if you do everything in your power and do it all right, it still may not make a difference in the end. That said, trying still has a better chance of a good result than not trying at all. If this kind of thing is important to you, then do what you can.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

In any competitive game, there are two core elements: execution and resources. The players must manage both of these elements in order to meet victory conditions and win the game. Execution encompasses the player's decision-making process and means to enact those decisions. This covers deciding which buttons to push and when those buttons are pushed. Resources entail things in game that are expended for game results - health, super meter, mana, ammunition, abilities with cooldowns, and so on.

Let's examine how a competitive game actually breaks down. Competitive games are not evenly distributed across the entire period of play - it isn't like a race where each player can move at only one speed and the winner is determined from the very beginning by that speed. In a fighting game, for example, there are different game states that affect what happens. When a player lands a hit, the attacking player can perform a combo to deal a chunk of damage to the defending player. The amount of damage dealt is determined by the attacker's Execution and expenditure of Resources. As such, the life bar is mostly an abstraction of how close a player is to losing. The reality is that good players can deplete the life bar in some limited number of combos (e.g. three combos will kill a player), so the game becomes about the players landing those three initial hits.

Once we understand that competitive game play is about using execution to convert resources into a new game state, things start making more sense. The design of the game determines when these resources are introduced and how large an effect those resources have. In League, the jungle creeps are early game resources. Baron Nashor is a late game resource. We should start to recognize that each of these elements represents a swing in the way the game's likely results - using a single Monopoly card in Settlers of Catan statistically increases your chances of winning by around 17%. The size of the effect must be sufficiently large, especially near the late game portion of the match.

This means that whoever has the advantage continues to hold that advantage, but it doesn't mean that the losing team is out. Because the resource + execution swing in game effect increases in size as the game progresses from early to mid to late game, judicious late game swings can make up for early game disadvantage. If a player can deal 40% health with a fully charged super move, it doesn't matter whether their opponent has 39% health or 1% health - landing the super move will still be lethal. The size of that chunk makes that player a reasonable threat, even when behind in game state. This is how we keep competitive games exciting while still maintaining advantage - the advantages earned shouldn't be so overwhelming that a player cannot reasonably come from behind, but should also not be meaningless over the course of the game. The size of the advantage swing should start low and increase over the course of the game, leading to more exciting late game play.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

I think that Mixtape is a fine game on its own for what it is - a visual novel that's a love letter to the pop culture depiction of the 90's - but the controversy surrounding it is primarily emblematic of a larger issue within the gaming community. My main concern with game reviews of Mixtape remain my same concern with all game reviews - too many people fixate on the score the game got, when the review's main purpose should be telling us who the reviewer thinks would actually enjoy the game. Review scores should never be considered universal, because a 10/10 MMORPG is not for the same player as a 10/10 FPS, which is not for the same player as a 10/10 visual novel. The target audience is different.

This isn't to say that I think Mixtape is a bad game. I think it's actually pretty good for what it is supposed to be - an extremely niche game that hits the [anemoia] receptors in its target audience. It's very heavy on the feelings and light on the gameplay. For those who are into this sort of thing, it does everything right. I think that players who are really into 90s Pop Culture Depiction Nostalgia (which isn't the same thing as nostalgia for growing up in the 90s... believe me, I was there), Mixtape is their dream game - it's the idealized imaginary depiction of the 90s the way they wish it was, rather than how it actually was. That said... there aren't a lot of players for this particular niche at all - we can clearly see that in Mixtape's player numbers. Somebody clearly spent a lot of money to build Mixtape (especially with the perpetual music licenses, those are not cheap) and they're assuredly not going to earn their money back. But that's ok too - not everything needs to be profitable to be successful. Rich people and vanity projects have been a thing for centuries¹.

I think the core issue is that there is an increasingly growing divide between game reviewers and the gaming community at large. Game reviews are increasingly not particularly helpful for what they ostensibly should be - the purpose of a review should be to provide context and information for players to consider when deciding whether to make a game purchase, and the largest deciding factor here is who the game is aimed at. Too many people look at a game's review score and treat it as a judgement on the game's actual quality, instead of what the review should tell you - who the game is for and how well it meets that specific target audience's wants. Instead, there are a number of standout reviews that feel as though they are putting the reviewer's personal preferences before those of their intended audience. Mixtape is one of those situations - it's a super niche title laser targeted at today's disillusioned adults who dislike their current life situation and yearn for the idealized 90s in the movies that have been "improved" for modern audiences. The Venn diagram you'd get from this demographic and the set of professional video game reviewers today would likely have a pretty big overlap. However, the Venn diagram overlap with most gamers today would be slim - as the devs intended. Mixtape was never going to be a mainstream hit, it was always a rich person's vanity project.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

Unfortunately, there really isn't much you can do realistically if your favorite isn't as popular as the others - all you can really do is maximize your engagement and hope that it's enough. Let's go over the levels of engagement you can do if you want to show the developers that you want more stuff for this character. Engaging with these will absolutely not guarantee anything, but will help optimize and increase your chances of seeing more content for your favorite.

At the very base level, you need to play the game and use that character a lot. All live services keep metrics of play, so we want to see which characters are used and how often. You'll get bonus points if your favorite character isn't top tier in comparison, it shows more interest.

Beyond the base engagement layer, if possible you should be spending on that character - on new content especially. If you have the budget, buy skins, emotes, stickers, whatever. Remember the old adages - "talk is cheap" and "put your money where your mouth is". If you want to convince the developers to make content for a character, you need to show that there will be people who will spend on it.

Engage with character content both in game and outside. Be a character evangelist and talk with others in the community about the character. Get into the details in public conversations, show the devs that you care and are interested. Try to persuade others to think about things. Get some healthy discussion going.

If you already spend on character content and engage both inside the game and outside through official and unofficial channels with character content, then that's already doing as much as you can really hope for. If you really want to maximize your chances, you can make your own fan-created content - fan art, fan fiction, cosplay, user-generated/mod game content, and so on. Cosplay especially goes over well - it requires significant dedication and craftsmanship and it shows well to help sell the game to outsiders too. It also has a higher level of virality than fan art or fan fiction - people are much more willing to share cool cosplay pics.

Finally... be willing to accept that doing all of this probably still won't move the needle very much. When we're building content for a game, there are generally a lot of other factors at work beyond popularity that determine what we choose to include. We need a good amount of content coverage because live service player bases tend to be a bunch of various partially-overlapping sub-communities. As we build content to release, we distribute what we can to each kind of sub-community to keep them fed. We do what we can with what resources we have, but the thirst for new content applies universally.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

It depends on the job you're applying for. If you're applying for an artist position, no chance - you need a portfolio that shows your best art. For design or engineering, we will only really look at a github or website (or cover letter) if the candidate is really close to passing muster and we need a tiebreak. The heavy lifting is still done by the resume/CV. Any candidate for engineering, production, or design must be able to show us why we should hire her via that resume/CV. The most persuasive way to do this is for the candidate to show us that that she's already been doing the kind of work we need our new hire to do. There is no expectation when it comes to portfolios for engineering or design - plenty of folks get callbacks without a portfolio at all. I've been hired many times without a portfolio. However, if you have a portfolio and want to optimize your chances at getting hired, you must approach it from the perspective of a potential hiring manager.

We want to see the relevant work you did and the decision-making process you went through when doing that work. Making a hiring manager download an entire project and scrub through it without any direction is really bad for this. You need to convey the relevant information to us somehow, optimally in an easy-to-understand intuitive way. You want to remove as much friction as possible between us arriving at your page and reaching that conclusion.

If you really want to optimize your portfolio, you should build a curated presentation of the work you did and the choices you made. Explain the problems you faced, the decision-making process including the benefits and drawbacks of each potential choice, and then the final choice you made and why you chose it. Go over the difficulties in implementation you went through, especially where you had to pivot or change the design/plan and why. Finally, show me your finished implementation, ideally in a video or an embedded demo form so I don't have to download foreign files and run an untrusted executable on my workstation. Make it as easy as possible for me (the hiring manager) to see your work in the best light.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

There are two core issues with toxic positivity in the workplace.

First, it's setting a bad set of expectations and a false sense of security for those who believe it. This can cause significant mental trauma when the rug gets pulled out from under us. To a true believer, it becomes a huge betrayal of trust. The ensuing guilt and shame of "I can't believe I didn't see it before" hindsight can haunt someone for a really long time. Trauma like this is a major contributing factor to burnout and the exodus of talent from the industry.

Second, it breaks trust in the leadership for those who can see the truth. It's very much the manifestation of "Who are you going to believe, us or your own eyes?" - we see that the emperor has no clothes, but we must bottle it up inside because we don't want to rock the boat or be seen as disloyal. This affects team morale and the craftsmanship of the development - it's difficult to feel good about the work when I know my bosses are lying to me about how well things are going. This also contributes to burnout, except it is more gradual. Turnover tends to increase among devs like us, because we know that the rug pull is coming and we don't want to be standing on it when it happens.

This has far-reaching effects in the workplace - morale affects just about everything. When morale tanks, it takes just about everything with it. Innovation and problem-solving decreases, engagement and productivity decreases, mental health worsens, we feel more isolated because we can't talk about it, and turnover rises sharply as more of us come to see the writing on the wall.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

The concept of damage over time can only exist in a game where combat [Time To Kill] is fairly long. A player can only really do damage over time if the thing she's damaging actually lives long enough for the damage occur over time. If the foe dies within seconds or on the first tick of the damage over time, there really wasn't much damage over time done - it was really just a delayed hit. Having DoT as a role means there must actually be enough time that passes for it to actually shine.

There are certainly adjacent gameplay roles that synergize well with Damage over Time as a playstyle - debuffs, area-of-effect damage, vampiric healing, etc. which can lend some more interesting player choices. But none of these require damage over time as a foundation; we can also easily distribute such things through direct damage or other means as well. We can attach such things to damage over time to make it more compelling, but that doesn't necessarily solve our core problem.

Damage over time also isn't particularly interesting as gameplay. There aren't many interesting choices to be made when doing it, so players really just end up figuring out what ability rotation they must use in order to keep all of their DoTs on the target based on the durations of each one. This is a solvable problem and isn't particularly fun or interesting to solve or to play after it's been solved. There must be more interesting choices that a player must make as she plays that aren't a solvable problem.

All this said, it doesn't mean these problems can't be solved but that they are difficult to address. This brings us to the real decision here - do we really need to offer damage over time to players as an archetype in our game? If we as designers don't have a compelling case for it in our game, we should probably cut it to make room for another, more compelling player option. This is what you've been observing - most designers have recognized that the play style isn't particularly compelling, so newer games have mostly chosen to retire it. It's actually fairly similar to how there aren't as many games with dedicated healer gameplay roles anymore either, and for similar reason.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

You've probably heard most of them already, but here they are. In no particular order:

You'll get promoted and pay increases more often (and larger) by switching jobs than by staying. Most employers will offer around 3-5% cost of living adjustment annually (for those companies that are doing well enough). However, changing jobs typically nets at least a 15% pay increase, often more (the largest pay increase I ever got from changing jobs was close to +60%). Thus, changing jobs typically speeds up your pay increases by at least 3-4 years worth.

Only a few companies regularly promote internally. This is something you can research while you're on the hunt for a job. If the prospective employer isn't one of those, consider how long you would want to work for them assuming that they don't. If you have more than one offer, this should be one of the factors you're considering.

After getting a job offer, you should always negotiate for a higher salary - I usually like to ask for 3-5% more at the very least. That much is basically the first year's cost-of-living adjustment up front. They already want you and shouldn't rescind the offer for asking - if they do, it's a huge red flag and you dodged a bullet. The worst they can say is that they think the offer is already fair, in which case you can choose to take it or not. I've asked for that small increase in the pay at each offer for the last three jobs I've taken, and I've gotten it three out of three times.

Skills and abilities are much more important to show than the number of years of experience. It doesn't matter how many years a candidate has worked, we're looking for competence. Years of experience can help show this if you've done a lot during those years you can tell us about, but this doesn't necessarily mean that it's enough - you can work for years and still not be good at the job. You'll need to be able to convey your skills and abilities to experts in the field and they'll be the ones evaluating whether they think you can do the job.

Finally, it's important to keep relationships and maintain your own network. Try to be friendly and get along with your coworkers. At the very least, be professional with them. You never know if they'll be a key ally or opponent to getting a new job elsewhere. The industry is small and word gets around. I've seen and participated in many informal reference checks, where an old coworker at a studio will reach out to me because he knows I worked at another studio with a candidate and ask for my assessment. A good worker reputation goes a long way to help open doors in the future.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

The way to do this is to be professional every step of the way. In my career, there was often nothing wrong with the workplace I was leaving. The new opportunity was just better for me - I'd often get a significant pay increase, a title change, and some significantly increased responsibility so I could grow as a developer. In my exit interview, I would tell them so. In places that I didn't feel was a good fit, I would tell them so.

You should do your exit interview openly, honestly, and provide the kind of feedback you think would make the workplace better. You should take the time to transfer as much tribal knowledge as you can to your successors on the team. You should exchange contact information and leave on good terms if you can. You should wrap up what you can and prepare it for handover to someone else. Leaving on a good note, doing all you can to make the transition as painless as possible, is a great way to ensure the bridge is still there if you decide to return later.

One thing I would like to add - it is entirely possible that your old employer may try to make a counter offer to get you to stay. You should not take this counter offer. The statistics are very clear about this - the majority of people who take a counter offer to stay are often laid off or let go within a year anyway. If you really like your employer, take a year or two at the new place, level up, and then apply to come back if you can. If you still keep a good relationship when you leave and there is a job opening at your old employer, you will likely be welcomed back with open arms and bypass most of the hiring process.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

It really depends on the studio culture and the dev team leadership. The leadership and direction establish the environment that encourages or discourages individual devs from speaking out critically. When the leadership pushes back against feedback or visibly overrules it, the working environment becomes inhospitable for that feedback. When the leadership visibly encourages and acts on feedback and criticism, the working environment encourages more.

In a studio and culture that fosters an environment where asking questions and constructive criticism is encouraged, critical feedback happens quite often. I'm currently working on one of those sort of teams - we've got our design pillars and core theme and everything we're building is in service to those pillars and theme. There have been many cases along the way where we have pivoted on specific features and systems because team members have said "this feature isn't working". We have regular play tests and regularly collect feedback from team members and others at the studio so we can gauge our direction overall. The old proverb "As iron sharpens iron, so one person sharpens another" applies - the more you have to defend your ideas and the more open you are to new ones, the better the overall result becomes.

Some studios have a very top-down structure where the leadership essentially dictates to the devs what to do and how to do it. The environment allows little room for feedback or for the recognition of mistakes. This is often when the leadership doesn't allow the workers to function autonomously or trust them to make their own choices along the way. The leaders have all the ideas and the workers execute those ideas. These studios can work when the leadership holds strong ideas from the start, but it hurts morale which can make retaining talent difficult.

Another type of studio where negative feedback is discouraged is the "toxic positivity" studio culture. This is where negative feedback is essentially ignored or dismissed, only the good things are shared and focused on. Criticism gets handwaved away and the consensus from the group encourages praise and encouragement instead. These studios are typically the "dream job" studios for new hires, working there can feel amazing because morale is high and everybody is happy. These kind of studios cultivate a false sense of security in the developers that cracks when reality inevitably strikes. In this kind of situation, everyone internally thinks everything is going great and then a project "suddenly" gets cancelled or the game fails at launch and mass layoffs ensue. This often comes as a shock to the less veteran devs in question, but makes perfect sense in hindsight.

While this may not have been the kind of answer you thought you'd get, it's helpful to understand why this is the answer I give. "This feature isn't working" is inevitable feedback as we build more and more things. We're not always going to get things right the first time around so iteration and improvement is always necessary. The working environment plays an incredibly important role in encouraging or discouraging that kind of feedback among the team members, so it makes sense that we should be able to identify the kind of environment we're in and understand the ramifications of that environment.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

I think my ability to put myself into another person's perspective and evaluate things based on their likes and dislikes is probably my most valuable skill as a designer. I pair this with my ability to extrapolate incentives to results and it makes for a very powerful combination - I figure out what players want, and then set up systems with incentive structures to encourage the player behavior that they will want to engage in and reward them for it. This "other perspective" view ability is not as common as I would like; it's something I look for in particular when hiring designers because of how useful it is. If a designer can see what our different types of player groups each want, they can better serve those players through good design.

On the other side, I don't think that I'm wildly creative enough. I'm not talking about coming up with an interesting approach to make some system work or solve some specific problem. I'm talking about the super out-there ideas like "What if we made a musical game about cats in space?" or "Let's make a game where players can paint the flavors of time". I really admire that kind of wild creativity that somehow works, like the wild idea of rolling up objects in a ball that gets steadily bigger, combining a randomized dungeon crawler, pokemon, and a dating sim into one cohesive game, or an idea where you start as a single-celled organism and evolve into an elaborate creature. This kind of ideation is something that I noticed that I lack, though not for lack of trying. As such, my ideas and approaches tend to be evolutionary rather than revolutionary - I am excellent at fixing broken things or evolving existing ideas but not so great at the blank canvas.

This kind of detriment won't end my career, but it does put a limiter on certain aspects of said career. Any new game pitch I put together will probably not change or disrupt the world, but will likely be dependable and fun. It's important to be aware of your own strengths and weaknesses. This way you can do what you can to compensate for those weaknesses and adjust your approach to play to your strengths.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

I think it depends on what you mean by "large teams". For most dev teams, the need for dev kits varies on the role of the developer. Artists and animators, for example, don't really need their own dev kits - a group of artists can share a dev kit or two because they really only need to verify that their work looks proper in engine when they are nearly finished. The ratio of time spent using the dev kit to validate their work compared to the time spent doing that work is small.

Programmers, on the other hand, more often need to debug directly on the console in order to track down bugs. At one point, I was working on a multiplayer system and had to commandeer two other dev kits (for a total of three) in order to test out my synchronized animation system. I had built a system for one player to grab and choke another player to death. The three dev kits were needed to make sure that the killer, the victim, and the observer all played their respective synchronized animations properly on their monitors at the right locations and angles. I don't have a dev kit now; I verify my work on the PC build of the game I'm working on. My boss told me early that they'll give me a dev kit if I need one, but the need hasn't arisen yet.

QA usually uses test kits instead of dev kits - these are usually slightly weaker development machines that can play development builds but lack the extra memory and beefy hardware that the dev kits have in order to run debug builds. Test kits are significantly cheaper than dev kits.

From what I remember, most studios get an allotment of dev and test kits based on their need and the team size. The leadership then gets to figure out who gets them. The turnaround is usually a question of getting everybody involved to sign the appropriate legal contracts and such, and then getting the process approved by Sony. I've never worked on that part of sourcing, the team leadership usually just had the dev kits ready for us when we needed them. On occasion a dev kit gets bricked and needs to be replaced and that usually takes a couple of weeks. That's all I really know about the actual sourcing aspect of dev kits.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

Any development work you do should be in your portfolio and on your resume/CV. If you've built systems and written code, especially if it works and you've tested it and given it to others to play test and incorporated their feedback, you should absolutely keep it for your portfolio. The number one predictor for whether someone we hire can do the job is whether they've done similar work in the past. That doesn't always have to be paid professional work, though that is the best indicator - we will consider talented amateur candidates who have done that kind of work as well.

The most important thing about any work that you do is that you're able to talk at length and in depth about the choices you made during development and evaluate why you made those choices. What were the tradeoffs? What were the things you prioritized? Why didn't you go a different way? The answers to these questions show us your approach to problem solving. If you can also tell us what you learned from it, that's really good as well. Development is really a cycle - you come up with an idea, you evaluate the tradeoffs in how to build it, you build it, then you reflect on what you did right and wrong so you can improve on it.

Remember, we're not looking for a new game to play when we're considering hiring candidates. We're looking for someone to do the work we need done, so we're evaluating each candidate against those needs. You want to show us anything you can to help persuade us that you are the best candidate for the job, and that potentially includes any fan and amateur development work you've done.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

I don't know about generations, but I'll point out that Ultima Online is still running today and is supported by a small but dedicated population that still pays subscriptions and supports the game via in-game transactions. There aren't a huge number of them, but there's enough to keep the lights on and the game is approaching its 29th birthday, so we are approaching the generational mark. As long as enough players are willing to pay for the game and the situation is tenable, it's entirely possible for a game to continue on continuing 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

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

I don't think we'll ever be "completely reliant" on AI. Right now AI is a tool that we're still evaluating - if we can iron out the legal and cost issues with AI and it significantly increases work efficiency, we will probably incorporate it into our workflows. This wouldn't really be any different from using an off-the-shelf engine like Unreal or licensing middleware tools like Havok for physics simulation. It's something we may choose to use when the tool can provide for a specific need and the cost to benefit ratio is deemed worthwhile.

There are some elements of AI that some developers are using already internally, such as using a LLM to index and act as a search engine for internal documentation. Smaller games don't need to do this, but long-running games with lots of systems and content in place often have thousands of pages of documentation that needs some way to sort through. LLMs are one of the easier and more efficient ways of organizing all of those data. Some designers and producers are using AI to generate art for internal pitches and presentations. Most of this is kept to internal systems, we can't risk intellectual property being pulled into the greater AI databases as training material because of the potential legal issues there.

Ultimately, it comes down to companies evaluating a value proposition. If AI costs too much, doesn't do enough, or is too big a liability, we won't use it. If AI can do the work we need it for at a reasonable cost with minimal liability, we'll start seeing more developers use 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

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr