Selbstgespräche über best practice patterns bei Django

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Antworten
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Auf der Suche nach einem kleinen Beispiel für eine Shootout zwischen Rails und Django habe ich gestern Nacht ein echt schäbiges PHP-Spiel (es funktioniert nicht, aber das habe ich zu spät bemerkt) in Django portiert.

Ich habe die einzelnen PHP-Dateien in jeweils ein Template und eine View-Funktion auseinander gezogen. Da der PHP-Author recht großzügig mit lokalen Variablen umging, habe ich einfach folgendes benutzt:

Code: Alles auswählen

@render
def index(request, player=None):
  ...
  return locals()
Ich fand es doof, immer 'request.player' zu schreiben, also übergebe ich diesen mir als Parameter. Ich hatte einen Moment über eine thread-lokale Variable nachgedacht, aber das als zu magisch verworfen. So richtig gut finde ich das aber nicht.

Die render-Funktion benutze ich auch in anderen Projekten gerne, um nicht jedes Mal "render_to_response" aufrufen zu müssen. Eine Variante, wo man den Namen des Templates wählen kann, ist fast genauso einfach.

Code: Alles auswählen

def render(func):
  def inner(request, *args, **kwargs):
    kwargs['player'] = setup(request)
    result = func(request, args, kwargs)
    if isinstance(result, dict):
      result['player'] = kwargs['player']
      return render_to_response(func.__name__ + '.html', RequestContext(request, result))
    return result
  return inner

def start(request):
  if 'id' not in request.session: return None
  return Player.objects.get(id=request.session['id'])
Statt "start()" könnte ich wohl auch eine Middleware benutzen, habe dann aber wieder "request.player". Möglicherweise doch die bessere Lösung, jetzt wirkt das irgendwie gehackt, insbesondere bei meinem Versuch, Formulare einfacher bearbeiten zu können, bin ich noch nicht glücklich:

Code: Alles auswählen

@post(ViewForm)
def formview(request, form, player=None):
  ...
  return redirect(index)

def post(form):
  def inner(func):
    def inner2(request, form):
      player = start(request)
      if request.method == 'POST':
        f = form(request.POST)
        if f.is_valid(): return func(request, form, player=player)
      else: f = form()
      return render_to_response(form.__name__ + '.html', RequestContext(request, {'form': f}))
    return inner2
  return inner
Hat da jemand bessere Vorschläge?

Am Mühsamsten war es übrigens, die HTML-Templates zu erstellen und vernünftig zu formatieren.

Dazu speziell noch ein Problem aus einem anderen Projekt (in Coldfusion): Wie setzt man sowas am besten mit Django um?

Code: Alles auswählen

<cfif p.id is playerID><cfset color="Aqua">
	<cfelseif p.allianceID gt 0 and (p.allianceID is myAllianceID)><cfset color="Fuchsia">
	<cfelseif p.allianceID gt 0 and (p.allianceID is ally1 or p.allianceID is ally2 or p.allianceID is ally3)><cfset color="PeachPuff">
	<cfelseif p.allianceID gt 0 and (p.allianceID is war1 or p.allianceID is war2 or p.allianceID is war3)><cfset color="Crimson">
	<cfelseif p.turn lte 72><cfset color="Yellow">	
	<cfelse><cfset color="White"></cfif>
Der Code stammt aus dem "template" und gehört da IMHO auch hin, denn er sucht eine Farbe für eine Tabellenspalte heraus. Ich könnte es in ein eigenes Tag auslagern, aber dann würde ich dort die Farben hart codieren und das fühlt sich falsch an.

Auch andere Kleinigkeiten lassen mich die Möglichkeit, einfache Ausdrücke in den Template schreiben zu können vermissen, hier ein Beispiel aus Rails:

Code: Alles auswählen

There are <%= posts.count - 1 %> replies.
In Django funktioniert dies, aber was bitte ist lesbarer?

Code: Alles auswählen

{{posts|length|add:-1}}
Vielleicht sollte ich mir mal Jinja anschauen?

Stefan
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

