#game development process

[askagamedev]

Thoughts on Gemini being able to crank out playable “demos”?

There's an enormous gulf between a prototype/demo and a shippable product. Even in the development process, the prototypes and tech demos are there years before the finished product can ever hit shelves. The Gemini Genie demos are no different. In the Genie demos, players are incredibly limited by the verbs they can perform and the verbs are what drive gameplay. Players can walk around, but they cannot fight, dodge, climb, shoot, crouch, equip gear, level up, pick up items, talk to NPCs, or any of a thousand other things players expect when playing a game. They're the equivalent of an internet rando cobbling a model and a few animations into Unreal Engine and having it run around in that default grassy field and posting it while other twitter people yell "NINTENDO HIRE THIS MAN" because they lack the context to understand what game development actually takes.

I wrote a while back about how [Keywords Studios attempted to build a game with generative AI back in 2023]. They were unsuccessful with building a full game, but the [GDC '24 talk they gave] was very interesting. The main takeaways from then were that the AIs were unable to fix their own bugs well enough and that the human touch is still necessary to go from the prototyping phase to the shippable production-quality phase. In 2024, [they tried to use generative AI to remaster an older game instead] and gave a talk at GDC '25 about it. The results were similar - the AI repeatedly failed to produce shippable quality assets, but was saved significant time at doing prototype and concept work early on.

This is basically where AI is right now - it struggles to make new things, but is very good at remixing a bunch of existing things into a prototype phase. Then, the actual humans have to do the real work of taking the prototype and improving it to production-quality. To me, this feels an awful lot like things are backwards. AI is supposed to do all the busy and tedious work like reducing the poly count and optimizing performance so that I can do the creative and interesting work, not the other way around. As such, we're not actively using AI in the development process in any real regard outside of making executive demo slide decks and as a search engine for our documentation.

[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

[robynahaley]

The rare luxury of concept art for environments - aka Robyn does a lot of studies in blue. 

The whole team spent a brief time trying to map out, jot down, and paint some of our ideas for general direction as we were researching oceanography and marine biology. What you see above is a collection of most of what I was able to produce in about a week or two’s time. All of these sketches and studies were done using Photoshop and my old trusty Wacom Intuos 2. 

All of this work went toward developing our first area and verticle slice; what we dubbed “the demo caves”. The demo caves is an example of a lot of development that wound up being cut. It was something we anticipated but is a tricky subject to navigate. It’s another lesson that’s valuable and difficult to teach. Working on this area was valuable, it taught us a lot and helped establish the overall look of the game, but I think we sunk a little too much time and energy into it. Last time I said it’s valuable to throw your work away, but there’s also the sunk cost fallacy. The more effort we put into this area the more reluctant I was about getting rid of it. Why were we spending so much time on something we weren’t certain would even make it into the final game? The answer to that is very complicated... 

[askagamedev]

As a follow up to your recent answer about game cancellations, don’t game studios need to present a much more coherent plan than that before production starts? I know things can be added or changed during development, but how come I’ve seen the narrative quite often that the creative leads couldn’t settle on a creative decision or direction and it killed the game? I thought games had a much tighter vision at the start of development than that?

I think you're confusing the part where third-party studios pitch a publisher, compared to the way things work internally. The way the process works internally is we start with a vague idea and a skeleton crew, then each green light meeting at each step focuses the core idea more and brings it closer to reality, while adding additional developers to the team in order to build more of that core idea. This means that the earliest steps of a game might be as simple as "Knights of the Old Republic 3", where the initial team's task is figuring out what "KOTOR 3" might actually mean. In a third-party studio, this is part is usually funded and bankrolled by the studio itself before it pitches the publisher.

The long preproduction internal projects that got cancelled were likely still in these fairly early stages, similar to [my own recent experience]. The main issue wasn't that they had strong ideas for what they wanted the game to be, the main issue was that they failed at transitioning from building cool demos and ideas to actually building the game they wanted to make. That transition can be really really hard, because every creative wants to keep being creative and having to roll up your sleeves and actually commit to stop being creative and actually get down to making the thing is immensely uncomfortable.

[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

[askagamedev]

Maybe not the best place to ask this, but thought I would anyway. Assuming you use Visual Studio, what are some extensions you recommend for game development and C++ that make your life easier?

There are three useful tools I use with visual studio that I would like to suggest for you today.

First, I like using [Entrian Source Search], especially if your project has a lot of code. It maintains an index which allows you to search for things very very quickly. It's like find in files, but instant because it's all pre-indexed for you. The bigger the project becomes, the longer find in files takes. ESS can search your stuff faster.

Second, I suggest getting the [Smart Command Line Arguments] plugin. If you're working on a project and command line arguments are a thing, this plugin will help a lot. It allows you to create a tree structure for different command lines so you can activate the different command line arguments you want by selectively turning specific arguments on and off. You can even group them within subfolders and turn everything within the subfolder on or off when you like.

Finally, I suggest [Search Everything]. It's not actually a visual studio plugin, but I use it all the time anyway. Search Everything is similar to Entrian Source Search in that it creates a searchable index for fast results, but instead of finding within files, this searches for specific filenames (or fragments thereof). This is really helpful if you're looking for a file or asset path somewhere within the project, but don't remember where it is or the exact name of it. You can search with fragments of the file name you're looking for, and it will show you all of the files that match your criteria.

Happy coding!

[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 are your thoughts whenever a dev claims their idea was stolen by a studio/publisher?

More than once, I've been working at a studio that's had an unannounced game with new gameplay fairly far along the development process only to see another very similar game with very similar gameplay get announced by another publisher. At least one of these cases had more than one new game announced by different publishers all featuring similar (new) gameplay at around the same time. It is highly unlikely that industrial espionage took place and that these other publishers somehow got wise to our idea (or that we stole the idea from them). It is much more likely that there are so many creatives in the game industry that it isn’t uncommon for some of them to come up with similar good ideas around the same time, and that publishing executives evaluated those ideas and came to similar conclusions.

Beyond this, it’s important to remember that ideas themselves are cheap and common. Remember, the most important part of a game pitch is not necessarily [the idea itself, but the ability of the pitcher to make that idea real]. It takes at least a year (if not more) of development time to take a game from a pitch to something we can announce. During that time, a lot happens - the game idea gets put through a constant trial by fire as questions and problems arise from hammering out the details. Just how will this actually work beyond what’s on paper? What will we do about these technical issues? How do we teach the player how to do this? How do we actually build this kind of gameplay? Is it even feasible? 

Any person who claims the original “idea” probably never gave these kind of related issues any major thought - certainly not to the extent of assembling a full-time development team who are actually solving these problems. Dismissing all that work as rote or obvious does a huge disservice to the team’s contributions during that development time. And, if they actually do have a whole team finding solutions to those sorts of problems, they’ll almost certainly do things differently in many ways since the designer philosophy, technology, tools, and even IP will likely be different. The core gameplay idea for Fable Legends (announced in 2013, cancelled 2016) parallels Evolve (announced 2014, launched 2015) - asymmetric pvp with a team of players against a much more powerful single villain/foe player, but the details and implementation of both vary significantly.

TLDR - ideas are cheap and building a game is hard. There have been many cases of similar ideas being developed completely different teams and publishers at the same time. Claiming that somebody “stole an idea” does a huge disservice to the huge amount of work that the team has to do in order to take an idea and make it real.

[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]

Hello, i am learning game designer and researching on QA. What does a test plan look like in the field of mechanics/abilities/power?

Let's take a step back and consider what a test actually is. When you test something, you are checking what happens in a game against expected behavior. If the results in game match the expected behavior, then the test passes. If the results in game do not match the expected behavior, then the test is failed. Each test failure then gets written up by QA with the steps taken to conduct the test, the behavior expected from the game, and the behavior of the game that was observed. This is also known as a bug report - it is a report about the game behaving in an unexpected way, along with steps to reproduce this unexpected behavior.

If you consider this as the definition of a test, then a test plan is a collection of tests used to determine whether a larger thing - a level, a mechanic, a game system, etc. - is working as intended. Let's consider an ability in a game like World of Warcraft as an example. An ability in a game might have:

A resource cost

Some kind of target

Some effect(s) applied when the ability is used

An animation that plays when the ability is used

Visual effects that play when the ability is used

A cooldown

An in-game description/tooltip

An icon

An effective range

We can turn each of these requirements into its own test. First, we test to see if using the ability consumes the correct amount of the right resource. Can the ability be used when I lack enough of the resource? Does it consume too much or too little resource? Then we can test to see if the ability chooses the proper targets. Does the ability select the proper targets correctly? And so on and so forth. The collection of all tests we've created to make sure each aspect of a given ability exhibit the expected behavior is the ability test plan. We can then use this test plan to test each ability. This then enables us to utilize more than one tester that will perform the same consistent and repeatable tests in order to validate the behavior of each new ability as it gets added to the game. As requirements for the expected behavior change, so must the tests and test plans.

[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 opinions on the Cyberpunk 2077 launch?

The writing was on the wall when they announced the delay after going gold. The warning signs were already there before then - CDPR is fairly well-known in the industry for their sweatshop working conditions and pay, the game had been in development since the PS3/X360 console generation, and there had been multiple delays - but the post-gold delay really confirmed that it was going to be a hot, buggy mess. So let’s talk about it for a moment.

First, Cyberpunk’s extremely long development cycle basically meant that the leadership couldn’t figure out what they wanted the game to be for a very long time. Nobody plans to take eight years to build a game - the video game market changes and evolves way too quickly for that to happen. When Cyberpunk was announced, League of Legends hadn’t hit its peak yet and everybody was starting to fall off of the big AAA MMOG boom. Hearthstone didn’t exist. Fortnite didn’t exist. Players were all super excited to play COD: BLOPS 2. Having a dev cycle take longer than 4 years generally means the dev team wasted a lot of time building things, discovering they didn’t work, and then throwing them out. The finished Cyberpunk isn’t the sum of eight years of work, it’s the sum of maybe three years of work and five additional years of cut systems and content. 

Second, CDPR is already known in the industry for their brutal working conditions. They’re a crunch culture studio and there have been confirmations from one of the devs on Cyberpunk that they’ve been crunching on it since at least June of 2019 despite public assurances that it wasn’t mandatory. These kind of working conditions are nothing new; they did it for the Witcher 3, they did it for the Witcher 2, and there’s no reason to think they won’t continue in the future since it clearly continues to work for them. Unfortunately, the effect of the exhausted dev team gets multiplied by the systemic effects of delaying the game as well.

Finally, Cyberpunk was also delayed several times - in January, then in June, then again in November. Delays are never planned into the schedule - they are responses to shit hitting the fan. They only occur when the producers realize that there is no way that they’ll be able to hit their target that they delay the game. There are several reasons for this, primarily budgetary - changing release dates greatly affects the marketing campaign, business deals, as well as the overall development cost of the game. Thus, delays are usually a last resort - the added time is the minimum estimated time to reach the goal by crunching super hard to get past the finish line. The fact that they had to delay three separate times meant that they blew their estimates and schedules three times and had to course-correct each time. This is why the effect of the death march crunch mentioned previously gets multiplied - the devs have already been on a year-long deathmarch crunch and are exhausted, causing their work to suffer. Delaying on top of that means that their work will continue to suffer.

Cyberpunk is the result of multiple contributing factors - years in development hell, a brutal sweatshop studio culture, and all exacerbated by pivoting due to delays changing the schedule. It is the result of bad planning multiplied by developer exhaustion, compounded by sudden scope and schedule changes. All of the warning signs were already there if you knew where to look. I actually would have been very surprised if this wasn’t the resultant state of Cyberpunk at launch.

[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]

On the topic of level design, are you given a preset selection of enemies to put around the environment or are enemies made specifically for your needs to match your level design? Does it depend on the game?

The full process of character/NPC creation takes a long time. From the art side, we need to model, texture, animate each NPC. Design-side, we also need to assign them abilities, behaviors, stats, and so on. This all requires a foundation of software engineering that they can actually render and animate like the artists want and behave how the designers want. The long lead time it takes to finish an NPC means the creation process must occur in parallel with level and environment creation in order to hit reasonable deadlines.

If the goal is a completely new level and set of enemies, what we do is start with the high level big idea (e.g. this part of the game will be in an ice dungeon with a frost dragon boss at the end) and then have the individual teams do their work toward that goal. The level designers start blocking out an environment that feels like an ice dungeon, the environment artists start creating assets that look like they belong in an ice dungeon, the character art team starts modeling the monsters that belong in an ice dungeon, and the gameplay programmers start working on features that are needed to make an environment feel like an ice dungeon (e.g. contextual ground textures that make NPCs slip and slide while walking on them).

The ice dungeon level then begins as placeholder assets and rough prototype geometry just to get something working. Then, as each individual part makes progress, we integrate them into the whole. This section of greybox assets gets replaced by ice boulders from the environment team, that group of default bad guys is replaced by ice goblins, this section of ice bridge gets the slippery ice gameplay applied to it, and so on and so forth. We gradually replace the various placeholder assets as the level that started as 100% placeholder assets slowly approaches a finished quality over the course of production.

It's important to note that this extended process only applies to the new assets and features we need to create. After we create our first ice dungeon, we can use most of the same assets to create a second ice dungeon much more easily. It is also much easier to take an existing asset like an ice goblin and modify it a bit (e.g. give it an axe instead of a sword, make it bigger or smaller, change its texturing, give its attacks different effects, etc.) to differentiate it from the previous ice goblins. This is generally why creating DLC content is cheaper than creating content for the base game - we've already built a lot of assets, so we can more easily reuse what we have with some modifications to make "new" things without having to make completely new things.

[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