Sophie

Sophie

distrib > Mandriva > 2010.0 > i586 > media > contrib-release > by-pkgid > 519a657156f8292188a5d8f560aa6169 > files > 73

pygame-doc-1.8.1-4mdv2010.0.i586.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>Game object classes</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
HREF="MakeGames.html"><LINK
REL="PREVIOUS"
TITLE="Kicking things off"
HREF="games3.html"><LINK
REL="NEXT"
TITLE="User-controllable objects"
HREF="games5.html"> <style type="text/stylesheet">
	<!--
	PRE.PROGRAMLISTING	{ background-color: #EEEEEE; border-color: #333333; border-style: solid; border-width: thin }	-->
 </style></HEAD
><BODY
CLASS="SECT1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
>

<DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
></TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="games3.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="games5.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN106"
></A
>4. Game object classes</H1
><P
>Once you've loaded your modules, and written your resource handling functions, you'll want to get on to writing some game objects.
The way this is done is fairly simple, though it can seem complex at first. You write a class for each type of object in the game,
and then create an instance of those classes for the objects. You can then use those classes' methods to manipulate the objects,
giving objects some motion and interactive capabilities. So your game, in pseudo-code, will look like this:</P
><PRE
CLASS="PROGRAMLISTING"
>#!/usr/bin/python

[load modules here]

[resource handling functions here]

class Ball:
	[ball functions (methods) here]
	[e.g. a function to calculate new position]
	[and a function to check if it hits the side]

def main:
	[initiate game environment here]

	[create new object as instance of ball class]
	ball = Ball()

	while 1:
		[check for user input]

		[call ball's update function]
		ball.update()</PRE
><P
>This is, of course, a very simple example, and you'd need to put in all the code, instead of those little bracketed comments. But
you should get the basic idea. You crate a class, into which you put all the functions for a ball, including <TT
CLASS="FUNCTION"
>__init__</TT
>,
which would create all the ball's attributes, and <TT
CLASS="FUNCTION"
>update</TT
>, which would move the ball to its new position, before blitting
it onto the screen in this position.</P
><P
>You can then create more classes for all of your other game objects, and then create instances of them so that you can handle them
easily in the <TT
CLASS="FUNCTION"
>main</TT
> function and the main program loop. Contrast this with initiating the ball in the <TT
CLASS="FUNCTION"
>main</TT
>
function, and then having lots of classless functions to manipulate a set ball object, and you'll hopefully see why using classes is
an advantage: It allows you to put all of the code for each object in one place; it makes using objects easier; it makes adding new
objects, and manipulating them, more flexible. Rather than adding more code for each new ball object, you could simply create new
instances of the <TT
CLASS="FUNCTION"
>Ball</TT
> class for each new ball object. Magic!</P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN117"
></A
>4.1. A simple ball class</H2
><P
>Here is a simple class with the functions necessary for creating a ball object that will, if the <TT
CLASS="FUNCTION"
>update</TT
> function is called
in the main loop, move across the screen:</P
><PRE
CLASS="PROGRAMLISTING"
>class Ball(pygame.sprite.Sprite):
	"""A ball that will move across the screen
	Returns: ball object
	Functions: update, calcnewpos
	Attributes: area, vector"""

	def __init__(self, vector):
		pygame.sprite.Sprite.__init__(self)
		self.image, self.rect = load_png('ball.png')
		screen = pygame.display.get_surface()
		self.area = screen.get_rect()
		self.vector = vector

	def update(self):
		newpos = self.calcnewpos(self.rect,self.vector)
		self.rect = newpos

	def calcnewpos(self,rect,vector):
		(angle,z) = vector
		(dx,dy) = (z*math.cos(angle),z*math.sin(angle))
		return rect.move(dx,dy)</PRE
><P
>Here we have the <TT
CLASS="FUNCTION"
>Ball</TT
> class, with an <TT
CLASS="FUNCTION"
>__init__</TT
> function that sets the ball up, an <TT
CLASS="FUNCTION"
>update</TT
>
function that changes the ball's rectangle to be in the new position, and a <TT
CLASS="FUNCTION"
>calcnewpos</TT
> function to calculate the ball's
new position based on its current position, and the vector by which it is moving. I'll explain the physics in a moment. The one other
thing to note is the documentation string, which is a little bit longer this time, and explains the basics of the class. These strings
are handy not only to yourself and other programmers looking at the code, but also for tools to parse your code and document it. They
won't make much of a difference in small programs, but with large ones they're invaluable, so it's a good habit to get into.</P
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN127"
></A
>4.1.1. Diversion 1: Sprites</H3
><P
>The other reason for creating a class for each object is sprites. Each image you render in your game will be a sprite object, and so
to begin with, the class for each object should inherit the <TT
CLASS="FUNCTION"
>Sprite</TT
> class. This is a really nice feature of Python - class
inheritance. Now the <TT
CLASS="FUNCTION"
>Ball</TT
> class has all of the functions that come with the <TT
CLASS="FUNCTION"
>Sprite</TT
> class, and any object
instances of the <TT
CLASS="FUNCTION"
>Ball</TT
> class will be registered by Pygame as sprites. Whereas with text and the background, which don't
move, it's OK to blit the object onto the background, Pygame handles sprite objects in a different manner, which you'll see when we
look at the whole program's code. </P
><P
>Basically, you create both a ball object, and a sprite object for that ball, and you then call the ball's update function on the
sprite object, thus updating the sprite. Sprites also give you sophisticated ways of determining if two objects have collided.
Normally you might just check in the main loop to see if their rectangles overlap, but that would involve a lot of code, which would
be a waste because the <TT
CLASS="FUNCTION"
>Sprite</TT
> class provides two functions (<TT
CLASS="FUNCTION"
>spritecollide</TT
> and <TT
CLASS="FUNCTION"
>groupcollide</TT
>)
to do this for you.</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN138"
></A
>4.1.2. Diversion 2: Vector physics</H3
><P
>Other than the structure of the <TT
CLASS="FUNCTION"
>Ball</TT
> class, the notable thing about this code is the vector physics, used to calculate
the ball's movement. With any game involving angular movement, you won't get very far unless you're comfortable with trigonometry, so
I'll just introduce the basics you need to know to make sense of the <TT
CLASS="FUNCTION"
>calcnewpos</TT
> function.</P
><P
>To begin with, you'll notice that the ball has an attribute <TT
CLASS="FUNCTION"
>vector</TT
>, which is made up of <TT
CLASS="FUNCTION"
>angle</TT
> and <TT
CLASS="FUNCTION"
>
z</TT
>. The angle is measured in radians, and will give you the direction in which the ball is moving. Z is the speed at which the ball
moves. So by using this vector, we can determine the direction and speed of the ball, and therefore how much it will move on the x and
y axes:</P
><DIV
CLASS="MEDIAOBJECT"
><P
><IMG
SRC="radians.png"></P
></DIV
><P
>The diagram above illustrates the basic maths behind vectors. In the left hand diagram, you can see the ball's projected movement
represented by the blue line. The length of that line (<TT
CLASS="FUNCTION"
>z</TT
>) represents its speed, and the angle is the direction in which
it will move. The angle for the ball's movement will always be taken from the x axis on the right, and it is measured clockwise from
that line, as shown in the diagram.</P
><P
>From the angle and speed of the ball, we can then work out how much it has moved along the x and y axes. We need to do this because
Pygame doesn't support vectors itself, and we can only move the ball by moving its rectangle along the two axes. So we need to
<I
CLASS="FIRSTTERM"
>resolve</I
> the angle and speed into its movement on the x axis (dx) and on the y axis (dy). This is a simple matter of
trigonometry, and can be done with the formulae shown in the diagram.</P
><P
>If you've studied elementary trigonometry before, none of this should be news to you. But just in case you're forgetful, here are some
useful formulae to remember, that will help you visualise the angles (I find it easier to visualise angles in degrees than in radians!) </P
><DIV
CLASS="MEDIAOBJECT"
><P
><IMG
SRC="formulae.png"></P
></DIV
></DIV
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="games3.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="MakeGames.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="games5.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Kicking things off</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
>&nbsp;</TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>User-controllable objects</TD
></TR
></TABLE
>

</body>
</html>



</DIV
></BODY
></HTML
>

Perl :: Catalyst :: PostgreSQL :: RPM Valid HTML 4.01 Transitional