Daily VA-11 Hall-A 2022 20

日本語版

There’s this video I saw a while ago that I regret not remembering who it was or what it was about because unlike every other case this month, I actually mean it in a “I wish I could show it to you” sort of way.

The reason is that the video made mention of a trend in videogames reviewing that I noticed for years and I wasn’t able to put into words. This idea that videogame reviews were usually more like “appliance reviews”.

What it means is that reviewers focus so much on the technical aspects, the framerate, the bugs, the lack of sometimes oddly specific features, over any specific creative merits, or many times in spite of it.

Now, the truth of the matter is that videogames ARE appliances of a kind. They’re software, they’re entertainment whose main method of engagement is interaction, and faults on this front will be felt. You can wax poetically about books all you want but if the font makes it hard to read then it will sour the story somewhat.

However, videogames are also meant to convey stories, narratives, characters, ideas, and yet all of these tend to be ignored for the sake of the technical side.

One of the really early criticisms of VA-11 Hall-A that stung me the most was people talking about the lack of a quicksave feature of any kind as if the game was absolutely unplayable, I was disrespecting them personally, and we were lazy for not adding it.

No, I am not using good ol’ hyperbole. THEY probably were though, one never knows with online comments.

In truth, the save system as is, was not only us working with what we could do, but the whole game was designed from the ground up (or as much of “ground up“ as the frantic patchwork of a code can be) with the design accounting for it.

So if you were one of the many that felt aggravated by the lack of quicksave, then congrats! You’re getting an explanation whether you want it or not.

So first let’s explain what “saving” and “loading” entails on the technical side since it’s not something everyone stops to think about.

Simply put: The game makes a copy of all the relevant states of the game the moment you save into a file of some kind. Loading, meanwhile, involves reading the file in question and based on it restoring not only all the relevant data into the game, but also loading the relevant scenes as needed.

Here’s a fun experiment for you all: Pick any game with save points and some sort of movement (first ones that came to mind were the PS2 Yakuza games and Atelier Totori), keep note of your character’s position when saving, and then notice the position they’re in when loading and if it’s the same.

Having specific save spots allows the programmers to only concern themselves with the specific place the player saved in rather than any number of other factors.

Got that? Alright.

Next I need to explain to you one of the many intricacies about the VA-11 Hall-A text framework. And I will preface this by saying that I owe the world to that framework. As I explained days ago back in 2014 text frameworks, much less the kind made thinking about a lot of text, weren’t commonplace at all. So the one in VA-11 Hall-A was one of the few out there, especially for Gamemaker Studio. So despite a lot of how the next paragraphs might be perceived as “bashing” and the like, it was the best I had at a moment where I had zero knowledge and I am aware that new versions were released since.

SO ANYWAYS, the reason you can’t save anywhere is mainly because of that framework.

More specifically, it had functions like flags and branching and whatnot but they existed inside the instance of the framework, rather than something that could be accessed out of it (eg: it remembers a dialog choice using the built in dialog system but not with variables and flags set by me), not only that but because I didn’t know much programming back then and I didn’t make this framework specifically I ended up building the whole game “around” it.

Basically, I noticed how to call the text, how I could manipulate things (like variable changes and calling characters) from inside the text, and then I made everything else just call it as needed. For example the process for dialog that branches within dialog itself looks something like this.

Fun fact, if you know that there is a branching that occurs outside of mixing drinks you can notice a brief delay of a couple of frames between dialog lines because the text frame is being destroyed then called again.

There is more to the way the logic works, and maybe one day I’ll map it all for kicks… but not today.

So to save the game we’d need to:

Save the current spot the player is at in the progression of the game.

Save all the necessary variables like Jill’s money, bar score, jukebox list, etc.

Save all the flags like drinks served, branches triggered, items purchased, deadlines met, etc.

Then loading would require all of this to be loaded in the right places and depending on where you are in the game either load Jill’s room or the bar, then loading the sprites in the right positions and expressions where you last saw them, on a specific point of the dialog.

And while the last part gave me a headache I still remember, I was actually stuck way earlier than that.

You see, when I say the dialog framework loads a specific point in the dialog I mean that I mark a spot in the script with say… “E:21” and then tell the game to create a text box with the dialog from a script starting at E:21. And the gap between E:21 and E:22 can be anything from a couple of lines of reaction to what you served to Dorothy’s Mega Santa Gangbang story.

I had no way to tell the game to grab any specific point in between E:21 and E:22. Hell, we just barely have a dialog log because I figured it had to print SOME variable and after half a week of doing the code equivalent of replacing individual lights in a christmas light installation I found which one did it.

You can probably think of many solutions, I can think of many solutions, but 2014’s Fer was just happy he could have dialog at all.

However, 2014’s Fer was aware that this was gonna be a problem since early, so we basically designed the whole game to be paced around the fact that you can’t just save and quit. Each half shift had to be comfortable to sit through in one go. While I wasn’t able to code a way for the game to remember which specific spot of the script it was at, I was able to make it load onto a specific point of the script just like when you start a new day.

Now, I wouldn’t call this an excuse because there’s nothing to excuse. We were aware of a technical shortcoming from lack of experience and we designed the game to accommodate it. To excuse it would be to flail our arms like Kermit the Frog and say “we didn’t know better” while doing nothing about it.

But it still stung to me when I saw people point this out in a way that made it sound as if we didn’t have any save system whatsoever or as if even that was somehow detrimental to the rest of the experience as a whole.

There’s that saying that nobody sets out to make a bad product, and while I wouldn’t call VA-11 Hall-A a bad product even in my worst self-deprecating moments, hopefully this illustrates the point. We didn’t make the save system we had out of neglect, laziness, malice, or some sort of archaic mindset. We just… couldn’t.

Oh, also, if you’re wondering why there haven’t been any mobile ports, the lack of an autosave if a big no-no when you’re dealing with games on phones.

If you’re playing along, today’s the second day of the third week, the one where Gaby gives Jill a letter asking to see her again.

I skipped that because of all this technical talk, so let’s go back to plot tomorrow.