askagamedev

[askagamedev]

This may be answerable in an archive post but tumblr search…

I have an idea for a game, a 2-D rpg I would like to try to solo-dev. I don’t have prior dev experience. What would be a good tool to use for my first foray into amateur game making?

Short answer - since you have no experience at all with anything, use [RPG Maker]. If you can't afford the retail price, wait for a Steam sale - it goes on sale quite often. For a longer answer as to why you should use RPG Maker, read on.

In the words of the inestimable Gin Rummy from the Boondocks, we can divide all knowledge in the world into one of three categories:

Known knowns - things we know

Known unknowns - things we realize that we don't know

Unknown unknowns - things we don't realize that we don't know

The process of learning is the conversion of the known unknowns (e.g. how to code) and unknown unknowns (things you probably didn't realize you'd have to do) into known knowns. The best way to do this is to start small with as limited a scope as you can, and then gradually increase as you level up and learn to do more things.

A toolset like RPG Maker does a lot of the lifting for you by providing a map editor, event editor, and content editor to allow you to work with a bunch of common systems that already exist in 2D RPGs. You'll learn a lot of the things that go into a video game from just having those tools and playing with them. There's also a lot of assets right out of the box, so you don't have to build a bunch of them on your own. If you want to expand past that, there's a lot of documentation and tutorials available online for making all kinds of additional features and content. As you get used to building things and creating content, you can slowly expand your scope to see what else you can do beyond that.

As for the project to do - build something very simple - a single story, with a handful of characters, that has a beginning, middle, and end. I suggest something simple like an episode of your favorite TV show. If you're feeling frisky, make some branching storylines for that episode. Whatever you do, don't try to make your magnum opus epic whatever for your first project. You're learning how to make stuff first. You're going to make mistakes, you're going to learn new things, and you're going to improve your skills. Most of all, you'll start turning those unknown unknowns into known knowns and known unknowns so that you can make a plan to start figuring out what else you need to do in order to make what you want to happen. Level up, improve your skills, and then start tackling bigger challenges. Good luck.

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

Do you have any thoughts as as a designer Magic the Gathering becoming a grab bag of IPs? How about as a player of MTG given how often you referenced it in your posts?

Any given game can be broken up into two major parts - what I call the mechanics (the rules and specifics of the game) and the fiction (the story, characters, lore, and such). Games can vary quite a bit between how important the mechanics are and how important the fiction is. Games like Chess, Tetris, or Basketball have very little to do with any real fiction. Narrative-heavy games like visual novels and immersive simulators lean much more heavily on the fiction than the mechanics. What bringing many crossover IPs does is muddy MtG's fiction without necessarily touching its mechanics.

It's pretty obvious that many players out there have responded positively to these kind of crossovers. Magic is hardly the first - Fortnite has built its entire model on being a platform for crossovers of all kinds, Call of Duty's multiplayer has become a similar world of crossover IPs, and mobile games have had brand IP collaborations for almost as long as we've had mobile games. It's generally a good thing for the business (so far), but it's hard to un-ring that bell once it's been rung especially in formats where all cards are legal.

For those who only care about the fiction, it's not a big deal - they can choose not to play with the fiction they dislike. For those who only care about the mechanics, it's also not a big deal - cards are essentially the mana costs, types, and effects. The art and the characters don't matter, only the efficiency and synergy in the deck. But for those players who care about both, the amount of sadness they'll feel is commensurate with how much they care.

Those who have made Magic The Gathering a large part of their lives growing up are likely to feel the most sorrow about it. I truly sympathize with them, but it's also part of the game's evolution over time (like how Magic is now much more stringent with its art direction than it once was). It's always important for me to maintain some emotional distance with products for this reason. I lament the changes with my friends but, at the of the day, we aren't friends because we play, we're play because we're friends. We can find other games to play, or we can enact house rules, or we can just try 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

Frequent Questions: The FAQ

[askagamedev]

What did you think you would be doing the most as a game developer when you were studying/trying to get into the profession versus what you did you actually end up doing the most once you got the job?

When I was a child, I dreamed of making the levels and coming up with cool features and abilities for characters in games. What kind of weapon, what kind of ability, what kind of item, what kind of bad guy, and so on and so forth. As I got older and learned more about how stuff worked, I thought I would be coming up with things like the characters, story, and the overall look and feel of the game. I believed I would be the one telling everyone else what to do, the quintessential "idea person".

