Obviously, going with this dynamic, data-driven approach is muchslower than having native code directly describe the behavior of thesystem. Performance-wise, hard-coding wins, hands down (both forloading time and for actually executing the simulation of the gamemechanics). With Zig, I may be able to chop down much of the loadingtime using comptime, but there is still going to be a cost there.
False dichotomy. You're claiming that's about data-driven design vs hardcoding values inline, but so long as you put stuff into data structures, does it matter if those data structures are hardcoded static arrays in your classes, or are read in from a config file at the start?
Whether stuff is hardcoded into a datastructure in the code, or hardcoded as separate lines of algorithms, they're hardcoded, and suffer zero read-in time.
And as others have pointed out, there's no significant time delay to reading in config files, compared to having the datastructures hardcoded as inline array declarations or whatever.
So, what stuff should you put into data structures?
Everything you possibly can. The less code you write, the less code you have to maintain, and the more code reuse you have.
Let's take Furcadia as an example. When I started working on the codebase, every species of avatar was a separate branch in a switch statement, a separate function call, and so on. Adding a new avatar was fairly simple: just search through the code for, say, "dragon", and copy each chunk of code for your new species. This had worked for decades, but the downside was, every new avatar meant a new client release.
I took all the various things that changed with each avatar (walk animation sequences, avatar ids, etc), and put them into an array, then made the code look up or loop over that array. This array was loaded in dynamically from the database on the serverside, and sent to the clientside on login and on change. Any art files the client lacked, it could request from the server.
That meant that adding a new avatar was just a case of uploading the new graphics to the server, and updating the database. No more massive client downloads, bigger with every avatar. No more client releases for cosmetic changes to the game. The system had become dynamic.
Even if, at the moment, your game is not networked, and won't have a server that will serve updates to the data, you might in future: and rather than update the whole client, it's way easier to just update data. That even means that you can dynamically update the client while the game is running, without a restart.
But even before you distribute the game, you'll likely see the benefits when it's time to debug. While you're testing, instead of quitting the application, editing the code, recompiling, restarting, and playing the game to get back to where you can reproduce the issue you were debugging... just change the data, reload it, and see your fix in the game immediately. So any time you can dynamically change something in the game rather than recompile, you save yourself hours of time in testing.
I'd go so far as to say that there is never an advantage to putting something inline in the code when you can put it in a data structure that the code can manipulate. And once you do that, it becomes super simple to move those data structures out to a config file, or even to a database like SQLite, making complex searches across the data massively simpler and faster.
JSON ain't bad for more complex data. CSV is ideal for simpler, tabular data, and makes migration to a database easier. Avoid XML, it's just crazy amounts of overhead.