I'm fairly new to godot and game dev in general. i have some python experience from school and i want to learn more.
my GDScript code is quite messy and i want to optimize it but i don't know how. any help please ?
here's the code:

extends KinematicBody2D

const TARGET_FPS = 60
const ACCELERATION = 8
const MAX_SPEED = 65
const FRICTION = 10
const AIR_RESISTANCE = 1
const GRAVITY = 6
const JUMP_FORCE = 150

var motion = Vector2.ZERO
export var on_ground = false

onready var animatedSprite = $AnimatedSprite

func _physics_process(delta):
	#declaring variables
	var is_rolling = false
	var is_crouched = false
	var x_input = Input.get_action_strength("ui_right") - Input.get_action_strength("ui_left")
	
	
	#input logic
	if x_input != 0 :
		motion.x += x_input * ACCELERATION * delta * TARGET_FPS
		motion.x = clamp(motion.x, -MAX_SPEED, MAX_SPEED)
		animatedSprite.flip_h = x_input < 0
	
	motion.y += GRAVITY * delta * TARGET_FPS
	
	if is_on_floor():
		if on_ground == false:
			on_ground = true
		if x_input == 0:
			motion.x = lerp(motion.x, 0, FRICTION * delta)
			if Input.is_action_pressed("ui_down"):
				is_crouched = true
				motion.x = 0
			else:
				is_crouched = false
			
		if Input.is_action_just_pressed("ui_up"):
			motion.y = -JUMP_FORCE
		
		if Input.is_action_just_released("ui_up") and motion.y < -JUMP_FORCE/2:
			motion.y = -JUMP_FORCE/2
		
		if x_input == 0:
			motion.x = lerp(motion.x, 0, AIR_RESISTANCE * delta)
	else:
		if on_ground == true:
			on_ground = false
	
	#animation logic
	if on_ground:
		if is_crouched:
			animatedSprite.play("crouch")
		elif x_input!= 0:
			animatedSprite.play("run")
		elif x_input==0:
			animatedSprite.play("idle")
	elif motion.y < 0:
		animatedSprite.play("jump_begin")
	elif motion.y > 0:
		animatedSprite.play("jump_loop")
		
	motion = move_and_slide(motion, Vector2.UP)
  • DaveTheCoder replied to this.

  • That code is actually pretty good if you're a beginner. It is a little messy, but the logic seems to make sense. One thing that could help is separating the input handling from the rest of the code. For example, by using the _input(event) function. Input only happens when a key is pressed. So for example, if you are checking for the jump key, right now you are testing every physics tick (at 60Hz) while the vast majority of the time that check will be false. If you put the logic in input, then the code is only called when the player pressed jump, which simplfies the logic and is technically more optimized. However a boolean true/false test is so fast that in practice, it probably makes little to no difference in the performance. I would also create your own input map names and not use the default ones. Because "ui_up" could mean anything, but something like "player_jump" is much more clear. You may also want to research state machines (or finite state machines, FSM) because that will make the logic more robust. While what you have now works, it could get confusing once you add more animations or actions and it could get too messy.

    That code is actually pretty good if you're a beginner. It is a little messy, but the logic seems to make sense. One thing that could help is separating the input handling from the rest of the code. For example, by using the _input(event) function. Input only happens when a key is pressed. So for example, if you are checking for the jump key, right now you are testing every physics tick (at 60Hz) while the vast majority of the time that check will be false. If you put the logic in input, then the code is only called when the player pressed jump, which simplfies the logic and is technically more optimized. However a boolean true/false test is so fast that in practice, it probably makes little to no difference in the performance. I would also create your own input map names and not use the default ones. Because "ui_up" could mean anything, but something like "player_jump" is much more clear. You may also want to research state machines (or finite state machines, FSM) because that will make the logic more robust. While what you have now works, it could get confusing once you add more animations or actions and it could get too messy.

    Optimizing is generally a waste of time unless you've determined that your code isn't meeting its speed requirements, and you've timed it to determine where it's bogging down. Getting it to work should be a much higher priority.

    Making your code more legible, on the other hand, is always important. If your code looks messy now, while it's fresh in your mind, you may have trouble following it at all months from now. One way to write legible code is to break everything into separate methods, so that the bulk of your code looks like this:

    func game():
	make_board()
	make_pieces()
	make_player_1()

	if two_players():
		make_player_2()
	
	display_game_is_ready()

	# input goes through _input()

	# Game will end when check_game_end()
	#   is called by timer.

    Note that this is less optimized than doing everything in one, long method, but it's usually more important that you can read and follow it when you need to make changes.

    everyone here seems to think that optimized always means "runs faster".
    "running faster" is not the only thing that code can be optimized for.
    with how fast today's computers are, i almost always optimize my code for "is more readable"
    so that i can change it later if needed.

      Another thing about optimizing, is most compilers will automatically do optimizations on the machine level.

      But, it certainly does help in many situations.

      This is trivial, but:
      if on_ground == false:
      can be simplified as:
      if not on_ground:

      Similarly:
      if on_ground == true:
      can be simplified as:
      if on_ground:

      I don't know if that's optimizing, but I think it's more readable.

        Sosasees

        Traditionally optimization refers only to making code run more efficiently in terms of speed or memory. The broader definition of the term was not used, so you're going to run into that, narrower definition most of the time. And you'll confuse people if you talk about optimizing for legibility.