Once I got to the university level and started taking computer science courses to learn how to make my ideas reality, I started thinking about how I would apply what I learned to making my ideas reality. A lot of seemingly-unrelated classes like linear algebra and vector math were actually very helpful in understanding classes like Computer Graphics and how it all works. Data Structures actually ended up being an incredibly important class. Ultimately, I took a software engineering course that required me to build a semester-long project. I chose to build a Half-Life game mod with a small team of others. It was during that course that I actually learned what game dev is really like (building features, adding assets, fixing bugs, tuning values, working with a team) and I realized I really liked it - so much so that I continued developing mods on my own after the class concluded.

Since graduation, the things I've worked on day to day in my career have mostly been doing the same things I learned in that software engineering class - I'm building features, adding assets, fixing bugs, tuning values, and working with a team. The features I build are bigger and more complex, the assets I use are higher fidelity and more complex, the tuning I do is more involved and complex, and the teams that I work with are bigger and more professional, but it's still in the same style as before - I can see that I've leveled up a lot and have a much greater understanding and ability than before, but it's still the same kind of skills involved.

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

What are other “we use X program for y tasks” that are standard in AAA game dev?

Beyond Visual Studio, there are a few common software tools we use.

We use Jira pretty as our task-tracking tool for bugs and tasks - I've used it at multiple studios now, though it isn't as ubiquitous as Visual Studio. I've seen competitors like Trello and Hansoft used at various studios as well.

We usually use Perforce for our asset versioning. It's able to handle both plaintext and binary assets. I haven't really seen any other solutions in use in my experience, though I have heard of other studios using some other options.

The most common tool we use for game design is actually Excel. A huge amount of [game design work is handled via spreadsheets and the formulae there]. Some studios use Google Sheets instead since it's pretty similar (and free), but we all inevitably some sort of spreadsheet tool with macro capability is needed in order to handle all of the various design math in content creation.

Every studio uses some kind of instant messenger tool for team members to talk to each other directly, though the specific tool varies a lot with the studio. These days most are using Slack, but I've seen studios use MS Teams, and back in the day we even used tools like Yahoo Messenger, MSN, or even Skype.

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

Hey, I just read your post about console development and the engineering effort it takes to use the extra bells and whistles a console provides. I was wondering if you had any knowledge or theories why more games haven't taken advantage of features like sampler feedback streaming. Memory always seems to be a stretched resource on consoles and this feature is claimed to improve memory utilization by over 2x. It seems like taking advantage of console specific hardware happens less these days outside of something like VRR or PSSR on the PS5 pro.

Thank you for taking the time with this and many other questions. Love your posts.

Thanks for reading and your kind words. I'll be the first to say that I'm no graphics programmer, so I can't really say anything to the specifics and utilization of a specific feature. That said, I'll try to address your question the best I can. Generally, there are two core reasons that we don't utilize specific hardware features that we could potentially use:

First - it's usually because we're still supporting last-gen hardware that doesn't necessarily have this feature, so we need to be more careful about where we spend our performance optimization resources. Getting last-gen performant is a much bigger undertaking than getting current-gen performant. Spending a bunch of engineering time optimizing this feature that doesn't help our game on last-gen consoles would likely be better spent on finding optimizations that help across the board, especially if the last gen still has a lot of players. This particular reason phases out over time, as more and more last-gen players convert to the new generation, but it's a really big issue in the first two or three years after the launch of a new hardware generation.

Second - it's usually because not all of the hardware that we're targeting supports that particular feature. The PS3 had their special SPU Cell processors that nobody else had, which meant that any work done to optimize games to run on those Cell processors was totally wasted on the PC, X360, or Wii. This is totally fine if we're targeting PS3 as an exclusive title, but it's not very resource-efficient if we're aiming at the roughly 40/40/20 split between PS3/X360/PC that most multiplatform AAA games saw at the time.

You probably noticed that the calculus here is primarily "Will this effort translate to significant gain across all of our target platforms?" We only have so many graphics engineers (some of the most expensive and sought-after roles in the game industry!) and they only have so much time to work their magic. We try to ensure that whatever we task these folks with is the most efficient use of their limited time. That's the real answer - we only have so much time/resource to spend over the course of development, so we try to get the most we can out of what we have.

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

