The levels in TARJECTORIES are procedurally generated, using a lot of calls to the Random Number Generator. Since the output of the RNG is stable for a given seed, the only variability from one runtime to another is the number of calls made to the RNG. Since the number of calls to the RNG in TARJECTORIES is deterministic, this gives the game the same random procedurally generated levels each time the game is played. Fortunately, those levels aren’t too bad to play.
The RNG sequence will vary if you die and play a new game without quitting/relaunching the game, but if you do quit/relaunch it will be the same sequence of levels every time.
I became worried that the game was too sensitive to the RNG, and wanted to capture the level data so that I could re-generate any of the levels in the procedurally generated sequence if I wanted to, even if the game ends up getting modified in such a way that the number of RNG calls changes, which would otherwise screw up the level generation.
To that end, I just wrote up a little script that writes the level data to a .json file, and played through the game, going through two cycles of the 18 procedurally generated levels, so I could get the original sequence plus the level sequence from GE Mode. This was pretty straightforward, except the part about where GameMaker writes the file.
It’s complicated and not easy to understand. GameMaker runs sandboxed, so you can’t just write files anywhere you want. There’s documentation that explains this in the manual, but even after reading it several times, it’s still not entirely clear where you should look to find a file.
My intent in this post isn’t to write a tutorial that guides you to a complete understanding of where GMS writes its files, but I will explain how I found the location.
GML has a built-in variable,
working_directory, which is a path on the filesystem where the game.exe is running. The confusing thing about
working_directory is that it can return two different values. In certain contexts, the working directory is literally the location where the game.exe is located. You can read files from here, so if you have any “included files” in your project that you need to read from, this is where they’ll be. The thing is, this location is read-only (to GameMaker) so you can’t have your application write any data here, not even to update existing included files. You have a separate location where GameMaker (and all well-behaved Windows applications) can write files, in %LocalAppData%.
This is where it gets weird for me, and I still don’t entirely understand what’s going on.
I run the project out of GMS, and to help me find the file I’m writing, I draw the working_directory to the screen, and I get this:
So I go there, and I do not see the file that I wrote!
Eventually, I found the file I was looking for in C:\Users\XXXXX\AppData\Local\[project_ name]
I was able to find it because I went to %LocalAppData%, sorted by date last modified, and looked for the most recently updated directory until I found it.
What’s the first directory, then? That’s where GMS builds your project when you run it through the IDE! GMS also uses %LocalAppData% to store the temporary build that it creates when you click Run Project. But this is the read-only working_directory location that is where the game.exe resides. The game.exe then creates its own directory in
%LOCALAPPDATA% which is named whatever you named your project (eg., [project_name]) and this is the directory that GMS will allow itself to write to. And of course you can also read files from here, too.
The confusing bit is when you call
working_directory in the context of, say,
draw_text(x, y, working_directory) and
working_directory returns the read-only path, but when you call
working_directory in the context of
fileID = file_text_open(working_directory+"file.txt");, working_directory returns the writeable path.
The behavior of
working_directory is what’s confusing. It would be a good idea, I think, if YYG were to create a GML variable called “
working_directory_writeable” which was an alias of the writeable
working_directory that always returns the writeable path. There should then also be a companion variable called
working_directory_readonly They could leave the behavior of
working_directory as it is, to avoid breaking anything already written. It can return the readonly directory or the write-able directory, just as it does currently. But if you need to be sure the path to the writeable directory, then you could use “writing_directory”.
So, moral of the story, if your your GameMaker Studio project wrote a file to
working_directory, you will find it in C:\Users\XXXXX\AppData\Local\[project_ name] — not the location given by
working_directory if you draw it to the screen.