Across various projects we've had several different systems, some working better than others.
Whenever possible and reasonable, a live update is best. Everybody loves it. It feels so much better than forcing a recompile, even if it is a partial recompile of scripted data.
Most projects had several different ways to reload and reparse data. Some subsystems would use one kind of adjustable data, other subsystems would use a different kind of adjustable data.
Some built all the data through tools. There was no hot-loading of data. Designers could make changes, but in order to see them in game they needed to save their stuff, stop the game, build the game, and re-launch the game. The incremental process was much faster than a code build, but still required several minutes. This was fairly common on certain consoles like the DS where it was somewhat difficult (but not impossible) to link between the PC and the console. One such editor worked well but was occasionally frustrating. That level/event editor, as just one example, had a transition trigger where the character enters a region for a doorway as the trigger area for the source map, and the this causes a load and transition to the target location for the destination map. It could take 2-3 hours before the level designer was completely happy with both ends of the doorway trigger, each time requiring building a new DS build but not a rebuild of the source code. It would have likely taken 2-3 days if this was in code so the fine tuning time was an improvement, but it could have been better as far as the designer was concerned. (When offered the choice of cutting features to improve the tool, designers preferred the annoyance.)
Some have required no tool changes, the executable monitored the source directory and automatically applied changes. This is particularly easy to do to for models and textures when the game is built with proxy items. We've had this on every PC game and about half of the console games. They can have Maya up, modify the model, hit export, and watch on the other monitor as the model vanishes and gets replaced instantly. I've seen (but never worked on) projects where the tools link directly into Maya, moving a vertex in Maya resulted in the model's vertex moving on the game screen. That seems harder than a file system monitor, but if you decide that is cost effective, it is a thing people do.
Some have used excel spreadsheets that designers could make changes to. There was an "export to xml" button they could press that ran several excel macros, potentially checking out files, then exporting to xml data files. These files were picked up in two different ways. First, the build system would compile them into an efficient format that gets loaded directly when the app started. Second, the game monitored that directory for file changes, and when any file was changed the simulator stopped, the xml parsed, and modified values re-imported and applied. This had a potential to break the game in progress. Some changes worked well for this type of editing, some changes required a restart. An example of this was adjusting our story tree in one game. The designer or writer could modify the spreadsheet, hit the button, switch over to the game which detected the file change and reloaded, then use a cheat code to jump to a specific node of the story tree. Usually this worked quite well.
Some have had built-in systems that allowed live tuning of data. On the PC you could hit a debug key, on the consoles this meant hitting a magic key combination, both opened a bunch of cascading menus on screen exposing tens of thousands of options and variables that had been created over the years. As an example on Tiger Woods, I built a fancy grid to show the surface of the putting green. It had little animated knots along the grid to help show the direction and speed of the slope. In this case designers could view and modify the data on the console but needed to write them down and hand-enter the final values. Designers could live-modify the tunable constants controlling the speed of the knots, write down the new values, and modify the script. They could also live-modify the spacing of the grid lines both horizontally and vertically, the number of grid lines in each direction, and several other values. IIRC there were about 10 different adjustable values I put in there. The designers could rapidly modify items and see them on screen instantly.
Still others used a tool as a side window that allowed modification in game and the option to save. Designers could make changes to live data in another window, watch as they took effect, and saved when they were happy. An example of this was on Sims 3, designers could change values for how much interest an object had. They could adjust values, perhaps making "evil" sims slightly more interested in sabotaging an item, then set to a fast speed and watch how often it happened. If they weren't satisfied, they could change the number that was instantly reflected, and watch for another several sim-days to see how often it happened. Once satisfied, hit the button to save the file, and all is well.
Some games have allowed modifying the script code, this one was rather advanced. It would stop the simulator, reset all of those objects that are in use (in turn resetting any Sims that were using the item), unload the items, replace the script code, and replace the items, then restart the simulator. I never looked into the mechanics, but I'm pretty sure they relied on the save/load system for it, saving off those objects to a serializer stream, deleting them from the world, rebuilding and recompiling the script, and then loading the objects into the world with a deserliazer stream. Once you get used to having this type of feature it is painful to not have it.
Exactly what kind of system you use is heavily dependent on the system you are tying it to.
Hot-reload of models and textures and animations is not too difficult to implement on the PC, saves artists a cumulatively hundreds of hours, possibly thousands of hours, over the course of a project when you multiply the number of people times the number of reloads over 12 or 18 or 24 months. Usually a low cost, usually a high benefit, do it.
A more complex live preview system like we used in Tiger Woods with a comprehensive menu with graphical sliders and such has a fairly high burden to create, sometimes the cost of creating tunable values for a specific features is large and never fully recovered. In that game, since the engine has lasted for a decade, over the long tail it becomes worth the large up front investment. Moderate to high cost, moderate to high benefit, may or may not be a good fit.
Some data has complex interactions and is very difficult to run a live update. Other times making it adjustable introduces penalties or forbids certain important optimizations. High cost, low benefit, bad idea.
). Granted you need to be able to write such scripts in a way that they can auto-recover when re-loaded, but my point was to highlight another potential advantage of a VM. As to whether or not you're interpreting script directly or compiling them into a bytecode first, is more of a optimization and obfuscation thing than anything else.
