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:

Freitag 6. Februar 2009, 13:33

Phlegma hat geschrieben:Jetzt hat es euch allen die Sprache verschlagen oder was? Warum?
Weil alles bereits gesagt wurde was gesagt werden muss.
Phlegma hat geschrieben:Ich suche also ein Framework, das mir bereits eine Userverwaltung bietet, an welches ich dann meinen speziellen Mapper anbauen kann.
Wenn du das wirklich willst django. Ansonsten sqlalchemy. Damit hast du dir deine Usermodels auch schnell selbst gemacht.

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

Freitag 6. Februar 2009, 13:36

Gut.

Vielen Dank an alle!!

Ihr hört von mir sobald ich wirklich was rausbringe, kann aber in Python noch gut ein Jahr dauern.
[url]http://ugamela-blog.pheelgood.net[/url]
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Samstag 7. Februar 2009, 13:01

Phlegma hat geschrieben:Hm, das wird jetzt dann langsam OT
Das sind die besten Diskussionen :)
Phlegma hat geschrieben: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.
Ja, aber wie willst du das sicherstellen? Ich denke, das Spiel wie ich's vorgeschlagen hatte zu takten, funktioniert einfach nicht. Doch welchen Ansatz sonst? Mir würde noch eine "priority queue" zur "Wiedervorlage" von Aktionen einfallen, doch das enthebt das System ja nicht davon, letztlich doch 100.000 Flotten pro Minute zu bewegen. Oder muss man die Spielregeln so anpassen, dass z.B. jeder der Spieler maximal 3 Flotten pro Minute bewegen darf. Irgendwie finde ich nach wie vor die Idee gut, alles im Hauptspeicher zu halten und so die relativ langsamen Datenbank-Operationen aus der Zeit-Rechnung zu nehmen.
Phlegma hat geschrieben:Beispiel das bereits gezeigte Kampfsystem, das totzdem einen Kampf zwischen mehreren Spielern in zwei Parteien zulässt.
Das habe ich überhaupt nicht verstanden. Willst du da einen Zufallsfaktor einbauen? Was heißt totzählen? Gewinnt in einem Kampf einfach die größere/stärkere Flotte?

Ich wollte ursprünglich bei meiner Regelinterpretation Bündnisse beschreiben, doch das ist schon alles andere als trivial, den Algorithmus zum Aufteilen von N Spielern in N' Fraktionen zu beschreiben, sodass ich denke, dass wäre als Datenbank-Operationen richtig aufwendig.
Phlegma hat geschrieben: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.
Nein, eine relationale Datenbank besteht schon aus Tabellen (diese heißen verwirrenderweise Relationen) mit jeweils gleich strukturierten Datensätzen (oder Tupeln) auf denen dann Grundoperationen (selection, projection und cartesian product) definiert sind. Die letzte (auch Join genannt) verknüpft die Tupel zweiter Relationen und bildet eine neue Relation mit verknüpfen Tupel. Die Operation drückt dann das, was du als eine Beziehung bezeichnet hast, aus.

Die Relation aus einem Entity-Relationship-Modell ist nicht die Relation einer relationalen Datenbank. Letztere basiert auf der Theorie der relationalen Algebra. Und weil sie so schön theoretisch untermauert ist und Tabellen in vielen Fällen echt praktisch sind, hat sie sich durchgesetzt.

Es gibt noch objektorientierte, deduktive, hierarchische oder Netzwerk-Datenbanken.
Phlegma hat geschrieben:Dabei fällt mir auch, dass ich bisher nur einen Typ von Verknüpfung brauche: One to Many (to Many).
Das verwundert mich, denn z.B. ein Bündnis wäre eine N:M-Beziehung. Was du als Vorteil zu erkennen glaubst, ist die Beschränkung einer relationalen Datenbank, gar keine N:M-Beziehungen modellieren zu können. Man muss sich dort mit einer Hilfstabelle und zwei 1:N-Beziehungen behelfen. Auf die Abstraktion einer N:M-Beziehung verzichten zu wollen, ist IMHO ein Schritt in die falsche Richtung.
Phlegma hat geschrieben: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.
Das klingt für mich auch äußerst fragwürdig.
Phlegma hat geschrieben:Ich suche also ein Framework, das mir bereits eine Userverwaltung bietet, an welches ich dann meinen speziellen Mapper anbauen kann.
Django bietet dir eine Benutzerverwaltung, allerdings erfordert der ORM, dass du nach Änderungen immer explizit speichern musst, was ich mit dem Attribut primitiv bezeichnen würde.

