MilesMouse
patreon
Progress Report 4/29/2022
🕑 Added 2022-04-29 21:28:59 +0000 UTCEvery time I tried to come up with a Friday intro today, I realized that I already made it in a past post! >.< Here's what I got done this week:
- Updated the "Speedy" character to move just like the player, but faster
- Slowed walking speed and obstacle speed
- Lowered the maximum stomp height to give the heroes just enough room for a safe space
- Began work on hero & NPC navigation around obstacles
Alright, explanation time! :D
I changed the Speedy character by request -- one that I agreed with. As it stands in 0.1.1, Speedy is just Glutton but faster. Moving like the player but faster makes him more unique and makes him feel faster in general. I'm not the best at explaining movement, so you guys will have to see for yourselves by playing 0.1.2 when it comes out. :)
Slowing down the walking and obstacle speeds was inevitable with the addition of heroes. It may still require more tweaking, but it's now much more manageable. The same thing goes for the lowered stomp height; it may need to be lowered further to give players a better chance at saving NPCs, but for now the slightly lowered height will work.
Now for the real meat of the post: NPC and hero navigation around obstacles. After turning on obstacles for the first time since adding in he heroes, I realized just how vital this is going to be, especially for the Tank character. The Tank only moves in four directions, and if you're above the obstacles, he's going to wanna move up and only up. Other heroes have similar problems to a lesser degree (except for Enlightened, who could care less about worldly problems like obstacles).
There are three key things I want out of the navigation: I want it to be effective, to feel natural, and to be light on performance. Performance in particular is what I'm focused on right now; there will be a dozen or more NPCs on the screen at once all doing their own navigation, and that may have potential to bog down CPUs if I get too careless.
I'm working on my own simple navigation system right now. I've been fighting my lack of knowledge of Godot the whole week, and so far I've managed to set up a detection zone above each hero that can detect obstacles.
A lot of the learning came from collision masks vs. layers and how to use signals... stuff I knew about but forgot since I last used them. ^^; Anyhoo, the way this thing works is that if an object with an "Obstacle" tag falls into this detection zone, the hero will move horizontally towards the nearest obstacle waypoint.
These obstacle waypoints pinpoint where exactly the heroes and NPCs need to move to stay clear of the obstacles. I suppose it's a bit of a crude version of pathfinding, but with pre-set waypoints for each obstacle.
The hero obstacle detection zones may not stay, however. After getting this far, I came up with a Plan B that seems more appealing, but that depends on things going smoothly.
Plan B is to gather the list of waypoints from each obstacle and have the heroes and NPCs move towards them as soon as the waypoints are spawned in (with the obstacle, of course) and below a certain height on the screen. With this, there's no need to have twenty collision boxes on the screen looking for obstacles.
Regardless of which plan I go with, I have to figure out how to get the waypoint coordinates to the heroes and NPCs. It's not as simple in Godot since each obstacle has its own scene with its children contained within, which basically means they're out of range for the objects in the main scene (to my knowledge). The simplest solution would be to throw every obstacle into the main scene out of eyeshot and have them teleport to the obstacle spawner rather than... well, spawning in. However, I don't know how many obstacles I'm gonna have, and that would clutter up the scene like crazy.
I currently have a couple of ideas to get the list of waypoints to the ones that need them, but I'll fill you guys in on what works next week. You know, assuming I succeed by then. :P
I hope all of that made at least some sense. I'm still trying to wrap my head around it, myself. ^^; If I'm gonna figure this out, I'll need some brain food in the form of Taco Bell! Ooh, and on a semi-related note, I hope you guys have a great Cinco De Mayo! I'll see you guys again next week!
Comments
Bombur
Oh yeah it was awesome! Besides just maps, people were able to program entire game modes and scripted events on their maps. They had all groundwork laid out to set up buttons and triggers that would do things like open doors, alter the map, spawn things/despawn things, etc. Some people got pretty crazy with it.
Minecraft's redstone circuitry is no joke. That stuff can get pretty friggin' complicated, haha! I never used Halo 5's forge mode, but that does sound like it has lots of potential. I'll bet people made some crazy stuff with it. :P
Bombur
Yeah I have no idea how Godot works :P I had never heard of it until this project. The only programming experience I have is Halo 5 forge or red stone in Minecraft which are like baby's first time programing a script XD On a serious note though, Halo 5 forge had a lot of potential. It was essentially a dumbed down development toolkit. I get what you're saying though. It's just hard for me to visualize without looking at it.
Hmm... wouldn't that be the same as looking for just the obstacles and moving away from them, but inversed? :P I believe it's best to keep the number of waypoints as low as possible if for no other reason than keeping things clean, but also potentially faster and much simpler. :) The fixed waypoint at the top of the screen is a good thought, but then that waypoint would need a waypoint, haha. Alternatively, it could detect collisions with obstacles and move away from them, but that would be a reskin of Plan A essentially. Plus some of the obstacles may be thin enough to pass the waypoint without giving it enough time to get fully out of the way. Sorry for shooting holes in all your ideas this time -- programming is quite a different beast from designing features. ^^;
Bombur
What if... Every grid square outside of the obstacles was a waypoint? As long as they keep moving forward have them path the shortest possible route around it. OR What if there was a fixed waypoint at the top of the screen that moved with the players and all they had to do was "follow the carrot"?
You're not useless; on the contrary, your ideas here are actually quite useful! ^_^ I hadn't considered a collision box encompassing the screenspace. That could work very nicely as a middleman between the waypoints and the heroes/NPCs. The only issue I foresee with my incredibly short-sighted third eye is that I'd need a collision box on each waypoint to tell the screen collision box when they're colliding with it. Still, that's a small price to pay all things considered. I'll call this a solid Plan C! ^_^
Bombur
Both ideas sound pretty reasonable to me. I don't know anything about Godot so I can't really give you any ideas unfortunately :( Plan A sounds like it makes more sense on paper. Have the NPC move around stuff within it's vision cone but without proper AI or anything to determine how pathing will work I can see how this is not so simple. Plan B therefor does seem to make more sense when you have to design NPCs that are on rails of a sorts. The issue you are facing with spawning obstacles... Would it be possible to make the entire viewable screen a trigger zone similar to the vision cone idea for the NPCs, and once an obstacle appears on screen it sends the coordinates to the NPCs? I guess a way to determine which pathing to use would be to introduce a distance check if possible and have them follow the shortest path. I know nothing about Godot so I'm useless :(
