Zope als Browsergamebasis

Django, Flask, Bottle, WSGI, CGI…
Benutzeravatar
Phlegma
User
Beiträge: 20
Registriert: Samstag 24. Januar 2009, 12:05

Hi,
bin neu im Forum und auch neu in Pyton. Ich hab noch keinen einzigen Python Script geschrieben...
Bin grade dabei ein Galileo Computing Buch durchzuackern, ist aber nur wie Vokablen lernen, habe schon viel mit PHP gemacht und bin immer noch dabei mich intensiv mit Softwardesign zu beschäftigen.

Ich schwanke bei einer Entscheidung noch mal einen Haufen bereits geschriebenen Code wegzuschmeißen um nochmal mit Python neu anzufangen.

Wahrscheinlich muss ich noch einiges lesen/lernen bevor ich hier wirklich mitreden kann, doch hier soll es erstmal darum gehen, ob sich Zope als Basis für ein Browsergame eignet.

Ich habe vor bestimmte Basisvorgänge der Businesslogik sehr nahe an einer PostgreSQL Datenbank auszuführen, auch dort würde sich Python anbieten, bisher hatte ich Stored Procedures in MySQL. Verträgt sich das mit Zope? In PHP war ich schon dabei meinen eigenen Pseudo OR-Mapper zu schreiben.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Hallo Phlegma, willkommen im Python-Forum,

So gut oder schlecht Zope ist, ist es auf jeden Fall recht kompliziert durchzusteigen (da würde man wohl noch ein Buch durchlesen) und viele Vorteile spielt es mit der ZODB aus. Es könnte auch sein, dass Zope für ein Browsergame overkill und ggf. zu langsam ist. Ich könnte mir vorstellen, dass Pylons oder Werkzeug dafür besser geeignet sind.

Achja, und lies besser ein weniger schlechtes Buch als das Openbook ;)
Benutzeravatar
Käptn Haddock
User
Beiträge: 169
Registriert: Freitag 24. März 2006, 14:27

Hallo!
Prinzipiell verträgt sich Zope ausgezeichnet mit Postgres. Trotzdem würde ich dir als Anfänger mit Python nicht dazu raten. Zope nutzt intern eine eingeschränkte Version von Python und ist, wenn man mit Python noch gar nichts gemacht hat, eher schwer verständlich.
Django wäre auch eine Möglichkeit, die dir vermutlich besser entgegenkommen würde.

Gruß Uwe
---------------------------------
have a lot of fun!
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Käptn Haddock hat geschrieben:Django wäre auch eine Möglichkeit, die dir vermutlich besser entgegenkommen würde.
Gerade Django ist auf ORM Seite eher schwach und so wie ich verstehe braucht der OP irgendwelche speziellen Datenbank-Features, da wäre SQLAlchemy vermutlich besser geeignet.
Benutzeravatar
Phlegma
User
Beiträge: 20
Registriert: Samstag 24. Januar 2009, 12:05

Dann kein Framework? Ich habe eigentlicht keine Lust Rechteverwaltung etc zu schreiben, da wäre ein Framework schon praktisch... Sonst bleib ich vllt doch bei PHP und übersetze es später mal nach Python...

Was hast du gegen das Openbook?
Benutzeravatar
Käptn Haddock
User
Beiträge: 169
Registriert: Freitag 24. März 2006, 14:27

Leonidas hat geschrieben:
Käptn Haddock hat geschrieben:Django wäre auch eine Möglichkeit, die dir vermutlich besser entgegenkommen würde.
Gerade Django ist auf ORM Seite eher schwach und so wie ich verstehe braucht der OP irgendwelche speziellen Datenbank-Features, da wäre SQLAlchemy vermutlich besser geeignet.
@Leonidas: Da geb ich dir recht. Für komplexe Datenbanksachen ist das sicher besser.

@OP: Ein Framework ist sicher eine gute Sache. Aber vorher solltest du deine Anforderungen daran genauer formulieren, dann kann man eine bessere Wahl treffen.

Das Openbook stellt verschieden Dinge sowohl fachlich als auch diaktisch zweifelhaft dar, Leonidas kann dir das sicher genauer sagen. Ich nutze es trotzdem gerne als Kompendium/Nachschlagewerk. Ergänzend dazu habe ich aber mittlerweile einen ganzen Schrank ergänzender Bücher zu speziellen Themen wie Qt, Django, Zope, SQLalchemy, OOP etc. Auch im Inet findet man sehr vieles, was meist aktueller als Bücher ist. So kann man auch mit den Fehlern des Buchs ganz gut leben.

