views:

398

answers:

3

Hey--I'm trying to design my first game using the Pygame library for Python, and I was wondering what the best practices are for level design in general. I would love to hear what you guys think are good object oriented design patterns for managing levels. Also, I'm fairly new to Python--thanks!

+4  A: 

If this is your first Pygame application, don't spend time worrying about "object oriented design patterns for managing levels". What you need to do now is to figure out how to make Pygame do what you want it to do.

  • Can you display everything you want to?
  • Is your display flicker-free?
  • Can you read the user input controls properly?
  • etc.

Object oriented patterns for managing levels comes later, much later.

Greg Hewgill
A good idea for just about any newbie!
RCIX
Thanks, but I think I have a fairly good understanding of the basic graphic and user-input stuff, and now I needed some advice on how to go about implement levels.
mportiz08
Fair enough then. Your post says "first game" and "new to Python" which led me to conclude that perhaps you hadn't used Pygame to write a game before.
Greg Hewgill
A: 

Generally speaking, a simple way to do it is using matrices (or multidimensional arrays - they work the same way here).

Basically, each Map is an Array, with each item in the array being a square on the grid. For example a 3 by 3 grid would be as follows:

(Psuedocode)

var Map = [[1,2,3][1,2,3][1,2,3]];

In place of numbers, you could put strings for a function to parse and draw or take action based on what the value of the cell is.

Moshe
+5  A: 

With this type of game your maps are in terms of tiles (I'm assuming that by level you mean an individual level, not managing all of your levels). Each tile has

  • an associated picture (what it looks like on the display)
  • a type (ie, a wall, the ground, a trap, etc.)

When I create tile-based games in Pygame, I usually have a Map class which contains the current map:

  • the pygame.Surface of the map (what you'll be blitting to the display)
  • a list of lists (ie, a matrix) where each item is a Tile object (I've also done games where you just have a string that tells you what type of tile it is, and then you don't need a separate Tile class)

The map should be relatively static - you could have that traps become normal tiles after you step on them (this is pretty easy - when you do collision detection and it's a hit, just change that tile to a different Tile object (presumably the one for an empty tile)), but you don't want characters or movable blocks in the map if you can help it. Since the movable blocks have their own rules for how they can be moved, it's not as simple as just changing a tile - you'd have a whole set of logic, and at least two tiles would have to be changed (and what if you could move the blocks onto traps - you'd then have to remember, separately, what was below it - bleh). In my opinion it's easier to just have a class for each moving object and item.

In short, you have:

  • Tile
  • Map
  • Block
  • other movable objects/sprites

And that's basically your whole level. For multiple levels, if individual levels are always the same, you can just have a list of Map objects, one for each level.

Daniel G
thanks--that's just what i was looking for!
mportiz08