I know it is not as easy as it sounds, I wish it was... would've made QoL changes so much easier in general.
Though this brings up a couple of questions: If it is called 'Desert' in the system, I am curious how stuff works if two maps have the same labeling. I suppose to some extend this already makes it a practical nightmare to make any changes on either of the maps, as one desert is not the other desert.
Secondly, why was this implemented this way in the first place? was the original desert just forgotten, ignored, or didn't it matter for data and was it therefore just the best fitting name for the map?
It will take time to implement such feature, thus I don't expect Ziax to put someone on just changing all entities of 'Desert' to 'Oasis', but let's say Parkour is getting a random update, adding new modifiers, new maps, new system, who knows what will be added or changed. Wouldn't this mean all the lines of the coding have to be checked anyway? if that's the case, then wouldn't it be possible to change all those lines?
This is something for the long run, but if parkour is getting an update, the hours you have to put into this specific change can probably almost be voided compared to the entire update. Obviously, Laura, you know way more about this than I ever will, so I would love to hear your thoughts on this for sure. Not only for this suggestion to get through, but also just for my understanding of your fever dreams knowledge of the working field.
Thanks for your response anyhow, you never fail to amaze us with your activity and involvement in the community <3
No worries, I'll answer what I can.
1) It doesn't
just use the name. It pairs the name with the difficulty (easy_barn_1, simple_mobs_4, etc) as the key.
So the stats will have both an easy_desert_# and a hard_desert_# to be able to tell them apart.
Basically the game talks to the stats databases and goes "Give me [player]'s best times and medals for the map [easy_desert_2]" so it can load in your stats. But you change the map name, now it's going "Give me [player]'s best times and medals for the map [easy_oasis_2]", which the database then goes "I don't have any stats with that key for that player... They must not have completed that level."
This is why you'd need to rename +14 million user stats too.
2) I don't know who originally coded it this way, but in all honesty it's not a bad way by any means. It works really well for what it needs to do. The way it's made allows for a lot of things to be done, but renaming levels wasn't one of these things. It's like how a tractor engine is amazing for torque and durability, it's just not been designed for speed.
Why two desert names? Probably the builder making the levels just didn't realise there was already a desert in a different difficulty, but the system could handle it fine so it didn't matter.
3) Ideally no. When you put someone on an update you
don't want them reviewing and updating all the code. If a Dev has been tasked with adding in, say, 3 new maps and 2 new modifiers, then time should only be spent making and testing those, not the whole parkour codebase.
They should just need to add in the respective map info into the databases, and spend time coding how the new modifiers affect the players.
Of course, if you're a Dev and you're knee deep in a project and you see something which can be done better and won't take up too much time, then yeh you should improve the code, but rewriting or just reviewing all the code for a game takes way too long.
But for this specific thing, renaming a map, the code isn't the problem. As I said the issue lies with renaming all the user stats. You cannot rename that many without backing up the database first, because if something goes wrong during the update you're running, you've now deleted all that user data...