has there been any transition from Visual Studio + Visual Assist X, or is that still the standard? i've tested CLion and Rider, but always seem to go back to Visual Studio.

Not everyone uses Visual Assist (though it is helpful), but everybody uses Visual Studio. The last time my employer used something other than visual studio was when we had to use Metrowerks Code Warrior for PSP development, which should give you an idea of how long ago that was. Visual Studio is pretty much the standard in the game industry.

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

On the follow up to the gambling question, have you seen industries you work with try to skirt around or cheat regulations, such as various car companies cheating at emission regulation tests?

I've never seen it myself at any studio I've worked at. I can't say it never happens, but I've never seen it on any project I've worked on, and I've been working on games with randomized rewards for over a decade. Many of the games I've worked on had cash shops, and I've worked on many of the loot systems involved with the distribution of these items. When we test these systems, we go for several million loot distribution trials and then analyze these results to make sure that our distributions are reasonable. Generally speaking, the internet never forgets and it's hard to regain the trust of spending players if we're found out to be manipulating the numbers.

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

Since you have worked in both gambling and games, how much do each “fix” the RNG? For example, how much are there “guaranteed wins” baked into loot boxes or slot machines to keep engagement (say a legendary skin/a win every 100 pulls even if the raw RNG would not have given it)? Conversely, how often are there “you can’t get a legendary skin/a payout unless you pull 100 times regardless of what the RNG would have given you?”

Honestly, a lot less than you think. Most of the time, we actually fix the RNG in the player's favor in order to avoid the more frustrating events. This includes loot systems that will force quest items to drop after N attempts without a success, and often massaging hit rolls behind the curtain to give players better chances than displayed.

For things like gacha, it isn't worth it to ham-hand things because it doesn't actually matter - any student of statistics knows that with a large enough sample size, things approach the mean. Any gacha game will have millions of players each doing hundreds or even thousands of pulls. As long as the overall distribution of the SSR units over those pulls closely approximates the given percentage chosen (1%, 2%, 0.5%, whatever), it doesn't matter if somebody goes for a thousand pulls without getting his waifu or if he gets it on his free pull. If there are 3 million players each pulling ~30 times each, that's 90 million pulls. A 1% distribution will see roughly 900,000 of that specific SSR distributed among those 90 million pulls. Some players will be extra lucky and get multiple, while many will be unlucky and get nothing. It doesn't really matter to the devs whether a specific player is one of the lucky ones or the unlucky ones, only that the general population is happy enough. If the gacha rates make too many people unhappy, the developers add a second-chance mechanic, usually a "sparking" mechanic where players can get to choose the SSR unit they want after some number of failed pulls. Fire Emblem Heroes actually does this - if you can somehow go for 100 pulls without a single SSR unit, the next circle will be guaranteed all SSRs. There's actually a super low chance, a little over 1/500 chance of it happening.

For actual casino gambling, there is no messing with the RNG at all. The RNG must be digitally signed by a government-approved testing lab across many hundreds of years of tests (multiple RNG simulating computers running tests for weeks at a time), and that RNG with that specific checksum/signature must be certified to be used in gambling machines. This is because any messing with the RNG at the casino level means the revocation of licenses by the government and basically destroying the business upon which it is built.

This is the same reason gacha companies don't mess with the RNG too much either - in any country where they must post rates, any statistical evidence that could bring them legal compliance trouble simply isn't worth it. These companies have millions of players, often who pull hundreds or thousands of times. That's a lot of statistical data out there for anybody who wants to collate it. Any sort of statistical discrepancy will come out with a sample size that big, so it's just not worth it to us to manipulate it when the consequences are legal.

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

Is direct console development (for a multi-platform title) only about certification requirements and console specific bug fixing, or is there more to it?

There's two sides to console development. There's the software certification side, which is what you asked about - all of the cert requirements and fixing console-specific and certification bugs like using the proper glyphs, using the copyrighted terms, and so on. The other side is actually setting up the software at the engine level to interface with the hardware drivers and utilize the game hardware. This tends to be the really crunchy programming work done by senior software engineers who really love playing with hardware.

