When creating games it is important that you play test the executable file to make sure that the final compile is correct and has no unforseen errors or differences. This means that since you have no access to the debug console, nor to the compiler window, it can be difficult to pin down and debug any problems that you may find.
However there is a fix for this, and that is to use command line parameters to set certain properties when the executable version of the game is run.
NOTE: This is available on the standard Windows target module only.
The first thing you need to do is create either a *.zip file or an installer file for the game (Do not create a single *.exe file as this functionality is not available for that format).
You must then unzip (or install) the game as you would normally, and once you have that done, you need to create a Shortcut to the game on the desktop. This is where we will add in the parameters to be passed to the *.exe (to create a shortcut, right-click the game executable and then Send to > Desktop (create shortcut)) .
Once you have made your shortcut you can then use any of the following parameters in the target path:
-noaudio : This switches off all audio in your game, no matter whether you are using the legacy sound functions or the new audio ones.
-inawindow : Forces the game to start in a window, even when set to run in fullscreen mode.
-output <filename> : sends console output to the filename, including any debug messages that you have in your code base
-debugoutput <filename> : sends console output to the filename, excluding any custom debug messages, but including extra information from the runner for bug reporting.
-software : Will force the game to use Software Vertex Processing instead of hardware for rendering the game graphics. This is especially useful for those PCs that are using an on-board Intel GFX chipset or show display issues on older machines.
-intel : This will switch on a fix for bad Intel drivers, no matter what GPU is being used. This work around for those bad drivers will slow things down, giving a noticeable performance hit for your game, so if you do not need the fix do not use it.
-vanillaGFX : Using this switches off any check for driver manufacturer, and can be very useful for testing your game "as is".
It's worth noting that the filename in -output and -debugoutput can be the same one if desired, as the file is opened and closed on each write.
Adding A Parameter
You should now go to where you created the shortcut to the game executable, and then right click on it and select Properties.
This will open a window similar to the one above. Here you can add into the Target path your command line. Simply scroll along to the end of the given path, add a space, then the parameter string. So, for example, to create a debug file output you would have:
D:\Users\Me\GameMaker\CustomLoadBar-Default-126.96.36.199\CustomLoadBar.exe -debugoutput debug.txt
This will now create a file called "debug.txt" in the same location as the executable (not the shortcut!) with debug and compiler information from your finished game. Click on "OK" and then use the shortcut to run your game to have it use these paramters and help with your debugging.
The YoYo runner also benefits from a special command line parameter:
-game <filename> : loads the given game file
Why would you use this? Well, normally you wouldn't, but if you wish to have more than one version of your game running at a time it can be done using this, making A/B comparative tests far easier. With this method you could focus test with someone else or, as the designer, get a better feel for things by doing side-by-side tests.
To set this up, you will need to know a couple of things beforehand. To start with you will need the path to the YoYo Runner itself. This can be found in the Appdata Roaming folder, using the following in Explorer: %appdata%/GameMaker-Studio/
You will also need the path to the <yourgame>.win file, as this is what we are going to point the runner to. the easiest way to find this is to go to the Temp folder and just search for *.win, as that will show you all those available and you can simply pick that which you need to get the full path from.
Now, we could create a shortcut to the runner like we did for the exe, and then change the parameters as necessary, but that means having to open and edit it between tests, which defeats the purpose of our using this functionality for side-by-side testing. instead we are going to create a couple of tiny "batch" files to handle this.
Create a new text document on your desktop and open it in Notepad. Add the following:
START %appdata%\GameMaker-Studio\Runner.exe -game <LOCAL TEMP PATH>\<GAMENAME>.win
You need to to set the temp path to point to your game *.win file, and then save this as "GM_Test_1.bat" to your desktop (be aware that Notepad will save automatically as a *.txt file unless you choose "all files" from the save dialogue options). An example of how your final command should look would be:
START %appdata%\GameMaker-Studio\Runner.exe -game D:\Users\Mark\AppData\Local\Temp\gm_ttt_44657\Delve_Pt6.win
Now, create another text file and add the same line, only this time you point it to the path for the second version of the game that you want to do side-by-side testing with, and you would save this as "GM_Test_2.bat".
Now you can double click either of them to bring up the different versions of your game, and having them as batch files means that you can easily open them again to edit them and change the game being tested.