I have had a problem in my game for a while now. I ignored it while I worked out different issues with my movement, such as how to make the turn-based movement effective. My problem is that I have top-down movement but I am not employing the top-down movement behavior, rather, my player and the npcs in my game are warping around the scene for 32 px distances, upon an invisible grid. The problem with this should be obvious: my player warps through walls. I would like to know if there is a way, using my system, to make it so that if the player is facing a wall, they cannot warp forwards.
(My movement system’s specifics:)
If the w key is pressed: the player’s angle changes to 180* / northward; my player’s y position loses 32 px.
If a, s, or d keys are pressed, the same as with w, but gaining pxs on x or y axis in the directions assigned to them by default.
<perhaps raycast would work, but what would it be raycasting to, is the problem>
Raycasting would work, sending the raycast out in the direction the player turns.
There are other ways too:
Add a point to the player sprite outside the sprite image and that is in the direction of forward (so to the right of the sprite image in the editor. Then check if the point is in a wall object.
Add a 32x1 object, place it in front of the player in the direction they’re facing and check if that collides with a wall object. Using the sticker extension would help a lot with this one.
Very, very good ideas. I tried no. 2 just a minute ago, actually, but for some reason it didn’t work. I’ll try no. 1 now, I think, because it did not occur to me that rays could be cast at angles, rather than toward specific points.
I already got rid of them because it didn’t work, but before my events that caused my character to turn and go in the direction indicated b y the keys pressed I made the condition that none of those would occur unless the “front_collision” object, which I put around the point in front of the player in an event at the bottom of the events screen, was in collision with a wall. The walls were 16 px wide and when they were immediately in front of the player, after the right keys were pressed, supposedly, the player would not jump forward. But he did, right through the wall.
I know it can probably done with raycasting by somehow checking if the object focused on by the rays (one for either side of the player so that windows don’t end up being passable unless I somehow, in some future update to my demo, decide to make a key combination allow the player to crabwalk) is an obstacle. However, the advent of the difficulty is when I realize that raycasting is currently beyond my expertise. Therefore, I will need to use a method that employs solid colissions.
I put the front collision object around a point 45 px in front of the player. I added a condition to check if the front collision object isn’t in collision with the obstacle to my conditions that signal for the player to head west. Thus, when I was facing a wall toward the west / left, I could go no further left. However, I could still go right. So far so good. But I added it to all of the similar conditions for the other directions. Now when I am facing a wall, I can’t go anywhere. Suggestions?
However, this itself won’t work, because you are placing the front_collision object before you turn the player. Us the Sticker extension instead. It’s a lot simpler.
I just thought of the best way to get the very best results in movement. Rather than go in four directions and auto-turn in those four directions, it would combine all the perfect, dreamy ideals I would have for a realistic movement system if I used arrow keys for turning (as i was already planning) and not turn the player at all when the aswd keys are pressed, which would allow for the crabwalk and slowly back away features that I dreamed of including (but didn’t believe i would ever get around to figuring out). Then, frontal collison will only effect frontal movement. However, the frontal movement object will have to be smaller and more central, windows should be impassable anyways except in the rare case in which the storyline demands it or secret areas may be accessed, and as for walls being light obstacles, there can be a different object for that, instead, which often coincides with movement obstacles. In explanation, among the arrow keys, each key makes the player look in a certain angle, while each aswd key makes the player move in a certain angle. There will be four collision objects, one small, central one for each side. Problem solved.
I admit I didn’t think the movement controls through fully. A problem arises in the moving forward button changing depending on the angle in which the player is facing. But that can be solved by conditions checking the angle, and that’s not the the topic of discussion here, right now.