Eigentlich will man IMHO einen "persistence context" am Ende einer Operation automatisch sichern können und sich nicht Gedanken darüber machen müssen, was man nun wo wie geändert hat. Was Relationen zwischen Modellen angeht, wird Django 1.1 für dich ausreichend sein.

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

Samstag 7. Februar 2009, 13:36

sma hat geschrieben: ...
doch das enthebt das System ja nicht davon, letztlich doch 100.000 Flotten pro Minute zu bewegen.
Ganz falsch. Das geht bei einem Browsergame nicht. Ihr seid zu sehr an euer Mini-Snake in Python gewöhnt, bei dem alles in Echtzeit abläuft. Die Flotten werden keineswegs alle gleichzeitig bewegt. Stattdessen werden sie beim Start und beim Ankommen berechnet. Dafür braucht man einen Eventhandler oder gar Daemon. Wenn sich Flotten im Raum treffen sollen muss man die Positionen jedes Mal nachberechnen.

Das Problem liegt an den versch. Usern, die bei jedem Klick eine ganze Scriptinstanz auf dem Server starten. Pro User läuft quasi ein Thread, das muss coordiniert werden. Allzu leicht kommt es zu Race Conditions. Ich habe nur mit einem kleinen Daemon die Möglichkeit Dinge in Echtzeit zu berechnen, aber dieser hält niemals alle Flotten im Hauptspeicher.
Phlegma hat geschrieben:Beispiel das bereits gezeigte Kampfsystem, das totzdem einen Kampf zwischen mehreren Spielern in zwei Parteien zulässt.
Das habe ich überhaupt nicht verstanden. Willst du da einen Zufallsfaktor einbauen? Was heißt totzählen? Gewinnt in einem Kampf einfach die größere/stärkere Flotte?
Theoretisch gewinnt die stärkere Flotte. Ein Zufallsfaktor ist schnell eingebaut (zB Schaden mal rand(0.5,2)). Wie man den genau formuliert ist Sache des Balancings. "Totzählen" 5k Schaden, die drei größten Schiffe haben jeweils 2k Leben => 2 tot, 1 halb kaputt. Natürlich kann man auch das noch etwas komplexer gestalten. Der Schadensempfang bleibt dem typenspezifischen Schiffsobjekt überlassen oder den eingebauten Modulen.
Ich wollte ursprünglich bei meiner Regelinterpretation Bündnisse beschreiben, doch das ist schon alles andere als trivial, den Algorithmus zum Aufteilen von N Spielern in N' Fraktionen zu beschreiben, sodass ich denke, dass wäre als Datenbank-Operationen richtig aufwendig.
Versteh ich nicht. Was ist aufwendig?
Nein, eine relationale Datenbank besteht schon aus Tabellen (diese heißen verwirrenderweise Relationen) mit jeweils gleich strukturierten Datensätzen (oder Tupeln) auf denen dann Grundoperationen (selection, projection und cartesian product) definiert sind. Die letzte (auch Join genannt) verknüpft die Tupel zweiter Relationen und bildet eine neue Relation mit verknüpfen Tupel. Die Operation drückt dann das, was du als eine Beziehung bezeichnet hast, aus.

Die Relation aus einem Entity-Relationship-Modell ist nicht die Relation einer relationalen Datenbank. Letztere basiert auf der Theorie der relationalen Algebra. Und weil sie so schön theoretisch untermauert ist und Tabellen in vielen Fällen echt praktisch sind, hat sie sich durchgesetzt.

