A PyGame Working Example: Starting a Game - Sprite Definitions
(Page 4 of 4 )
Next, we'll need to define the classes for player sprites as well as object sprites. Since the player sprite has no ability to move vertically, it will only have to be moved by its x-position. So, the player class's update method will only need to accept the amount its x-position needs to move. Likewise, because objects will have a static x-position, the object class's update method will only need to accept the amount to update the y-position. Also, our game will move objects by their center positions, not by their upper-left corners. We'll use centerx and centery rather than x and y.
import pygame
class Player(pygame.sprite.Sprite):
def __init__(self, image, xCenter, yCenter):
pygame.sprite.Sprite.__init__(self)
self.screen = pygame.display.get_surface().get_rect()
self.image = image
self.rect = self.image.get_rect()
self.rect.centerx = xCenter
self.rect.centery = yCenter
def update(self, xAmount):
self.rect = self.rect.move([xAmount, 0])
# Check to see if we have gone offscreen
if (self.rect.x < 0) or (self.rect.x >= self.screen.width):
self.rect = self.rect.move([-xAmount, 0])
class Object(pygame.sprite.Sprite):
def __init__(self, image, xCenter):
pygame.sprite.Sprite.__init__(self)
self.image = image
self.rect = self.image.get_rect()
self.rect.centerx = xCenter
def update(self, yAmount):
self.rect = self.rect.move([0, yAmount])
Save the script as gamesprites.py. We'll import it as a module when we need to create the sprites for our game. The Player class accepts three arguments when it is initialized: the player image, its center x-position and its center y-position. Note that the player image will already be loaded onto a Surface object by the level, so there's no need to load it again. The Object class only accepts two arguments, the object's image and the center x-position. Since all objects will start at the top of the screen, there's no need to accept any y-position. The update methods simply accept the amount the sprites need to move, with each class moving in a different direction, as described before. Additionally, the Player class checks to see if the sprite has gone off the screen. If it has, we undo any movement to put it back on the screen.
The Internals
The functional code of the game will make up its own module, and related Python instructions will be grouped into the module's methods. This is so we can customize the game later on by importing the module, calling whatever methods we need to call, and passing whatever level we want to play rather than modifying the internals of the game. Using this method of organizing the game, it's possible to add extra features such as a menu rather than limiting it to one game. This also allows us to create custom “Game Over” or success screens rather than relying on a generic one or modifying the internals to create a more specific one. We could also create either a linear or semi-dynamic campaign by going this route.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
/ 12 
