Zope als Browsergamebasis

Django, Flask, Bottle, WSGI, CGI…
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Montag 26. Januar 2009, 21:05

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

Montag 26. Januar 2009, 22:14

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
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Dienstag 27. Januar 2009, 09:42

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:

Dienstag 27. Januar 2009, 11:20

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

Dienstag 27. Januar 2009, 14:06

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]
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Dienstag 27. Januar 2009, 15:39

Phlegma hat geschrieben: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.
Ich denke weniger das dir das Probleme bereiten wird. Vor allem nimmt es dir arbeit ab die du dafür ins Spiel investieren kannst. Am späteren optimieren wird es dich auch nicht hindern. :wink:

- Jonas
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Mittwoch 28. Januar 2009, 11:23

Verschiedenes:

1. Eine Sprache, deren Syntax objektorientierte Konstrukte erlaubt, führt halt nicht automatisch dazu, dass deren Nutzer einen objektorientierten Software-Entwurf beherrschen. Zudem war es wohl wie BlackJack vermutet und PHP4 war noch aktuell.

2. Nach wie vor bin ich der Meinung, dass eine relationale Datenbank die Programmierung eines Spiels eher erschwert denn erleichtert und es wundert mich, dass Phlegma lieber low-level SQL programmieren möchte, als verfügbare Abstraktionen zu nutzen.

3. Ich halte ein gutes Mehrpersonenstrategiespiel für eine sehr anspruchsvolle Aufgabe und würde erwarten, dass man sich erst einmal darauf konzentriert, denn von Tag 1 Performance- und Installations-Aspekte in den Vordergrund stellt. Natürlich ist PHP weiter verbreitet, aber ein V-Server oder dedizierter Server ist nicht so viel teurer als ein Shared-PHP-Hoster und ungleich flexibler. Haben shared hoster nicht allgemein MySQL im Angebot?

4. Webseiten dienen bei einem Spiel letztlich nur zur Anzeige des Spielstands und dem, was seit dem letzten Besuch so passiert ist und das ist ein einfacher Report. Je nachdem, wie komfortabel das UI zur Eingabe der Befehle sein soll, verschiebt sich das Problem hier immer weiter Richtung JavaScript und erfordert möglicherweise kaum oder gar keine Funktion zum Erstellen der Seite auf dem Server. Dieser muss dann nur Daten im XML- oder JSON-Format bereitstellen. So wäre jedenfalls mein Ansatz. Somit wäre das, was PHP vielleicht am besten kann, nämlich Webseiten darstellen, mit das unwichtigste.

5. Das Web-Rahmenwerk ist IMHO egal, solange nicht das Spiel fertig ist und interessant genug, dass man es auch spielen wollen würde. Auf der Suche nach einer Datenbank wäre vielleicht auch ein Blick auf etwas wie CouchDB oder der DataStore der Google App Engine interessant. Das hängt jetzt ein bisschen von dem Spiel selsbt ab, wo ich nicht abschätzen kann, was sich Phlegma genau vorstellt.

6. Würde man z.B. das Brettspiel Risiko "ins Web" bringen wollen, bestünde das Datenmodell eine Menge von Ländern, in denen jeweils Truppen eines Spielers stehen. Spieler halten außerdem noch Karten auf der Hand, die sie gegen neue Truppen eintauschen können. Die Topologie der Länder kann man hart verdrahten und ebenso die Regel, wie viele neue Truppen man pro Kontinent bekommt. Das ist so einfach, dass sich das bequem auf die Google App Engine bringen lässt.

7. Veers letzte Aussage würde ich auch unterschreiben.

Phlegma, ich fände es klasse, ein bisschen mehr über das Spiel, das du bauen willst, zu erfahren und den Ansatz, wie du es umsetzen willst. Ich möchte gerne verstehen, warum so viele Leute SQL als besten Weg sehen und wie sie eigentlich (im Gegensatz zu mir) so ein Problem angehen.

Stefan
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Mittwoch 28. Januar 2009, 13:15