sma hat geschrieben:Der Code stammt aus dem "template" und gehört da IMHO auch hin, denn er sucht eine Farbe für eine Tabellenspalte heraus. Ich könnte es in ein eigenes Tag auslagern, aber dann würde ich dort die Farben hart codieren und das fühlt sich falsch an.
Die Farben würde ich im Stylesheet definieren und im Template nur entsprechende CSS-Klassen verwenden. Sowas klappt gut für good/normal/bad, notice/warning/error usw. und in deinem Fall offenbar ebenso.
sma hat geschrieben:Auch andere Kleinigkeiten lassen mich die Möglichkeit, einfache Ausdrücke in den Template schreiben zu können vermissen, hier ein Beispiel aus Rails:

Code: Alles auswählen

There are <%= posts.count - 1 %> replies.
In Django funktioniert dies, aber was bitte ist lesbarer?

Code: Alles auswählen

{{posts|length|add:-1}}
Vielleicht sollte ich mir mal Jinja anschauen?
In Genshi und Kid würde das so aussehen:

Code: Alles auswählen

There are ${len(posts) - 1)} replies.
Einfach Python. Da muss man auch keine spezielle, andere Syntax lernen.
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

YOGi, ich habe mir mehr den Frust über einige Umständlichkeiten von Djangos Template-Sprache von der Seele geschrieben, als das ich nach einem (radikal) anderen Ansatz suchen würde. Wenn, dann dann richtig anders und eher wie Breve oder Haml, nicht jedoch Genshi oder Kid, welche wohl beide durch die ursprüngliche Template-Attribute-Lanugage von Zope beeinflusst wurden. Diese Form gefällt mir nicht so gut.

Direkt den Python-Interpreter auf die Ausdrücke loszulassen ist möglicherweise zu viel Flexibilität. Macht nicht Mako, die für Pylons empfohlene Sprache, dies?

Ob ich übrigens aus Farben von Klassen auswähle ist IMHO für das eigentliche Problem egal, dass die Auswahl im Template stattfinden sollte und damit hier doch relativ komplexer Code stehen müsste.

Mit den Möglichkeiten von Django muss ich jetzt all die Tests vorhersehen und passende Methoden für p bereitstellen, die aber den aktuellen Spieler, Allianzen und diverse andere Dinge kennen müssen, selbst also auf den Kontext zugreifen könnten müssten. Wüsste nicht, wie das gehen soll. Vielleicht mit einem nachgeschalteten context procesor...

Stefan
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Ich denke das Django nicht das ideale Werkzeug ist um ein Online Game zu erstellen. Django finde ich gut um CMS artige Systeme zu erstellen. Da ist es imho auch recht gut. Für ein Browser Game würde ich vermutlich ein anderes Werkzeug verwenden.

Zu den Farben kann ich mich Y0Gi nur anschliessen, diese gehören ins Stylesheet. Dann müsstest du anstelle der Farbe die Klasse wählen und ob du dass dann auslagern willst oder nicht hängt davon ab wie oft du das verwendest.
sma hat geschrieben:Direkt den Python-Interpreter auf die Ausdrücke loszulassen ist möglicherweise zu viel Flexibilität.
Mir fallen eigentlich nur zwei Situationen ein wo das zu flexibel ist.

1. User können Templates bearbeiten / erstellen - kein Sandboxing.
Das ist jedoch auch mit Sandboxing noch sehr problematisch.