Gruß Uwe
---------------------------------
have a lot of fun!
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Vorweg: Ich kenne Zope kaum (habe nur ein bisschen mit Grok gespielt) und meine Erfahrung mit browserbasierten Spielen ist eher theoretisch. Das hindert mich aber nicht an einer Antwort, da ich das Thema interessant finde ;)

Für Zope spricht IMHO die objektorientierte Datenbank ZODB. Diese kann es einfacher machen, das Datenmodell des Spiels zu repräsentieren, da man sich nicht mit einer relationalen Datenbank (Postgres) herumquälen muss. Selbst mit einem ORM ist das IMHO immer noch ein mühsames Unterfangen - jedenfalls wenn es transaktionssicher sein soll. Zope kann zwar auch mit relationalen Datenbanken, aber eigentlicher Vorteil ist ZODB. Ich würde so weit gehen uns sagen, dass wenn du diese DB nicht haben willst, brauchst du auch Zope nicht.

Selbst mit Grok fand ich Zope recht aufwendig und würde daher eher zu Django raten. Der Einstieg ist da viel einfacher. Gleichzeitig ist Django vollständig und du musst dir nicht alle Komponenten aus diversen Teilprojekten zusammensuchen. Django ist allerdings eher ein CMS, denn ein Application Server wie Zope und passt somit auch nicht optimal.

Meine, vielleicht überholte, Vorstellung von Browsergames kommt eher der eines Postspiels nah, wo Spieler ihre Züge an den Server schicken (also z.B. über ein Formular eingeben oder sonstwie zusammenklicken), der diese dann quasi gleichzeitig gemäß der Spielregeln auswertet, damit den Zustand des Spiels ändert, und den Spielern dann einen Report zukommen lässt, der dann die Grundlage für den nächsten Spielzug ist.

Dieses Ansatz hatte ich bei einem meiner ersten Django-Gehversuche ausprobiert und es war furchtbar umständlich. Ich wollte alle Spielstände aufbewahren und versuchte somit, jedes Datenobjekt zu versionieren. Einfache Dateien wären ausreichend gewesen. Das ganze ist sehr funktional, ich ändere niemals Daten, sondern schreibe für jeden Spielstand immer wieder neue Dateien. Etwas wie CouchDb könnte da ganz gut passen, scheint mir aber auch ein großer Overhead.

Beispiel:

Es gibt Spieler. Es gibt Planeten. Planeten sind durch Sprungtore verbunden. Spieler können Planeten besitzen, diese entwickeln, dadurch Raumschiffe bauen und zu anderen Planeten schicken. Treffen Raumschiffe mehrerer Spieler aufeinander, wird gekämpft bis nur noch ein Spieler dort Raumschiffe hat. Für jedes Schiff werfe ich einen sechsseitigen Würfel. Bei 4+ wird ein gegnerisches Schiff zerstört. So kann das Datenmodell aussehen, wobei ich die Typen hinter die Attributnamen geschrieben habe, um die Attribute zu erklären:

Code: Alles auswählen

class Game:
    turn = int
    players = [Player]
    planets = [Planet]

class Player:
    name = str
    planets = [Planet]
    orders = [Order]

class Planet:
    no = int
    neighbors = [Planet]
    owner = [Player]
    development_level = int
    ships = int
    incoming_ships = {Player:int}
Spieler und Planeten werden durch ein Spiel-Objekt zusammengehalten. Dies kann man einfach so serialisieren, z.B. mit pickle. Die Befehle der Spieler beschränken sich darauf, anzugeben, von welchem Planeten wie viele Raumschiffe zu einem Nachbarplaneten fliegen sollen.

Code: Alles auswählen

class MoveOrder(Order):
    issuer = Player
    from_planet = Planet
    to_planet = Planet
    ships = int
    
    def execute(self):
        if from_planet.owner == self.issuer and \
            from_planet.ships >= self.ships and \
            to_planet in self.from_planet.neighbors:
                from_planet.ships -= self.ships
                to_planet.incoming_ships[self.issuer] += self.ships
