Python shooter game code copy and paste

Alright, this may be something where you need/desire/end up with multiple reviews - since changing this from it's current (procedural) style to OOP is (very) unlikely to be something someone new to OOP gets right first time.

But, there are certain aspects of this code that could be made better even in a procedural style - so I'll start with these...

Decomposition

Decomposition, or "functional decomposition" is important in all structured programming paradigms (which includes both OOP and procedural programming). One of the most elementary steps in this process is to construct your programs using modularity and hierarchies.

Structurally, using different scopes for different things is important in creating conceptually seperated 'modules'. For example, in your program the variable purple (a color, obviously), is in the same scope as the variable vodka (in image for a power-up item). Logically speaking, an image and a color do not belong in the same place - they should be separated (into 'modules', of some logical nature).

For example, instead of:

black = [0, 0, 0]
white = [255, 255, 255]
red = [255, 0, 0]
orange = [255, 102, 0]
yellow = [255, 255, 0]
green = [0, 255, 0]
blue = [0, 0, 255]
purple = [128, 0, 128]

(which are ALL in the __main__ scope,) you could have used a dictionary (Python's dict) data structure, like this:

colors={
    "black" : [0, 0, 0],
    "white" : [255, 255, 255],
    "red" : [255, 0, 0],
    "orange" : [255, 102, 0],
    "yellow" : [255, 255, 0],
    "green" : [0, 255, 0],
    "blue" : [0, 0, 255],
    "purple" : [128, 0, 128]
}

This would mean, instead of using yellow, you would now use colors["yellow"]. This not only helps you structure your program's code, but also makes it clearer what something is. This is probably not a big deal for "yellow", but when scrolling through and seeing vodka, rather than images["vodka"], it can create confusion.

Note:   in an object oriented design, you may wish to decompose these to a class or subclass rather than using a dictionary.

This same decomposition concept could also be used in your twenty lines of sprite loading!

Don't Repeat Yourself (DRY)

Some of your code, for example the following block of sprite definitions, is VERY repetitive...

gameover = loadSprite('images/gameover.png', screen_w, screen_h)
background = loadSprite('images/background.png', screen_w, screen_h)
menu = loadSprite('images/menu.png', screen_w, screen_h)

item = loadSprite('images/item.png', block_s, block_s)
vodka = loadSprite('images/powerup.png', block_s, block_s)
wall = loadSprite('images/wall.png', block_s, block_s)

leadup = loadSprite('images/leadup.png', block_s, block_s)
leaddown = loadSprite('images/leaddown.png', block_s, block_s)
leadright = loadSprite('images/leadright.png', block_s, block_s)
leadleft = loadSprite('images/leadleft.png', block_s, block_s)

enemyup = loadSprite('images/enemyup.png', block_s, block_s)
enemydown = loadSprite('images/enemydown.png', block_s, block_s)
enemyright = loadSprite('images/enemyright.png', block_s, block_s)
enemyleft = loadSprite('images/enemyleft.png', block_s, block_s)

bulletup = loadSprite('images/bulletup.png', block_s, block_s)
bulletdown = loadSprite('images/bulletdown.png', block_s, block_s)
bulletright = loadSprite('images/bulletright.png', block_s, block_s)
bulletleft = loadSprite('images/bulletleft.png', block_s, block_s)

Generally, any time your have many lines like this that are largely the same, you're better off using some sort of loop to construct a data structure to contain them. For example:

img_dir = "images/"
screens = {
    "gameover" : 'gameover.png',
    "background" : 'background.png',
    "menu" : 'menu.png'
}
for screen in screens.keys():
    screens[screen]=loadSprite(img_dir+screens[screen], screen_w, screen_h)

sprites = {
    "item" : 'item.png', "vodka" : 'powerup.png', "wall" : 'wall.png',
    "leadup" : 'leadup.png', "leaddown" : 'leaddown.png', "leadright" : 'leadright.png', "leadleft" : 'leadleft.png', 
    "enemyup" : 'enemyup.png', "enemydown" : 'enemydown.png', "enemyright" : 'enemyright.png', "enemyleft" : 'enemyleft.png',
    "bulletup" : 'bulletup.png', "bulletdown" : 'bulletdown.png', "bulletright" : 'bulletright.png', "bulletleft" : 'bulletleft.png'
}
for sprite in sprites.keys():
    sprites[sprite]=loadSprite(img_dir+sprites[sprite], block_s, block_s)

This has several advantages;

1. Each thing is specified once. Imagine if you moved our images to imgs/ rather than images/ - this way you need only change 1 variable (img_dir) on 1 line (rather than editing 20 lines).

2. You change the name/signature of the loadSprite function. 2 lines to edit rather than 20, etc.

It is fairly apparent that your game world is using square tiles, thus the x and y of the sprites (as oppose to the screens, such as 'background" You may also wish to alter your loadSprite function from:

def loadSprite(path, x, y):
    return pygame.transform.scale((pygame.image.load(path).convert_alpha()),(x,y))

to something which either uses default arguments (x and y defaulting to block_s), or which allows either a tile size (square) OR x and Y (rectangle) to be supplied. For example:

 def loadSprite(path, x, y=None):
    return pygame.transform.scale((pygame.image.load(path).convert_alpha()),(x,x if y is None else y))

On to the OOP!

Your program currently has a number (7, actually) of global variables:

• FPS
• clock
• block_s
• screen_w
• screen_h
• screen
• font

(That is, excluding the 8 colors and 18 sprites that I already mentioned).

These pretty much ALL belong in some sort of class. Probably named something like Game, World, Engine, etc. This would provide a place for all of the data (variables) and behavior (functions, called methods once they're in a class) of the game itself.

Using the hierarchies idea from the decomposition concept, this Game class could hierarchically contain (i.e. be the parent of,) the sprites (or images) and colors data structures created earlier.

The line pygame.init() would go into the constructor, rather than being in the main program body.

Each of the 3 global functions; message, loadMap, and mainLoop could then be made into methods of that class.

Note: the playMusic and loadSprite global functions may or may not be promoted to methods. They seem to me more like helper functions for PyGame, rather than explicit behaviors of your Game/World.

Your main()... monster?

This function is 153 lines of code, with a cyclomatic complexity of around 54! I really don't even want to begin on it until the program structure (everything else I've talked about) is improved.

However, I will just say that you CLEARLY need decomposition here! Methods should always have a complexity less than 7, so this function would need to be decomposed into around 8 other (smaller) functions. Although, from scanning over it and looking at all your loop conditions (like while True, etc) I think you can probably made it less complex.

As I said at the start of this answer, this may be something where you need/desire/end up with multiple reviews. You can refactor your code and post another question with the new (OOP structured) version (then put a comment on this question pointing to it, etc).

How do you write a game code in Python?

Can Python make 3d games?

Can you write a game using Python?