sma hat geschrieben:Ich möchte gerne verstehen, warum so viele Leute SQL als besten Weg sehen und wie sie eigentlich (im Gegensatz zu mir) so ein Problem angehen.
Hallo Stefan!

Wie du ja weißt, halte ich nicht sonderlich viel von ORMs. Und vielleicht interessiert es dich, wie ich dann meine Probleme löse.

Zuerst entwerfe ich ein Objektmodell, welches meine Probleme in die für mich am besten geeignete Abstraktionsebene hebt. Und dann versuche ich die Aufgaben auf die Objekte so zu verteilen, wie sie, meines Erachtens, am ressourcenschonendsten und trotzdem noch weitestgehend abstrakt gelöst werden können.

Um es mit einem kleinen Beispiel zu untermalen: Adressen

Es gibt bei einer Adressenverwaltung eine "Adressen"-Klasse. Weiters gibt es auch eine "Adresse"-Klassen. Wenn ich mit einer Adresse arbeiten möchte, dann nehme ich die "Adresse"-Klasse zur Hand und führe dort die Methode "load" aus. An diese Methode wird die "ID" der Adresse übergeben, die diese Instanz darstellen soll bzw. mit der gearbeitet werden soll. Wurden die Daten geändert, dann werden die Änderungen mit Hilfe der "save"-Methode wieder in die Datenbank gespeichert.

Eine Instanz der "Adressen"-Klasse hält alle Adressen zur Verfügung. Z.B. sind dort Methoden aufgehoben, um eine Adresse zu finden. Wenn ich nur herausfinden möchte, wieviele Adressen in der DB stehen, dann wird das über "Adressen" erledigt. Wenn ich eine Liste (z.B. "Vorname, Nachname, Ort") aller Adressen brauche, dann gibt es dort eine Methode, die mir diese Daten aus der DB ausliest und als Cursor zurückgibt. Oft brauche ich auch komplexer selektierte Daten, dann werden die Daten mehrerer Datenbanken ausgelesen und miteinander kombiniert. Die Daten werden dann meist als Liste zurück gegeben.

Wenn ich also eine einzelne Adresse bearbeite, dann arbeite ich mit einer Instanz der Klasse "Adresse". Wenn ich mit mehreren Adressen etwas tun möchte oder Informationen über mehrere Adressen abrufen möchte, dann arbeite ich mit einer Instanz der Klasse "Adressen".

So entscheide ich wann es günstiger ist, alles "in einem Rutsch" mit einer SQL-Anweisung zu erledigen, oder eine Adresse einzeln in die "Hand" zu nehmen um damit zu arbeiten. Außerdem ist es auf diese Art einfacher, mehr Leistung von der Datenbank erbringen zu lassen.
Wenn eine SQL-Anweisung umfangreich (viele Zeichen lang) wird, dann mache ich daraus eine View oder eine "Gespeicherte Prozedur", die direkt in der Datenbank ausgeführt wird. Erstens wird diese Abfrage dann vom Datenbanksystem optimiert und zum Aufrufen der View oder der Prozedur müssen weniger Zeichen über das Netzwerk übertragen werden.

Ich weiß nicht, ob dieses Beispiel gut ist... zumindest habe ich es versucht... ;-)

Es wird also abstrahiert, aber nicht so konsequent. Und es wird der Datenbank mehr Macht gegönnt. Die Frage der Kompatibilität zu anderen Datenbanken stellt sich bei meinen Anwendungen nicht.

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
Phlegma
User
Beiträge: 20
Registriert: Samstag 24. Januar 2009, 12:05

Mittwoch 28. Januar 2009, 13:59

Also gut. Vorweg nehmen wir als Basis OGame, dann brauch ich das Spielprinzip nicht erklären. Ich wünsche auch keine Diskussion darüber warum ich nun ein OGame-ähnliches Spiel will, das ist OT.

Nachdem ich ein lange Zeit (damals musst ich noch grundlegende Programmierung lernen) mit dem OpenSource UGamela 0.2 verbracht habe und auch an einigen Versionen in german UGamela (bis 0.5) gearbeitet habe, wurde mir klar, dass der Code Mist ist. Je mehr ich lerne desto mehr merke ich wie schlecht der Code wirklich war/ist. Daher meine Erfahrungen.