2. Man will den Template Autor davor schützen sich selbst ins Bein zu schiessen.
Das Probleme sehe ich eigentlich nur wenn ein Designer die Templates komplett selber baut. Ein Python Programmierer sollte mit Pythons Flexibilität zurecht kommen.[/quote]
[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

veers hat geschrieben:Für ein Browser Game würde ich vermutlich ein anderes Werkzeug verwenden.
Welches?

Stefan
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

sma hat geschrieben:
veers hat geschrieben:Für ein Browser Game würde ich vermutlich ein anderes Werkzeug verwenden.
Welches?
zB Werkzeug :lol:
TUFKAB – the user formerly known as blackbird
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

veers hat geschrieben:Mir fallen eigentlich nur zwei Situationen ein wo das zu flexibel ist.
Mir fällt noch eine dritte ein, die ich im Alltag habe und zwar Designer die panische Angst vor Programmieren haben und daher alles in so vereinfachter Form wie eben die Django-Templates es bieten haben müssen.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

mitsuhiko hat geschrieben:
sma hat geschrieben:
veers hat geschrieben:Für ein Browser Game würde ich vermutlich ein anderes Werkzeug verwenden.
Welches?
zB Werkzeug :lol:
Ich hatte die pre-0.1-Version nach meinem Posting mit Vorschlägen für Beispielprojekte für ein kleines Projekt ausprobiert und sah mich irgendwie die Hälfte von Django nachbauen. Ich habe verstanden, dass das Konzept von Werkzeug ist, weniger zu können als ein Rahmenwerk wie Django und dafür flexibler zu sein. Die Flexibilität habe ich bei meinem Wiki-Projekt nicht benötigt und wie gesagt, begonnen, Liebgewonnenes nachzubauen. Daher bin ich noch nicht so überzeugt, dass weniger mehr ist für ein Browser Game.

PS: Natürlich konntest du auf diese Vorlage nicht nicht reagieren, aber ich bin wirklich daran interessiert, ob und welche Vorteile du bei Werkzeug gegenüber Django siehst.

Stefan
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

sma hat geschrieben:Ich hatte die pre-0.1-Version nach meinem Posting mit Vorschlägen für Beispielprojekte für ein kleines Projekt ausprobiert und sah mich irgendwie die Hälfte von Django nachbauen.
Hast du das Kickstart-Modul gesehen? In der pre-0.1 waren da schon fertige Request- und Response-Objekte, in pre-0.2 ist nun auch eine fertige WSGI-App mit einigen Features dabei. Ist aber natürlich auch nicht aller Weisheit Schluss, es wächst eben mit den Bedürfnissen.
sma hat geschrieben:PS: Natürlich konntest du auf diese Vorlage nicht nicht reagieren, aber ich bin wirklich daran interessiert, ob und welche Vorteile du bei Werkzeug gegenüber Django siehst.
Die Template-Sprache ist besser, denn Werkzeug hat keine (richtige). Dadurch kannst du frei wählen oder ganz einfach Jinja verwenden. Ebenso das ORM, welches Werkzeug ebenso nicht bietet. Dadurch hast du zwar kein Admin-Interface, aber wählst eben das ORM (oder gar keines) das dir am besten passt. Vom Konzept ist Werkzeug, obwohl es einige Django-ähnlichkeiten hat (wie die Processors, die wie die Django Middlewares funktionieren) eher mit Pylons oder dem darunterliegendem Paste vergleichbar. Aber die beiden hatten in meinen Augen immer den Nachteil, unnötig komplex zu sein und eine schlechte Dokumentation zu haben.

Außerdem hat Werkzeug gegenüber Django noch einen weiteren Vorteil, der immer wichtiger wird, je mehr Möglichkeiten man braucht: besserer Upstream-Kontakt. Natürlich sind die meisten Commits von mitsuhiko selbst und er ist auch der Gatekeeper, aber man kann einfach Patches, Bundles oder geklonte Repositories anbieten, die dann ohne große Diskussion, ohne riesen Formalitäten etc. akzeptiert werden. Dadurch hat man mehr Möglichkeiten, die weitere Entwicklung selbst zu beeinflussen. Was da reinspielt ist auch, dass Werkzeug kein 37signals oder Ellington hat, für dessen Bedürfnisse es geschrieben wird, sondern sich in die Richtung entwickelt in die die einzelnen Committer es brauchen.

Vielleicht mag es dir ja falsch erscheinen, noch ein nächstes Framework in die Schlacht zu schicken - das dachte ich mir ursprünglich auch, aber als ich es mal für ein kleines Projekt angetestet habe, hat es sich recht gut bewährt. Ob es nun am Code, an der Dokumentation oder am Support liegt, ist schwer zu entscheiden.

P.S.: Ja, ich habe auch die Django-Struktur in Werkzeug nachgebaut, also mit urls.py, views.py etc. Aber ich denke, dass sich das recht gut bewährt, also sehe ich nichts was da dagegen sprechen sollte.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Leonidas, ich denke nach wie vor, zu viel Flexibiliät ist genauso schlecht wie zu wenig. Wenn ich nicht erst fünf Template-Systeme, drei URL-Dispatcher und zwei ORMs evaluieren muss sondern ein gut dokumentiertes Gesamtsystem habe, dass perfekt mit den anderen Komponenten zusammenarbeit, ist das in meinen Augen ein Vorteil. Ich finde, dass die Dokumentation von Werkzeug (und anderen Projekten auf pocoo.org) ansprechend und übersichtlich ist - Respekt! - doch Django bietet - und dokumentiert - einfach mehr. Weglassen kann ich immer, dafür muss ich nicht mit weniger starten.

Mich nervt bei Django nur die Weigerung der Entwickler, häufiger zu releasen und in kleineren Schritten Neuerungen einzubauen. Die bislang beste Erklärung für dieses Problem habe ich gerade von Zed Shawn gelesen, als er sich gestern über die Consulting-Firmen, Rails-Entwickler und die Welt ausgekotzt hat. Leider bietet auch Zed keine Lösung an - offenbar haben Lua-User das selbe Problem mit dessen Kernentwicklern wie ich mit Django.

Was mich aber eigentlich in diesem Thread interessiert hatte war, wie ein Rahmenwerk aussehen sollte, dass besonders gut für Browser-Spiele geeignet ist und warum mitsuhiko meinte, dass Werkzeug da besser sei als Django.

Ich habe mir mittlerweile drei (zugegeben antike - in der Hoffnung, die wären einfacher als etwas, das schon einige Jahre entwickelt wurde) Browser-Spiele angeschaut und der Quelltext war jedes Mal katastrophal. Das mag an den Sprachen (Pike, Coldfusion und PHP) liegen, aber meine aktuelle Theorie ist, dass es an dem Typus Entwickler liegt und daran, was er kennt bzw. alles nicht kennt.

Das Spiel 1000AD sah ganz interessant aus. Leider ist es in Coldfusion realisiert und was ich bislang gesehen habe sagt mir, dass ich bitte niemals CF benutzen müssen möchte. Das ist die gleiche Soße wie PHP. Programmcode und HTML sind fest verdrahtet, überall sind SQL-Statements hart verdrahtet und die einzige Möglichkeit zur Strukturierung ist das "include".

StellarCrisis war nach eigener Aussage das erste Browser-Spiel und da ich es sogar früher mal gespielt hatte, hatte ich auch dies mir angesehen, nachdem ich die Originalversion von 1997 aufgetrieben hatte. Das ist ein knapp 8000-zeiliges Pike-Programm. Ich greife mir immer Sprachen, die ich nicht kenne, aber auch hier ist der Code grausam. Zwar kein SQL oder Datenbank, dafür ein einziges großes assoziatives Array bei dem sich die Bedeutungen der Elemente nur langsam erschließen.

Ich würde das ganze wohl mit einer transaktionalen Objektdatenbank angehen. Hat man einen Server, der länger läuft, wäre auf ein System wie SimpleDB/CouchDB geeignet, einmal den Spielstand zu sichern und ihn ansonsten im Hauptspeicher zu halten. Regeln und Auswertungen lassen sich IMHO jedenfalls deutlich einfacher objektorientiert forumulieren als rein prozedural mit der Hilfe von SQL-SELECT- und -UPDATE-Statements, wie es ein leider nur halbfertiges in PHP geschriebenes Spiel versuchte, das ich mir noch angeschaut hatte. Ich kann verstehen, warum der Autor da wieder aufgegeben hat.

Stefan
Benutzeravatar
keppla
User
Beiträge: 483
Registriert: Montag 31. Oktober 2005, 00:12

sma hat geschrieben:Leonidas, ich denke nach wie vor, zu viel Flexibiliät ist genauso schlecht wie zu wenig. Wenn ich nicht erst fünf Template-Systeme, drei URL-Dispatcher und zwei ORMs evaluieren muss sondern ein gut dokumentiertes Gesamtsystem habe, dass perfekt mit den anderen Komponenten zusammenarbeit, ist das in meinen Augen ein Vorteil.
Das ist imho kein gültiges Argument, wenn man auf der Suche ist. Bei jedem alternativen "rundum glücklich"-framework musst du dir auch den dispatcher, das orm und das templating angucken, das wird nicht weniger dadurch, dass es in einem Paket geboten wird.

Falls es interessiert, bin ich recht glücklich mit Werkzeug, SQLAlchemy, Mako.
Imho tun sich die Templatingengines nicht viel, und bei den ORM ist die Frage, ob viel Magie und wenig Kontrolle oder das Gegenteil.
doch Django bietet - und dokumentiert - einfach mehr.
mir fiele da höchstens der Formhelper ein.
Besser dokumentiert als SQLAlchemy ist der ORM-Teil imho nicht, gleiches gilt imho für den Templatingteil.
Was mich aber eigentlich in diesem Thread interessiert hatte war, wie ein Rahmenwerk aussehen sollte, dass besonders gut für Browser-Spiele geeignet ist und warum mitsuhiko meinte, dass Werkzeug da besser sei als Django.
Ist jetzt logischerweise nicht Mitsiuhikos, sondern meine Position: weil Werkzeug+ORM+Template imho alles bietet, was man braucht, und nicht so monolithisch ist, was es einfacher mit weiteren Komponenten agieren lässt, die ziemlich sicher mal hinzukommen, und, da es ein browserspiel ist, vermutlich aus dem typischen "crud"-ansatz der rails-inspirierten frameworks herausfallen.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

sma hat geschrieben:Leonidas, ich denke nach wie vor, zu viel Flexibiliät ist genauso schlecht wie zu wenig. Wenn ich nicht erst fünf Template-Systeme, drei URL-Dispatcher und zwei ORMs evaluieren muss sondern ein gut dokumentiertes Gesamtsystem habe, dass perfekt mit den anderen Komponenten zusammenarbeit, ist das in meinen Augen ein Vorteil.
Naja, das hat Werkzeug auch. Du nimmst Werkzeug + Jinja + SQLAlchemy und bist fertig. Jede dieser Komponenten ist gut, teilweise auch sehr gut dokumentiert und sie werden oft benutzt.
sma hat geschrieben:Ich würde das ganze wohl mit einer transaktionalen Objektdatenbank angehen. Hat man einen Server, der länger läuft, wäre auf ein System wie SimpleDB/CouchDB geeignet, einmal den Spielstand zu sichern und ihn ansonsten im Hauptspeicher zu halten. Regeln und Auswertungen lassen sich IMHO jedenfalls deutlich einfacher objektorientiert forumulieren als rein prozedural mit der Hilfe von SQL-SELECT- und -UPDATE-Statements, wie es ein leider nur halbfertiges in PHP geschriebenes Spiel versuchte, das ich mir noch angeschaut hatte.
Hast du dir auch ZODB/Durus angesehen?

CouchDB kannte ich noch nicht, werde ich mir ansehen müssen.

Edit: Achja, was Forms angeht gibt es neben newforms-extraced (was eben Djangos Newforms sind) auch noch FormEncode zur Formularvalidierung (bis auf dass es etwas seltsam ist, da es HTML-Code parst (htmlfill) funktioniert es bei meinen Projekten recht gut) und das dazu passende FormBuilder, das die Formulare generiert. Letzteres habe ich aber nicht benutzt, ich habe die Formulare als HTML vorliegen gehabt.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Keppla, ich bin nicht (mehr als sonst) auf der Suche :) Ich hatte nur gehofft, es könnte mir jemand konkret sagen, nimm "X" statt "Y", denn da ist "Z" besser, was in Bezug auf Browserspiele ein großer Vorteil ist, weil... Es freut mich, dass du mit Werkzeug, SQLA und Mako glücklich bist... du schreibst damit aber nicht zufällig ein Browserspiel, oder? ;)

