Weil alles bereits gesagt wurde was gesagt werden muss.Phlegma hat geschrieben:Jetzt hat es euch allen die Sprache verschlagen oder was? Warum?
Wenn du das wirklich willst django. Ansonsten sqlalchemy. Damit hast du dir deine Usermodels auch schnell selbst gemacht.Phlegma hat geschrieben:Ich suche also ein Framework, das mir bereits eine Userverwaltung bietet, an welches ich dann meinen speziellen Mapper anbauen kann.
Das sind die besten Diskussionen :)Phlegma hat geschrieben:Hm, das wird jetzt dann langsam OT
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: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.
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?Phlegma hat geschrieben:Beispiel das bereits gezeigte Kampfsystem, das totzdem einen Kampf zwischen mehreren Spielern in zwei Parteien zulässt.
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.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.
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:Dabei fällt mir auch, dass ich bisher nur einen Typ von Verknüpfung brauche: One to Many (to Many).
Das klingt für mich auch äußerst fragwürdig.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.
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.Phlegma hat geschrieben:Ich suche also ein Framework, das mir bereits eine Userverwaltung bietet, an welches ich dann meinen speziellen Mapper anbauen kann.
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.sma hat geschrieben: ...
doch das enthebt das System ja nicht davon, letztlich doch 100.000 Flotten pro Minute zu bewegen.
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.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?Phlegma hat geschrieben:Beispiel das bereits gezeigte Kampfsystem, das totzdem einen Kampf zwischen mehreren Spielern in zwei Parteien zulässt.
Versteh ich nicht. Was ist aufwendig?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.
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.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.
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...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:Dabei fällt mir auch, dass ich bisher nur einen Typ von Verknüpfung brauche: One to Many (to Many).
?? 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..Das klingt für mich auch äußerst fragwürdig.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.
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.... allerdings erfordert der ORM, dass du nach Änderungen immer explizit speichern musst, was ich mit dem Attribut primitiv bezeichnen würde.
Was Relationen zwischen Modellen angeht, wird Django 1.1 für dich ausreichend sein.
schön. Ich werde mich mit Django anfreunden.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.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.
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.Darauf zu hoffen, dass dieser theoretische Fall nicht eintreten wird, halte ich für keine gute Strategie.
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.Eventhandler oder Demon sind meines Wissens Dinge, die es in PHP nicht gibt.
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.Und dies macht den Ansatz ineffizient. Zugriff auf den Hauptspeicher eines System ist mindestens eine Größenordnung schneller und wäre daher eine Alternative.
Ja, so wie du sie beschreibst... So schwer ist das aber eig. gar nicht:Bündnisse im Kampf sind aufwendig.
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.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.
"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.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.
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.Ja, so wie du sie beschreibst... So schwer ist das aber eig. gar nicht:
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.Mh, ich hätte auch sehr gerne ein komplexes Kampf-/Bündnissystem, aber das kann ich mir momentan nicht leisten
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.Aber wie kommt es dann, dass PHP soviel verbreiteter ist?
Hallo Phlegma!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?
Macht nix.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.
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.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.
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.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
