the GM files include text data such as "item name" and "item description", as well as things like monster parameters like attack point and defense point
Those are potentially different categories of things.
Names and descriptions are often fine to modify. In fact, you may want to provide different versions of them for clients in different languages.
Yet, stats have a more direct impact on game play. For example, more or less attack points - presumably - means battles could last longer or shorter.
For those you are going to consider the online and multiplayer mechanics of the game. If every game is pretty much isolated from each other, there is little harm on these modifications. Yet if there are online rankings, or some other way in which players compete to each other, then you need to consider if modifying these stats can enable cheating. It can be far removed from the actual player-player interaction, for example changing the stats leads to defeating more offline enemies that lead to more resources that are used in a player-player interaction.
Addendum: The server should be in charge of player-player interactions. In general, don't let the client tell the server what it has (be it stats or inventory or rewards or whatever). But some of those changes made locally, if the game is entirely offline, or other players can't see and are unaffected by them are fine.
(1) Are text info such as names and descriptions generally considered data that need to be pulled from server every request or something that can be accessed from the local file?
No, not really. Unless it is something that changes often. Usually you would download them in case of an update.
I'll elaborate further below.
(2) When the local file for game rendering become out of sync with the server, when should it be synchronized? It does not seem likely for me one has to wait until the next version upgrade to fix these type of bugs.
Again, this depends on your game. On one extreme it could be that this is entirely irrelevant. On the other it could be that you need to tell the player that they have to update the game because a new version is available and they can't play with the old version.
Plus, I cannot hold it against you if you don't have a hot reload mechanism if isn't a problem, much less on an initial version. Yet, it cost you very little to publish the current version on the server, so the client can check if its version matches.
You seem to be worried that the players are going to see the wrong thing. And one part is to keep the data up to date. And another part is to prevent the data from being tampered with.
If the player tampered with the game in such way that they see a million times the damage or coins or whatever, but that is only local and the server register the correct value, is that really cheating? Also, are you worried they don't see the correct information when it is them who tampered with it? I don't think it is cheating, nor that you should be worried.
One problem I am considering is, storing the item names locally would reduce the amount of data transfered (and hence the cost) than when pulled from server every request. However I am not even sure whether this is considered a significant factor in real life games since the amount of data is tiny when compared to other resource files. (A programmer in my team is very keen on this method but I am pretty precarious as research I made suggests the other way. The main argument he makes is actually about the data transfer cost rather than the rendering speed)
It will be important for you and your servers to save transfer data. And it will be important for those players on a measured connection. You need to consider how many players are there, and how much data transfer per unit of time they need. Having a server and connection that can handle more will have a monetary cost for you.
If the player sees the wrong values because they tampered with them, it won't cost you.
Let us put this in terms of information security. There are three main properties of the information we want do defend:
- Confidentiality. I believe there are no confidentiality concerns here.
- Availability. The local files are available even when there isn't a network connection, or the network connection is of poor quality.
- Integrity. The local files could be tampered with or corrupted. Also, sometimes they can become outdated.
This tells us that having local files is better. But we need some kind of integrity check and update check. And let me reiterate that you should not worry about the integrity check.
Thankfully, we can address both checks in a single one: when launching the game - or when you first need the data - ask the server for a checksum of the files. Compute it for the local files and compare it with the checksum from the server, and if they don't match, download them again. You may also add a timestamp so the client can bypass the check if the server is saying that it is a newer version of the files than the client has downloaded.
However, that is an extra request (one for asking for the checksum, and one to download). We can do better, let the client tell the server what it got (checksum and timestamp), so the server can simply reply "not modified" or reply with the file. Or perhaps just a timestamp, if we don't care about the integrity.
Ah, but that request could be faked… Look, if this is text data, this is fine. The players that tampered with it is only affecting themselves. If they got to the point when they bypassed the checksum so they can tamper with their own copy, let them.
It is when we talk about player-player interactions that you would have some concern. To prevent cheating you need to have the server decide all rewards, control the player stats and inventory, and have the server validate all interactions. The local copy is both to reduce data transfer and for performance. But your game logic should remain on the server.
I have been assuming we are talking only about text data. But you can imagine how you could start doing something like this for textures, models, and so on. Which have their own considerations (e.g. if the player can modify the textures, can the player make an x-ray mod?).
Also, as I was saying, stats and text are not necessarily on the same bucket. yet, that depends on how authoritative the server is.
You could also imagine how you could even have it update without closing the game. Or how you could have the server generate diff patches so the client does not have to download the whole files, only what changed. It can get quite complex. However I believe I gave an outline of something you can get working that address the issues at hand.