Es gibt noch objektorientierte, deduktive, hierarchische oder Netzwerk-Datenbanken.
Für mich hatte sich das eig. immer intuitiver angefühlt in der Datenbank, hatte auch bisher noch keine wirklichen Probleme die Daten in Objekte zu füllen. Algebra... aha.
Phlegma hat geschrieben:Dabei fällt mir auch, dass ich bisher nur einen Typ von Verknüpfung brauche: One to Many (to Many).
Das verwundert mich, denn z.B. ein Bündnis wäre eine N:M-Beziehung. Was du als Vorteil zu erkennen glaubst, ist die Beschränkung einer relationalen Datenbank, gar keine N:M-Beziehungen modellieren zu können. Man muss sich dort mit einer Hilfstabelle und zwei 1:N-Beziehungen behelfen. Auf die Abstraktion einer N:M-Beziehung verzichten zu wollen, ist IMHO ein Schritt in die falsche Richtung.
Hm vllt hab ich noch zu wenig mit OOP gemacht, aber eig. dachte ich da schon durchzusteigen, vllt hab ich auch nur zuviel mit SQL gearbeitet...
In welcher Beziehung stehen die Mitglieder einer Fraktion zur anderen? Sind es nicht nur die Fraktionen die in Kontakt treten und ihre Mitglieder dabei haben? Ich hätte die Mitglieder in ein Bündnis über Objekt geladen.
One to Many. Für den Rest nehme ich ein echtes ORM.
Phlegma hat geschrieben: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.
Das klingt für mich auch äußerst fragwürdig.
?? Klarer ausdrücken bitte. Was ist fragwürdig. In den Usertabellen passiert quasi kaum eine Veränderung und wenn doch betrifft sie nur den User selbst. Seinen Namen kann er ändern, aber nicht seine ID..
... allerdings erfordert der ORM, dass du nach Änderungen immer explizit speichern musst, was ich mit dem Attribut primitiv bezeichnen würde.
Ja. Ich hab mir da etwas nettes ausgedacht: Ein automatisches Update am Ende des Scripts, bei PHP im Objektdestruktor. Natürlich nur veränderte Werte.
Was Relationen zwischen Modellen angeht, wird Django 1.1 für dich ausreichend sein.
:D schön. Ich werde mich mit Django anfreunden.
[url]http://ugamela-blog.pheelgood.net[/url]
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Sonntag 8. Februar 2009, 12:00

Phlegma, es geht doch laut deiner Aussage darum, dass das Spiel gefühlt in Echtzeit abläuft und nicht in diskreten Runden. Bei 5.000 Spielern, die theoretisch alle gleichzeitig handeln können, würden 5.000 Flotten, die in der selben Minute starten sollen, das Spiel auf einem üblichen Rechner gegen die Wand fahren, denn man hätte nur 12ms pro Flotte zur Verarbeitung.

Darauf zu hoffen, dass dieser theoretische Fall nicht eintreten wird, halte ich für keine gute Strategie. Daher fragte ich, ob man nicht eher mit Hilfe der Spielregeln so einen Fall ausschließen will. Alternativ kann man eine andere Architektur des System wählen, als die Verarbeitung von Requests in jeweils einem neuen Prozess (so wie es PHP immer und Python meist machen).

Eventhandler oder Demon sind meines Wissens Dinge, die es in PHP nicht gibt, welches ja nur einen HTTP-Request bearbeiten kann und dafür einen Prozess (oder Thread eines Prozesses) startet, nicht jedoch kontinuierlich ablaufende Programme erlaubt. Auch die Aussage "pro User läuft ein Thread" kann ich daher nicht nachvollziehen. Ist die Anfrage des Users bearbeitet, läuft da nichts auf dem Server weiter und hält insbesondere keinen Zustand. Dieser muss, soll er nicht verloren gehen, in einer Datenbank abgelegt werden.

Und dies macht den Ansatz ineffizient. Zugriff auf den Hauptspeicher eines System ist mindestens eine Größenordnung schneller und wäre daher eine Alternative. Dieses Verfahren ist natürlich nicht beliebig skalierbar, doch theoretische Skalierbarkeit nützt nichts, wenn man sich die notwendigen Computer nicht auch leisten kann/will.