Sind alle Befehle eingegangen, kann eine Runde ausgewertet werden. Alle Bewegungsbefehle können parallel und in einer beliebigen Reihenfolge durchgeführt werden. Dadurch, dass ich Schiffe in ein `incoming_ships` dict verschiebe, können sie sich auch nicht mehr als einmal bewegen. Danach kann ich pro Planet prüfen, ob es zu kämpfen kommt und der Besitzer des Planeten sich ändert und schließlich die Anzahl der Raumschiffe aufstocken.

Code: Alles auswählen

class Game...
    def process_turn(self):
        self.turn += 1
        for p in self.players:
            for o in p.orders: o.execute()
        for p in self.planets:
            p.combat()
            p.arm()

class Planet...
    def arm(self):
        if self.development_level == 1:
            self.ships += 1
        elif self.development_level == 2:
            self.ships += d6()
        elif self.development_level == 3:
            self.ships += d6() + d6()
    
    def combat(self):
        if self.owner:
            if self.owner not in self.incoming_ships:
                self.incoming_ships[self.owner] = 0
            self.incoming_ships[self.owner] += self.ships
        while len(self.incoming_ships) > 1:
            casulties = []
            for p1, count1 in self.incoming_ships.items():
                enemies = []
                for p2, count2 in self.incoming_ships.items():
                    if p1 == p2:
                        continue
                    enemies.extend([p2] * count2)
                shuffle(enemies)
                hits = sum(d6() >= 4 for i in range(count1))
                casulties.extends(enemies[:hits])
            for p in casulties:
                if p in self.incoming_ships:
                    self.incoming_ships[p] -= 1
                    if self.incoming_ships[p] == 0:
                        del self.incoming_ships[p]
        self.owner = None
        self.ships = 0
        for owner, ships in self.incoming_ships.items():
            self.owner = owner
            self.ships = ships
Spiel ist fertig :) Jetzt braucht es nur noch eine Webseite, die jedem Spieler eine Liste mit seinen Planeten anzeigt, die Eingabe der Befehle etwas einfacher macht und die die Ergebnisse anzeigt. Das Spiel sollte nämlich den Besitzerwechsel eines Planeten oder eine gewonnene oder verlorene Schlacht irgendwie aufzeichnen.

Ach ja, und ich will noch mal auf http://www.python-forum.de/post-121169.html#121169 hinweisen.

Stefan
Benutzeravatar
Phlegma
User
Beiträge: 20
Registriert: Samstag 24. Januar 2009, 12:05

Hm, danke für das Angebot, doch das Spiel wird eher à la OGame und daher mehr Langzeit- als Rundenbasiert.

Ich schreibe gerne alles von Grund auf, doch eine Userverwaltung wäre praktisch gleich miteinzuarbeiten. Mit einem Framework könnte das sogar performanter sein als ich es überhaupt schreiben kann, ich weiß nicht.
Ein ORM wäre schon praktisch, micht drängt es aber meinen eigenen Entwurf in dieser Richtung durchzubringen.
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Ich kenne OGame nur vom Hörensagen. Rundenbasiert ist aber wahrscheinlich auch dieses - nur liegt die Länge einer Runde eher im Minutenbereich und Aktionen können länger als eine Runde dauern. Ich würde aber erst einmal vermuten, dass es nichts am Prinzip ändert. Mir persönlich missfällt allerdings ein Spiel, dass 24h am Stück läuft und mich dadurch zwingt, immer online zu sein. Meine Wunschvorstellung ist etwas, dass ich in der Mittagspause in 10-15min spielen kann.

Ansonsten kann ich nur als Tipp anbieten: Wenn du ein Spiel schreiben willst, schreibe das Spiel. Schreibe keinen weiteren ORM, kein Web-Irgendwas und kein CMS. Schreibe insbesondere kein Rahmenwerk für was auch immer, wenn du nicht das Problem mindestens schon 3x gelöst hast. Es gibt einfach zu viele Rahmenwerke.

Ich persönlich würde wahrscheinlich versuchen, erstmal ein funktionierendes Spiel ganz ohne Web, Grafik, usw. zu entwerfen. Das erscheint mir der schwierigste Teil zu sein. Jedenfalls, wenn es originell sein soll.

