Retro-Games mit Pygame/Python [aus: Qix in BASIC V2]

Bin auch ein bißchen weitergekommen. Stört euch das, wenn ich von der Pygame-Version schreibe? Ich halte die Themen auch allgemein, versprochen.

Ich speichere den Zustand des Playfields in Zahlen, dafür lösche ich beim Zeichnen ausnahmsweise nicht die Oberfläche, auf der der Spieler malt. Sein "Sprite" wird dann als neue Schicht darüber geblittet.

Bisher kann man rumlaufen wie bei Nibbles, und die Kollision wird geprüft (mit dem Playfield in Zahlen, nicht durch Abfrage der Bildschirmfarben).

Bei dem Original-Qix ist es tatsächlich so, daß man auf die Linie laufen kann, und sobald man das tut, wird gefüllt. Bei mir wird man vorerst noch vor der Linie gestoppt (das andere Verhalten kommt später).

Jetzt fehlt eigentlich (mehr oder weniger) nur noch das Füllen. Das werde ich wie EgonOlsen71 machen: Ausgehend vom Gegner (dem Qix) füllen, dann invertieren. Ist wohl die beste Lösung. Wie gesagt habe ich den Zustand des Playfields in Zahlen, das heißt in einem Array (of Array). In diesem Array werde ich das Füllen machen. Erstmal nur rein in Zahlen. Und wenn es fertig ist, den Zustand des Playfields aus dem Array auf den Bildschirm übertragen. Dürfte machbar sein.

Also, so'n Hexenwerk ist Qix in der Programmierung nun auch wieder nicht. Läßt sich schon machen. Aber geniale Spielidee.

Code (version 0.1). Geschrieben in Python 2.7; kann sein, daß man für neuere Versionen noch kleinere Anpassungen machen müßte.

https://github.com/hlubenow/pyqueex

Zitat von Retrofan

Zitat von next_i

Stört euch das, wenn ich von der Pygame-Version schreibe?

Ich fände es besser, wenn wir hier bei Basic (oder wenigstens beim C64) bleiben würden. Dass man das auf dem PC in Python/Pygame hinbekommt, sollte wohl jedem einleuchten.

Ja, ok. Dann halte ich mich zurück. Wollte halt zumindest einmal zeigen, was ich damit ganz gern so mache.

Dafür, daß jedem einleuchten sollte, daß man in Pygame tolle Sachen machen kann, gibt es in Pygame erstaunlich wenig gute Spiele. Eigentlich kenne ich gar keins. (Bis auf "Frozen Bubble", das in dem Perl-Pendant "SDL_perl" geschrieben ist - das ansonsten auch keiner nutzt).

