Moin,
wenn ich zwischen Server und Client textbasierte Daten (z.b. Webseiten oder Chatnachrichten) austauschen möchte, dann nehme ich auf dem Server Django (oder Flask) und auf dem Client einen Webbrowser.
Aber wenn ich mich auf der Client-Seite nicht mit HTML und Javascript herumärgern möchte, sondern auf Client-Seite gerne so etwas wie pygame haben möchte?
Nach dem ersten flüchtigem Blick in die pygame-Doku scheint es dort kein Kapitel zum Thema Kommunikation übers Netz zu geben.
Habe etwas übersehen oder sollte ich eine andere, mit Python nutzbare, Bibliothek nehmen?
netzwerkfähige Bibliothek
- __blackjack__
- User
- Beiträge: 13417
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
Was soll denn übertragen werden? Man muss für eine API die über HTTP läuft keinen Browser als Client verwenden.
“They say they blame it on a song when someone kills a cop, what music did they listen to when they bombed Iraq?” — Michael Franti
Das was gebraucht wird damit sich die Spieler bei dem Server an- und abmelden können und das was benötigt wird damit das Welt-Model auf dem Server aktualisiert werden kann und das was benötigt wird damit die Darstellung der veränderten Welt auf der Clientseite aktualisiert werden kann.
Wenn mein flüchtiger Blick in der pygame-Doku richtig war, dann müsste man sich bei pygame wohl selbst um die Netzwerkfähigkeit kümmern und z.b. vielleicht mit Twisted was hochziehen.
Arcade (https://pypi.org/project/arcade/) hatte ich auch schon entdeckt. Offenbar ebenfalls ohne eingebaute Netzwerkfähigkeit...
Wobei ich da jetzt einen Link entdeckt habe (muss ich mir mal in Ruhe anschauen): Multiplayer 2D games with Python Arcade
Offenbar zieht er da mittels zmq die Multiuser-Netzwerkfähigkeit von Grund auf hoch. Für so einen Vortrag auch gut so, aber hat da wirklich noch niemand den grundlegenden Code ein eine Bibliothek für Python gekippt und die veröffentlicht?
Ich habe da jetzt auch noch was zum lesen gefunden: https://joostdevblog.blogspot.com/2014/ ... games.html
Aha, vielleicht hatte ich die falschen Suchworte benutzt! Anstelle von Game-Bibliotheken und Netzwerkfähigkeit, nehme ich jetzt mal "multiplayer programming python" für die Suche. Aber falls da jemand schon passende Links kennt, denen ich folgen könnte....
Also der Betreff gehört eigentlich geändert: "netzwerkfähige Bibliothek" ist nicht meine Frage bzw. Ziel meiner Suche, sondern ich suche "Multiplayer-fähige Bibliothek"
Wenn mein flüchtiger Blick in der pygame-Doku richtig war, dann müsste man sich bei pygame wohl selbst um die Netzwerkfähigkeit kümmern und z.b. vielleicht mit Twisted was hochziehen.
Arcade (https://pypi.org/project/arcade/) hatte ich auch schon entdeckt. Offenbar ebenfalls ohne eingebaute Netzwerkfähigkeit...
Wobei ich da jetzt einen Link entdeckt habe (muss ich mir mal in Ruhe anschauen): Multiplayer 2D games with Python Arcade
Offenbar zieht er da mittels zmq die Multiuser-Netzwerkfähigkeit von Grund auf hoch. Für so einen Vortrag auch gut so, aber hat da wirklich noch niemand den grundlegenden Code ein eine Bibliothek für Python gekippt und die veröffentlicht?
Ich habe da jetzt auch noch was zum lesen gefunden: https://joostdevblog.blogspot.com/2014/ ... games.html
Aha, vielleicht hatte ich die falschen Suchworte benutzt! Anstelle von Game-Bibliotheken und Netzwerkfähigkeit, nehme ich jetzt mal "multiplayer programming python" für die Suche. Aber falls da jemand schon passende Links kennt, denen ich folgen könnte....
Also der Betreff gehört eigentlich geändert: "netzwerkfähige Bibliothek" ist nicht meine Frage bzw. Ziel meiner Suche, sondern ich suche "Multiplayer-fähige Bibliothek"
Du könntest auch auf GitHub nach Multiplayer-Games in Python suchen:
https://github.com/topics/multiplayer-g ... sc&s=forks
Recht ausgereift scheint mir dabei dies zu sein:
https://github.com/akapkotel/top-down-m ... er-shooter
Vielleicht kannst du dir da ein paar Dinge abgucken. Die meisten Projekte, die ich mir (kurz) angeguckt hab, setzen direkt auf dem socket-Modul auf. Da müsste man einschätzen, welche Vorteile das bringen kann. Alternativ gibt es ja Frameworks wie z.B. Twisted.
EDIT: Twisted hattest du ja schon selbst erwähnt. Ich denke, das ist einfach eine bessere Grundlage für einen eigenen Multiplayer-Server. Vermutlich hast du die Anleitung aus der Twisted-Doku auch schon gefunden, aber ich verlinke sie dennoch:
https://docs.twisted.org/en/stable/core ... rvers.html
https://github.com/topics/multiplayer-g ... sc&s=forks
Recht ausgereift scheint mir dabei dies zu sein:
https://github.com/akapkotel/top-down-m ... er-shooter
Vielleicht kannst du dir da ein paar Dinge abgucken. Die meisten Projekte, die ich mir (kurz) angeguckt hab, setzen direkt auf dem socket-Modul auf. Da müsste man einschätzen, welche Vorteile das bringen kann. Alternativ gibt es ja Frameworks wie z.B. Twisted.
EDIT: Twisted hattest du ja schon selbst erwähnt. Ich denke, das ist einfach eine bessere Grundlage für einen eigenen Multiplayer-Server. Vermutlich hast du die Anleitung aus der Twisted-Doku auch schon gefunden, aber ich verlinke sie dennoch:
https://docs.twisted.org/en/stable/core ... rvers.html
Ich bin zum einen schon seit vielen Jahren nur in lokalen Netzwerken und zum anderen dort nur mit Mercurial unterwegs. Daher habe ich öffentliche git-Geschichten nie so wirklich auf dem Schirm und suche dann nur im Web. Daher danke für den GitHub-Link. Vieles mehr oder weniger interessantes dabei... der top-down-multiplayer-shooter sieht nett und (noch) übersichtlich aus.
Meine Hoffnung war (oder 'ist') ja dass ich von solchen Lowlevel-Geschichten verschont bleibe. Vor Jahren hatte ich mal versucht mich mit Twisted anzufreunden... naja, bin ich nicht richtig mit warm geworden.
Mindestens ein Entwickler sieht das offenbar ähnlich und hat etwas auf der Basis von Django hochgezogen...
https://github.com/karamfarhan/SquaresGgame
Was das netzwerken auf Lowlevel-Ebene betrifft: da bin ich gestern noch bei ZeroMQ gelandet https://zeromq.org/
Laut "Eigenwerbung" in der Doku sollte man statt einfachen Sockets besser die Sockets (und 'Context') von zeroMQ nehmen. In meinem Firefox-Browser funktioniert die Doku zwar nicht richtig (die Python-Codebeispiele kommen nicht zur Anzeige), mit Microsoft Edge-Browser funktioniert sie aber...
...und hier auf meinem Linux-Rechner erzählt mir der Paketmanager dass ich ZeroMQ schon installiert habe und offenbar auch nutze: wird von libteam benötigt und das wird von networkmanager benötigt, der dann auch von KDE benötigt wird...
Offenbar ist zeroMQ wirklich aktuell im produktiven Einsatz und kein alter Kram den keiner mehr kennt bzw. zu neuer Kram den noch keiner kennt.
Eine für mich neue Engine habe ich auch aufgetan: "Ursina" https://www.ursinaengine.org/documentation.html
oder auf github: https://github.com/pokepetter/ursina
Auch mehr oder weniger viele Einträge die ich mir mal anschauen kann... und offenbar hatte da auch schon jemand in eine sehr ähnliche Richtung gedacht: https://github.com/BroCodeAT/python-multiplayer
So etwas könnte doch auch gleich in einer Game-Engine mitgeliefert werden...
Eben darum... meine Suche im Web, bei der ich mir verschiedene Projekte (kurz) angeguckt hatte, hat das gleiche Ergebnis geliefert....
Meine Hoffnung war (oder 'ist') ja dass ich von solchen Lowlevel-Geschichten
Code: Alles auswählen
from socket import socket, AF_INET, SOCK_STREAM, gethostname, gethostbyname, error as socket_error
Mindestens ein Entwickler sieht das offenbar ähnlich und hat etwas auf der Basis von Django hochgezogen...
https://github.com/karamfarhan/SquaresGgame
Was das netzwerken auf Lowlevel-Ebene betrifft: da bin ich gestern noch bei ZeroMQ gelandet https://zeromq.org/
Laut "Eigenwerbung" in der Doku sollte man statt einfachen Sockets besser die Sockets (und 'Context') von zeroMQ nehmen. In meinem Firefox-Browser funktioniert die Doku zwar nicht richtig (die Python-Codebeispiele kommen nicht zur Anzeige), mit Microsoft Edge-Browser funktioniert sie aber...
...und hier auf meinem Linux-Rechner erzählt mir der Paketmanager dass ich ZeroMQ schon installiert habe und offenbar auch nutze: wird von libteam benötigt und das wird von networkmanager benötigt, der dann auch von KDE benötigt wird...
Offenbar ist zeroMQ wirklich aktuell im produktiven Einsatz und kein alter Kram den keiner mehr kennt bzw. zu neuer Kram den noch keiner kennt.
Eine für mich neue Engine habe ich auch aufgetan: "Ursina" https://www.ursinaengine.org/documentation.html
oder auf github: https://github.com/pokepetter/ursina
Nun fiel mir gerade ein und auf: ich könnte auch mal bei pypi nach Multiplayer suchen https://pypi.org/search/?q=multiplayer
Auch mehr oder weniger viele Einträge die ich mir mal anschauen kann... und offenbar hatte da auch schon jemand in eine sehr ähnliche Richtung gedacht: https://github.com/BroCodeAT/python-multiplayer
So etwas könnte doch auch gleich in einer Game-Engine mitgeliefert werden...
Im Endeffekt geht das durchaus auch mit Flask. Es geht ja "nur" um das Anmelden und die Verwaltung der Teilnehmer innerhalb eines aktiven Spiels. Letzteres wird du wahrscheinlich selbst implementieren müssen. Ein wirklich ausgereiftes Framework dafür gibt es in Python AFAIK bisher nicht. Für die Übertragung von Nutzerdaten, Zustand und ähnlichem bietet sich bis zu einem gewissen Grad JSON an. Hängt auch davon ab, wieviel das Spiel auf der Client-Seite selber macht und welcher Anteil über das Netzwerk laufen soll. Dann auch noch die Frage, ob du von einem lokalen Netzwerk ausgehst oder per Internet übertragen willst. Denn du musst ja womöglich auch die Übertragungs- bzw. Reaktionszeit im Blick haben. Je nachdem, welche Art von Spiel du da hast und wieviel Netzwerkverkehr zu erwarten ist. Ich nehme an, es soll *nicht* im Browser laufen, da du ja PyGame ins Spiel gebracht hast...?
in der Zwischenzeit hatte ich auch mal bei den größeren Geschichten reingeschaut: "Godot" und "Unity". Beide haben auch ein Kapitel Networking in der Doku und bei beiden werde ich mit Python nichts. ![Sad :(](./images/smilies/icon_sad.gif)
Aber ich bin auch bei Panda3D gelandet. Ist zwar eigentlich C++, aber man kommt auch mit Python an die Engine ran und es gibt in der Doku dieses Kapitel: Networking
Also gibt es doch mindestens diese Gameengine: für Python, mit Netzwerk-Fähigkeiten!
Da war die Suche ja schon mal nicht erfolglos.
![Sad :(](./images/smilies/icon_sad.gif)
Aber ich bin auch bei Panda3D gelandet. Ist zwar eigentlich C++, aber man kommt auch mit Python an die Engine ran und es gibt in der Doku dieses Kapitel: Networking
Also gibt es doch mindestens diese Gameengine: für Python, mit Netzwerk-Fähigkeiten!
Da war die Suche ja schon mal nicht erfolglos.
Panda3D direkt zu nutzen halte ich für gewagt. Wir wissen aber natürlich nicht, wie fit du auf dem Gebiet bist. Das von dir bereits erwähnte Ursina-Framework setzt ja auf Panda3D auf. Dieser Ansatz könnte besser geeignet sein, um erstmal brauchbare Ergebnisse zu erzielen. Verändern kann man es später immer noch. Bei der konkreten Ausgestaltung der zu übertragenen Daten scheinst du dir selber nicht so sicher zu sein. Willst du wirklich die grafischen Objekte an sich übertragen oder reicht dir eine reine Nachrichtenübermittlung aus? Normalerweise rendert man ja auf der Client-Seite und überträgt bloß Positionsdaten, aktuelle wie auch immer geartete Eigenschaften des Spielers und solche Dinge über das Netzwerk. Die werden dann von den teilnehmenden Clients in die Spielersicht "übersetzt". So würde ich da zumindest rangehen.
Übrigens, selbst wenn du die Welt zufällig aufbauen lässt (bezüglich Farben, Objektformen, Positionen, etc.), könntest du mittels random.seed() aus der Standardbibliothek einen gemeinsamen Wert als Startpunkt für den Random-Generator benutzen (eine beliebige Zahl oder Zeichenfolge). Dieser wird zu Spielbeginn per Zufall vom Server erzeugt und an alle teilnehmenden Clients mitgeteilt. Wenn dann alle Clients den gleichen Algorithmus für den Bau der Welt nutzen, dann wird das Ergebnis überall gleich sein, weil das random-Modul überall den gleichen Zustand hat und somit vorhersehbare Werte ausspuckt (Stichwort: Pseudo-Zufall). Das erspart einem die Übersetzung der Welt in ein geeignetes Datenformat und spart natürlich auch die zu übertragene Datenmenge erheblich ein.
Theoretisch eher mau und praktisch schlechter...
![Wink ;)](./images/smilies/icon_wink.gif)
Dass bei einem Spiel mit mehreren Rechnern es auch problematisch ist, wenn die Rechner unterschiedlich schnell sind bzw. das Game mit unterschiedlichen FPS (frames per second) läuft weil dann die berechneten Positionen der Objekte in der Spielwelt unterschiedlich ist, ist mir auch erst richtig bewusst geworden nachdem ich kürzlich dazu etwas gelesen hatte.
Ein Problem welches nicht existiert wenn das Spiel nur lokal auf einem Rechner läuft. Aber wenn sich das Spiel auf mehrere Rechner in einem Netzwerk verteilt...
![Sad :(](./images/smilies/icon_sad.gif)
Und wahrscheinlich gibt es da noch tausendundzwei weitere Probleme die ich noch nicht auf dem Schirm habe...
Darum nun die Suche nach einer Bibliothek in der hoffnungsweise diese vielen Probleme schon irgendwie berücksichtigt bzw. behandelt wurden...
Gut, es hängt auch von der Art des netzwerk-fähigem Spiel ab welche Probleme da eigentlich relevant sind: beim Kartenspiel übers Netz sollten die jeweiligen FPS reichlich egal sein, beim Ballerspiel oder Autorennen ist es dann was ganz anderes...
Aber irgendetwas ist sicherlich immer und diese Probleme hatten dann andere Entwickler ja auch schon gehabt und gelöst.
Die klassischen Probleme, die man schon hat wenn das Spiel/Programm nur auf einem Rechner läuft, wie Animationen, Kollisionserkennung, Kamera, Licht, GUI werden ja eben schon in den verschiedenen Game-Bibliotheken abgehandelt.
Ich bin ja noch nicht mal sicher welche Projektidee ich als erstes umsetzen möchte....
"einfach" nur die farbigen Pixel zu übertragen ergäbe vielleicht einen einfachen Client, aber mehr als genügend andere Probleme über die ich nicht nachdenken möchte. Nee nee, ich bin da auch bei "Positionsdaten und dem ganzen Rest....". Die Clients dürfen dann daraus ein schönes Bild machen.snafu hat geschrieben: ↑Mittwoch 8. März 2023, 05:33 Willst du wirklich die grafischen Objekte an sich übertragen oder reicht dir eine reine Nachrichtenübermittlung aus? Normalerweise rendert man ja auf der Client-Seite und überträgt bloß Positionsdaten, aktuelle wie auch immer geartete Eigenschaften des Spielers und solche Dinge über das Netzwerk. Die werden dann von den teilnehmenden Clients in die Spielersicht "übersetzt". So würde ich da zumindest rangehen.
Aber wie ist es mit dem Erstellen der Clients?
Von der Ursina-Webseite:
Wenn ich hier unter Linux entwickel (ich könnte auch auf einen Windows-Rechner ausweichen), aber die angepeilten Anwender haben Windows-Rechner bzw. Mac....?Platforms
• Windows
• Linux
• Mac (not officially supported, but will most likely work)
Windows: um mit py2exe aus dem Python-Code eine Windows-Exe zu machen muss py2exe auf einem Windows-Rechner laufen damit er die Bibliotheken findet die in die Exe integriert werden müssen. Also dann vielleicht schon gleich auf einer Windows-Kisten entwickeln. Oder was für Alternativen gibt es da?
Mac: hier bin ich völlig planlos! Wie mache ich ein Mac-Programm? Ich hatte zwar früher schon mit Macs gearbeitet, aber noch nie Programme für entwickelt.
Eine der offenen Projektideen ist ein einfachster Multi-User-Chatserver. Dafür reaktiviere ich wohl am besten mein Channels-Tutorial-Projekt (https://channels.readthedocs.io/en/stab ... art_2.html) und nutze den Webbrowser als Client. Der läuft dann auch auf einem Mac.
Obwohl... ich glaube auf dem betroffenen Mac läuft auch ein Windows-Emulator (ich müsste mal den Mac-Besitzer fragen). Damit könnte ein Windows-Client für alle ausreichen.
Auf der anderen Seite ist der Mac heutzutage doch ein BSD-Unix, oder habe ich da was falsch verstanden? Da läuft doch auch Python... Also unter Linux ein Python-Programm schreiben welches dann später vom Python-Interpreter eines BSD-Unix abgearbeitet wird.... ist das einfach machbar, ist es überhaupt machbar?
Tja, oder halt das Frontend für den Browser entwickeln (Stichwort: JavaScript Game Engine) und ggf. die Server-Logik in Python schreiben. Dann bräuchte der User bloß einen aktuellen HTML5-tauglichen Browser, was deutlich bequemer sein dürfte. Hier ist bei grafiklastigen Spielen das Thema WebGL sicherlich einen Blick wert...