Ziel ist nun schon seit langem eine wirklich gute Basis zuschreiben. Dazu kommen eine grobe Veränderungen zu OGame und vor allem ein Haufen Flexibilität, Konfigurierbarkeit und Erweiterbarkeit. Davon wird es natürlich nicht einfacher und je mehr ich lerne desto eher weiß ich wie komplex das Ganze wirklich ist.

Nun zur wirklichen Angelegenheit zurück. Mein Focus liegt auf dem Herzstück des Spiels, der Kampfberechnung.
Der OGame-Kampf ist nicht nur Ressourcen-verschwendend, sondern auch noch unlogisch. Ziel ist vor allem ersteres Problem zu besiegen und den Kampf etwas logischer zu machen.

Kampfschema:
1. Schadensumme(SQL SUM())+Reduzierung bilden (wichtigster Aspekt)
2. Schiffe von oben herunter "totzählen", evtl. in zwei Gruppen (kleine/große Schiffe)

schön einfach, bei austarierten Faktoren gar nicht so unlogisch.
Nun wird es komplexer.

Die Schiffe können mit speziellen Modulen (e.g. Waffen) ausgerüstet werden, gerade dieser Teil soll extrem flexibel werden um möglichst gute Erweiterbarkeit zu erreichen.
Objektschema:
Flotte[Eigenschaften(coords usw)] <- Schiffe[Basiseigenschaften(Anzahl, Angriff, Def, ...)] <- Module mit Einfluss auf die Methoden des Schiffs, evtl auch die Eigenschaften SQL SUM Problem.

Die Verschachtelung dieser drei Objekttypen möchte ich abstrahieren, des weiteren möchte ich auch bestimmte Features in den unteren Ebenen einbauen können (Beispiel: Planeten bzw Sonnensysteme erhalten einen ähnlichen Aufbau, doch die Aktualisierung der Ressourcen soll auf unterster Ebene geschehen).

Ich wollte in PHP Objekte sparen, da dieser gerade nicht wenig Speicher im Threadram verbrauchen. Teils scheint mir auch manchmal ein direkter Algorithmus effizienter als ein riesen Objektgedöns, vor allem wenn das andauernd zum Zug kommt.

