Again it takes longer than I would’ve thought, but I implemented movement. To be honest, the movement part was actually the easiest thing and I spent most of the time fighting with ty (the LSP/type checker).

• Instead of editing the coordinate attributes of the class in the main event loop, I took inspiration from some established Pygame projects and made the Player class have a custom update() method. Inside, I check for the currently pressed keys and then use an if-statement to eddit the coordinates there. This makes the whole thing much smoother, as with the former option it would be choppy and wouldn’t let you keep holding down the key. Also, when I add the other entities (asteroids), I can make it have its own update() method, and that can be called as well. I am using this cool feature called pygame.sprite.Group, which lets me have a set of sprites and update and draw them all simultaneously. The player can be moved with the left and right arrow keys or A and D. I made it so that if they are both pressed the player will not move at all.
  • The main issue with the type checker/LSP was that Pygame sets the type hint of the rect attribute of pygame.sprite.Sprite to pygame.Rect | pygame.FRect | None, which causes ty to throw an error because None has no attributes. First, I tried ignoring all errors of that type by setting them to "ignore" in the ty configuration, but then I figured out I could just set the rect attribute to pygame.Rect | pygame.FRect inside the entity class, and that fixed the issue.

It’s a little complex as of right now because of the sort of unique way Pygame projects are structured, but I think it’s coming along very well.