Hallo,
ich plane eine Umsetzung eines Brettspiels in der Form, dass es später im Browser gespielt werden kann. Nach längerem Recherchieren habe ich mich für Python als Programmiersprache entschieden. Das Ganze soll auf einem eigenen Webserver laufen (LAMP). Es soll keine KI implementiert werden, sondern nur die Regeln des Spiels. Vorbild ist die Brettspielwelt.
Bezüglich der Umsetzungen habe ich noch einige Fragen:
1. Ist Python die richtige Wahl oder habe ich etwas nicht bedacht, was eine Umsetzung in Python deutlich erschwert?
2. Ich werde die Teile des Brettspiels (Spielplan, Karten) einscannen und als Dateien ablegen, um dann den aktuellen Stand auf dem Spielbrett im Browser anzeigen zu lassen. Eventuell benötige ich später noch einige kleine grafische Elemente wie Kreise, Quadrate, die ich mit Hilfe von Python erstelle. Welches grafische Toolkit sollte ich dafür nehmen? Und wird es dann automatisch bei jedem Nutzer im Browser angezeigt (oder muss der Nutzer sich ein Plugin installieren, was ich natürlich nicht so gerne möchte)?
3. Zunächst werde ich eine lauffähige Version erstellen, die nur auf dem Rechner läuft, also noch nicht im Browser. Gibt es beim späteren Wechsel auf den Webserver einige Fallstricke oder reicht es, wenn ich das Python-Modul installiere? Oder sollte ich von Anfang an das ganze auf dem Webserver laufen lassen?
4. Hat jemand so etwas schonmal gemacht und kann über Erfahrungen berichten, evtl. sogar Links zu Beispielcodes posten?
Grüße Lars
Brettspielumsetzung mit Python?
Hallo und willkommen im Forum!
Ich würde erstmal zwei kleine Gegenfragen in den Raum stellen: Hast du schon mal etwas programmiert? Und in welchem Umfang und mit welcher Sprache? Aus deinen Ausführungen wird das nicht ganz deutlich, es hört sich alles noch etwas abenteuerlich an. Im besonderen die Darstellung auf der Clientseite.
Bis dann,
Sebastian
Ich würde erstmal zwei kleine Gegenfragen in den Raum stellen: Hast du schon mal etwas programmiert? Und in welchem Umfang und mit welcher Sprache? Aus deinen Ausführungen wird das nicht ganz deutlich, es hört sich alles noch etwas abenteuerlich an. Im besonderen die Darstellung auf der Clientseite.
Bis dann,
Sebastian
Das Leben ist wie ein Tennisball.
Danke für den Empfang!
Ich habe diverse Dinge in Java/Fortran/Prolog während des Studiums programmiert. Diese Programme liefen aber allesamt ausschließlich auf dem Rechner und nicht auf einem Webserver, sodass ich keine Erfahrung mit Serveranwendungen habe, ebensowenig mit grafischen Anwendungen.
Damit es nicht falsch verstanden wird: Die Brettspielwelt sollte als Beispiel dienen, wie es aussehen könnte. Meine Anwendung soll nur für einen kleinen privaten Kreis sein und auch nicht mit einem zusätzlichen Client laufen, sondern ausschließlich im Browser. Performance o.ä. spielt also keine große Rolle.
Ich habe einfach wieder Lust aufs Programmieren bekommen. Und damit es nicht ganz sinnfrei ist, habe ich mich für diese Umsetzung entschieden.
Grüße Lars
Ich habe diverse Dinge in Java/Fortran/Prolog während des Studiums programmiert. Diese Programme liefen aber allesamt ausschließlich auf dem Rechner und nicht auf einem Webserver, sodass ich keine Erfahrung mit Serveranwendungen habe, ebensowenig mit grafischen Anwendungen.
Damit es nicht falsch verstanden wird: Die Brettspielwelt sollte als Beispiel dienen, wie es aussehen könnte. Meine Anwendung soll nur für einen kleinen privaten Kreis sein und auch nicht mit einem zusätzlichen Client laufen, sondern ausschließlich im Browser. Performance o.ä. spielt also keine große Rolle.
Ich habe einfach wieder Lust aufs Programmieren bekommen. Und damit es nicht ganz sinnfrei ist, habe ich mich für diese Umsetzung entschieden.
Grüße Lars
-
Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Hast Du denn Erfahrung mit "Web-Programmierung"? Um so etwas hinzubekommen reicht es ja nicht nur, irgend was auf einem Server laufen zu lassen, sondern man braucht daneben ja sicherlich auch einen großen Anteil an JavaScript (oder eben auch Flash - auch wenn ich das aus Prinzip ablehnen würde 
). Reines HTML ohne aktive Inhalte dürfte für viele Sachen zu unflexibel sein.
Die Alternative wäre eine Client, der ein gängiges Toolkit nutzt (Qt oder Gtk z.B.), oder sogar ein Client mit pygame. In einigen Fällen könnte das sogar einfacher sein, anstatt sich mit den Fallstricken von http rumzuschlagen.
Hinzu kämen ja bei Webanwendungen das Auswählen / Einarbeiten in ein Framework. Django oder etwas "kleines" a la flask / bottle? Oder gar pures "werkzeug", um komplett flexibel zu sein?
Was ich nicht kapiere: Wieso schließt Du java so komplett aus; wo Du doch damit schon Erfahrung hast? Nicht, dass ich was gegen Python sagen wollte, aber um das mühsame Erlernen der Grundlagen wirst Du eh nicht drum rumkommen - da kannst Du solch ein Projekt garantiert nicht von Anfang an stemmen bzw. direkt darauf hinarbeiten.
Zudem bist Du wirklich nicht sehr konkret geworden. "Spielbrett einscannen" usw. ist ja keine Aussage über das wirkliche Prinzip.
). Reines HTML ohne aktive Inhalte dürfte für viele Sachen zu unflexibel sein.Die Alternative wäre eine Client, der ein gängiges Toolkit nutzt (Qt oder Gtk z.B.), oder sogar ein Client mit pygame. In einigen Fällen könnte das sogar einfacher sein, anstatt sich mit den Fallstricken von http rumzuschlagen.
Hinzu kämen ja bei Webanwendungen das Auswählen / Einarbeiten in ein Framework. Django oder etwas "kleines" a la flask / bottle? Oder gar pures "werkzeug", um komplett flexibel zu sein?
Was ich nicht kapiere: Wieso schließt Du java so komplett aus; wo Du doch damit schon Erfahrung hast? Nicht, dass ich was gegen Python sagen wollte, aber um das mühsame Erlernen der Grundlagen wirst Du eh nicht drum rumkommen - da kannst Du solch ein Projekt garantiert nicht von Anfang an stemmen bzw. direkt darauf hinarbeiten.
Zudem bist Du wirklich nicht sehr konkret geworden. "Spielbrett einscannen" usw. ist ja keine Aussage über das wirkliche Prinzip.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
Ok, ich versuche anhand eines Beispiels konkreter zu werden.
Unter http://endeavorpbw.appspot.com/gamelist hat jemand ein Brettspiel umgesetzt. Wenn man auf einen Link links in der Liste klickt, kommt man auf das Spielfeld. Die Spieler können Spielsteine verrücken, Karten aufnehmen und die Anwendung zählt am Ende die Siegpunkte. Das Beispiel ist sicher nicht sonderlich komfortabel, aber darum geht es auch nicht. Daran kann man später noch feilen.
So etwa soll meine Umsetzung aussehen mit einem Spiel, was ähnliche Vorausetzungen hat.
Zu Deinem Beitrag: Webprogrammmierung habe ich wenig Erfahrung. Und ich habe Java nicht ausgeschlossen. Aber da meine Programmierzeit eh ein bisschen her ist, spielt es keine Rolle, ob ich mich in Java wieder einarbeiten muss oder Python lerne. Entscheidend ist, was für meine Anwendung am besten geeignet ist.
Und ob ich ein Schachspiel oder das oben erwähnte Beispiel umsetze, ist auch nicht relevant. Die Regeln (also wie die Steine auf dem Brett ziehen dürfen) sind nicht das Problem. Wichtig ist für mich, was ich außer der Programmiersprache noch an Werkzeugen für mein Projekt benötige. Da fehlt mir ein wenig der Überblick.
Grüße Lars
Unter http://endeavorpbw.appspot.com/gamelist hat jemand ein Brettspiel umgesetzt. Wenn man auf einen Link links in der Liste klickt, kommt man auf das Spielfeld. Die Spieler können Spielsteine verrücken, Karten aufnehmen und die Anwendung zählt am Ende die Siegpunkte. Das Beispiel ist sicher nicht sonderlich komfortabel, aber darum geht es auch nicht. Daran kann man später noch feilen.
So etwa soll meine Umsetzung aussehen mit einem Spiel, was ähnliche Vorausetzungen hat.
Zu Deinem Beitrag: Webprogrammmierung habe ich wenig Erfahrung. Und ich habe Java nicht ausgeschlossen. Aber da meine Programmierzeit eh ein bisschen her ist, spielt es keine Rolle, ob ich mich in Java wieder einarbeiten muss oder Python lerne. Entscheidend ist, was für meine Anwendung am besten geeignet ist.
Und ob ich ein Schachspiel oder das oben erwähnte Beispiel umsetze, ist auch nicht relevant. Die Regeln (also wie die Steine auf dem Brett ziehen dürfen) sind nicht das Problem. Wichtig ist für mich, was ich außer der Programmiersprache noch an Werkzeugen für mein Projekt benötige. Da fehlt mir ein wenig der Überblick.
Grüße Lars
Ich habe seit Ewigkeiten im Netz ein browserbasiertes Brettspiel laufen, allerdings ist das Ding noch in PHP geschrieben und ich habe es noch nicht in Python umgesetzt. Es ist nicht so, als ob Python das nicht könnte, es würde sogar sicherlich deutlich eleganter sein, aber mir fehlte bisher einfach die Zeit und die Motivation dazu.LarsP hat geschrieben:Und ob ich ein Schachspiel oder das oben erwähnte Beispiel umsetze, ist auch nicht relevant. Die Regeln (also wie die Steine auf dem Brett ziehen dürfen) sind nicht das Problem. Wichtig ist für mich, was ich außer der Programmiersprache noch an Werkzeugen für mein Projekt benötige. Da fehlt mir ein wenig der Überblick.
Was habe ich gebraucht?
- Eine ordentliche Modellierung der Spielobjekte
- Die Spiellogik im serverseitigen Code
- Saubere Schnittstellendefinitionen
- Für dynamische Grafiken ein passendes Imaging-Modul
- Gute Kenntnisse in HTML und CSS
- Kenntnis des MVC-Modells
- Eine gute Entwicklungsumgebung
Edit: Oha, das von dir angegebene Beispielspiel ist "Magister Navis". Das ist das Spiel wo ich immer schon mit einem vorletzten Platz sehr glücklich bin.
Zuletzt geändert von /me am Dienstag 1. Juni 2010, 22:33, insgesamt 1-mal geändert.
-
Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Tja, also bei diesem Beispiel sehe ich viel JavaScript. Man muss also neben der Server seitigen Logik (und ggf. netzwerkommunikation) vor allem auch mit JavaScript umgehen können. Insofern wären das schon mal zwei Sprachen für Dich zu lernen.
Auf Server Seite brauchst Du dann vor allem ein Framework, dass irgend wie Sessions unterstützt, Ajax und ggf. Datenbank / Storage-APIs einbettet und natürlich Templates für die HTML-Ausgaben. Da gibt es viele viele Ansätze und Lösungen; einige hatte ich schon genannt. Im Forum und im wiki sollte man da auch noch mehr finden.
Generell wird es für Dich sicherlich schwer zu entscheiden, was genau der richtige Ansatz ist, da Du weder mit Python als Sprache, noch mit diesen Technologien / Konzepten vertraut zu sein scheinst. Imho ist das bereits ein KO-Kriterium für die stringente Umsetzung ohne den langwierigen Umweg über das Erlernen der Grundlagen zu gehen.
HTML ist für Brettspiele eben nicht wirklich gemacht - insofern würde ich dann schon überlegen, dass ganze per Stand-Alone Client mit PyQt, PyGTK oder eben auch pygame umzusetzen. Somit sparst Du Dir JavaScript zusätzlich zu erlernen (zumindest am Anfang; prinzipiell ist es sicherlich nie verkehrt sich das anzugucken) und hast generell mehr Flexibilität bei der Grafik.
Deine Hauptschwierigkeiten werden neben den typischen Sprachausdrücken vor allem die Datenorganisation und Modellierung sein. Wie verwaltet man denn ein solches Brettspiel? Was sind die notwendigen Kommandos, mit denen man den Spielfluss steuert? Wie werden "Züge" ausgewertet? Wie ein Sieg / Niederlage erkannt? usw.
Alleine das kann man komplett ohne Weboberfläche klären und testen! Bevor auch nur irgend was mit Grafik ins Spiel kommt, hast Du da schon einen Bazten von Arbeit...
Also mein Rat: Lerne ruhig Python, da es durchaus für solche Aufgaben geeignet ist und an sich eine imho tolle Sprache darstellt. Allerdings versteife Dich mal nicht zu sehr nur auf dieses eine Ziel. Und fang bescheiden mit den Grundlagen an - vergiss für die ersten Monate, dass es etwas wie GUIs o.ä. überhaupt gibt. Dann kannst Du irgend wann sogar damit anfangen, das Spiel als Konsolenapplikation aufzubauen. Wenn Du dann die Logik und die Daten im Griff hast, kannst Du Dir evtl. überlegen, wie man das ganze nun grafisch wrappen kann.
Auf Server Seite brauchst Du dann vor allem ein Framework, dass irgend wie Sessions unterstützt, Ajax und ggf. Datenbank / Storage-APIs einbettet und natürlich Templates für die HTML-Ausgaben. Da gibt es viele viele Ansätze und Lösungen; einige hatte ich schon genannt. Im Forum und im wiki sollte man da auch noch mehr finden.
Generell wird es für Dich sicherlich schwer zu entscheiden, was genau der richtige Ansatz ist, da Du weder mit Python als Sprache, noch mit diesen Technologien / Konzepten vertraut zu sein scheinst. Imho ist das bereits ein KO-Kriterium für die stringente Umsetzung ohne den langwierigen Umweg über das Erlernen der Grundlagen zu gehen.
HTML ist für Brettspiele eben nicht wirklich gemacht - insofern würde ich dann schon überlegen, dass ganze per Stand-Alone Client mit PyQt, PyGTK oder eben auch pygame umzusetzen. Somit sparst Du Dir JavaScript zusätzlich zu erlernen (zumindest am Anfang; prinzipiell ist es sicherlich nie verkehrt sich das anzugucken) und hast generell mehr Flexibilität bei der Grafik.
Deine Hauptschwierigkeiten werden neben den typischen Sprachausdrücken vor allem die Datenorganisation und Modellierung sein. Wie verwaltet man denn ein solches Brettspiel? Was sind die notwendigen Kommandos, mit denen man den Spielfluss steuert? Wie werden "Züge" ausgewertet? Wie ein Sieg / Niederlage erkannt? usw.
Alleine das kann man komplett ohne Weboberfläche klären und testen! Bevor auch nur irgend was mit Grafik ins Spiel kommt, hast Du da schon einen Bazten von Arbeit...
Also mein Rat: Lerne ruhig Python, da es durchaus für solche Aufgaben geeignet ist und an sich eine imho tolle Sprache darstellt. Allerdings versteife Dich mal nicht zu sehr nur auf dieses eine Ziel. Und fang bescheiden mit den Grundlagen an - vergiss für die ersten Monate, dass es etwas wie GUIs o.ä. überhaupt gibt. Dann kannst Du irgend wann sogar damit anfangen, das Spiel als Konsolenapplikation aufzubauen. Wenn Du dann die Logik und die Daten im Griff hast, kannst Du Dir evtl. überlegen, wie man das ganze nun grafisch wrappen kann.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
Ok, ich danke Euch erstmal für die hilfreichen Tipps. Mir war nicht bewusst, dass da noch mehr als nur Python+Webserver dranhängt. Zumindest nicht so viel mehr...
Ich werde dann wohl erstmal nur eine Standaloneversion auf dem Rechner umsetzen (in Python). Und es dann langsam in Richtung Webapplikation entwickeln.
@/me: Ja, Magister Navis ist momentan der Favorit in unserer Spielerunde. Ich war begeistert, dass man es auch mal online spielen kann.
Grüße Lars
Ich werde dann wohl erstmal nur eine Standaloneversion auf dem Rechner umsetzen (in Python). Und es dann langsam in Richtung Webapplikation entwickeln.
@/me: Ja, Magister Navis ist momentan der Favorit in unserer Spielerunde. Ich war begeistert, dass man es auch mal online spielen kann.
Grüße Lars
Hi Lars,
mit Python liegst du sicherlich nicht falsch, aber ich würde mich Hyperion mit der Einschätzung anschließen, dass du den Großteil deines Spiels in JavaScript implementieren wirst (wenn denn das UI einigermaßen interaktiv sein soll) und daher empfehlen, nicht nur auf dem Client, sondern dann auch gleich auf dem Server JavaScript zu benutzen. Node.js ist ein sehr interessantes Projekt, welches insbesondere gut für Comet (simulierter Server-Push mittels Long-Polling vom Client) und für Web-Sockets (dem kommenden Standard im Rahmen von HTML5, bereits implementiert in Chrome) geeignet ist. Als Datenbank würde ich MongoDB empfehlen. Falls dir node.js gefällt und es da noch keinen MongoDB-Treiber geben sollte, wäre Redis eine interessante Alternative.
Zum Thema Spielplan einscannen will ich noch anmerken, dass du bei kommerziellen Spielen ziemlich sicher deren Copyright verletzt, außerdem (oder Alternativ) noch deren Wort- und Bildmarken. Brettspielwelt hat es offenbar geschafft, das Okay der Verlage zu bekommen, aber ob die das noch jemandem geben würden, weiß ich nicht.
Bereits mit einfachem HTML4 und dem geschickten absoluten Platzieren von Grafiken kommt man schon recht weit, doch mit HTML5, Canvas und/oder SVG sollte es genug Möglichkeiten für Brettspiele geben, sodass du kein Plugin installieren musst. Den Weg mit Templates und serverseitigem Generieren von HTML-Seiten würde ich nicht gehen, sondern akzeptieren, dass es eine echte Web-App ist, die aus einer Seite HTML mit viel JavaScript ist, die dynamisch alles weitere regelt.
Außer -- du willst auch im Browser Python programmieren, wozu du dann Silverlight (bzw. Moonlight) mit der IronPython-Bibliothek nutzen könntest. Den Weg würde ich mangels Erfahrung damit allerdings nicht gehen.
Von der Idee, zunächst eine (grafische) Version ohne Web zu bauen, halte ich nichts. Das soll nicht heißen, dass es nicht sinnvoll ist, Modell und Darstellung zu trennen, doch eine (interaktive) Webanwendung funktioniert deutlich anders als z.B. eine Tk-Anwendung.
Ich hatte vor einigen Jahren mal vor, Twilight Imperium umzusetzen, weil die 2. Auflage vergriffen war, die dritte (inzwischen erschienene) nicht in Sicht und das Spiel spannend klang und ich es gerne mal gespielt hätte, es mir aber zu teuer war. Gemacht hatte ich das dann aber doch nicht, könnte jedoch ein paar Gedanken dazu teilen.
Wenn Java nicht ausgeschlossen ist und du damit Erfahrung hast, ist vielleicht GWT eine gute Idee. Gerade wenn man ein bisschen Erfahrung hat, wie AWT oder Swing (oder meinetwegen auch Qt oder Wx) funktionieren, ist das recht einfach - wenn auch Java-gewohnt etwas umständlich - zu benutzen. Und man muss sich um keine Details bzgl. HTML, JavaScript oder der Interaktion mit dem Server kümmern. Und MongoDB geht immer noch
Raphael soll eine ziemlich gute Bibliothek für Vektorgrafik (SVG bzw. VML beim IE) sein und da scheint es auch eine GWT-Anbindung für zu geben. Benutzt habe ich's noch nicht. GWTCanvas fand ich jedenfalls nicht so toll. Damit wollte ich mir schon mal ein von Morphic inspiriertes UI-Rahmenwerk bauen.
Stefan
mit Python liegst du sicherlich nicht falsch, aber ich würde mich Hyperion mit der Einschätzung anschließen, dass du den Großteil deines Spiels in JavaScript implementieren wirst (wenn denn das UI einigermaßen interaktiv sein soll) und daher empfehlen, nicht nur auf dem Client, sondern dann auch gleich auf dem Server JavaScript zu benutzen. Node.js ist ein sehr interessantes Projekt, welches insbesondere gut für Comet (simulierter Server-Push mittels Long-Polling vom Client) und für Web-Sockets (dem kommenden Standard im Rahmen von HTML5, bereits implementiert in Chrome) geeignet ist. Als Datenbank würde ich MongoDB empfehlen. Falls dir node.js gefällt und es da noch keinen MongoDB-Treiber geben sollte, wäre Redis eine interessante Alternative.
Zum Thema Spielplan einscannen will ich noch anmerken, dass du bei kommerziellen Spielen ziemlich sicher deren Copyright verletzt, außerdem (oder Alternativ) noch deren Wort- und Bildmarken. Brettspielwelt hat es offenbar geschafft, das Okay der Verlage zu bekommen, aber ob die das noch jemandem geben würden, weiß ich nicht.
Bereits mit einfachem HTML4 und dem geschickten absoluten Platzieren von Grafiken kommt man schon recht weit, doch mit HTML5, Canvas und/oder SVG sollte es genug Möglichkeiten für Brettspiele geben, sodass du kein Plugin installieren musst. Den Weg mit Templates und serverseitigem Generieren von HTML-Seiten würde ich nicht gehen, sondern akzeptieren, dass es eine echte Web-App ist, die aus einer Seite HTML mit viel JavaScript ist, die dynamisch alles weitere regelt.
Außer -- du willst auch im Browser Python programmieren, wozu du dann Silverlight (bzw. Moonlight) mit der IronPython-Bibliothek nutzen könntest. Den Weg würde ich mangels Erfahrung damit allerdings nicht gehen.
Von der Idee, zunächst eine (grafische) Version ohne Web zu bauen, halte ich nichts. Das soll nicht heißen, dass es nicht sinnvoll ist, Modell und Darstellung zu trennen, doch eine (interaktive) Webanwendung funktioniert deutlich anders als z.B. eine Tk-Anwendung.
Ich hatte vor einigen Jahren mal vor, Twilight Imperium umzusetzen, weil die 2. Auflage vergriffen war, die dritte (inzwischen erschienene) nicht in Sicht und das Spiel spannend klang und ich es gerne mal gespielt hätte, es mir aber zu teuer war. Gemacht hatte ich das dann aber doch nicht, könnte jedoch ein paar Gedanken dazu teilen.
Wenn Java nicht ausgeschlossen ist und du damit Erfahrung hast, ist vielleicht GWT eine gute Idee. Gerade wenn man ein bisschen Erfahrung hat, wie AWT oder Swing (oder meinetwegen auch Qt oder Wx) funktionieren, ist das recht einfach - wenn auch Java-gewohnt etwas umständlich - zu benutzen. Und man muss sich um keine Details bzgl. HTML, JavaScript oder der Interaktion mit dem Server kümmern. Und MongoDB geht immer noch
Raphael soll eine ziemlich gute Bibliothek für Vektorgrafik (SVG bzw. VML beim IE) sein und da scheint es auch eine GWT-Anbindung für zu geben. Benutzt habe ich's noch nicht. GWTCanvas fand ich jedenfalls nicht so toll. Damit wollte ich mir schon mal ein von Morphic inspiriertes UI-Rahmenwerk bauen.Stefan