Alright, let’s keep going.
I’ve had time to think how to tackle the next step, so I had this idea of creating a list of locations per chapter and then the resources are loaded based on said list.
The keen-eyed among you might’ve noticed how assets are loaded via strings. In theory that means that if we have a list called locationlist with “cafe” as the third item, then we could do something like load("Scenes/"+locationlist[2]+".tscn").
Why “2” if it’s the third item? If you’re reading this without knowing much about programming (first of all: Welcome and thank you for your time), lists and arrays start at 0 so the third item would be 2.
Also yeah, the code is incomplete, I’m just writing from memory to illustrate my point.
This would modify the start of the chapter like this.
This, of course, hinges on being able to load things outside of a variable, which is actually the first thing I want to test today.
First things first, we initialize the list… or rather the Array. On reading the documentation I learned that Godot’s lists, while they use the same syntax I’m familiar with from elsewhere, are actually called Arrays and they can hold more than one type of value (and you can tell it to limit itself to a specific kind of value).
This is good to know in general but (thankfully) doesn’t change our path forwards.
Then we create a function with the loop that will assign all of this at the appropriate time.
If you’ve never seen a For Loop, it’s actually one of the most fun ways to iterate through code. You tell it essentially “for each THING in this structure, do this” but THEN because it stores THING in a variable (in this case i which is the most traditional one to use but not the only one) it’s not just “repeat this many times” but “repeat this many times AND use the thing while you’re at it”.
Knowing about it opens up so much stuff you can do with games, it’s great.
In this case we’re telling it to go through all the items in locationlist, and build the Dictionary with the item as a Key and then load something using the item as part of the name as value.
Reminder: it’s the loading part that we’re interested in testing right now.
…actually, with that in mind, let’s add a print check for it.
I also caught the fact that I was saving it all onto the wrong variable while at it.
For the current test, I will simply duplicate the current assets in the LookScenes folder.
Wait fuck, I needed to also instantiate the assets after loading, right?
One step at a time…
Anyway, for now we do this.
We start the game, aaaand…
Well, if they’re loaded, now we need to do SOMETHING with them…
On paper, this is the exact same code that worked last session, but we changed how the dictionary is filled and what key it loads.
We have an error. This error can mean a) You’re trying to access something that doesn’t exist or b) you’re trying to access something you can’t use.
Unless the print is lying to us, it means that indeed skipping the instantiate step was not a good move.
So we do this
With this temp loads the asset and then instantiates it as the Value of the key.
Now, this approach hinges on the assumption that instantiating is what I understand instances as and they’re basically “copies at the moment of creation and no further”.
But anyway, let’s try again.
…we get the same error.
Notably, though the error happens SPECIFICALLY when we try to pull the dictionary value to do something with it.
So let’s add one extra detail to the print at the for loop.
This should tell us what the hell we loaded.
And indeed it does, not only does it load properly but it means the print check didn’t lie.
We have a Node2D loaded into the dictionary, what we need to adjust is how it’s called forth.
….actually, here’s a wild thought: The printing happens while the loop is taking place, what if we check for the existence of the instanced nodes immediately after that command?
Well, the result is neither A nor B but a secret third thing… a crash.
Meaning that we’re either not accessing the information correctly, or things aren’t getting saved to the dictionary.
We know that the list is successfully added because it then uses those keys to seemingly load things. We also know that the command is executing, so the issue is taking place AFTER the loop ends.
We’ve officially entered the Tire Check stage of programming, which is what I call the part where I start doing random things to find where the problem is just like when you put a tire underwater to find where the bubbles come out of.
First test: Is the dictionary empty?
No, next: Would that code pass if it WAS empty?
Yes. So the problem is not that the dictionary is empty but instead how that information is being accessed.
Next: Can we check if the dictionary has a specific key?
OKAY the key is not detected. Now we know what it couldn’t access.
However, we know from the earlier experiment that the dictionary isn’t empty.
So what happens if we check for the other key?
…
…can we check the size of the dictionary?
It’s not that we couldn’t access the dictionary earlier, but that the key we were looking for didn’t exist. Now the question is WHY.
…
…
…
………………………………..son of a bitch motherfucker it’s so obvious now.
Here, let me highlight it.
In short: I’m not adding keys but instead overwriting the dictionary as a whole.
It should instead be like this:
Now let’s see if the size of the Dictionary changes.
It did.
So we do this…
It works as before despite the other changes. Also please note the new button Nashira made. Thank you.
There’s one more change we’re gonna make.
First we initialize a new variable.
Then we add this bit.
And then we go back to the earlier code and change this…
The result? On the outside when you play nothing changed, but the code has now become more flexible and it has laid the foundations for what we ACTUALLY want to work on. As you can probably guess “cur_loc” will change with the Move buttons that will come up next and it will determine what to show.
I kinda like how this session turned out because it’s how programming is 99% of the time: You get stuck on an extremely dumb detail but learn a lot in the process and nothing changes on the outside despite this, but without the change things become precarious.
We also tackled absolutely nothing from the To-Do list, by the way, but that was expected for me going in.
We’ll stop for now, aside from my brain feeling fried already, I need to get photos for the actual locations.