Comment by gambiting
7 years ago
I work on AAA games and we definitely don't leave any debug code in production copies of the games. It's all #ifdef'd out in Retail builds.
7 years ago
I work on AAA games and we definitely don't leave any debug code in production copies of the games. It's all #ifdef'd out in Retail builds.
Maybe it's less common now that tooling and frameworks are more standardized but having spent quite a lot of time messing with the PSX and its emulators I can vouch that it's fairly common to find debugging code and strings in production versions. Simply using an emulator to enable the debug UART will spew quite a lot of debug infos for some games. FFVII has a "debug room" that you can't normally access but is present on retail copies. I also seem to recall that the PC version shipped with full debugging symbols which gave reverse engineers a field day.
I’m always surprised when I see you here but I’m not sure why.
Anyway. I can corroborate this. Debug code is /really/ harming performance in AAA games. Also, you want to remove your “cheats” that QC use to skip chunks of the game.
Older games are known for still containing various cheats to skip chunks of the game or make them easier. I'd guess a PS1 game might still have debug left in along with cheats simply either due to time pressure or someone forgot.
In my experience, we would leave the cheats in retail builds of those old games mostly because leaving them in was less risky than removing them. They had been there during all of development and testing, and we were reasonably certain of the build’s stability, but.. pull them out and your compiled code layout changes, data layout potentially changes, and who knows whether it’ll expose a new misbehaviour we’ve never seen before or know to regression test.
It’s just much much much safer to leave the debugging assistants (level skip, etc) in place. Especially back in the days when we couldn’t issue patches after release!
(Also, depending on era, you could feed a cheat code or two to magazines/websites/etc to get another article written about your game.. doubt that trick works any more, though!)
1 reply →
It really depends on what you mean by "debug code". If you mean special versions of the code built with "-O0 -g" (or the equivalent in whatever compiler/toolchain they're using) then obviously that's going to be a problem. If it's just helper methods like "go directly to section X in the game", "spawn any monster" or "if global variable DEBUG is 1 then log this" then that can easily make it in the final product if they're not optimized away in production builds. Those won't seriously harm performance either, just bloat the binary a little (which will most likely be totally negligible since modern games routinely end up using dozens of GB).
I’m sorry, I don’t know what statement you’re making really.
Maybe (uncharitably) you’re trying to look smart or maybe you’re also in the industry and I just don’t understand what you’re saying :/
When I talk about “debug” builds it’s actually a large thing; Not _only_ is it switching the compiler (Microsoft C++ compiler ofc) to build stripped/optimised binaries, it’s also removing things like, built in command consoles, logging subsystems and “phase handlers”, budget profiling for subcomponents of the game (AI, lighting/shadows, props) and also removing all assert statements.
Simple things (like asserts, which are essentially switch statements) need to run in tandem with other processes, when you’re trying to push 60/120 frames per second nearly every switch statement is going to “cost” something. That cost can be high very quickly. So, you don’t tend to leave things in which check conditions of various environment variables.
2 replies →