Speaking as someone with game development experience, its not that uncommon. Trying to strip down an entire game into a single functional snippet can be a mammoth of a task since an absolutely ludicrous amount of systems/things in the stripped down app might be needing the full code systems they're referencing in order to properly function. For example, in the benchmark they'd need basically all the skill data in its entirely in order to properly render real-time skills being used in the benchmark, hence why its also been datamined.
It's the same reason why game demos these days are often ridiculously huge in size despite being a small section of the game, or back in ye olde days, would often just be the full game but with some arbitrary code inserted to force cut-off the player. It's easier to just leave way more information in your demo/benchmark/etc slice than is necessary since trying to meticulously bugfix/figure what the heck you need to include and can exclude in the demo/benchmark isn't worth the dev time in most cases. But this is also a double-edged sword since it makes the app more vulnerable to datamining.
Even beyond that, it's how people knew Cross-Region DC was coming almost a year in advance. Despite the fact the base clients had zero interaction with the system due to it not being implemented, Square did implement the special <tag> for it. Even if the benchmark doesn't interact with the servers in any way, if their latest build they were working on had already implemented the updated list of servers that would be coming, it'd be super easy to find it in the hexcode text dump.
Either way, from what I've read on the "mines" on reddit, it's *extremely* obvious to me they basically just ripped the latest build of their DT testing server at the time they created the benchmark and shimmied whatever was easiest to do off the data volume to reduce its size that wouldn't break things in order to ship it out the door. Hence why there's such very big stuff in the benchmark.



Reply With Quote