All software needs to interact with the actual hardware at some point - there must be data sent to the hardware and the hardware has to operate on those data. There are often many layers of abstraction between the hardware and the software - most programmers don't need to think about how the math is done, only that the math is done. It's the experts who work with the hardware that do what they can to squeeze additional performance out of that hardware in the time they have allotted to do so.

One such example would be back in the PS3 days. The PS3 famously had a bunch of "synergistic processing units" (SPUs) that could do a bunch of math very quickly, but required a special half-float format to operate. Most game dev teams didn't bother to utilize those SPUs for that reason - it took a lot of additional effort to set up the software to store data in that format, send them to the SPUs for calculation, and then convert those data back to the normal floating point precision numbers we usually use. Some teams like Naughty Dog's Uncharted team, however, took full advantage of the SPUs and used them for the post-processing effects to make Uncharted 2 look so good.

This is the other side of console development - writing code to take advantage of the specific hardware bells and whistles and squeezing out better visuals and performance from the hardware that's waiting to be used.

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

How long have Sony and Microsoft been using the same file formats for their games? Has it been the same since you started?

I must apologize - I made a mistake yesterday. Microsoft doesn't use ELF files at all, it was a brain fart on my part. I haven't touched the consoles directly for a few years now. Thinking back after I posted, I realized that I was wrong. Sony has used ELF files forever, but Microsoft has had different file formats for each console.

Original Xbox used .XBE (Xbox Executable)

X360 used .XEX, and the development console was called a "Xenon"

XBone and XSX both use the MSIX format, which is a "universal windows" type executable.

Sorry about the mistake - I'm old and forgetful now, and I haven't had to do direct console development in years.

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

How does compilation/building work when you're programming for consoles?

It works mostly the same as it does on a PC, as the compiler and linker build an executable that can be run. Consoles are basically PCs running a different operating system, so it changes the file format of the executable. Xbox and Playstation consoles run games in an ELF file format. ELF stands for Executable and Linkable Format, first introduced way back in the Unix System V days. Nintendo does their own thing - they've got their .NSO file format (Nintendo Switch Object) that's a compiled and linked Switch executable.

Thanks to higher network speeds, it's possible to serve data directly from our dev workstations to our consoles, rather than package everything up. The console dev kit connects to a network drive and runs the game remotely, similar to running an app installer over the network. This can cause some discrepancy between a development environment (our local workstation drives) and a full build with all data included on the disc/cartridge. This discrepancy can lead to odd bugs showing up.

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

On the topic of game preservation, what do you think is the best solution or pathway that consumers should try to push for that would might be a reasonable compromise between companies, consumers, and legislators?

Whenever one group tries to compel or coerce another group to do something that doesn't benefit them, you get minimal compliance at best and malicious compliance at worst. This doesn't really serve the interests of the coercing group - they don't really get what they want, and the other group often does whatever it legally can to make sure the first group never gets what it wants. Nobody wants that.

Instead, I think the groups involved need to figure out how to align everyone's incentives such that everybody involved wins. Right now, the publishers and rights holders gain no benefit from preserving games publicly. Forcing them to release post-sunset games to the public saddles them with the all the costs of doing this (engineering and QA primarily) and no benefit to them. If all they get out of this is added costs, of course they'll have every reason to minimize those costs.

One solution think both players and publishers should lobby the government for is some kind of tax incentive to offset the costs of making a "functionally playable" post-sunset game available along with stringent IP protections for the publisher and rights holders (e.g. a separate EULA for post-sunset releases to clear the publisher of any liability and protect any IP), and some sort of limited license agreement that protects any third-party licensor with their licensed work in use. This should preserve the majority of what players want (a functional game), provide financial incentive for the publishers to eat the post-sunset cost, and allow all IP owners to protect their property at the same time. In this regards, everybody gets something valuable they want out of the deal, rather than trying to force one party to do something with no visible benefit to itself.

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

Why do many games that offer controller support not offer full button customization for the controller like they do for keyboard and mouse?

It's a good question. This is one of those rare situations where it actually is pretty easy to make these changes. Setting this up actually shouldn't be that difficult - we already must handle device input mapping to in-game actions no matter what we do, so whether we do so using a set of internally built presets or a saved map generated by the player still results in the same action mapping. It's a little bit harder to collate a dynamic set of mappings than a prebuilt one, but not by much.