Mit Python - und darauf will ich ja die ganze Zeit hinaus - ist man nicht auf das simple Request-Processing-Modell von PHP beschränkt und kann einen dedizierten Server für das Spiel schreiben, der dann den Spielstand im Hauptspeicher schnell zugreifbar hält. Der Preis für die Geschwindigkeit ist, dass man Transaktionen selbst bauen muss.

Ich muss gestehen, ich würde die Aufgabe lieber in Java + JavaScript angehen als in Python - einfach, weil Java grundsätzlich schneller wäre, Multithreading unterstützt und ich schon immer mal Terracotta ausprobieren wollte (zum Clustern der Systeme), aber Python würde prinzipiell funktionieren.

Zusammen mit der Google App Engine vielleicht sogar richtig gut.

Bündnisse im Kampf sind aufwendig. Annahme: Ein Spieler kann mit einem anderen Spieler verbündet sein. Dann unterstützen sich ihre Flotten im Kampf und greifen sich nicht automatisch an. Flotten nicht verbündeter Spieler kämpfen gegeneinander. Flotten können nur auf Planeten aufeinander treffen - ansonsten sind sie im Hyperraum. Auf einem Planeten können nun Flotten von N Spielern aufeinander treffen, sagen wir mal es sind A, B und C. C ist mit A und B verbündet. A greift B an, C würde B verteidigen, aber würde auch A nicht angreifen. Was nun? Das Bündnis zu A lösen? Es war aber Zufall, dass A B angegriffen hat und nicht B A. In diesem Fall müsste C das Bündnis mit B lösen. Also soll C beide Bündnisse lösen? Das wirkt sich dann aber auf die Kämpfe auf allen anderen Planeten aus. Oder werden (das wäre meine Präferenz) Bündnisse an Planeten gebunden? Wenn ich A, B, C und D habe und B ist mit A, C mit B, D mit C und A mit D verbündet, welche Bündnisse muss ich lösen? Alle? Gefällt mir nicht, kompliziertere Regeln sind aber eben komplizierter und wohl für die Spieler weniger einfach nachvollziehbar.

Fragwürdig finde ich, dass du (so habe ich das verstanden) sagt, dass du bei Dingen, die sich wahrscheinlich nicht zum selben Zeitpunkt ändern, keine Transaktionen brauchst. Es ist IMHO nicht maßgeblich, ob sich etwas selten oder häufig ändert. Wenn auch nur die kleinste Chance für einen Konflikt existiert, muss man ACI-Transaktionen benutzen. Angenommen, ein Spieler kennt die Zahl der Rohstoffe, die er verbauen kann. Dieses Attribut ist zwar privat für jeden Spieler, aber dieser eine Spieler kann ja (mit mehreren Browsern oder Programmen) mehrere Befehle quasi parallel abschicken und somit auszunutzen versuchen, dass es hier Racing-Conditions geben könnte, je nachdem wie das genau implementiert ist.

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

Sonntag 8. Februar 2009, 12:38

