Release templates handle command line debugging arguments

[dalexeev]

Godot version:
3.1.1.stable.official - linux_x11_64_release

OS/device including version:
Linux

Issue description:
I don’t know how critical this is, but I noticed that release builds handle command line arguments almost as well as debug builds. Examples:

$ ./your_game.x86_64 --help
$ ./your_game.x86_64 scenes/world2.tscn
$ ./your_game.x86_64 --resolution 2000x2000
$ ./your_game.x86_64 -d --time-scale 0.25

That is, there is a theoretical possibility to skip any scene, change the timescale, expand the window even if it was locked.

I understand that, most likely, there is nothing to be done, cheaters and speedraners cannot be stopped, I just inform other developers about this feature. See also #24716.

[Calinou]

It's possible to achieve --time-scale-like behavior using external tools, so there wouldn't be much point in removing it. We can remove it from release builds to make the command-line help shorter, but that's the only argument I see in its favor 🙂
Edit: I think it makes sense to disable --time-scale in release export templates, but it should be kept in debug export templates and editor builds as it can be used to speed up reproducing certain bugs.

Likewise, ignoring the window geometry restrictions can be done using external tools.

[dalexeev]

Anything can be done using external tools. 😃
But some things are too easy to do. IMHO

[KoBeWi]

^
Yep, if something is more difficult to do then it means less cheaters. I don't think it's preferable to let people go full "oh it's Godot game, I can easily override the time-scale".

On a second thought, older games had command-line arguments that enabled in-game console and it was a standard way to use cheats, so not sure.

(talking about external tools, I once ran game in XP VM and used snapshots to "save" game at any moment like in emulator, heh)

[Xrayez]

The command line parsing should hopefully undergo major changes in #26213 which could possibly allow more fine-grained set of options to be present under different build configurations.