Du schreibst weiter "Werkzeug+ORM+Template imho alles bietet, was man braucht" und meinst mit "man" bestimmt dich, denn genau diese Aussage hängt ganz klar von dem konkreten Anwendungsfall ab. Ich hatte mich ursprünglich mit Django beschäftigt, weil dessen Admin UI mir bei einem Projekt in der Firma einen großen Zeitvorteil verschafft hat. Nach wie vor ist für mich diese Komponente bei Django mit die wichtigste. Offenbar ist sie für dich nicht wichtig. Gut, aber eben eine andere Anforderung.

Ob ich bei einem Browserspiel ein Admin-UI brauche? Ich kann es nicht mit Bestimmtheit sagen, aber es fühlt sich IMHO gut an, wenn ich von Anfang an, bequem im Datenbestand wühlen kann (ich betrachte das databrowing-Modul von Django als nahen Verwandten des Admin UIs ;) ohne dafür viel programmieren zu müssen. Gleiches gilt für die User-Verwaltung, ein weiterer Bestandteil, der in deiner Liste nicht vorkommt.

Ich will hier nicht streiten, welches Rahmenwerk absolut besser ist (das wäre müßig), sondern erhoffte mir Tipps in Bezug auf meine selbstgestellte Aufgabe.

Leonidas, Durus habe ich auf der Platte und kurz angeschaut, aber es ist auch schon größer als mir lieb ist und daher habe ich einen Bogen um ZODB gemacht. Vielleicht denke ich noch zu sehr in Java, doch dort hätte ich mich einfach darauf verlassen, dass Tomcat schon lang genug läuft und alles im Hauptspeicher gehalten - wissend, dass der lesende Zugriff so sehr effizient ist und bei schreibenden Zugriffe durch einen Log gesichert (Stichwort "Prevayler") - wenn überhaupt. Bislang erwische ich mich immer noch dabei, das ganze wie ein Postspiel zu sehen, wo nur einmal die Züge ankommen und dann ausgewertet werden. Bei einem Zug pro Tag (als Beispiel) hätte ich für jeden Spieler genau eine Schreiboperation. Dafür brauche ich keine DB. Oder eben etwas wie CouchDB, welches ein strukturiertes Dokument (im JSON-Format, aber das könnte auch XML sein oder eben ein Python-Pickle) ablegt. Durus scheint ähnlich angefangen zu haben, dann aber immer mehr in Richtung OODB - sowas wie Gemstone, falls das jemand kennt, ein Application Server, den es gab, als es das Wort noch gar nicht gab ;)

