Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

Devlog, or, Anthology Of Coding Misadventures!

A topic by isorfilas created Jun 28, 2021 Views: 154 Replies: 4
Viewing posts 1 to 3
(+1)

Going into this, I had the idea of making a top-down, action RPG game using the Godot engine. When the theme, "Free", was announced, I decided to amend this to a top-down stealth game where the player is either breaking free from some facility, or breaking in to a facility to rescue someone or something.

So day one I got to work creating a player scene, enemy scene, and wall scene based on what little I remembered from watching tutorials a while back. We also got some basic movement going for the player sprite:


Enemy detection of players will obviously be important, so I started working on that day two. I re-watched this video from the KidsCanCode channel on YouTube and attempted to duplicate some of that functionality. I didn't implement this using Area2d though, as they did in the tutorial, because 1) facing and fov will be an important factor of this game and 2) I really still don't get signals in Godot yet. I only have about 7-8 months of self-taught python programming under my belt, so working directly with GDscript makes more sense to me right now than using some of the other built in functionality of the Godot Engine. Anyway, first pass I came up with this using _draw() to display the enemy's field of view, and some boolean functions to change the color if the player scene is within the enemy's fov:



Which ALMOST works as intended.  As you can see, the enemy thinks it can still "see" the player if the player exits the fov to the right. Following my understanding of the vector math tutorials from Godot's documentation, I was calculating the angle from two vectors--the facing vector (green line) and the vector from enemy-to-player--and checking if that result was less than half the value of my fov. It took an embarrassingly long amount of time to realize that the problem here was negative values for that angle will ALWAYS be evaluate as less than. Abs() function to the rescue, and: 


Now I have the functionality I was looking for.

The next step will be to continue implementing the ideas of the video tutorial so that walls and other obstacles block vision. I'd like it to also change the way the cone is drawn so we can clearly see what will and won't be detected. Besides using this for debugging, I have an idea that it would be cool if the player could find power-ups or gear they could use to temporarily see the fov of enemy guards and scanners.

So that's what I'll be working on over the next few days (as well as possibly making some placeholder art that isn't just Godot logo recolored!)

(+1)

Day Three:

Added an Area2D node to the enemy to represent their range of vision. I figured out how to get the signal system to connect, so now the enemy now has an 'objects_in_range' array and bodies are added and removed from that list as they enter and leave the Area2D.

Went on to add ray-casting so that if a player is hiding behind a wall or obstacle, the enemy cannot see them.


But of course, I want to be able to change the shape of the enemy's vision cone, which means I need to do some more vector math to find which corners are blocking LOS, and then locate the points that represent the new polygon:

That's some progress! I've found edges of what's being blocked, and drawn lines for myself to represent as much. But using this method, I'm not calculating the inner corners that the enemy can see, and I also found that if the player stands between the enemy and his los of the center of the wall, the enemy thinks it can't see ANY of the wall. Also, two wall tiles placed next to each-other produce to extra lines along inside the wall that aren't useful. As you can see:

So I tried completely rewriting this code to see if I could address those issues, with some success:


Player movement is still interfering with calculating these points in unexpected ways, but as long as the player isn't in the way, I have the points I need to redraw the field of vision (but I have no idea if they are in the proper order, or how to sort them!) Hopefully soon I can achieve the following:

But that's for another day. Right now, my brain hurts from all the maths so I bid you adieu!

(+2)

Hey! It's good to see another Godot developer. This is really interesting and helpful for the future so thanks!

A quick thought: Have you thought of using a collision polygon2d or collision shape2d a little outside of the walls (in the areas the enemy shouldn't see). So when the player enters it a signal is sent to the enemy that indicates that they cant see the player. I'm not sure if this helps or not but I hope it does. Good luck on your project!

(+1)

Thank you!

Right now I'm using an Area2D RectangleShape2D to mark the area of the wall, and then casting an intersection ray from the guard to the player. If the ray hits the wall before the player, it lets the guard know that they can't see the player yet, but if it hits the player then the guard knows they can see the player.

When the whole cone color changes from blue to red, that's my visual indication for debugging that the guard sees the player.

The whole business of redrawing the cone so it's shape reflects what can and can't be seen by the guard is what has me stumped. But I think I'm just going to set that idea aside and work on getting the other game-play mechanics in place.

(+1)

Day Four: Art Update!

I'm helping a friend move after I get off work this afternoon, so I don't have much free time to work on the game today. 

So I woke up early this morning to make some quick place-holder sprites for the player and the guard, set up a few walls, and programmed some simple patrol logic for the guard:

Oh yeah! You know getting by him is going to be a challenge. ^.^