Legacy GM Seeking Assistance with Enemy Movement behavior

[Chungsie]

I have been following HeartBeast's rpg tutorial, and have been slightly modifying it with good results. For example I was able to add a run state, and the shown dash state, and was able to change animation speeds in states.

But now I am trying to make a ram enemy that moves up and down to line up 10% of y with player and then charge towards the player on the x axis.

my movement code for the ram is the following

if (collision_point(sign(obj_player.x-x)64-x,y,obj_player,false,false)) {
phy_position_x += 32/3;
image_speed = .25;
} else if (collision_point(x,sign(obj_player.y-y)64-y,obj_player,false,false)) {
phy_position_y += sign(obj_player.y - y)*spd;
image_speed = .25;
} else {
    image_speed = 0;
    image_index = 1;
}

I have tried changing the x and y variables to physics positions, but it gives me the same results.

the game looks like this, you walk on a platform in a top down world avoiding the red tiles.

EDIT: the problem was that collision point returns an id. so I have changed it to a x and y coord comparison structure. it works fine now.

/// Move towards the player
var vspd = 0;
if abs(phy_position_x-obj_player.x) <= 64 and abs(phy_position_y-obj_player.y) <= sprite_height/10 {
spd = 3;
hspd = sign(obj_player.x-phy_position_x) * spd;
phy_position_x += hspd;
} else {
var hspd = 0;
}
if abs(phy_position_y-obj_player.y) >= sprite_height/10 and abs(phy_position_x-obj_player.x) <= 64 {
vspd = sign(obj_player.y-phy_position_y) * spd;
phy_position_y += vspd;
} else {
var vspd = 0;
}

event_inherited();
var dirx = sign(obj_player.x - x);
var diry = sign(obj_player.y - y);

if sign(hspd) = -1 and abs(vspd) < abs(hspd) {
    sprite_index = spr_enemy_ram_left;
} else if sign(hspd) = 1 and abs(vspd) < abs(hspd) {
    sprite_index = spr_enemy_ram_right;
}

if sign(vspd) = 1 and abs(vspd) > abs(hspd) {
    sprite_index = spr_enemy_ram_down;
} else if sign(vspd) = -1 and abs(vspd) > abs(hspd) {
    sprite_index = spr_enemy_ram_up;
}

I even managed to figure out how to make it change animation sequences based on movement. now I will have to figure out how to have it stop charging when it collides with the player. I think I may need to use a finite state machine for the enemy.

 

[jo-thijs]

I have been following HeartBeast's rpg tutorial, and have been slightly modifying it with good results. For example I was able to add a run state, and the shown dash state, and was able to change animation speeds in states.

But now I am trying to make a ram enemy that moves up and down to line up 10% of y with player and then charge towards the player on the x axis.

my movement code for the ram is the following

if (collision_point(sign(obj_player.x-x)64-x,y,obj_player,false,false)) {
phy_position_x += 32/3;
image_speed = .25;
} else if (collision_point(x,sign(obj_player.y-y)64-y,obj_player,false,false)) {
phy_position_y += sign(obj_player.y - y)*spd;
image_speed = .25;
} else {
    image_speed = 0;
    image_index = 1;
}

I have tried changing the x and y variables to physics positions, but it gives me the same results.

View attachment 10479 the game looks like this, you walk on a platform in a top down world avoiding the red tiles.

Is this a thing now? People constantly using GameMaker's physics system when it doesn't make any sense at all?

First of all, tell me why you're using the physics system.

Secondly, tell me why you're using collision_point for lining up the enemy's y coordinate with the player's y coordinate.
Shouldn't you instead only compare y coordinates? Currently you're only lining up when the player is directly above or below the enemy.

Also, I assume you forgot some multiplications * after the sign functions in collision_point.

 

[Chungsie]

Is this a thing now? People constantly using GameMaker's physics system when it doesn't make any sense at all?

First of all, tell me why you're using the physics system.

Secondly, tell me why you're using collision_point for lining up the enemy's y coordinate with the player's y coordinate.
Shouldn't you instead only compare y coordinates? Currently you're only lining up when the player is directly above or below the enemy.

Also, I assume you forgot some multiplications * after the sign functions in collision_point.

I am following Heartbeast tutorial on rpg. big disclaimer right there

I have changed it to do a coord comparison and it works now. There are some more things I want the ram to do, such as reposition itself for another ram attack, but for now it is fine. It approaches on y coord until aligned within 10% and then charges left or right.