Dabei können Pygame-Spiele pixelexakt genau so aussehen wie die Spiele der 8-Bit-Computer, wenn man es darauf anlegt (ich hab' mal den ersten Level von "Manic Miner" im Spectrum-Stil in Pygame nachprogrammiert, deshalb weiß ich das).

Den Amiga-Bereich oder Spectrum Next könnte Pygame auch abdecken.

Und wie gesagt ohne den Coding-Masochismus, stattdessen Motorrad mit Nitro-Einspritzung.

Mich frustriert immer, daß das keiner macht, weil da so viel Potential wäre.

Na ja, mein Problem.

Der Füll-Algorithmus steht auch schon.

Code: https://github.com/hlubenow/pyqueex

Zitat von Retrofan

Was Pygame angeht, finde ich dieses Video ganz gut gemacht

Ganz interessante Entwicklung, die der in dem Video gemacht hat.

Irgendwas ist mit den Plattform-Spielen, bzw. der Art, wie man die heute macht. Das wirkt alles so hektisch, die Sprünge unrealistisch, die Sprites so nach Anime; auch bei seinen Spielen in dem Video. Mir machen Spiele in dieser Art einfach keinen Spaß, ich hätte gar keine Lust, sowas zu spielen.

Giana Sisters (auf dem Amiga) dagegen: Jederzeit.

Ebenso "Rick Dangerous" im Vergleich zu seinem Abenteurer-Plattformer.

Wie gesagt, das muß langsamer sein, sonst sieht es nach nichts aus, außer nach Schluckauf vielleicht (also die Sprünge).

Liegt aber nicht an der Technik. Pygame wäre dazu schon in der Lage, es auch wie Giana Sisters zu machen.

Obwohl ich Probleme mit einem wirklich sanften Scrolling habe. Dies ist das beste, was ich damit hinkriege, und ich finde, das ruckelt an manchen Stellen immer noch:

https://github.com/hlubenow/py…n/scrolling_background.py

Vielleicht machen die anderen deshalb die Spiele so superschnell und hektisch, damit man dieses Ruckeln nicht wahrnimmt.

Das ist sicher noch ein Punkt, an dem es etwas zu verbessern gäbe.

Ich weiß auch nicht, ob das besser wird, wenn man SDL (oder SDL2) direkt mit C verwendet. Na ja, Pygame-Spezialthema. Aber in dem Zusammenhang nicht unwichtig.

P.S.: Sein Kampf-Spiel mit den Rittern und Schwertern (Minute 02:43 im Video) sah dagegen ziemlich gut aus, fand ich.

Noch ein Update (0.3) : Hab' mir das Original-Qix angesehen, und die Bewegungen angepaßt. Man bewegt sich jetzt also nicht mehr irgendwie (wie Nibbles - das war ein Spiel, das bei QBasic für DOS dabei war, auch "Snake" genannt), sondern wie es sein soll. Das heißt, man kann auf den weißen Linien laufen. Geht man in den schwarzen Bereich, wird die Linie gelb, bis man auf eine andere, weiße trifft. (Man kann also auch keine "Schnecke" machen: Wenn man gegen seine eigene gelbe Linie läuft, wird nicht gefüllt).

Ist die eigene Linie gelb, und trifft man auf eine weiße Linie, wird die Fläche blau gefüllt (und die gelben Linien werden zu weißen). In die blauen Flächen kann man danach ebenfalls nicht hineingehen.

Code: https://github.com/hlubenow/pyqueex

Das ist es also im Prinzip. Hab' ein paar Stunden geknobelt, bis es ging, aber das macht ja gerade den Spaß aus.

Es fehlen noch die Bewegungen der Gegner ("KI"), Kollisionen mit denen, Punktesystem, Joysticksupport (kein großes Problem), und Spielstatus, also Überprüfung, ob man gewonnen oder verloren hat, sowie Anpassung an Python3 / neueres Pygame (, ohne die die meisten Leute, die das Skript ausprobieren wollen, bisher wohl leider immer noch einfach nur einen Programmfehler erhalten, das ist natürlich blöd, ich weiß). Schau'n wir mal.

Hallo,

hab' doch noch ein bißchen weitergemacht. Jetzt ist es also bei Version 0.6.

Es gibt einen Gegner, der sich "Breakout"- oder "Boing ball"-mäßig bewegt. Ist bisher nur ein grünes Rechteck, daraus könnte halt ein beliebiger Sprite werden (wie z.B. ein Huhn ), wenn man noch was malen wollte (in sowas bin ich nicht so gut). Der Gegner kann manchmal glitch-mäßig "wegspringen", wenn er "eingekesselt" wird (was ja noch nicht so optimal ist).

Dann gibt es vier "Siderunner" (wie ich sie nenne). Die sind ganz witzig.

Es gibt drei Leben und kurze Mitteilungen bei "Game Over" oder "Level geschafft" (75% der Fläche gefüllt). Noch keinen Sound. Bisher nur Tastatursteuerung (PC-Cursor-Tasten). Schrift in "Arial" (na ja, könnte auch schöner sein ).

Ist als Spiel alles immer noch nicht so weltbewegend, also ich würde es selbst nicht unbedingt spielen wollen. Es ging mir halt mehr darum zu sehen, ob ich sowas prinzipiell schreiben kann.

Ist jetzt auch auf Windows 10 getestet. Bräuchte halt den Python-Interpreter und Pygame. Das Skript ist bisher (nach meiner eigenen Einschätzung) aber nicht so toll, daß es sich lohnen würde, das nur dafür zu installieren.

Trotzdem viel Spaß!

Code: https://github.com/hlubenow/pyqueex

@EgonOlsen71: Vielen Dank für das Feedback! Macht doch viel mehr Spaß, wenn andere sich das auch wirklich anschauen.

Ich guck' mir den Code nochmal an, und versuch' mich um die Probleme zu kümmern. Offenbar ist vor allem die Kollisionsüberprüfung noch nicht ganz, wie sie sein soll. Durchtunneln geht ja mal gar nicht. Das mit der Fläche muß ich mir auch ansehen.

Auch die Meldungen kommen ja noch viel zu schnell, und der Ablauf ist viel zu abrupt. Z.B. bei einer Kollision (wenn also ein Leben verlorengeht) wäre es ja schöner, wenn da erst noch eine Explosionsanimation zu sehen wäre, die ein bißchen Zeit vor den Neustart bringt, usw.. Müßte man halt alles noch schreiben, wenn es mal ein gutes Spiel werden sollte. Ist bisher alles noch roh.

Hallo,

hatte erstmal noch nicht wieder so viel Lust, an dem Qix-Klon weiterzuschreiben.

Aber vielleicht kann man das Thema ja etwas weiter fassen.

An Pygame reizt mich, daß man damit (endlich) Spiele (für den modernen PC) schreiben kann, die wie die Spiele von früher aussehen, und die auch so schnell laufen; aber ohne sich mit Assembler abzumühen. Auch wenn Pygame jetzt auch nicht gerade kinderleicht zu lernen ist - aber halt leichter als 6502- oder Z80-Assembler.

Hier ist gerade nochmal so ein "Proof of Concept": Jemand hat den ZX Spectrum- (und C64-) Klassiker "Skool Daze" (einschließlich der Nachfolger) in Pygame neu programmiert:

https://pyskool.ca

Das ist im Spectrum-Stil gehalten, es sieht also (exakt) so aus, wie die ZX Spectrum-Version damals. Mit

kann man das Scaling größer machen. Wenn man die Tastaturbelegung ändern will, kann man das durch Bearbeiten der Konfigurationsdatei "pyskool.ini" im Unterverzeichnis "./pskool/data" (ich hatte erst ewig in den Python-Skripten rumeditiert, und hab' mich gewundert, warum das nichts gebracht hat ) :

Krass finde ich, daß das Projekt 6,4 MB groß ist (!). Es kann wohl geschehen, daß Pygame-Spiele größer werden als der frühere Assembler-Code. Mein "Erster Level von Manic Miner" ist 64K groß, und da gäbe es noch Potential zur Verbesserung.

Mehrere MB ist schon nicht wenig.

Die Frage ist, will man jetzt alle Spiele von damals in diesem Format haben? Mir würde es wohl eher darum gehen, was Neues zu machen. Oder überhaupt die Möglichkeit dazu zu haben. Trotzdem freuen mich auch gelungene 100%-Nachbildungen. Ist die erste dieser Art, die ich bisher gefunden hab'.

Manchmal mag es bei sowas auch immer noch Probleme mit dem Copyright geben. Z.B. "Ultimate - Play the Game" ("Jetpac", "Atic Atac") sollen da relativ knickerig sein. Bei "Manic Miner" war ich mir nicht sicher (jemand wollte wohl nochmal eine Smartphone-Version verkaufen? Edit: Ach ja, stimmt), deshalb hab' ich's erstmal nur bei mir.

Zitat von ZeHa

Dabei wurde bereits der C64-Look voll eingehalten, d.h. die Python-Prototypen sehen quasi 1:1 aus wie die danach entstandene C64-Version.

Das ist doch cool, oder? Also, ich finde das cool.

-------------------------

Hier gerade nochmal eine Kleinigkeit von mir: Auf dem "Commander X16"- Emulator wollte ich wissen, wie man Sprites in C baut. Dazu hab' ich ein BASIC-Beispiel gefunden, und versucht, das nach C zu übersetzen. Hat auch soweit geklappt (war für mich aber mal wieder recht anstrengend).

Dann hat jemand so ein bißchen Grafik in BASIC gemacht, und das wollte ich auch übersetzen. Stellte sich heraus, daß ein einfaches "PLOT" in C (oder Assembler) auf dem Commander X16 nicht so einfach ist. Da muß man einiges vorbereiten, und dann gibt es so "Data-Ports", in die man Daten sendet. Wobei die Bildschirmstelle anscheinend automatisch verändert wird.

Die im Forum sagten auch nicht viel mehr als "Lies die Referenz", aber die ist nicht sehr ausführlich, da sind nur mehr oder weniger ein paar Speicheradressen angegeben (in die man aber nichtmal einfach so POKEn kann, um einen Punkt zu bekommen), das ist für mich so nicht verständlich.

Von all dem war ich angenervt und dachte, in Pygame geht das Sprite-Beispiel bestimmt auch. Also hab' ich das auch nochmal gebaut. Läuft ganz schön so, finde ich. Hier im Unterverzeichnis "pygame":

https://github.com/hlubenow/x1…ts/tree/main/x16_sprite.c

Nachdem ich mir ein weiteres mal an Assembler (sei es für PC, für Commander X16 oder für ZX Spectrum) die Zähne ausgebissen und keine besonderen oder gar vorzeigbaren Erfolge erzielt hab', bin ich wieder zu Pygame zurückgekehrt.

Hier also das nächste Experiment: Oldschool 3D-Grafik mit Rotation:

Code (Der (grüne) Download-Button ist ein Verzeichnis darüber.)

Screenshot unten.

Man kann das Skript auch mit der Option "-ship" starten.

Erstaunlich übrigens, wie gut OOP und Vererbung auf sowas zugeschnitten sind.

Nächster Schritt wäre, OpenGL zu lernen. Perspektivisch verschieben (links, rechts, weit weg, nah dran) sollte ja auch noch sein. Und gefüllte Flächen.

Dann nähert man sich schon fast "Starglider 2".

Das oben ist sozusagen "Painting with Rolf".

Die Amiga Boing-Ball-Demo fiele eigentlich auch in diese Kategorie, dachte ich mir. Bei der originalen Demo (1984) haben sie wohl ganz schön getrickst, damit das geht:

Zitat

By ... changing the offset values it bounces around the screen. The graphics hardware does the heavy lifting. No pixels need to be erased, no polygons rendered.

Tja, und wie wäre das in Pygame, wo eben doch Polygone gerendert werden müssen? Kein Problem!

https://github.com/niklasekstrom/boing_ball_python

166 Zeilen Python-Code. "What's the big deal?", möchte man fast fragen.