sma hat geschrieben:Phlegma, es geht doch laut deiner Aussage darum, dass das Spiel gefühlt in Echtzeit abläuft und nicht in diskreten Runden. Bei 5.000 Spielern, die theoretisch alle gleichzeitig handeln können, würden 5.000 Flotten, die in der selben Minute starten sollen, das Spiel auf einem üblichen Rechner gegen die Wand fahren, denn man hätte nur 12ms pro Flotte zur Verarbeitung.
Bei 5k Spielern schicken niemals alle gleichzeitig eine Flotte ab. 5k Spieler sind zudem die Obergrenze für ein "Universum" davon sind auch niemals alle online. Natürlich gibt es Spitzen, dennoch ist mit einer Flotte gar nicht so viel Arbeit verbunden. Der Kampf ist wenn dann schwierig, da muss man vorsichtig sein. Notfalls lässt sich dieser auslagern.
Darauf zu hoffen, dass dieser theoretische Fall nicht eintreten wird, halte ich für keine gute Strategie.
Das ist eine Wahrscheinlichkeit die gegen Null tendiert. Wieso sollte ich mir über sowas sorgen machen? Genauso ist ein Forum überlastet wenn alle genau im selben Moment abschicken drücken... Auch das ist verdammt unwahrscheinlich.
Eventhandler oder Demon sind meines Wissens Dinge, die es in PHP nicht gibt.
Hab mich lange und breit damit auseinander gesetzt und weis genau wo es Probleme gibt. Einmal macht man Updates bei Bedarf und ein ander Mal müssen sie pünktlich und nur einmal passieren. Das alte UGamela hatte bei längerem und zu schnellem (Spielgeschwindigkeitsfaktor) Spiel immer wieder Flottenverdoppelungen. Ein Daemon lässt sich in PHP nicht in seiner Standardausführung schreiben, nein, aber man kann etwas ähnliches schreiben.
Und dies macht den Ansatz ineffizient. Zugriff auf den Hauptspeicher eines System ist mindestens eine Größenordnung schneller und wäre daher eine Alternative.
Schön. Das benötige ich dann für ein Spiel einer anderen Größenordnung. Momentan geht es darum aus einem Webspace so viel rauszuholen wie möglich. Ein vServer soll später für ein solches Spiel vollkommen ausreichen. Da arbeite ich mit dem was mir zur Verfügung steht: PHP+Datenbank.
Ich habe mich ja gerade erst dazu entscheiden einen Schritt weiter zu gehen und Python dazu heran zu ziehen, weil es weit besser als PHP geeignet ist und etliche weitere Vorteile bietet. Ich weiß jetzt nicht wie weit ich mit einem einfachen Python Webserver auf den Hauptspeicher zugreifen kann, aber das wäre natürlich in Erwägung zu ziehen. Andererseits finde ich es unnötig Flotten die erst in zwei Tagen ankommen permanent im Hauptspeicher zu lassen.
Bündnisse im Kampf sind aufwendig.
Ja, so wie du sie beschreibst... So schwer ist das aber eig. gar nicht:
Flotten können mit Erlaubnis auf einem Planeten halten. Wenn der Planet angegriffen wird kämpfen sie mit, auf der Seite des Planeten. Zum Angriff kann man sich auch zusammenschließen.
Fragwürdig finde ich, dass du (so habe ich das verstanden) sagt, dass du bei Dingen, die sich wahrscheinlich nicht zum selben Zeitpunkt ändern, keine Transaktionen brauchst. Es ist IMHO nicht maßgeblich, ob sich etwas selten oder häufig ändert. Wenn auch nur die kleinste Chance für einen Konflikt existiert, muss man ACI-Transaktionen benutzen. Angenommen, ein Spieler kennt die Zahl der Rohstoffe, die er verbauen kann. Dieses Attribut ist zwar privat für jeden Spieler, aber dieser eine Spieler kann ja (mit mehreren Browsern oder Programmen) mehrere Befehle quasi parallel abschicken und somit auszunutzen versuchen, dass es hier Racing-Conditions geben könnte, je nachdem wie das genau implementiert ist.
Wie bereits gesagt, ich habe das im Blick. Dein Beispiel funktioniert zum Beispiel nicht, weil die Gebäude automatisch in eine Warteliste gelangen bevor sie dann wirklich gebaut werden und natürlich braucht man dabei Transaktionen. Ich rede von Nachrichtensystem oder persöhnlichen Einstellungen oder angebundenen Foren, die recht unabhängig vom eigentlichen Spielgeschehen sind. Bei dieser "Userverwaltung" brauche ich keine Transaktionen und werde auf ein normales ORM zurückgreifen.
[url]http://ugamela-blog.pheelgood.net[/url]
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Samstag 14. Februar 2009, 10:04