This sort of thing is usually dependent on available UI/UX dev time, since you need to do this on a per-platform basis. We already do this for many other UI screens. The main hurdle I can think of is that we tend to need to use special cert-required images for button inputs (we call them glyphs, like the triangle and square button on Playstation or the A/B/C/D button on Xbox) on these screens which makes them a bit more complex on the testing side. But these are still not that heavy in terms of validation time needed - this feature should not be super expensive to implement.

I'm really not sure why this doesn't happen more often - like I said, it's actually pretty easy to do, it just requires some more UI/UX dev time. That small amount of dev time might be a deal breaker for some studios, but this is the sort of thing that does confuse me.

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

Staying on the topic of computer specs, how do the recommended/minimum hardware requirements on Steam get determined? I can't image you just have an array of different computers to test them all on, but after seeing a single machine with 256GB memory anything seems possible

Compatibility is a pretty big thing with AAA game dev, since we want our games to run on as many devices as we can. Usually we aim min spec hardware to be whatever is most common in the Asian PC bangs/cafes so that users there can play. We aim at mid-spec for our recommended specs, and we will test against a variety of high end machine builds to make sure everything works. We've also got tools to simulate different network situations and test rooms with different internet service providers for real world network testing purposes, both with various PC builds and with gaming consoles. We try to test many kinds of different play environments in order to ensure everything works the way we hope it does.

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

On the topic of computer specs, how close to the limit does your over powered dev computers come to running unoptimized versions of the game? How common is it for your dev computer to run out memory?

I'm usually able to run most test levels at a solid 100+ fps with default graphics settings. Big maps and higher settings can bring it down to 60. Things I'm working on rarely push the game to the limit while I'm working because I'm not working on the high fidelity visuals. My workstation is fairly standard for our technical design and engineering teams.

When our workstations are in the office, they're often used for distributed build systems like Incredibuild, SN Systems, Jenkins, and the like. This allows us to compile code faster because we can have multiple idle machines split the work up across them. I'm a fully remote worker so my workstation doesn't participate in the distributed build system.

In my case, the situation that pushes my workstation to its limits tends to be when I'm building and compiling assets. I've seen both my CPU and my memory footprint go up to 98% with noticeable slowdown and choppiness doing anything else on the machine. Processing assets and building levels tends to eat as many resources as I'm willing to give.

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

As a follow up for the IP rights question, I know there are a lot of games/movies/shows who's release or remake is in jeopardy due to either not being able to figure out who owns the rights or there being multiple parties that own part of the rights who do not agree. How do the rights owners go from "known" to "unknown" and how much piecemeal can rights be split up? (With the understanding you are not a legal professional. Still curious about the layman in the industry's understanding).

It can get pretty weird with how things get split up. Here's my current go-to example. Right now, Hasbro is currently promoting and accepting preorders for a Marvel Legends action figure for a character named Gargantos.

If you're familiar with the Capcom Marvel fighting game series, this character may look familiar to you... but you'd do a double take at the name. Here is a win screen taken from the Marvel Super Heroes (1995) arcade fighting game.

This character, however, isn't Gargantos - it's named Shuma-Gorath. So why is Hasbro releasing a toy based on a Capcom character design of a Marvel character that has clearly been renamed but nothing else is changed? Especially when the target audience almost certainly knows this character by the name Shuma-Gorath?

It's because today, neither Marvel, Hasbro, nor Capcom have the rights to the name Shuma-Gorath. Marvel absolutely owns the rights to the giant mystic eyeball squid character who has fought Dr. Strange many times, but they do not own the name. The name Shuma-Gorath was created by writer Robert E. Howard, also the creator of Kull the Conqueror and Conan the Barbarian. Marvel licensed Howard's IP and first used the name Shuma-Gorath for a space squid villain for Dr. Strange back in 1973. In 1994, Marvel was a lot looser with their licensing and Capcom was able to make use of this character for their Marvel fighting game. Since then, the ownership of Howard's catalogue (and the name Shuma-Gorath) was picked up by Paradox Entertainment (spun off from Paradox Interactive), which then became Cabinet Entertainment, which then became a company called Heroic Signatures that mostly manages IP, which was then bought by Funcom. Now Funcom owns the rights to the name Shuma-Gorath, which Hasbro was unwilling or unable to license, so the character's toy must be renamed Gargantos or Hasbro and everyone else involved might get sued for copyright infringement on the name.

