I've seen it done. In those days programming teams were usually smaller and this would be something put in place by a lead (usually a grizzled veteran of shipping multiple titles) and not advertised to the entire team. It might be hidden away somewhere like the core memory manager which would be owned by that lead and not generally touched by anyone else without consulting them. If someone happened to find it when running a memory profile they'd probably go and ask the lead about it and be let in on the 'secret'.

I actually found one of these when pulled in to help a title ship that had been put in for a previous title in the franchise and forgotten about when the lead moved on. I found it when memory profiling and after talking with a few people we figured out what it was there for and I got to be the 'hero' who found some extra memory to ship.

> If someone happened to find it when running a memory profile they'd probably go and ask the lead about it and be let in on the 'secret'.

Perhaps the obvious question here is "hidden from who?" Blinding the entire dev team to the trick might be possible for the lead, but sounds like a pain.

But squirreling away a bit of memory that won't be announced to PMs/artists/designers/producers? I can certainly picture a couple of programmers realizing that the person calling the shots intended to push them to the absolute limits of "what will fit", and deciding to fudge those limits. Hell, hedging is common practice for programmers and freelancers today when they anticipate bad requirements, and everything I know of the game development's history says the problem used to be much worse.

It's pretty normal for game assets to follow their own version of Parkinson's Law https://en.wikipedia.org/wiki/Parkinson%27s_law and expand to fill the memory / performance budget available (usually at least +5-10%). That can be just a consequence of artists and designers trying to make the best game they can within the budget available to them and so isn't particularly a bad thing. That's why an experienced programmer building in a 'secret' extra buffer for use around ship became a thing.

Yeah, I've seen something similar done to the art budgets, but hiding memory from programmers is impossible if they had any clue, especially on PS2/Xbox (32M/64M RAM). You could read .map in 5 minutes and see anything suspicious. Same with delay loops - good luck with that. Though I've observed some "miraculous" recoveries due to utter idiocy. E.g. a PS2 game using double floats (because your time calculations will break after few hours with a 32-bit float, duh!). The CPU had 0 double support so they were all done in software and the library with it was rolled into the standard math lib. Or some incredibly misguided GPU programming done to a "non-lead SKU". Nobody notices that one system runs 5 times slower than another until it's close to shipping and you try to bring it to QA.

The point was not to hide memory from programmers who "had a clue" if they went looking. During production, most programmers on the team would be focused on delivering features they were responsible for and fixing bugs. If they were doing perf or memory profiling it would mostly be focused on whatever feature they were implementing. Only a few people on the team, perhaps only the lead, would be looking at global memory usage / perf on a regular basis and even then they'd mostly be looking for regressions. If anyone did happen across this they'd probably go talk to the lead (there might even be a comment directing them to do so) and be let in on the 'secret'.

At the end of production coming up to release is when there'd be a wider focus on general perf / memory usage to get everything to fit for the final release build. In my anecdote above, the reason I happened to find an example of reserved memory was just that I happened to be the first person to go looking in the right place with the right tools, not due to any particular skill or experience on my part (I was pretty junior at the time, this would probably have been around 2004 towards the end of the PS2 / Xbox console generation).

I don't buy it. If you need to shave some bytes the first thing you do is look at the map file or run a binary analysis tool to figure out what the best candidates for optimisation are.

And if your performance is poor the first thing you do is add some debug code to measure what is taking too long and where the biggest gains can be made.

The whole point of these tools is to make this stuff easy to find.

Noel Llopis is quoted here as saying it did happen: https://www.gamasutra.com/view/feature/132500/dirty_coding_t...

I'd assume that in the era where lots of stuff was global and code was messy and convoluted to fit into a console no one would take issue with yet another global variable if it was named a clever enough name as some buffer, temporary, cache, etc. and compilers didn't yet warn about unused variables or remove them (which is an easy fix in C anyway with a single totally portable line or a special compiler specific directive).