Why should you try to avoid execute_string() and execute_file(), in Game Maker?
- They make execution of your game slower. When Game Maker starts, it converts all scripted GML into a byte-coded representation, by verifying the syntax, checking the parameters and converting them into something that GM can execute much faster. Your game runs faster because this first step of interpretation of your programming takes place the start of the executable, and not while it is actually running the game. But execute_string() and execute_file() always apply this parsing during the game, when these commands are called. This can introduce a performance drop in your game, especially when used in continuously (step, draw) and semi-continuously (key, collision) triggered events.
- It is a bad programming practice for beginners. The two commands make GML scripts self-modifying: GML scripts can modify or add code 'on the fly'. But this is not possible in all programming languages (because the result would have to carry an interpreter or parser around). You would face a drawback in understanding and using languages such as C++ and Delphi if you are unaware of the alternatives to self-modifying code.
- They allow malicious script injection. Where execute_string() is used to parse user input, or execute_file() to run an external script, a user may introduce their own script and retrieve a great number of it's resources from your game and / or introduce cheats to their merit. To make your solution safe to malicious script injection you would need to strip it from all commands that could possibly allow for injection. And that is harder than you may think.
- Rewriting pieces of script to optimize or finetune them to runtime circumstances. One could argue whether this is necessary and whether the parser interpretation is faster than a well-adjusted script to begin with, but this can be tested on a per-case basis.
- Parsing expressions from the user. For example, including a calculation to plot a path. Parsing expressions is complex and may be slow, so it's better left to the built-in parser.
- Allow building of modifications such as levels, plugins and fixes as separate scripts without redistributing the game. There are few (if any) alternatives to this apart from building a custom parser or interpreter.
Unfortunately, these are not always the reasons why people advice using them in the Q&A forums. They are promoted because:
- You want to get away with doing less. Some of the alternatives may require a little more programming effort, or an overal redesign of particular concepts of your game (we can argue that your game may require a rewrite should it become dependent on these methods).
- People simply do not know better. Sadly, this is more often the case in the Q&A forums. I'll be as blunt as stating, if you do not know an alternative (not counting the valid reasons above), don't consider yourself expertised enough to answer the question.
We'll make it a bit of a game (without a prize, apart from the usual glorification). You give your piece of execute-infected script (provided it does not fall into the list of valid reasons). Others are welcome to reply and invent alternatives, by trying to eliminate execute_() (obviously) while keeping its functionality intact. As this often requires a different approach in the game, feel free to elaborate.
First we need a script.