This is WAY less taxing than studying CNNs and RNNs.
By encapsulating data and behavior into objects, we can create modular and efficient programs. Python allows us to do so with classes. Classes allow us to model real-world entities and their interactions, making complex systems easier to understand and manage.
In Python, classes are like blueprints for creating objects. Just as a blueprint provides a detailed plan for building a house, a class provides a detailed plan for creating objects that have certain properties and behaviors.
In a multiplayer game context, without classes, each player control that is run would be a standalone piece of code, lacking a structured organization. As they identify differently, universal modification can be arduous.
By building classes, we not only just save ourselves the troubles of copy-and-pasting long chunks of code into our game loop or redraw function, but also create a more organized, maintainable, and extensible codebase. You could even make detailed subclasses from simpler classes.
Making the player class introduces reusability and more controllable and repetitive editing. After you are done scripting in it, the class can be fetched, referenced, and be applied with various appropriate parameters.
As a certain programming principle still says: don't repeat yourself. An alternative saying to this is "duplication is evil."
While the tutorial did not focus on this tidbit, you can import your player's jumping logic into the class for easier maintenance and shrinking the size of your Pygame loop code for the same purpose.
The projectile class shares many attributes with our player class (see below). The key difference in their code lies in player control, or the lack of it, so to speak.
A direct application of containing multiple instances of a class item is with an array. When we press our shoot button, a bullet is stored into the array, and when a condition is met, it can be easily removed from it.
A reminder: put everything you want your game to draw onto the screen into the redrawGameWindow() function.
We will cover how to spawn bullets shortly after, but for now, write conditions for their movement and despawning.
Before we finish up our shooting logic, there is one more feature I need to cover. When a player is facing a direction and fires a projectile, said projectile is believed to spawn and move towards that direction until despawning.
We need our program to track the current direction our player is facing towards.
Through the usage of simple multiplication, the script below ensures that each bullet fired in a specific direction moves at THAT direction for the rest of its spawn duration. A horizontal axis has positive values on the right side and negatives values on the left.
While I completed the direction logic of my game, I also took the time to update my sprite system to also correspond with player direction.
The texture files you can import from the 28th October section all face left. The Pygame library has you covered with its transform commands, including the flip option that horizontally mirrors your selected sprites.
After some tidy renaming of the sprite dictionaries, we now have a more complete set of animations for our player. If you noticed the lack of a jumpCount index refresher, this is due to an unaddressed bug where the walking and jumping sprite run times collide with each other. We will address this in a later section.
For now, enjoy your progression in Pygame (alongside some programming fundamentals inexclusive to Python).