Wenn ich mir anschaue, wie 1000AD funktioniert, dann reicht für ein solches Spiel eine RDB. In der DB stehen Spieler (die Tabelle hat ca. 100 Spalten!), Alliancen, Nachrichten und etwas, dass sie Queues nennen, nämlich die Befehle, die in der nächsten Runde ausgeführt werden sollen. Das Programm ist wie ein Menü strukturiert (und das Layout extrem tabellenlasig) und es gibt im Prinzip nur eine index-Seite, in die immer wieder neue Seiten eingebunden werden, wobei es dann noch Callbacks für die Funktionen gibt. Der Autor hat unermüdlich SQL-Update-Statements für alle Änderungen an der Datenbank geschrieben - und tausende Zeilen Code, wenn es z.B. um etwas wie den Kampf geht. Nur Funktionen waren nicht so sein Ding :(

Im Prinzip kann ich als Spieler mir den aktuellen Spielstand anschauen und Befehle für den neuen Spielstand geben. Wirklich beeinflussen kann ich nichts, denn echte Änderungen passieren erst mit dem Wechsel zu nächsten Runde - egal ob so eine Runde alle zwei Minute, zwei Stunden oder zwei Tage passiert.

Sagen wir, ich habe ein simples Spiel, in dem jeder Spieler ein Königreich (hat Größe, Gold und Einwohner) verwaltet und seinen Einwohnern Aufgaben zuteilt. Bauern erzeugen Nahrung für alle, Handwerker bringen Gold, Soldaten (kosten Gold) und können das Land verteidigen sowie Land, Gold oder Sklaven von anderen Spielern rauben, Arbeiter und Sklaven können eine Burg und eine Pyramide errichten, Priester stimmen den Zufallsgenerator gnädig. Wer zuerst die Pyramide errichtet hat, gewinnt.

Ändere ich mit jedem Befehl den Spielstand? Oder hebe ich alle Spielstände für alle Runden auf? Was, so hatte ich mir überlegt, wenn das Auswerten einer Runde nicht klappt. Einen halb veränderten Stand zu haben ist doof. Transaktionen benutzt die Generation-MySQL sowieso nicht, für all diese Spiele ist daher ein Bug fatal. Dann doch lieber niemals destruktive Änderungen haben, dann kann man immer wieder neu ansetzen. Ich würde sogar soweit gehen, und den seed des (Pseudo)-Zufallszahlengenerators mit in dem Spielstand ablegen, damit ein Runde reproduzierbar wird.

Stefan
Benutzeravatar
keppla
User
Beiträge: 483
Registriert: Montag 31. Oktober 2005, 00:12

sma hat geschrieben:Keppla, ich bin nicht (mehr als sonst) auf der Suche :)
Deshalb das wenn, mir ist klar, dass du nicht den thread mit "suche alternative zu django" gestartet hast, aber die diskussion ging ja in die Richtung.
Ich hatte nur gehofft, es könnte mir jemand konkret sagen, nimm "X" statt "Y", denn da ist "Z" besser, was in Bezug auf Browserspiele ein großer Vorteil ist, weil... Es freut mich, dass du mit Werkzeug, SQLA und Mako glücklich bist... du schreibst damit aber nicht zufällig ein Browserspiel, oder? ;)
Nein, aber eine Anwendung, die kein typisches CRUD ist. Und da fühlt man imho eben schnell durch, wenn das framework hauptsächlich für das publishen geschaffen ist.
Ich hatte mich ursprünglich mit Django beschäftigt, weil dessen Admin UI mir bei einem Projekt in der Firma einen großen Zeitvorteil verschafft hat. Nach wie vor ist für mich diese Komponente bei Django mit die wichtigste. Offenbar ist sie für dich nicht wichtig. Gut, aber eben eine andere Anforderung.
Ich hätte ehrlich gesagt nicht gedacht, dass sie für ein Browsergame brauchbar ist, weil ich dort mit deutlich komplexeren Strukturen gerechnet hätte, als es so ein durchschnittliches Publishing-Projekt hat.
Gleiches gilt für die User-Verwaltung, ein weiterer Bestandteil, der in deiner Liste nicht vorkommt.
gleiches auch hier: ich hätte nicht gedacht, dass Djangos Ansatz für user in einem Browserspiel geeignet ist. Ich fand die damals schon sehr schwer auf meine eher klassischen Probleme zu münzen.
Ich will hier nicht streiten, welches Rahmenwerk absolut besser ist (das wäre müßig), sondern erhoffte mir Tipps in Bezug auf meine selbstgestellte Aufgabe.
Das war ehrlich als Tipp gemeint. Meiner Einschätzung nach sind die meisten Frameworks nahezu nur dazu geeignet, das zu machen, was im coolen screencast gezeigt wird. Werkzeug ist kein Framework im klassischen Sinne, der Name triffts schon ganz gut. Werkzeug steht einem als Werkzeug zur Seite und rahmt einen nicht ein. Tut mit leid, dass ich das nicht sonderlich konkret sagen kann.
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Erstens hatte ich nicht ernsthaft vor dir Werkzeug nahezulegen, ich fands nur witzig Werkzeug als Werkzeug vorzuschlagen. Dennoch muss ich mich den Vorrednern anschließen: das Django Admin Panel / databrowser kannst du für sowas wie ein Browserspiel vergessen.