Mein Ansatz nahe an der DB zu arbeiten kam von einem Teamkollegen, mittlerweile weiß ich, dass die DB so schon gerne mal zum Bottleneck wird und man sie nicht überlasten sollte, dennoch ist es am effizientestem sehr nah an ihr zu bleiben, muss ja nicht gleich die ganze Businesslogik in MySQL Procedures stehen.
[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:

Mittwoch 28. Januar 2009, 18:13

http://steve-yegge.blogspot.com/2008/10 ... ttern.html lies das mal... Und vergiss Performance. Um die kannst du dich kümmern wenn du merkst wo das Problem liegt.

Und sma, bezüglich relationalen Datenbanken. Ein großer Vorteil davon sehe ich in der Transaktionsfähigkeit. Das ist ziemlich Mühsam wenn du es selber nachbauen willst.

- Jonas
[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

Mittwoch 28. Januar 2009, 18:20

Schön, wenn ich mal viel Zeit habe lese ich das auch noch... oder magst du mir vllt eine spezifische Stelle sagen?

Achja, die Transaktionen brauche ich auch. Oder zumindest hätte ich gerne Transaktions.
Und vergiss Performance.
Hmm okay.
Um die kannst du dich kümmern wenn du merkst wo das Problem liegt.
Das glaube ich weniger, das Design kann ich dann nicht mehr ändern...
[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:

Mittwoch 28. Januar 2009, 19:47

Phlegma hat geschrieben:
Und vergiss Performance.
Hmm okay.
Um die kannst du dich kümmern wenn du merkst wo das Problem liegt.
Das glaube ich weniger, das Design kann ich dann nicht mehr ändern...
Dann ist das design schlecht gewesen ;) Dann schreibst du eben alles neu. Passiert aber eher selten - sofern vernünftig gehandelt wird. :wink:
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Sonntag 1. Februar 2009, 18:58

Transaktionen sind in der Tat ein guter Punkt.

Ich hatte eine sehr lange Antwort geschrieben, in der ich über das Spiel selbst sinniere, den erspare ich euch aber lieber. Nur soviel: Transaktion != relationale Datenbank. ZODB, CouchDB oder Google's DataStore haben ebenfalls Transaktionen. und Clojure ist eine (der wenigen) Programmiersprache(n die ich kenne), die Transaktionen auf Objektebene haben.

In Python könnte man versuchen, damit durchzukommen, dass man alle Änderungen des Datenmodells serialisiert. Das funktioniert bei meinem Ansatz, mit Runden im Stunden oder Tagesbereich problemlos. Wenn man aber ein quasi kontinuierliches Spiel haben will, wird's schwierig.

Ich dachte, man könnte einfach Runden im Minutentakt machen. Doch angenommen, ich habe 5.000 Spieler und 100.000 Planeten und z.B. 10.000.000 Raumschiffe, schaffe ich es nie und nimmer, alles einmal pro Minute auch nur anzuschauen. Ich hätte für die Entscheidung, ob ein Raumschiff kämpfen, landen, fliegen soll, gerade mal 0.1ms.

Wie skaliert man so ein Spiel? Datenbanken können da auch keine Lösung sein, denn die sind um Größenordnungen langsamer.

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

Sonntag 1. Februar 2009, 20:17

Hm, das wird jetzt dann langsam OT, hat auch nichts direkt mit Python zu tun, denn in PHP bau(t)e ich etwas Ähnliches.

Zahlen: 5000 Spieler: 50.000 Planeten, 100.000 Flotten, seehr viele Schiffe
Wichtig ist, dass die Interaktion nicht zu häufig ist, vor allem nicht flächendeckend. Die Transaktionen brauche ich gegen etwaige Race Conditions. Wichtig ist, dass das Spielprinzip auf die Implementierung optimiert ist, das heißt, das Spielprinzip profitiert von einfachen Vorgängen und verzichtet auf komplexere Probleme. Beispiel das bereits gezeigte Kampfsystem, das totzdem einen Kampf zwischen mehreren Spielern in zwei Parteien zulässt.

Ich komme nochmal zum OR-Mapper zurück. Ich habe grade erst verstanden was "relational" überhaupt bedeutet, so doof sich das auch anhört, aber bisher dachte ich damit sei nur die Tabellenform gemeint. Aber "Relation" heißt ja "Beziehung". Die Tabellen sind verknüpft. Dabei fällt mir auch, dass ich bisher nur einen Typ von Verknüpfung brauche: One to Many (to Many). Die OR-Mapper bieten eine Verallgemeinerung, die ich gar nicht benötige. Stattdessen baue ich mir meinen speziellen OR-Mapper selbst.
Habe auch ein paar schöne Berechtigungsdiagramme für User gesehn, dafür bräuchte ich schon eher einen OR-Mapper, fragt sich nun welcher. Bei diesen Bedingungen kann ich sogar auf die Transaktionen verzichten. Da verändert sich nicht viel gleichzeitig.
Ich suche also ein Framework, das mir bereits eine Userverwaltung bietet, an welches ich dann meinen speziellen Mapper anbauen kann.
[url]http://ugamela-blog.pheelgood.net[/url]
Benutzeravatar
Phlegma
User
Beiträge: 20
Registriert: Samstag 24. Januar 2009, 12:05

Freitag 6. Februar 2009, 11:56

Jetzt hat es euch allen die Sprache verschlagen oder was? Warum?
Phlegma hat geschrieben:...
Ich suche also ein Framework, das mir bereits eine Userverwaltung bietet, an welches ich dann meinen speziellen Mapper anbauen kann.
Meinungen?
[url]http://ugamela-blog.pheelgood.net[/url]
Antworten