<ot><rant>Ich weiß nicht, wie Browsergames in der Regel geschrieben werden, aber von der Zeit, wo ich bei browsergames24 im Forum über Programmierung mitgelesen habe, hat sich bei mir das Vorurteil festgesetzt, dass da überwiegend Amateure, Programme zusammenstümpern, dass es körperlich schmerzt. PHP+Mysql scheint mir eine ungenügende Basis zu sein, da kaum Abstraktionen (wie sie z.B. die Objektorientierung bietet) genutzt werden, die ein so schwieriges Thema wie das einer Simulation handhabbarer machen würden. Auch transaktionssichere Datenverarbeitung scheint ebenso unbekannt wie die einfachsten Prinzipien der Software-Entwicklung.</rant></ot>

Mit Python sollte es einfacher fallen, weniger dieser Fehler zu machen.

Stefan
Birne94
User
Beiträge: 90
Registriert: Freitag 28. November 2008, 15:18
Kontaktdaten:

<ot><rant>Ich weiß nicht, wie Browsergames in der Regel geschrieben werden, aber von der Zeit, wo ich bei browsergames24 im Forum über Programmierung mitgelesen habe, hat sich bei mir das Vorurteil festgesetzt, dass da überwiegend Amateure, Programme zusammenstümpern, dass es körperlich schmerzt. PHP+Mysql scheint mir eine ungenügende Basis zu sein, da kaum Abstraktionen (wie sie z.B. die Objektorientierung bietet) genutzt werden, die ein so schwieriges Thema wie das einer Simulation handhabbarer machen würden. Auch transaktionssichere Datenverarbeitung scheint ebenso unbekannt wie die einfachsten Prinzipien der Software-Entwicklung.</rant></ot>
PHP ist durchaus Objektorientiert...
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Birne94 hat geschrieben:
<ot><rant>Ich weiß nicht, wie Browsergames in der Regel geschrieben werden, aber von der Zeit, wo ich bei browsergames24 im Forum über Programmierung mitgelesen habe, hat sich bei mir das Vorurteil festgesetzt, dass da überwiegend Amateure, Programme zusammenstümpern, dass es körperlich schmerzt. PHP+Mysql scheint mir eine ungenügende Basis zu sein, da kaum Abstraktionen (wie sie z.B. die Objektorientierung bietet) genutzt werden, die ein so schwieriges Thema wie das einer Simulation handhabbarer machen würden. Auch transaktionssichere Datenverarbeitung scheint ebenso unbekannt wie die einfachsten Prinzipien der Software-Entwicklung.</rant></ot>
PHP ist durchaus Objektorientiert...
PHP bietet die möglichkeit Objekte und Klassen zu erstellen. Aber es scheint sich nicht daran zu orientieren. Zumindest sind (waren?) die meisten APIs rein strukturiert. Für eine dynamische Sprache ist das Objekt Model auch sehr primitiv.

Und zum Topic, ich denke nicht das Zope dafür eine optimale Lösung bietet. Ich würde eher in Richtung Werkzeug+SQLAlchemy+Jinja2 tendieren. Vor allem wegen SQLAlchemy. Wobei Django auch eine Lösung ist und dir der Einstieg vermutlich leichter fallen wird.

- Jonas
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
BlackJack

Vielleicht stammen sma's Erfahrungen mit dem Forum noch aus Zeiten wo sich PHP5 noch nicht so durchgesetzt hatte.

Und jetzt behaupte mir bitte niemand, dass PHP4 objektorientiert ist. Damit musste ich nämlich mal was machen und bin fast an den netten Randbedingungen verzweifelt, die man da beachten musste. Kann mich da noch so dunkel an Sachen erinnern, wie das man die Ergebnisse von Methodenaufrufen nicht immer sofort verwenden, sondern zwingend an Namen binden musste.
Benutzeravatar
Phlegma
User
Beiträge: 20
Registriert: Samstag 24. Januar 2009, 12:05

Ja ich befasse mich schon länger mit dem Thema, dein Eindruck ist allerdings nur der erste Blick. Das Problem ist die Einfachheit und Verfügbarkeit von PHP, dass es gerne von Anfängern genutzt wird. Die Resultate sind dementstrechend schlecht. Doch meist sind Abstraktionen überhaupt nicht notwendig für eine Website.

Vor einem Jahr war ich auch noch Anfänger, bin aber gerade durch die intensive Beschäftigung mit dem Thema schnell voran gekommen, anstatt weiter auf der Stümperebene zu bleiben.