but ya, I don't know why the teacher is using built in physics, or even if it makes sense or not, but that's how I'm learning.

 

[jo-thijs]

I am following Heartbeast tutorial on rpg. big disclaimer right there

I have changed it to do a coord comparison and it works now. There are some more things I want the ram to do, such as reposition itself for another ram attack, but for now it is fine. It approaches on y coord until aligned within 10% and then charges left or right.

but ya, I don't know why the teacher is using built in physics, or even if it makes sense or not, but that's how I'm learning.

I've just skimmed through a couple of his vids and he really should not be using the physics system for what he's doing.
My guess is that he's just too lazy to code a collision system in his tutorials and as a result falls back to something premade.
Using the physics engine when not appropriate can lead to future bugs however which might not be easy to fix.
I would have to thoroughly follow his tutorials though to be sure this is the case.

Anyway, I'm glad your issue got (partially?) fixed!

 

[Chungsie]

someone suggested that it would not be hard to code my own physics for the game. I just don't want to depart too far from his tutorials yet. I mean I do a little, but the built in physics gets a majority of time on the tutorials. I already know some of my ideas won't be covered in the tutorials, that's a given.

appreciate your advice pal.

 

[Chungsie]

this can be closed. here is the ai solution in execution:

 

[Guest]

This is why I stopped using tutorials except for getting higher-level ideas. The problem is these guys, including Heartbeast, will set out a "how to achieve X" goal and then take the most literal, least extensible way of achievinig it. In a classroom, examples serve to illustrate a more generally useful principle. In tutorials, examples often serve to illustrate---the example.

Also, there's the fact they take 30 minutes when a paragraph of explanatory text and a page of code would be far more useful.

 

[Chungsie]

i've got to learn somehow.

 

[Guest]

i've got to learn somehow.

I'm in the same boat! This is my second go-round attempting to make a game. My first time, I really hammered the heck out of video tutorials. Maybe it was good for planting some basic ideas, but I eventually gave up, overwhelmed. The problem is threefold: the tutorials are simultaneously overambitious ("let's make an RPG!"), underexplained ("Bitshift five positions to convert to our grid, &~ 31 to snap the sprite, and lerp to our destination."---rather than explaining their inefficient but understandable equivalents, then ramping up), and often employ techniques that are tangential at best, or inappropriate at worst, to your desired project.

I'm having much more success this time by breaking down a desired behavior (move this sprite here) into logic steps (move this sprite one pixel at a time and then stop, goddammit, I said stop)---which almost always amounts to some combination of variables, if checks, loops, and functions. The "functions" bit is important, because GMS nearly always provides a built-in way to get or set the information you need to shove into a variable/if-check/loop combination, so I've been trying to learn what functions are available to me. There's a finite number of functions, and they also break down into some basic patterns: storing and retrieving information; finding distance or relationship between, or location of, screen, sprite, or instance pixel points; finding out when two pixels or instances overlap; and then a mess of screen and drawing operations to spray your information onto the screen.

Here is a link to a stripped-down index to the manual that I made. It lists only these core functions and excludes specialized matter relating to 3D, physics, DnD, platform configuration stuff, audio, advanced gpu functions, shaders, and matrixes (since figuring out what those are for can wait). I also took out the real number functions because I know they exist and there's an easy list of them under the "real numbers" entry. I recommend going through and glancing through the manual entries for these functions to learn what's available.

I focus on written tutorials and internet posts on how to achieve a specific desired behavior, although I'll still burn time on video tutorials when I'm really stuck just to get logic ideas and ideas for how to use functions, or for learning useful algorithms that I'd never come up with on my own. And at some point I sat down and worked through binary operations starting with the official tutorial by Mike here.

Edit: I'm also working through a pretty good book called Game Programming Algorithms and Techniques. The Patterns book by Bob Nystrom is much harder to understand, but he's a great writer, and it and his blog posts on roguelikes have been helpful because my game has some roguelikeish elements.

 

[Chungsie]

logic is something I went to school for. i think it's a matter of learning the functions and knowing when and how to apply them and see how they can help.

 

[Chungsie]

so now I have two issues going into the second week of development.

Whenever I do a room change my obj_player says phy_fixed_rotation is never set before reading, and if I make the parent for player set it then the game says it is a read only variable.

Now for some reason my player won't animate walking, and the minions go out of room somehow.