Ein neuer Blick auf das Framework: Pizza Plane in Pygame Zero

Das ist – wegen meines Abschieds von TigerJython – nun schon die dritte Inkarnation meines kleinen roten Fliegers. Ich war nämlich zu der Erkenntnis gelangt, daß – sollte ich das Spiel in Py5 implementieren – ich dafür ein kleines Mini-Framework benötige. Und meine Beschäftigung mit TigerJythons GameGrid und mehr noch mit der GameGrid-Inspiration Greenfoot haben mich einen völlig neuen Blick darauf werfen lassen, wie solch ein Framework zu entwerfen ist.

Gewiß, ich hatte schon ein wenig mit Pygame Zero gespielt, aber ich hatte es dabei mehr als ein radikal vereinfachtes Pygame denn als ein eigenständiges Framework mit einer eigenen Philosophie im Blick. Das möchte ich jetzt nachholen und daher habe ich einen ersten Entwurf des Pizza-Fliegers in Pygame Zero neu implementiert:

# Pizza Plane Stage 1 (Version Pygame Zero)
# Endless Scrolling Background
# Background Image: »PWL« (https://opengameart.org/content/seamless-desert-background-in-parts)
# Aeroplane: Tappy Plane, Kenney (https://www.kenney.nl/assets/tappy-plane)
import pgzrun
import sys

WIDTH = 720
HEIGHT = 480
TITLE = "Pizza Plane Stage 1 (Pygame Zero)"
LEFT = WIDTH/2
BOTTOM = HEIGHT/2

# Konstanten
BG_WIDTH = 1067             # Breite des Hintergrundbildes
BG_WIDTH2   = 533           # BGWIDTH//2 (abgerundet)
BACKGROUND = "desert"
PLANE_X = 70                # X-Position des Fliegers (bleibt fest)

# Init Game
# Hintergrund
backs = []
back0 = Actor(BACKGROUND, (LEFT, BOTTOM))
back1 = Actor(BACKGROUND, (BG_WIDTH + LEFT, BOTTOM))
backs = [back0, back1]
# Player (Flieger)
plane_image = []
for i in range(3):
    img = "planered_" + str(i)
    plane_image.append(img)
plane = Actor(plane_image[0], (PLANE_X, 200))   # Startposition
plane.r = 0
plane.updown = 3
plane.dir = "NONE"

def update():
    ## Background
    for back in backs:
        back.x -= 1          
        if back.x <= -BG_WIDTH2:
            back.x = BG_WIDTH + BG_WIDTH2
    ## Flieger
    if plane.dir == "NONE":
        plane.y += 0
    elif plane.dir == "UP":
        if plane.y > 20:
            plane.y -= plane.updown
    elif plane.dir == "DOWN":
        if plane.y < HEIGHT - 20:
            plane.y += plane.updown
    plane.image = plane_image[int(plane.r)]
    plane.r += 0.2
    if plane.r >= 3.0:
        plane.r = 0
            
def draw():
    screen.fill("#94b0c2")  # Light gray
    for back in backs:
        back.draw()
    plane.draw()

def on_key_down():
    ## Steuerung des Fliegers
    if keyboard.up:
        plane.dir = "UP"
    if keyboard.down:
        plane.dir = "DOWN"
    ## Spielende mit ESC
    if keyboard.escape:
        print("Bye, Bye, Baby!")
        sys.exit()

def on_key_up():
    plane.dir = "NONE"
    
pgzrun.go()

Erste Erkenntnis: Ich benötige dringend in Py5 eine Actor()-Klasse, die ich implementieren und die als Oberklasse für alle Spielelemente (mindestens Player und alle NPCs) herhalten muß. Sie sollte eine leere update()-Methode besitzen, die je Unterklasse zu implementieren ist. In der draw()-Methode – die ich zwecks Unterscheidung von Processings draw() – display() nennen möchte, sollte ich dagegen eine einfache Default-Behandlung einbauen. Das bedeutet aber auch zwingend, daß dem Konstruktor der Klasse mindestens ein Bild (Sprite) mitgegeben werden muß.

Ob ich – analog zu Greenfoot – eine GameWorld()-Klasse einführen sollte, weiß ich noch nicht. Pygame Zero besitzt zwar eine Screen-Klasse, aber die übernimmt eigentlich die Aufgaben, die in Processing der canvas übernimmt. Eine World()-Klasse würde zwar der reinen Lehre der Objektorientierung entsprechen, aber manchmal darf und muß man auch undogmatisch sein. Ich befürchte nämlich, daß ich sonst gegen das statt mit dem Processing-Framework arbeite.

Auch scheint mir der Py5s Module Mode die geeignetste Basis für mein Vorhaben zu sein. Er befreit mich nicht nur aus der Abhängigkeit von Thonny (damit könnte ich leben) und erlaubt den Einsatz jedes beliebigen Editors oder jeder beliebigen IDE, sondern er ist auch mit seinem import Py5 und pay5.run_sketch() ziemlich hahe an Pygame Zero (mit import pgzrun und pgzrun.go()). Zudem habe ich die Hoffnung, daß ich im Module-Mode mehr und besseren Zugriff auf andere Python-Bibliotheken (ich denke hier vor allem ab die Matplotlib) habe. Das muß ich allerdings noch testen. Still digging!

Ansonsten habe ich in meiner Implementierung streng darauf geachtet, die Grenzen zwischen update() und draw() nicht zu vermischen und alle Variablen, die sonst als global deklariert werden müssen, als Objekt-Instanzen zu implementieren.

Jetzt besteht natürlich noch eine Gefahr: Die Beschäftigung mit Pygame Zero macht Spaß und ich könnte mich so in das Framework verlieben, daß ich die Realisierung des Programms in Py5 vergesse. Aber ich denke, daß ich genügend Motivation beistze, hier parallel mit beiden Frameworks zu arbeiten.

Den Quellcode und die Bildchen könnt Ihr in meinem GitHub-Repositorium zu Pygame Zero finden. Und mein derzeitiger Plan ist es, erst einmal eine vollständige Implementierung des Spiels in Pygame Zero fertig zu programmieren, bevor ich mich an die Implementierung eines Py5-Spiele-Frameworks wage. Schaun wir mal, wie weit ich komme …

(Kommentieren)