Okay, mein Beispiel mit den 5000 Spielern ist in der Tat unrealistisch. Dennoch bleibt bei einer strikten Einteilung des Spiels in sehr kurze Runde das Problem, dass man nur wenig Zeit hat und somit zusehen muss, dass nicht zu viele Aktionen in einer Runde stattfinden. Du schreibst ja selbst, es ich wichtig, dass alles pünktlich stattfindet.
ch weiß jetzt nicht wie weit ich mit einem einfachen Python Webserver auf den Hauptspeicher zugreifen kann, aber das wäre natürlich in Erwägung zu ziehen. Andererseits finde ich es unnötig Flotten die erst in zwei Tagen ankommen permanent im Hauptspeicher zu lassen.
"Auf den Hauptspeicher zugreifen" führt in die Irre. Es geht darum, ihn zu nutzen. Der fundamentale Unterschied ist, wie das Programm aufgerufen wird bzw. wie es abläuft. Für einem 2,50€-Mietserver spielen diese Überlegungen eh keine Rolle, aber wenn du einen eigenen dedizierten Server hättest, in dem einige GB RAM stecken, dann kannst du ganz anders vorgehen. Das Stichwort im Java-Umfeld heißt hier Application Server, aber ich denke, wird sind hier in unterschiedlichen Welten zuhause.
Ja, so wie du sie beschreibst... So schwer ist das aber eig. gar nicht:
Natürlich kannst du einen Kompromiss mit den Spielregeln machen. Ich hätte schon gerne die Möglichkeit, dass ein Spieler ein unabhängiger Beobachter auf einem Planeten sein kann oder aber das ein Verbündeter plötzlich die Seiten wechselt. Vielleicht bin ich dabei aber immer noch zu sehr in der Welt der Brett- oder Postspiele verwurzelt, wo es mehr um Diplomatie denn um tatsächliches Kräftemessen gehen sollte.

Noch was zu deinem Blog-Artikel: Python gibt es seit 20 Jahren und deutlich länger als PHP. Selbst Ruby ist älter und bei Java würde ich's auch noch sagen, wenn PHP 3.0 (1997) als die Version, die wir heute noch kennen, zugrunde legt (Java erschien 1995). Ich würde Python daher schon zu den alteingesessenen Sprachen zählen. Allgemein leidet die Glaubwürdigkeit eines Artikels, wenn einfach überprüfbare Fakten am Anfang eines Artikel schon fargwürdig sind.

Ob ein Browsergame wirklich mit nichts im Web vergleichbar ist, ist für mich noch nicht bewiesen. Ich halte es nicht für so anders. Anfragen werden verarbeitet, Webseiten dargestellt. Das man diese Dinger nicht häufiger sieht, liegt IMHO eher daran, dass es schwer ist, sich entsprechende Regeln auszudenken. Außerdem scheint es eine Subkultur zu sein, die ich zum Teil irritierend primitiv finde (wenn ich einmal von der Sprache und Art der die Beiträge in deinem Forum urteilen darf). Eigentlich schade.

Ich würde übrigens nicht mit der Performance (so weit sie die Ausführung der Programme angeht) argumentieren. Diese ist egal. Das führt nur zu unschönen Streitereien um Nichtigkeiten. Dich wird die Datenbank und die Auslieferung der Webseiten über das Netz begrenzen, nicht wie schnell jetzt Python oder PHP rechnen können.

Ich finde übrigens interessant, wie konservativ und wenig dem neuen aufgeschlossen die Teilnehmer im Forum sind. Da weht ein kalter Wind, was Python angeht ;) Ich hoffe, du bleibst trotzdem am Ball.

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

Samstag 14. Februar 2009, 10:57

Mh, ich hätte auch sehr gerne ein komplexes Kampf-/Bündnissystem, aber das kann ich mir momentan nicht leisten. Zur Zeit versuche ich einen guten Grundaufbau hinzubekommen, die Feinheiten kommen später. Ich hoffe auch später auf andere Entwickler, die mit meinem Grundgerüst ein paar Ideen umsetzten wollen. Mal sehen wie sich das entwickeln wird...

Die Fehler über Python sind natürlich reine Dummheit. Ich hätte das umbedingt nachsehen müssen. Vielen Dank für den Hinweis!

