<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>Kicking things off</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
HREF="MakeGames.html"><LINK
REL="PREVIOUS"
TITLE="Revision: Pygame fundamentals"
HREF="games2.html"><LINK
REL="NEXT"
TITLE="Game object classes"
HREF="games4.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="games2.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="games4.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN82"
></A
>3. Kicking things off</H1
><P
>The first sections of code are relatively simple, and, once written, can usually be reused in every game you consequently make. They
will do all of the boring, generic tasks like loading modules, loading images, opening networking connections, playing music, and so
on. They will also include some simple but effective error handling, and any customisation you wish to provide on top of functions
provided by modules like <TT
CLASS="FUNCTION"
>sys</TT
> and <TT
CLASS="FUNCTION"
>pygame</TT
>.</P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN87"
></A
>3.1. The first lines, and loading modules</H2
><P
>First off, you need to start off your game and load up your modules. It's always a good idea to set a few things straight at the top of
the main source file, such as the name of the file, what it contains, the license it is under, and any other helpful info you might
want to give those will will be looking at it. Then you can load modules, with some error checking so that Python doesn't print out
a nasty traceback, which non-programmers won't understand. The code is fairly simple, so I won't bother explaining any of it:</P
><PRE
CLASS="PROGRAMLISTING"
>#!/usr/bin/env python
#
# Tom's Pong
# A simple pong game with realistic physics and AI
# http://www.tomchance.uklinux.net/projects/pong.shtml
#
# Released under the GNU General Public License
VERSION = "0.4"
try:
import sys
import random
import math
import os
import getopt
import pygame
from socket import *
from pygame.locals import *
except ImportError, err:
print "couldn't load module. %s" % (err)
sys.exit(2)</PRE
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN91"
></A
>3.2. Resource handling functions</H2
><P
>In the <I
CLASS="CITETITLE"
>Line By Line Chimp</I
> example, the first code to be written was for loading images and sounds. As these
were totally independent of any game logic or game objects, they were written as separate functions, and were written first so
that later code could make use of them. I generally put all my code of this nature first, in their own, classless functions; these
will, generally speaking, be resource handling functions. You can of course create classes for these, so that you can group them
together, and maybe have an object with which you can control all of your resources. As with any good programming environment, it's up
to you to develop your own best practice and style.</P
><P
>It's always a good idea to write your own resource handling functions,
because although Pygame has methods for opening images and sounds, and other modules will have their methods of opening other
resources, those methods can take up more than one line, they can require consistent modification by yourself, and they often don't
provide satisfactory error handling. Writing resource handling functions gives you sophisticated, reusable code, and gives you more
control over your resources. Take this example of an image loading function:</P
><PRE
CLASS="PROGRAMLISTING"
>def load_png(name):
""" Load image and return image object"""
fullname = os.path.join('data', name)
try:
image = pygame.image.load(fullname)
if image.get_alpha() is None:
image = image.convert()
else:
image = image.convert_alpha()
except pygame.error, message:
print 'Cannot load image:', fullname
raise SystemExit, message
return image, image.get_rect()</PRE
><P
>Here we make a more sophisticated image loading function than the one provided by Pygame (<TT
CLASS="FUNCTION"
>image.load</TT
>). Note that
the first line of the function is a documentation string describing what the function does, and what object(s) it returns. The
function assumes that all of your images are in a directory called data, and so it takes the filename and creates the full pathname,
for example <TT
CLASS="FUNCTION"
>data/ball.png</TT
>, using the <I
CLASS="CITETITLE"
>os</I
> module to ensure cross-platform compatibility. Then it
tries to load the image, and convert any alpha regions so you can achieve transparency, and it returns a more human-readable error
if there's a problem. Finally it returns the image object, and its <TT
CLASS="FUNCTION"
>rect</TT
>.</P
><P
>You can make similar functions for loading any other resources, such as loading sounds. You can also make resource handling classes,
to give you more flexibility with more complex resources. For example, you could make a music class, with an <TT
CLASS="FUNCTION"
>__init__</TT
>
function that loads the sound (perhaps borrowing from a <TT
CLASS="FUNCTION"
>load_sound()</TT
> function), a function to pause the music, and a
function to restart. Another handy resource handling class is for network connections. Functions to open sockets, pass data with
suitable security and error checking, close sockets, finger addresses, and other network tasks, can make writing a game with network
capabilities relatively painless.</P
><P
>Remember the chief task of these functions/classes is to ensure that by the time you get around to writing game object classes,
and the main loop, there's almost nothing left to do. Class inheritance can make these basic classes especially handy. Don't go
overboard though; functions which will only be used by one class should be written as part of that class, not as a global
function.</P
></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="games2.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="games4.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Revision: Pygame fundamentals</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
> </TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Game object classes</TD
></TR
></TABLE
>
</body>
</html>
</DIV
></BODY
></HTML
>
distrib
>
Mandriva
>
2010.0
>
i586
>
media
>
contrib-release
>
by-pkgid
>
519a657156f8292188a5d8f560aa6169
>
files
>
72
