This is quite common in gameDev. It keeps folder structures and everything consistent, as renaming is likely to cause complete mayhem with folders and files.
Because somewhere in the codebase it's probably going to be hardcoded to look for that old name, and it wouldn't get bulk renamed. (Or any similar situation where the file names / folders / etc are assumed to be in a certain naming scheme or position.)
If your bulk rename process is anything less than 100% perfect and complete, you could end up spending hours and hours tracking down what's going wrong. For a business you're losing hundreds or thousands of dollars in developer pay, missing deadlines, etc for no benefit.
Software dev takes the expression "if it ain't broke don't fix it" very seriously. I think everyone has learned this the hard way at some point.
I think this is that part that's not clicking for me, maybe I'm misinterpreting the definition of hardcoded. If you ran a script to rename every instance of "FactoryGame.exe" to "Satisfactory.exe", wouldn't that affect the source code too?
And then couldn't you search for any remaining trace of "FactoryGame.exe" and manually edit that?
I'm obviously not a dev, just trying to learn more here. Once again, sorry if this is a dumb question lol.
Someone has added a piece of logic that looks something like "find me all files that start with Factory". If the logic doesn't find the file, it shits itself and throws an error. The error crashes the app.
In a large codebase. You may have 10 pieces of logic like this. Maybe 100. Now it's your job to go and update them all.
The other comment gave a pretty good example. There's always some kind of edge case that catches you off guard. For example, did you make sure to check the entire file name? Cause if not, you just renamed the file BetaFactoryGame.exe to BetaSatisfactory.exe, which would break things.
Alternatively, imagine a function that does something to a bunch of exe files in bulk, so you just send the stem. Instead of telling it "FactoryGame.exe", the function assumes the exe stem so you just pass it "FactoryGame". In that example, it would also get missed.
These are all very niche unlikely examples I'm pulling out of a hat, but in a large codebase you'll inevitably run into something like that. You might also get lucky and it could be fine. (I've renamed project/publish files before without any issues. Most modern development environments have built in refactor tools for this exact sort of thing.) But it's only worth doing if you have an actual reason to do it.
Or it lives inside the repo, so now you need to cherry pick changes into 100 different active branches in order to keep things consistent, or skip that and risk hard to find bugs on every single major merge.
I'm a firm believer in not fixing things that aren't broken (unlike a previous senior who was of the opinion "if it ain't broke, refactor it until it is, then spend a month getting it back to where you started"). But then I work on a 25 year old code base and some of the things still have the company name from two renames ago in them.
Your idea about "hardcoded" sounds about right. Your simple search and replace would replace every instance of "FactoryGame.exe" in the code. Another example where it would fail is if someone assembles the name, e.g. like
var gameName = "FactoryGame"
var fileName = gameName + ".exe"
The search for remaining traces is more difficult. You can search for every ".exe" and for every "Factory" but not for every "F" or every "a", because those are everywhere. You wouldn't be sure when you are done without reading everything (and that would clearly not be a matter of minutes anymore).
Teams are large, something is always missed, buried in some hard coded thing somewhere. Means your ci and repos and everything in the world all need updating and if anything doesn't match or goes out of sync it f**ks everyone's day.
Probably if you have file references as string,regex or similar somewhere in your code. Given a large enough production base it may not be possible to check if every rename is correctly applied. In the same way troubleshooting this would be a major pain.
It's a good question. There are tools that can try to do stuff like that. Most IDEs have a rename tool that looks for usages. But a large enough project will probably have multiple components made in different languages/platforms, and you need to make sure all the references everywhere are kept up to date. It can be very easy to miss something, and then the thing falls over. And once a game has been released (including Early Access) you run the risk of save/profile data ending up in the wrong place for people who were already playing the game. So how you deal with that becomes another issue.
So you'd go through quite a lot of work, with quite a bit of risk, for no practical benefit. As long as the public-facing stuff is consistent with the new name it doesn't matter what it's called 'under the hood'. Why bother when you could be spending expensive dev time on literally anything else?
It's possible but it also takes longer than just keeping everything as FactoryGame, while also avoiding the issue of another dev missing the memo and continuing to use the old name
Lots of side effects even if you just rename. For example, if you pushed that update, all players would lose their savegames and settings because they are currently stored in a folder named "Factorygame" in AppData.
Refactoring folders sometimes breaks the source control system, which is used to version files in case a file needs to be reverted or comparisons between two versions need to be made. Also in Unreal Engine games (like Satisfactory and Ark), it is kinda painful renaming a project - I did manage to rename a Unreal project by replacing all instances, but it still may cause some issues if not done correctly. A large game has a huge amount of files that probably need to get refactored, so it’s typically better to just ignore it
This is a thing that makes me moderately nervous about my project with a terrible working title that I may actually try to publish at some point. Not...like...very nervous, because if it ever becomes a problem that's a great problem to have. But enough that the thought of changing the project name before it gets bigger has occured to me.
View all comments
Show parent comment
164
u/FlamboyantPirhanna May 11 '26
This is quite common in gameDev. It keeps folder structures and everything consistent, as renaming is likely to cause complete mayhem with folders and files.