I'm not sure why you would think that this function has anything to do with arrays. I suggest re-reading its manual entry in order to allow you to understand what it is really used for.
Correct. This would require run-time evaluation, which, in turn, would require GML to be an interpreted language, which is not the case (since Studio 1.x).
It
is possible to mis-use ds_maps as collections of pseudo-variables that are possible to probe for existence without risking to blow up the program... at a corresponding performance cost... but I wouldn't recommend doing so, as there should never be a situation that requires checking whether a variable exists or not, anyway (if this is "required", there is most likely a better way to achieve the desired result).
There are a couple of important distinctions to be made here. You may be aware of some of them already, but I'll list them all for the sake of completeness.
- A variable may exist and hold a value that follows a valid format for a sprite ID, but still not resolve to a valid sprite.
- A variable that does not hold a value or does not exist can not resolve to a valid sprite. It can't resolve at all; If attempted, an error will be thrown.
- A sprite that does not exist is not undefined. It just doesn't exist.
- A variable that does not exist is not undefined. It just doesn't exist.
- undefined is the state of being declared but not defined, not the state of not existing.
An approach I'd consider suitable would be to take manual control over resource handling instead of relying on the black-box function that
game_restart is, because as long as you are in control, if something goes wrong, you at least know where the problem lies (within your code) as opposed to having to figure out whether it even
is your fault in the first place (and, therefore, whether you can do anything about it without rewriting everything).
For example, if you're dynamically adding sprites at "game start", you should dynamically remove them at "game end" - so that they can be added at "game start" again when you're restarting the game. Alternatively, implement your own method of keeping track of which sprites and subimages are loaded at which time, and use this info to determine when what needs to be loaded (or unloaded if it's currently not needed for optimization purposes). Instead of calling
game_restart, return to your game's title screen or wherever a restart would take you, and using the info you were able to ensure to be suitable for the restarted game state because you are in control of it, you can go from there.