In a bit of amusing trivia, the giant squid eyeball monster from Dr. Strange and the Multiverse of Madness was also named Gargantos and not Shuma-Gorath for the exact same reason. So yeah, licensing IP can get really weird and also specific sometimes!

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

Some Thoughts on Cancelled Games that were in Preproduction for 5+ years...

You may have seen a lot of video game news recently about projects that have been in development for a long time while still in preproduction getting cancelled. This is normal behavior for the current economic climate - things are cooling off and the big publishers are essentially cutting all projects that aren't on track to ship within the next two years because they don't have the money to keep paying for such long term bets. Many of these projects are said to be "doing well" or "coming along", so why do these projects get killed if they're so promising? As somebody who's been on a couple of these projects (including recently), the view from the inside is often very different.

My studio was in a somewhat similar boat to many of these - we had one major money-making franchise at our studio that paid all of our bills and a small incubation [blue-ocean] project in preproduction (for several years) that studio execs hoped would be a new franchise we could start. All of the demos and video we saw looked absolutely amazing - the studio devs were super excited about it and most of the devs I spoke to wanted to join the team because of how awesome it looked.

This project was looking so promising that it got green lit for a [vertical slice] - the next step in the development process, where all of the separate demo and preproduction game systems get integrated into a single cohesive gameplay experience that's representative of the whole. As such, the small team that was working on this project got additional resources (developers) to build that vertical slice. I was one of the developers tapped to join this team to help build things out. I wasn't actually super enthused about this - the greater economic situation in the industry had already started to sour and I really would have preferred staying on the money making franchise for safety. I was also bit leery of the experimental project with its grand ambitions - the scope seemed like way too much for the number of people we had and the time we had to build it out.

Once I joined, it became clear to me that my concerns were validated. The project absolutely needed to switch gears from "make cool ideas" to "bring everything together and work towards this major goal", but the team's leadership was still very much in blue ocean mode. We chased down many cool new ideas, but the integration of everything lagged behind. For the kind of game we were building, we absolutely needed a well-established workflow and tool base to build enough content for players to engage with... and very little of that was even on the horizon - a large part of it was me personally pushing for it directly and personally because I had worked on the kind of game we were building in production and I knew that we needed those battle-tested tools and workflow.

Instead, we spent the first few months building another awesome set piece and cool one-off scenario that would look amazing in a demo. The set piece scenario was held together by shoe string and bubblegum but it mostly worked, was mostly playable, and it looked fantastic when it didn't break. I did my part and built the stuff I was tasked with, but the kind of hacks and shortcuts we were forced to use made it very clear that we needed a reliable and systemic method of creating much more content much more quickly if we really wanted to build a real game out of it.

This is the curse of these kind of projects - most games that have been in preproduction for years are stuck in this "cool amazing demo" mode and have a really really hard time switching gears to "making the damn game" mode. They show great in demos and videos, igniting the imagination on what the game could be if/when everything comes together, but the actual coming together portion is one of the hardest parts of game development.

Almost a year after I joined the experimental project, I was reassigned back to the mothership game because the main franchise needed more people to get it to a shippable state and the overall industry economic situation had continued to turn sour. Internally, I was actually extremely relieved for myself, but I felt very sorry for the team I was leaving behind. A few months later, the experimental project was cancelled and the remaining team was let go in a situation very much like what happened to Perfect Dark, Everwild, the Zenimax MMOG, and all the other preproduction games that met their demise during the recent Microsoft culling.

This isn't my first time (or even second time) on a promising project that failed trying to go from preproduction to production - the core problems have been very similar on multiple projects I've worked on. Dialing in the core gameplay, recognizing the need to shift gears, and then actually executing on that major change in team direction is one of the most difficult problems in game production. It's difficult to do and there are innumerable buried and cancelled projects over the years that were unable to do it. I mourn for what could have been but I also understand that many of these dream projects just weren't meant to be.

[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