Aber wie kommt es dann, dass PHP soviel verbreiteter ist?
[url]http://ugamela-blog.pheelgood.net[/url]
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Dienstag 17. Februar 2009, 13:52

Mh, ich hätte auch sehr gerne ein komplexes Kampf-/Bündnissystem, aber das kann ich mir momentan nicht leisten
Warum kannst du dir das nicht leisten? Mache einfach die Runden länger. Kämpfe finden dann nur alle 15 Minuten statt. Oder mache das Spiel kleiner. Wenn du nur 100 Spieler hast (was ich ja auch schon viel finde) die z.B. 1.000 Planeten verwalten und insgesamt 10.000 Raumschiffe haben, wird's doch schon viel entspannter.

Meine Vorstellung (vom dem Brettspiel Twilight Imperium kommend) wäre, Raumsektoren zu haben, um deren Vormachtstellung man kämpfen kann. Ein Raumsektor kann mehrere Planeten enthalten, Ich würde dabei versuchen, so viele Spieler wie möglich interagieren zu lassen, d.h. mehrere Spieler pro Planet und Raumsektor zu erlauben. Denn meist ist eine Kooperation schwieriger und interessanter als einfach nur ein Vernichtungskampf.

Pro Sektor gibt es dann Flottenbefehle, z.B. Neuankömmlinge anzugreifen. Ausnahmen müssten möglich sein, um etwa einem eigentlich verfeindeten Spieler den Durchflug zu ermöglichen. Angenommen, ich habe im Schnitt 4 Planeten pro Sektor, dann habe ich 250 Sektoren und somit 250 mögliche Kämpfe pro Runde.

Eine andere Alternative wäre, einfach nur 3 aktive Flotten pro Spieler zu erlauben. Dann kann es maximal zu 300 Kämpfen pro Runde kommen. Da man sich aber wahrscheinlich nicht nur gegenseitig überfallen will, sondern gegeneinander kämpft, werden sich die Flotten ballen und es sind noch weniger.
Aber wie kommt es dann, dass PHP soviel verbreiteter ist?
Das ist denke ich der Eigenschaft von PHP zu verdanken, relativ einfach und unkompliziert als Apache-Modul in einem Sharedhosting-Umfeld einsetzbar zu sein. Außerdem hat die Sprache den Ruf, recht einfach zu sein und so wie JavaScript schafft sich da jeder so ein bisschen Knowhow drauf.

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

Mittwoch 4. März 2009, 22:50

sma, sorry, bin jetzt nicht weiter auf dich eingegangen, weil ich das Gefühl hatte, dass wir fertig waren und sowieso etwas aneinander vorbei reden, weil wir versch. Ideen von Browsergames haben.

Ich komm hier nochmal zum Anfangspost zurück, weil ich eben einen Eintrag zu Applicationservern in einem Browsergamesforum gelesen habe. Dort wird C# und Java angepriesen, aber mit Zope gibt es ja auch einen in Python. Wie gut eignet dieser sich für
1. Ajaxtortur von vielen kleinen Anfragen
2. einen Daemon, der ständig eine Datenbank nach eintretenden Events fragt

?
[url]http://ugamela-blog.pheelgood.net[/url]
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Donnerstag 5. März 2009, 08:48

Phlegma hat geschrieben:weil ich eben einen Eintrag zu Applicationservern in einem Browsergamesforum gelesen habe. Dort wird C# und Java angepriesen, aber mit Zope gibt es ja auch einen in Python. Wie gut eignet dieser sich für
1. Ajaxtortur von vielen kleinen Anfragen
2. einen Daemon, der ständig eine Datenbank nach eintretenden Events fragt?
Hallo Phlegma!

Zope ist ein großer Applikationsserver -- basierend auf einer Objektdatenbank. Zope kann viel, aber genau so wie Pylons oder Django, würde ich Zope **nicht** für so etwas verwenden. Zope kümmert sich **automatisch** um Dinge wie Authentifizierung und Zugriffsbeschränkungen -- und noch einige Dinge mehr. Das ist für manche Projekte ein Vorteil. Aber für so etwas was du vor hast, ist das ein Nachteil, weil Ressourcen verbraten werden, die du anderweiteig besser einsetzen kannst.