Mir missfällt an den ORM-Frameworks, das was eigentlich gefallen sollte. Ich gebe die Macht über die Datenbank an ein bestimmtes Konstrukt, das mir aus Einträgen Objekte mit Beziehungen erstellt. Entweder ich habe es einfach noch nicht verstanden, oder ich möchte meine Queries einfach spezieller formulieren. Dann erscheint mir das ORM allerdings als Bremse.
[url]http://ugamela-blog.pheelgood.net[/url]
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Phlegma hat geschrieben:Doch meist sind Abstraktionen überhaupt nicht notwendig für eine Website.
Ich würde sagen: doch, durchaus. Wenn ich alle etwas komplizierteren Abstraktionen rausnehme, die in typischen PHP-Code nicht verhanden sind, dann Ende ich mit sowas wie Wordpress oder phpBB. Und diesen Code will man wirklich nicht warten müssen.
Benutzeravatar
Phlegma
User
Beiträge: 20
Registriert: Samstag 24. Januar 2009, 12:05

Genau das ist das Problem und deshalb plane ich mein Projekt lieber besser. Momentan bin ich so weit, dass ich einsehe dass Python die bessere Lösung ist. Jetzt stehen noch ein paar Frameworks zur Wahl..
[url]http://ugamela-blog.pheelgood.net[/url]
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Phlegma hat geschrieben:Mir missfällt an den ORM-Frameworks, das was eigentlich gefallen sollte. Ich gebe die Macht über die Datenbank an ein bestimmtes Konstrukt, das mir aus Einträgen Objekte mit Beziehungen erstellt. Entweder ich habe es einfach noch nicht verstanden, oder ich möchte meine Queries einfach spezieller formulieren. Dann erscheint mir das ORM allerdings als Bremse.
Seh dir SQLAlchemy an ;)
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
Benutzeravatar
Phlegma
User
Beiträge: 20
Registriert: Samstag 24. Januar 2009, 12:05

Hab jetzt nicht die besonderen Unterschiede zu anderen ORM Mappern finden können. Ich habe weiterhin das Gefühl, dass diese ORM Frameworks einen Overhead prodizieren, den ich gar nicht brauche. Ich werde mich natürlich weiterhin mit dem Thema beschäftigen und rausfinden was das Beste für mein Spiel (übrigens dann AGPL) und mich ist.

Ich hoffe immer noch auf ein paar Meinungen welches Framework (wenn überhaupt) passen würde. Es darf auch gerne kompliziert sein wenn es performant ist.
[url]http://ugamela-blog.pheelgood.net[/url]
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Phlegma hat geschrieben:Hab jetzt nicht die besonderen Unterschiede zu anderen ORM Mappern finden können.
DataMapper statt ActiveRecord und wie gesagt, das ORM ist optional. Man kann den ORM-Layer weglassen und ich kenne durchaus jemanden der das auch so macht.

Ich habe hier eine Erklärung, warum SQLAlchemy auch ohne das ORM sinnvoll ist.
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Leonidas hat geschrieben:
Phlegma hat geschrieben:Hab jetzt nicht die besonderen Unterschiede zu anderen ORM Mappern finden können.
DataMapper statt ActiveRecord und wie gesagt, das ORM ist optional. Man kann den ORM-Layer weglassen und ich kenne durchaus jemanden der das auch so macht.

Ich habe hier eine Erklärung, warum SQLAlchemy auch ohne das ORM sinnvoll ist.
Als ich die URL gesehen habe war mir sofort klar das es sich um einem Vortrag von __doc__ handeln muss *g*
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
Benutzeravatar
Phlegma
User
Beiträge: 20
Registriert: Samstag 24. Januar 2009, 12:05

Okay, vllt kann man sich die Queries mit den Expressions einfacher bauen und es ist zu mehreren Datenbanken kompatibel, doch letzteres brauche ich nicht umbedingt (PostgresSQL würde mir reichen) und mich macht das ewige PREPARE skeptisch, von PHP und MySQL internen Proceduren weiß ich, dass das zwar recht sicher ist, aber auch recht langsam. Ich möchte DB Kapatzitäten lieber anders nutzen.
[url]http://ugamela-blog.pheelgood.net[/url]
Antworten