Woah!! That went by fast!
Had to take a break to get my blood sugar back up to normal, but I think I’m nearing the 65% complete mark already!!
1 Like
Me: “I gotta change the logic of the stagingLocation PreCondition to account for the new parkour challenges, and not make the player throw themselves off of ledges to get to something that’s really near.”
Me: (starts to behold the scale of the problem)
Me: (Implements a simple parkour pathfinding algorithm that finds safe connections with the lowest possible loss in climb height, but will only offer one auto-climb upward, if necessary.)
Me: “Wow that was way harder than it was supposed to be. Okay, what percentage are we at now?”
Project Outline: 67%; up from 65%
Me: “Hmmmmmm…”
2 Likes
Are you working on hints in adv3? I made some modifications that I’ve been pretty happy with to the hint system… you just have to have a lot of .reveals (or other tags) in your code for the adaptivity to check with…
2 Likes
I’d be interested to hear what you’ve done there. (I actually devour ALL the code discussions, relevant to my work or not. I inevitably pick up more capabilities I never knew existed. Soft vocabulary, for example.) Tangentially this does confound me a bit. On the one hand, I’d like to become a full partner in sharing code. On the other, I am reluctant to air what I hope to be game play surprises to the very small crowd most likely to encounter them.
To the hint topic, .reveals definitely have a role to play in what I’m doing, but two bigger changes I’m playing with are a) location-specific menu functionality and b) dynamic generation. I don’t envision these being generally useful (in some ways they are more limiting). I am doing it to try and serve a very specific narrative purpose. It has been an interesting enough diversion though, that I’ll probably write it up once the game is released. Y’know in a year or so :]
3 Likes
I don’t know, maybe it’s not all that much compared to what you’re going for… I’ll send some code when I get back to my computer some time…
2 Likes
Okay, so after refining the pathfinding system for parkour I have unfortunately realized that allowing for automatic pathfinding creates problems for the player.
So, as proud as I am for the pathfinding thing, I’m just gonna stow that code in the vault for the moment. Parkour will need to have a bit more intent now. The most pathfinding this thing will do is if you have an adjacent platform with something you wanted to enter or board. Pathfinding will search as far as the adjacent connections, and no further.
Again, this forces the player to be a bit more step-by-step and have more intent, but moving in parkour can sometimes have punishments or environmental issues, so it’s better for the player to approach it one step at a time, just in case pathfinding would have done something unexpected.
I didn’t lose a lot of progress, compared to the rest of the project, so that’s good. Pathfinding was actually a relatively small thing. I’ve been working on a lot more facets of the larger system, and fixing one bug made pathfinding “show its true colors”, but as I start tweaking pathfinding, I was like “Hmmm… Maybe I shouldn’t fix this. This seems like more of a problem than a tool…”
1 Like
I don’t know exactly what the implementation nuts and bolts look like here, but it sounds like it might make sense to implement automatic pathfinding only for sequences that the player has explicitly traversed themselves “manually” first.
So if you theoretically have five different paths from point A and point B and the player has only taken path #1, then pathfinding between A and B will always select path #1. If the player has taken path #2 and #5 but none of the other paths, pathfinding will { take the most recent path | take an arbitrary previously-traversed path | take the shortest previously-traversed path | prompt the player about which previously-traversed path they want to take }.
If the paths are extremely dynamic (traversing the path is basically playing Frogger instead of solving a touring knights problem) or something like that then this won’t work, but it’s something worth considering.
Underlying principle being that the first time it’s a puzzle and the second time it’s a pain in the ass, so whenever possible prevent situations where the player has to keep re-solving the same puzzle over and over unless it’s part of your core gameplay loop (like combat in a JRPG or jumping mechanics in a platformer).
3 Likes
Yeah, that’s how the pathfinding was originally implemented. There’s actually an option in the extension settings that lets you choose whether or not implicit actions can use unexplored paths or not.
The problem is more that this extension could be used in an environment with a lot more dangers, like stepping on certain things could cause penalties and stuff, as implemented by whoever is making the game. I could add in a thing where pathfinding avoids danger zones, but then the game designer might want some dangers to be hidden, or to be inspected by the player and have the player decide if they’re dangerous or not, etc.
Additionally, the pathfinding would need to be deeply-entwined with the “can reach” checks, because attempting parkour on something far away results in a reach fail.
So I would need to do a pathfinding eval for every reach check, in case the player was trying to get a distant item, etc.
Again, it was implemented pretty close to this (was maybe two tweaks away), but it had a lot of uncomfortable implications for how reach checks might start working. If someone was just testing for if something was in reach, and didn’t mean to go somewhere, then would the player be able to teleport distant items into inventory? Do I want to bog down the system with a pathfinding eval for every reach check? Do I need to create a caching system to save on computation? Etc etc
The idea I was leaning towards was creating a custom precondition specifically for handling implicit parkour pathfinding, which would save the result for any future reach checks, but trying to figure out how to get these two systems to work together based on context started to explode in scope quite a lot. Like, what I try to auto-parkour to something in another room? Do I need to edit the preconditions of other actions to account for this? Etc etc.
I might recycle the pathfinding code for NPCs, though.
Again, I’m not deleting the whole thing; it’s useful code, but how to prevent exploits, slow-downs, reference loops, etc was starting to get a lil sweaty.
EDIT: Full pathfinding for both players and NPCs will eventually get added, but I might keep it minimal until after SpringThing. For now, version 1.0 is gonna have to require intent until I figure out a system that doesn’t completely explode, and works better in dynamic and dangerous environments. It’s just that figuring out how to handle this is gonna take a lot more time, and I gotta wrap this up and work on the rest of my SpringThing project.
1 Like
Not trying to talk you into anything, but if you only pathfind through “problem” areas via recorded player pathing then you’ll never reveal information about traps (or whatever), and you won’t have to worry about reachability checks unless reachability is non-positional (that is reachability is a function of something other than the endpoints and the actor traversing them).
Basically if your “main” pathfinding is Dijkstra or something, then you’re collapsing all of the “problem” parts into a single node, and then you have a lookup table of checks for the single node, if that makes sense.
Like I said, not trying to talk you into anything. But this sort of thing is a pretty common pathfinding problem in e.g. roguelikes and metroidvanias.
2 Likes
Ohhhhhh I might have misunderstood you before.
So you mean pathfinding will only use nodes that the player has climbed before? Because I have a system where players need to inspect objects to create parkour opportunities (unless they use a very explicitly-clear parkour command to test it).
So what you mean is that for pathfinding, you need to not only know the route, but you have to walk through it manually first? That would make a lot more sense.
I was also considering borrowing a note from the GOTO command and making it so auto-parkour is a unique command that does things in stages, which the player must accept with the CONTINUE command. Part of this would also tell the player what the next step in the route would be, in case the player would rather do something else.
1 Like
Yeah. First time through you get no pathfinding or only pathfinding up to but not across the “problem” area (if the path goes through a minefield, pathfinding will take you to the edge of the minefield but not through it).
Then if you successfully traverse the “problem” area, the path you used is now available for automatic pathfinding subsequently. That could be by explicitly storing each step (which might be needed if backtracking is part of the puzzle) or just flagging the individual locations/platforms/objects/whatever in the problem area to indicate that they’re available for use in pathfinding.
2 Likes
Ohhhhhhhh, okay! Yeah! I might also do a thing where if routes change, then it resets their availability for pathfinding as well.
Will be making notes for version 2.0!
1 Like
Okay, in the interests of SpringThing time budgeting, I’ve simplified parkour pathfinding, and moved a few other things over to the “2.0 wish list”. This is a problem for future-me!
Parkour 1.0 is now 83% complete!!
1 Like
I am so close to being done.
I’m maybe 98% done. I have to get some sleep. There’s maybe 2 hours of coding left. I cannot believe I didn’t get the whole thing done tonight.
So close.
But if I don’t sleep, then certain people will be grumpy with me.
3 Likes
PARKOUR (VERSION 1.0) IS COMPLETE
AT LONG LAST. NOW THE GET ON WITH THE REST OF THE GAME.
If anyone can help me out, by the way, I posted a question about screen reader accessibility, for this extension’s route listing menu. I’d appreciate knowing how screen readers might work with this, as I’m using @blindHunter’s For Everyone extension.
Also, I generally try to lean as hard as I can into screen reader support, as I am passionate about game accessibility as a whole.
2 Likes
I’m probably way too late for this, but if you make this a module, I will absolutely use it — in currently beginning work on a game (in adv3Lite) where parkour would make a lot of sense and add a lot to the world, so it’d be really cool to have already built!
4 Likes
Yay!! 
Once SpringThing is over, I’m going through my game code and I’m gonna start with the parkour module. I still have some messy connections between it and other stuff, but once I get everything neat and tidied up, I’ll write up documentation for it and let you know!
For what it’s worth, I’ll probably start the process in May, because SpringThing has taken so much outta me. I’m probably going to turn to goo when April 2nd arrives, lol! 
But once it’s ready to be used in other projects, I’ll make sure to tag you!
3 Likes
Thank you! And yeah, be sure to take care of yourself first, I’m not in any hurry. 
(I’m actually slowly recovering from post concussion syndrome, so most days I can only work for a few hours, and some days I’m taken out entirely).
3 Likes
Woah!
You take care, too! Concussions are no joke!!
(Though you certainly knew that already!)
2 Likes
Okay, so you might have noticed it’s October 2023, lol.
Uhhhhhh mental health has been abysmal for the past couple of months, lol.
But also, I’ve been looking over the parkour system in I Am Prey, and realizing that a lot of its mechanics are very specific for that one game, and it might be better to make a module that is a lot more general-purpose.
So…it’s gonna be a while. I am really trying to hold on, so priorities are just being an issue and causing delays with parkour, lol.
6 Likes