Help Please! New to GameMaker & Struggling With Sprite Direction!

Hi all!

I recently downloaded GameMaker and started doing some tutorials on Youtube to teach myself the basics.

I'm happy to be part of the GameMaker family and have always had a passion for gaming, with only recently having the idea of trying to create my own game from scratch.

I have a question that I desperately need some assistance with - I'm struggling to get my sprite to animate facing the correct direction.

Some background information:

I'm working on a top-down ARPG (old school Zelda vibes) where the character has 4 basic movement sprites (up, down, left and right). With the tutorial that I've followed so far (also using their free asset pack), the character is moving perfectly and facing the correct direction no matter which key I'm pressing, in all directions (can move diagonally as well).

My issue is, I've since found an amazing asset pack that I want to use to rebuild the above-mentioned character. The only issue is that the sprites for this asset pack only have a left and right facing animation. So, only 2 basic movements. Currently, when I move left or right, the sprite faces the right direction, but when I move upwards or downwards it seems to randomly shift the sprite to any given direction instead of remaining in the direction they were currently in.

So, I'm pretty sure this issue stems from the fact that I've built my movement around the 4 directional sprites instead of only having 2, but how can I adjust things so that my character sprite will update correctly now in terms of facing the right direction?

I'm essentially looking for a movement system similar to Forager if that helps?

I really hope this makes sense, but I'm really eager to learn, and thank you to anyone who is willing to assist!
 
Last edited:

woods

Member
welcome to the game maker community!!

since i have no idea how you are moving around, i can throw out a raw basic concept..
first code is super simple 4way movement with 4 sprites, 1 for each direction.
second code same thing but with 2 sprites... the player will look right while moving right or up.. and will look left while moving left or down. simply by assigning the sprite to the keypress.

4dir/4sprites
Code:
if keyboard_check(vk_up)
{
sprite_index = spr_player_up; //move up look up
obj_player.y -= 1;
}
else
if keyboard_check(vk_down)
{
sprite_index = spr_player_down;//move down look down
obj_player.y += 1;
}
else
if keyboard_check(vk_left)
{
sprite_index = spr_player_left;//move left look left
obj_player.x -= 1;
}
else
if keyboard_check(vk_right)
{
sprite_index = spr_player_right;//move right look right
obj_player.x += 1;
}


4dir/2sprites
Code:
if keyboard_check(vk_up)
{
sprite_index = spr_player_right;//move up look right
obj_player.y -= 1;
}
else
if keyboard_check(vk_down)
{
sprite_index = spr_player_left;//move down look left
obj_player.y += 1;
}
else
if keyboard_check(vk_left)
{
sprite_index = spr_player_left;//move left look left
obj_player.x -= 1;
}
else
if keyboard_check(vk_right)
{
sprite_index = spr_player_right;//move right look right
obj_player.x += 1;
}

cant do much without more information ;o)

i think you'd have better visibility in the programming section.. also would be alot easier to help if you shared the code you have, that is relative to making your player move..
we can only shoot in the dark as there are many many ways to make things happen.
 
Thanks for the warm welcome and feedback!

I will try out the suggested code and see if it makes a difference - apologies for not adding my current code as I know that would prob of helped a lot in terms of input from your side haha

Looking over the tutorial again and the progress I've made so far, it's clear that the movement seems to have been built specifically for the number of directions of the player character used. So, some of the movement functions seem to have been absorbed into some scripts (tutorial started before the recent update where functions became a thing).

Here is an example of how the current sprites are laid out:

Idle (4 directions)

player_idle.png

This theme carries over across the other movement sprites (roll etc.), all following this format just with added frames for the animation in each direction. But now as mentioned, the sprites I want to update them to only consist of a left and right animation but I still want to maintain the correct facing direction of the sprite while moving up or down seeing as I don't have sprites for these.

Here is an overview of the current object for the player character:

Player Object - Create Event

player_object_create event.png

Player Object - Step Event

player_object_step event.png

And then here are the current scripts/functions (hopefully I got all the relevant ones here):

Player Animate Sprite

script_player animate sprite.png

Player Free State

script_player state free.png

I hope this helps sheds some light on the movement system currently implemented. As mentioned, this is as per the tutorial I've followed, so it could be that there are some magic numbers added here to make everything work as per the number of sprite directions originally used.

I appreciate the help once again!
 
Last edited:

samspade

Member
I'm only vaguely familiar with Shaun's animation system. I watched all the videos, but it was awhile ago. However, you're right, he has a lot of it tied together to a four direction system. It's probably a pretty easy fix if you understand the system well, but if I remember right, he has all of his animations for all directions inside of a single sprite (e.g. idle) and then is selecting only a section of that sprite animation and manually animating it (by directly incrementing the frame number rather than letting GM handle it). It's a nice system, but it means it might be hard to find someone who knows how to modify it.

I would start with the following experiments. First, remove all frames you don't want (e.g. up and down it sounds like). Second in the player animate sprite function, divide by 2 instead of 4 (if you only want two directions). Third, CARDINAL_DIR looks like a macro - go change that macro to give you a 0 or a 1 (instead of a 0, 1, 2, 3 - which is what it looks like it gives from that code, I might be wrong).

That might be all you need to do, but again, I don't use this specific animation system so it could be that that is just a starting point. I'd also review his videos on this system (and the system where he updates it to use 2.3 methods) and try to pay attention to his logic for this code so that you can see the points where you need to change it.
 
Glad you recognized Shaun's work - def some of the easier to understand and better tutorials out there.

Thank you so much for your input here, and I figured it might be a very specific fix given the mechanic used for the movement.

You are totally correct with how he structures his sprites though, and that the above-mentioned mechanic for the movement system is directly impacted by that.

I tried your suggestion by dividing by 2 in the player_animate_sprite function, and that allows the player to move left and right, as well as diagonally, either up or down, while facing the correct direction. So that's a win!

However, the up and down movements on their own still tend to flip the sprite and I think the CARDINAL_DIR MIGHT be the culprit here.

See below of the way it is currently set:

Image 1.png

This is a bit tricky and setting it to 0 or 1 directly just seems to fix the player in one direction.

If you possibly have any other suggestion, I'm all ears!
 
Just tried this strangely enough - everything works fine now except when the player is facing left.

Then it defaults back to facing right when moving directly up directly down.

Watching over the old videos now to see if I can possibly pick up on something in the hopes that it helps solve this issue!
 

samspade

Member
To fix that you might have to change how you get your direction. As coded I think a pure up or pure down will always default to the same direction because you're selecting which sub portion of the sprite sheet to use with your actual direction not with your key presses. So it isn't going to know that when you are moving straight up, but were formally facing left, that it shouldn't switch. You might to track your last facing direction and set the CARDINAL_DIR value based on that. But that could cause problems as well as if that function takes an object specific variable (e.g. a variable that doesn't exist for all objects) then any object that calls that function will need to have that variable or there will be a crash.
 
Top