askagamedev - Tumblr blog

[askagamedev]

Sometimes I need to reboot my games because of “memory loss”. What is it? Why does it make my games run faster after rebooting?

I don't think there's a term called "memory loss", but you're probably thinking of a "memory leak". A memory leak is when a program grabs more memory for use while looping than it releases. This results in the machine using more and more memory over time, thus having less and less available memory to use. This causes slowdown and eventually crashing once all of the available memory has been used. When you reboot, all of that claimed memory gets released and becomes available for use again. That's why your games run faster after rebooting, the games have access to more memory after the reboot.

[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

[askagamedev]

What do you believe are the easiest and the toughest real world sport to translate into video games? My guess is Golf being the easiest since there are so few active objects at any given time.

I suspect you're asking from a technical perspective, since the "business" answer is that the easiest game to translate is the one that stands to make a good profit, and the hardest game to adapt is the one that won't sell. The number of active objects don't really matter all that much, we've got tech like the Dynasty Warriors games where we can have hundreds and thousands of moving dudes at once. Difficulty to adapt is also dependent on how much abstraction we're doing - today's Madden NFL 24 is an entirely different beast than 1988's John Madden Football was, even though both games are ostensibly translations of the same sport. Back in 1988, the biggest roadblock for the game was Madden himself insisting each football team needed to have 11 players on it and the hardware couldn't support that many.

From a technical perspective, I think the hardest sports to adapt have core features that are (currently) extremely expensive. Features such as:

Physical deformation - physical bodies contorting and deforming accurately when hitting each other

Signature movements and likenesses from well-known and familiar real life players

Real time environmental changes - rain causes players to get wet and changing their characteristics and animations, but also certain patches of the ground turn to mud, resulting in players getting muddy and difficulty traversing those areas

Thus, I think Rugby is probably the most technically difficult sport to chase after. American Football and Football/Soccer are probably close contenders as well.

Easy games to adapt tend to be the ones that need the fewest resources. Most games that are easy to adapt show up in compilation games like the Olympic type games. A 100m run or swim, for example, could take advantage of reusing a lot of resources (environments, animations, etc.) and don't have a high bar. Weight lifting games would be similarly low-effort for feasibility.

[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

[askagamedev]

Hello! I have a question about cutscenes. How does a decision get made about whether a cutscene can be skipped or not? I know some games have certain skipable cutscenes and others unskippable, and that in HD remakes of old games developers will sometimes add the ability to skip them. Do these decisions tend to be story-motivated or is there commonly a background mechanical reason to force a cutscene to play fully through?

Cinematics are mostly for storytelling purposes, but they also hid a very real secondary purpose - we would do a lot of game setup during cinematics, like streaming data off of a physical disc while the cinematic is playing so that we can load what comes next. If we need to load a bunch of assets, it's much better to hide that in a cinematic than pop up a loading screen or force a decompression area like a tight locked corridor to hide the new environment popping in. This kind of thing is less important now that we can install the full game to the hard drive and most gaming devices are now running SSDs, but it was a real concern before ~2012 or so when we still needed to read data from optical drives.

[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

[askagamedev]

Especially with so many projects that were never announced probably getting canceled right now due to layoffs and studios dissolving, how risky would it be for devs to keep personal copies of their work/builds?

I always thought NDAs were generally time limited, and at least that way the work wouldn't be entirely lost for ever. Is that even something devs generally want?

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

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

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

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

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

How do the people working in marketing know how effective their marketing is?

There's a whole field called Marketing Analytics that is dedicated to quantifying the results and context of marketing efforts. It is rare for companies to spend a large amount of money (e.g. on marketing budgets) without some means of measuring what they get from spending it. This measurement generally includes things like impressions, click-through rates, time spent engaging with the content, google searches for the marketed material, visits to the websites, view counts, average and median watch time, and so on. There are a lot of key performance indicators that analysts will track in order to measure how effective a specific marketing tactic is, and those performance indicators get compared to the cost of the marketing tactic to determine overall cost efficiency.

[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

[askagamedev]

What do you do when you are at work but for whatever reason you have to wait to keep working (development breaking bug that is being fixed by other people, code compiling, waiting on person working on X thing you need so you can start work on Y, etc)

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

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

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

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

You often talk about budget in your answers, so I was curious about something. Is it possible for the company to run out of budget before devs could complete the game as they initially planned, so that they have to wrap up all the pending storylines as best as they can even if incomplete? Talking specifically about massive story driven games with a lot of important characters having long storylines such as The Witcher 3, Final Fantasy 7 Rebirth, the Mass Effect series, etc.

It has certainly happened in the past, though not necessarily specifically the narrative part of the game. Many games are pushed to launch without development being as far as they want it to be due to reasons like hitting their budgetary limit and needing to recoup some of the investment. Our estimates are only estimates after all, sometimes we run into unforeseen problems and things take longer than expected. We can't stop paying the developers when we hit snags like that, so certain features end up more costly than others, which eats into the budget that was earmarked for other stuff instead. Most games in this situation have a lot of other launch issues too for the same reason - when you're pushed out the door to make the deadline due to running out of budget, things that should have been fixed are often not.

When World of Warcraft launched in 2004, there were several entire world zones that were incomplete and (mostly) locked off from players. Some players were able to sneak in through various exploits and take screenshots of those areas. Most notable were that the zones were primarily unpopulated by anything - no mobs, no quests, empty towns and buildings, just environment geometry that had been built out. This accompanied other incomplete bits of the game like quests that still had XML code in them. It would take years before players would finally see the incomplete-at-launch zones in some form or other.

Cyberpunk 2077 famously launched after multiple delays with numerous bugs and weird issues. Notably, the dev team also completely cut the multiplayer mode of the game that they had been building in order to consolidate resources to ship the single player game. The game came in super hot and had a huge number of launch issues that were eventually (mostly) ironed out, but the multiplayer mode was never resurrected.

The most famous example of this is probably Knights of the Old Republic 2. The publisher famously moved the deadline up and Obsidian scrapped the in-development ending since they didn't have the time to finish it. Instead, the story was wrapped up super quickly to ship the game. Notably, the partially-finished original ending was left on the disc and modders eventually discovered (and later restored) 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

[askagamedev]

Does it take much work/money to edit cutscenes once finished? Like, you develop a cutscene but then you decide to change details like background, music, clothes, facial expressions of the characters or even add to the scene a character who originally wasn't supposed to be there. How often does this happen?

The cost of making changes entirely depends on how expensive the individual changes are to make. That is generally dependent on how many people are needed to do the work to make those changes. Once upon a time, back when all cutscenes were pre-rendered FMV, it was tremendously expensive to make changes because making any small change required re-rendering the entire video which was enormously expensive. Today, for an in-game cinematic, a lot of the things are done in real time so we can swap things out as needed.

For the specific assets used in the cinematic, it depends on what it costs to make those new assets. If we already have the assets built for other reasons (e.g. a different outfit for this character), it's a lot cheaper than having to build a new asset from scratch for the cinematic. If we already have a voice line recorded, it's a lot cheaper and easier than having to arrange for the voice actor to come back in and record new lines. If we want to change the background music for the scene, it's a lot cheaper to use an existing piece we already have than to get a composer to make a new piece.

We usually try to minimize massive changes after the fact because of the cost involved. It's far more efficient to make sure that we've gotten our narrative and story locked down and finished before we begin constructing the cinematics than doing it as we go. Sometimes changes must be made (e.g. the voice of a major character has to pull out for whatever reason and we need to re-record all of the character's lines, we might be able to make some changes since we need to re-record anyway. But generally speaking, the early planning is much cheaper than the later implementation. We can't get refunds on development time or effort spent and we only have so much to spend on the total game.

[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

[askagamedev]

Do you have any insight as to why annual sports titles have not gone the Live Service model yet given the fact each year it is mostly minor tweaks and roster changes anyway?

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

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

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

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

Addendum to cut content: people find remnants of cut content in game files often enough. So/but is there any even rough estimate you could give of cut content that's dug up versus cut stuff that could never be found?

It's really hard to say because every project is different. The kind of games that have the least cut content are annual sports titles - they have the most stringent schedules and know exactly what they are committing to with each annual cycle, so they have significantly less wiggle room than a project with a longer schedule and bigger scope (e.g. GTA6). The games with the most cut content are often those that manage to make it out of development hell, the kind of games that are lucky to get released at all.

The other thing is that cut content often comes in various degrees of completion. Some cut content never goes beyond existence in documents, let alone a prototype. Most gets a few iterations on a prototype before the plug gets pulled, often because we can't find the fun in the idea within the time we've allotted to it. Rarer, we have nearly-finished content that gets cut for other reasons - the senior developers pushing for the feature get laid off or leave the company, there's a big leadership shake up that changes the game's direction, the senior developer working on it is needed elsewhere more mission-critical for the game to ship, additional funding for the project falls through, and so on. This kind of content is what the data miners are often able to dig up.

Also, it can vary based on technical constraints - if cut content eats up a whole bunch of disk space and we need to shrink the install size, we have to remove it. If the cut content is shared by a bunch of load-bearing assets, it will probably stay with those assets so that we don't accidentally break the game. Generally, we leave stuff there unless there's a good reason to remove it. It is often tough to know whether something is load-bearing so removing anything is always riskier than leaving it inert.

That's basically it - the amount of cut content that players/data miners can possibly discover depends primarily on the kind of game, the kind of content, and the circumstances of the game's development.

[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

[askagamedev]

Sent this ask a while ago but I think Tumblr ate it so here it is:

In which stage of game development are relationships between characters decided? Asking this because I recently found an old Final Fantasy VII relationship chart and originally some characters were supposed to have completely different bonds compared to the ones they ended up having in the actual game. These seem to be quite important plot points, so I assume that final decisions should be made before creating cutscenes? Or you can change stuff later if devs come up with better ideas?

The importance of the narrative depends primarily on how important the narrative is to the game. For a game like Overwatch, where the core gameplay is team pvp, the narrative is a lot less important and things like relationships are generally prioritized. It matters more that each character fills the specific gameplay needs of a team-based pvp shooter than it matters that these characters are brothers or that group has a rivalry with this one. In a situation like Overwatch, the narrative tends to be more like the glue that holds the bigger parts of the game together - it's decided on later once the big decisions have been made (e.g. we are locking in a flying rocket character and a fast teleporting character).

The important thing to think about when it comes to development is that we can't build the game sequentially, we have to build as much of the game in parallel as we can. This means we have to start work on the things that take the longest as early as possible (e.g. building environments, creating animations and rigs, building the technology), and then do the things that take less time to complete later. For features like cutscenes, it depends on how much difficulty it takes to build the cutscenes. In the original FF7, the FMV sequences were set in stone. Making changes to pre-rendered FMV was untenable, so everything in the FMV sequences had to be locked in very early on in order to get it all done on time. The in-game bits - the low-poly characters moving, talking, and animating - were cheaper and easier to build, so they could be changed significantly later in the dev cycle. Today such things would be much more difficult due to the necessity of voice acting and the difficulty of getting the voice actors back into the recording booth.

When we're in deadlines, we have deadlines - this is the last day for us to make changes to the feature we're working on. That could mean combat, it could mean itemization, it could mean summoning magic, it could mean narrative, it could mean cutscenes/cinematics. After that deadline passes, we commit to fixing bugs with what we have and not making any more changes or additions, no matter how good the ideas are. If we can always make changes forever, we'll never ship the game. As the inestimable Dolly Parton said, "Sometimes you need to to tinkle or get off the potty."

[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

[askagamedev]

Why companies don't record "Making Of" for games anymore?

A good rule of thumb when answering questions like "Why don't companies do X anymore?" is to think about what X will cost them and what X will get them in return. The purpose of doing things is ostensibly to generate value - no one does X without a reason. There needs to be a method to determine whether the returns of a choice are worth the costs of that choice in order to make a decision. Let's consider the bigger costs of recording "Making Of" videos, and then consider the gains from releasing those "Making Of" videos.

Producing behind-the-scenes "making of" video requires getting a film crew, recording developer interviews, and setting up + filming B-roll footage of the developers doing things (most commonly animators moving wireframes around). Recording the interviews isn't off-the-cuff either, the developers being interviewed need to think about their answers and prepare as well. The time these developers spend recording these interviews is time not spent doing their assigned tasks or fixing bugs, which comes at a material cost when there's a deadline. These interviews are coming at the cost of bugs not getting fixed.

Next, consider what these videos earn in exchange. When the publisher puts them out, what is the gain? Who will be most interested in behind-the-scenes videos? How can the publishers convert these videos into tangible value? Making players feel good or "exposure" isn't really worth very much. We're giving up a significant quantity of work, we need to get something equally or more valuable in return. One possibility would be making these videos a Collector's Edition pack-in bonus for a retail game. Another value gain could be offering them as a stretch goal for a crowdfunding drive. A third possibility would be paying for this as part of the marketing budget, but this still only really targets the extremely invested audience already and is difficult to convert to tangible value gain.

Ultimately, it's a cost-benefit analysis. Look at the studios and games that are doing such videos and consider what circumstances they're doing them. There's usually some reason that the production of such is a tangible value add and there aren't a lot of them.

[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

[askagamedev]

Does cut content exist for video games? Not material devs save for later use in dlcs or expansions, but content that was created and for some reason didn't make it to the final product. Idk like, a boss battle was way too long so a portion of gameplay was cut off or some footage devs felt like removing from certain cutscenes.

Of course cut content exists. On the latest shipped game that I worked on, I was hired for and spent months working on a significant game mode that was eventually cut. Our game mode was playable with a full game loop but the higher-ups decided it wasn't shaping up to be what they wanted for the overall game. We managed to save some of the early content we built for that game mode and repurpose it for another game mode, but a significant amount of the systems and features we built for the cancelled mode (including several boss battles and a progression system) will never be seen by players and exist only in our memories and our code/asset repositories.

[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

[askagamedev]

You have talked at length at standard optimizations (LoD, not rendering things, deleting cars on a distant highway to avoid memory overflow, etc). What are the weirdest optimization strategies you have seen?

One of my favorites was detecting animated background characters on screen, skipping 80% of their animation updates, and instead interpolating between the animation frames during the missing frame updates. Since they were just auto-looping background characters and not often looked at, most players didn't notice a difference but it saved a lot on the animation calculation overall.

[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

[askagamedev]

How is the process of learning In-house game engines once you get into an AAA studio? Do they immediately put you in production to learn as you go, or does it take some weeks before allocating you to a project?

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

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

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

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

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

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

Game Dev Glossary: Prototype, Vertical Slice, First Playable, MVP, Demo

Someone on our discord brought up a good bit of nuance in response to the Vertical Slice talk - there's a bunch of different terms for things that seem really similar. Each of the terms are the same basic concept - a demonstration of gameplay - but they each have small but important distinctions. Let's go over them here.

[Vertical Slice] - We just went over this. It's a functioning version of all planned game systems in the game working together for a representative final game experience.

First Playable - Basically the same as a Vertical Slice. Some people have some bigger distinctions between the two, the First Playable is the milestone that marks the end of preproduction and the beginning of production.

Prototype - A playable example of a single gameplay system to prove out the concept. Examples might be character movement, a combat combo system, or a specific game mechanic. The above screenshot is from the Breath of the Wild systems prototype - wind, fire, etc. was modeled in this prototype before being translated to the 3D game world.

MVP - Minimum Viable Product. The absolute bare-bones critical path minimum of whatever deliverable we're working on that meets acceptance criteria. This can refer to the whole game or a specific chunk of work we're doing (e.g. a specific system, a feature, etc.).

Demo - A stripped-down build of the game for exhibition, either for executives, tradeshows, or public-facing. Split into pre-release demo and post-release demo, with the post-release demo being easier to deal with.

[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

[askagamedev]

In regard to the vertical slice. Do studios work on/produce it to pitch a game or is it used as a milestone to reassure the money people that the game is progressing? (or both)?

Both. The vertical slice is a big milestone in a game's development because it shows the entire game coming together in a cohesive play experience. It typically signals the end of preproduction and the transition to production - we're no longer going to spend time coming up with any more major new ideas for game systems because we're committing to what we have and building those systems out. The vertical slice (sometimes also called First Playable) is our milestone to showcase all of our work so far.

Because it's a showcase, the vertical slice is an excellent demo to pitch to executives and publishers. Since it shows all of the major systems in the game working together, it naturally answers most questions about how the game will play. The executives/publishers can get a strong idea of what the finished game will be like, which gives them sufficient context to decide whether to fund the rest of the game's development (from production to ship and possibly beyond). This also gives them a good idea of how much longer the game will take to build, how the game will fit in with the rest of the publisher's release schedule, and how it will sell.

Similarly, the vertical slice also serves as a proof-of-concept for an internal project and used to get the green light for continued development. Most publishers won't fully fund projects from inception to completion unless they are well-established franchises (e.g. Call of Duty, Pokemon, Madden, etc.). What's more likely to happen is that they fund initial prototypes for several new game ideas, then approve the more promising ones and cull the rest. Internal projects go through these "green light" meetings where the executives assess development progress and determine whether development will continue. The vertical slice is an important green light showcase for exactly that reason - entering production requires a significant increase in workforce to build the rest of the game out, so the vertical slice is a big financial commitment.

[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