Dodge the Creeps Up&Down animations not working with touch support

gamerdev

Hi, first time trying out the forum and new to Godot engine.

I am following the tutorial on the first game Dodge the Creeps. All went fine and game working. However after making the changes necessary to support touch input for mobile devices, as described in https://docs.godotengine.org/en/stable/getting_started/step_by_step/exporting.html, the up and down animations aren't showing anymore. The player still moves up and down but only the left and right animations are rendered for the whole movement. Below is the complete code. I've added some debug messages, but it never prints out the debug message I've added for line "elif velocity.y != 0". Any help is much appreciated.

extends Area2D

signal hit

export var speed = 400
var screen_size
# Add this variable to hold the clicked position.
var target = Vector2()

func _ready():
	hide()
	screen_size = get_viewport_rect().size

func start(pos):
	position = pos
	# Initial target is the start position.
	target = pos
	show()
	$CollisionShape2D.disabled = false

# Change the target whenever a touch event happens.
func _input(event):
	if event is InputEventScreenTouch and event.pressed:
		target = event.position

func _process(delta):
	var velocity = Vector2()
	# Move towards the target and stop when close.
	if position.distance_to(target) > 10:
		velocity = target - position

# Remove keyboard controls.
#    if Input.is_action_pressed("ui_right"):
#       velocity.x += 1
#    if Input.is_action_pressed("ui_left"):
#        velocity.x -= 1
#    if Input.is_action_pressed("ui_down"):
#        velocity.y += 1
#    if Input.is_action_pressed("ui_up"):
#        velocity.y -= 1

	if velocity.length() > 0:
		velocity = velocity.normalized() * speed
		$AnimatedSprite.play()
	else:
		$AnimatedSprite.stop()

	position += velocity * delta
	# We still need to clamp the player's position here because on devices that don't
	# match your game's aspect ratio, Godot will try to maintain it as much as possible
	# by creating black borders, if necessary.
	# Without clamp(), the player would be able to move under those borders.
	position.x = clamp(position.x, 0, screen_size.x)
	position.y = clamp(position.y, 0, screen_size.y)

	if velocity.x != 0:
		print_debug("left right movement")
		$AnimatedSprite.animation = "walk"
		$AnimatedSprite.flip_v = false
		$AnimatedSprite.flip_h = velocity.x < 0
	elif velocity.y != 0:
		print_debug("up & down movement")
		$AnimatedSprite.animation = "up"
		$AnimatedSprite.flip_v = velocity.y > 0

func _on_Player_body_entered( body ):
	#hide()
	#emit_signal("hit")
	$CollisionShape2D.set_deferred("disabled", true)

Megalomaniak

Does the animation for either side movement play instead? It might be that the if velocity.x != 0: takes precedence.

gamerdev

That's right. It plays the side movement animations. But what I don't understand is why the code before Removing keyboard shortcuts work just fine. Here is the code snippet before adding touch support:

extends Area2D

signal hit

export var speed = 400  # How fast the player will move (pixels/sec).
var screen_size  # Size of the game window.

func _ready():
	screen_size = get_viewport_rect().size
	hide()

func _process(delta):
	var velocity = Vector2()  # The player's movement vector.
	if Input.is_action_pressed("ui_right"):
		velocity.x += 1
	if Input.is_action_pressed("ui_left"):
		velocity.x -= 1
	if Input.is_action_pressed("ui_down"):
		velocity.y += 1
	if Input.is_action_pressed("ui_up"):
		velocity.y -= 1
	if velocity.length() > 0:
		velocity = velocity.normalized() * speed
		$AnimatedSprite.play()
	else:
		$AnimatedSprite.stop()
		
	position += velocity * delta
	position.x = clamp(position.x, 0, screen_size.x)
	position.y = clamp(position.y, 0, screen_size.y)
	
	if velocity.x != 0:
		$AnimatedSprite.animation = "walk"
		$AnimatedSprite.flip_v = false
		# See the note below about boolean assignment
		$AnimatedSprite.flip_h = velocity.x < 0
	elif velocity.y != 0:
		$AnimatedSprite.animation = "up"
		$AnimatedSprite.flip_v = velocity.y > 0


func _on_Player_body_entered(body):
	hide()  # Player disappears after being hit.
	emit_signal("hit")
	$CollisionShape2D.set_deferred("disabled", true)
	
func start(pos):
	position = pos
	show()
	$CollisionShape2D.disabled = false

Megalomaniak

When you test your keyboard code are you only pressing one key at a time? The touch input is probably rarely if ever perfectly aligned with just one axis. Try and control your character via two keys at a time, such that both axis are in motion, see if the result isn't similar.

cybereality