Wie ich dieses Projekt angehen würde? Ganz klar, mit Cheetah, CherryPy, mod_wsgi und dem Apachen. Im Hintergrund werden die Daten von PostgreSQL verwaltet.
Cheetah -- ganz einfach, weil ich mich daran gewöhnt habe und ich es für eine hervorragende pythonnahe Vorlagensprache halte.
CherryPy ist ein kleiner Applikationsserver, der mir genau die Arbeit abnimmt die sowiso erledigt werden muss -- und nicht mehr. CherryPy kann auch direkt XMLRPC anbieten (http://paste.pocoo.org/show/106541/). Auch JsonRPC ist kein Problem für CherryPy. Sessionverwaltung und Authentifizierung kann dazugeschaltet werden. Die Authentifizierung könnte aber auch der Apache erledigen.
mod_wsgi dient als schnelle Schnittstelle zum Apachen
Und der Apache liefert alles aus. Der Apache kann statischen Content (z.B. Bilder) sehr schnell ausliefern. Deshalb übernimmt dieser die Auslieferung dieser Dateien direkt -- ohne den Umweg über mod_wsgi und CherryPy machen zu müssen.
Der Apache kann auch so eingestellt werden, dass dieser Daten cached. Wenn man das richtig ausnutzt, dann reduzieren sich die Anfragen an CherryPy.
PostgreSQL arbeitet im Hintergrund und verwaltet die Daten. CherryPy öffnet mehrere Threads, die gleichzeitig auf die Datenbank zugreifen und PostgreSQL kann damit sehr gut umgehen.

Was will ich damit sagen? Nimm (in deinem Fall) kleine Tools und setze diese zu einer großen Anwendung zusammen. Lasse dir nicht von irgendeinem großen Framework oder Applikationsserver die Aufgaben und Werkzeuge diktieren.

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Donnerstag 5. März 2009, 11:58

Phlegma hat geschrieben:sma, sorry, bin jetzt nicht weiter auf dich eingegangen, weil ich das Gefühl hatte, dass wir fertig waren und sowieso etwas aneinander vorbei reden, weil wir versch. Ideen von Browsergames haben.
Macht nix.
Phlegma hat geschrieben:Ich komm hier nochmal zum Anfangspost zurück, weil ich eben einen Eintrag zu Applicationservern in einem Browsergamesforum gelesen habe. Dort wird C# und Java angepriesen, aber mit Zope gibt es ja auch einen in Python.
Wäre dies nicht das Python-Forum, würde ich in diesem Fall auch zu Java (oder Scala oder eine andere JVM-basierte Sprache) empfehlen :) Wie ich schon die ganze Zeit versuche zu sagen, ermöglicht ein fortlaufend Anwendungsserver ein ganz anderes Vorgehen als die Script+Datenbank-Share-Nothing-Architektur von PHP oder Python.

Do wolltest doch aber möglichst viel aus einem simplen shared-hosting-Service herausholen und da ist ein Application-Server keine Option.
Phlegma hat geschrieben:Wie gut eignet dieser sich für
1. Ajaxtortur von vielen kleinen Anfragen
2. einen Daemon, der ständig eine Datenbank nach eintretenden Events fragt
Zu Zope konkret kann ich leider nichts sagen, aber in Java wäre 1. kein prinzipielles Problem, allerdings kommt dies zu dem Preis von viel Speicher und viel CPU-Bedarf. Bei 2. würde man anders Vorgehen und ein Messaging-System (z.B. JMS, aber das ist eigentlich zu viel, Hazelcast sieht ganz nett aus) benutzen und die Datenbank nicht für Events benutzen.

Bei Python und Ajax fällt mir noch Orbited ein. Ich meine aber, die/der Entwickler hat sich inzwischen mehr in Richtung XMPP und WebSockets orientiert und bietet jetzt auch etwas Java-basiertes an...

Stefan
Antworten