Ich hab gerade selber eine etwas größere Django Anwendung zum Bearbeiten und dort hauen wir gerade das Django Admin Interface Weg weil unsere Models so kompliziert geworden sind, dass das Admin Interface unbrauchbar wurde. Und das obwohl wir immer noch eine CRUD Anwendung haben.
TUFKAB – the user formerly known as blackbird
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

mitsuhiko hat geschrieben:Dennoch muss ich mich den Vorrednern anschließen: das Django Admin Panel / databrowser kannst du für sowas wie ein Browserspiel vergessen.
Wieso? Neu ein Gefühl oder gibt es konkrete Beispiele?

Bei 1000 AD steckt ein erschreckend simples Datenmodell dahinter. Das von Stellar Crisis ist komplexer, aber alles lässt sich auf 1:N-Relationen (man braucht noch nicht einmal N:M, da das Spiel selbst alles in assoziativen Arrays ablegt) abbilden. Lästig empfinde ich da eher die Anzahl der Tabellen und Relationen die man braucht. Im Original gibt es den Fall, dass zu einem Spieler gespeichert wird, welche Planeten er kennt. Da jeder Planet durch eine X,Y-Koordinate eindeutig identifiziert wird, wird für den Spieler einfach ein String mit diesen Koordinaten, jeweils durch ein Leerzeichen getrennt abgelegt und darin gesucht. Eigentlich ist das aber eine Relation zwischen Planeten (`System`) und Spielern (`Participant`), die man so modellieren könnte und sich dann z.B. prima im Admin UI anschauen kann.

Code: Alles auswählen

class Exploration(models.Model):
    participant = models.ForeignKey(Participant, related_name='explored_systems')
    system = models.ForeignKey(System, related_name='explored_by_participants')

class System...
    def mark_as_explored_by(participant):
        if self not in participant.explored_systems:
            self.explored_by_participants.create(participant=participant)
mitsuhiko hat geschrieben:Ich hab gerade selber eine etwas größere Django Anwendung zum Bearbeiten und dort hauen wir gerade das Django Admin Interface Weg weil unsere Models so kompliziert geworden sind, dass das Admin Interface unbrauchbar wurde.
Ich würde das gerne verstehen - schon um zu wissen, ob wir in der Firma da auch mal Probleme bekommen könnten und wäre daher an konkreten Beispielen interessiert? Zu viele Daten? Zu komplexere Relationen?

Stefan
Antworten