I see a few things that look wrong, but I'm not sure if that is your issue.

if position.distance_to(target) > 10:
   velocity = target - position
target = position

You need to set target equal to position after reading the value (or on touch up) otherwise it will continue to move even when you let go of the screen (unless that is what you want).

if velocity.length() > 0.001:

Never check for zero or hard-coded values when using floats. Always have some epsilon (a small margin of error) otherwise it won't work. Same reason you can't check for not equal to zero below:

if abs(velocity.x) > 0.001:
...
elif abs(velocity.y) > 0.001:

Finally, this line might be repeatedly setting the animation to the first frame (in which case it would look like it's not working but it's just repeating the first frame over and over):

if velocity.length() > 0:
   velocity = velocity.normalized() * speed
   $AnimatedSprite.play()
else:
   $AnimatedSprite.stop()

It might be best to put the animation play code somewhere else (for example, in your _input() control code you can check for touch press and touch release and do the animation play/stop there instead).

DaveTheCoder

gamerdev's code is taken directly from the tutorial in the official documentation. Maybe the documentation needs to be updated.

cybereality

There is another sample for the mobile version of the Dodge the Creeps. Maybe the OP should try that one (I think it's in the Asset Library) and see if it works and what code is different.

DaveTheCoder

I did the same tutorial, including the touch input revision. My code has the same issue as gamerdev, I just hadn't noticed it before.

The problem is simply that the condition velocity.x != 0 will nearly always be true using a touch (or mouse) input, so the "walk" animation will nearly always be selected. It's very unlikely for a touch input to have exactly the same x-coordinate (or y-coordinate) as another point.

If you reverse the order of the velocity.x and velocity.y checks, then the "up" animation is always chosen.

Here's one possible fix, that uses the "walk" animation if the velocity is mostly horizontal, and the "up" animation if the velocity is mostly vertical:

	if abs(velocity.x) > abs(velocity.y):
#	if velocity.x != 0:
		$AnimatedSprite.animation = "walk"
		$AnimatedSprite.flip_v = false
		$AnimatedSprite.flip_h = velocity.x < 0
#	elif velocity.y != 0:
	else:
		$AnimatedSprite.animation = "up"
		$AnimatedSprite.flip_v = velocity.y > 0

cybereality

Yeah, I knew that line looked suspect.

Megalomaniak

Yeah, ideally you want to structure the code such that you have a check which movement axis to prioritize/play the animation for. Say with 2 axis analog input(or touch screen emulation of such) you can check both x and y values and play the animation for which ever outputs the greater absolute value.

gamerdev

Thanks a lot for your replies Megalomaniak, cybereality, and DaveTheCoder.

That's true. The code is taken directly from the tutorial with minimal changes for some logging at lines 57 and 62.

Actually I did try the workaround suggested by DaveTheCoder, and it worked! The vertical movement animations show even when the movement is diagonal. Nice work!

I should checkout the other sample as suggested by cybereality to see if there's a different approach there.

DaveTheCoder

Do you think it's worthwhile to submit a Pull Request to add that fix to the documentation?

I noticed that the "latest" documentation doesn't seem to have that section on supporting touch input.

TwistedTwigleg

@DaveTheCoder said: Do you think it's worthwhile to submit a Pull Request to add that fix to the documentation?

I noticed that the "latest" documentation doesn't seem to have that section on supporting touch input.

I think it might be worth while, but I'm not totally sure. If it is relatively quick and easy, then I would say making a PR is probably a good idea, but if it's going to take more than a little bit, I might make an issue first just so no time is wasted.

DaveTheCoder

You mean create an issue and ask if a PR will be accepted?

TwistedTwigleg

@DaveTheCoder said: You mean create an issue and ask if a PR will be accepted?

Kinda. I mean creating an issue to make sure it's cool to add the touch input section back to the latest branch of the documentation, since if it's no longer there it was probably removed for some reason. That said, if the section is still there, then just opening a PR to fix the issue is probably better as it's likely a bug.

DaveTheCoder

I created a PR. It wasn't much harder than creating an issue. https://github.com/daveTheOldCoder/godot-docs/pull/1

Besides, I can use the practice. :)

It's possible that page wasn't intentionally removed, but hasn't been added yet to the new documentation. There's been a lot of reorganizing there.

DaveTheCoder

The Merge button on the PR was enabled, so I clicked it. Was that a mistake?

cybereality

@DaveTheCoder said: The Merge button on the PR was enabled, so I clicked it. Was that a mistake?

Oh, no. You pressed the history erase button. All is lost.

DaveTheCoder

Should I resubmit the PR? The information is still on the link, so it would be simple to do.

I've tried to learn how github works, but can't wrap my head around all the details.

cybereality

I was joking.