JHK

Nun hat es in Scherbenwelten erneut hart die Glocke geschlagen. Wie sich nun so langsam abzeichnet hat es diesesmal die groesste Fraktion in Scherbenwelten, der Hain, erwischt.

Anfangs war es nur verwunderlich das die zu dieser Zeit groesste Stadt von fast 4 Millionen Einwohnern drastisch an Einwohnern verlor. Dann kamen die ersten Geruechte, nun die Bestaetigung. Im Hain sind zahlreiche Accounts aufgrund von Multi-Using-Verdacht gesperrt. Noch sind keine konkreten Zahlen da. Ist auch verstaendlich das die Spielleitung vor Abschluss der Pruefung sich hierzu aeussert. Von den anderen Nationsmitgliedern gibt es bis jetzt auch noch keinen Kommentar dazu. Boese Zungen behaupten gar das es keine anderen Nationsmitglieder gibt.

Bis zur endgueltigen Klaerung wird es sicher noch eine Zeit dauern, aber allein das es derzeit solche Auswirkungen hat, insbesondere bei einem Spieler welcher schon einmal im Verdacht stand, stimmt doch schon traurig. Traurig das es fuer manche Spieler, zumindest liegt der Verdacht derzeit nahe, es fuer noetig halten in einem Spiel wie Scherbenwelten nicht nur einen Mehraufwand an Zeit investieren, sondern auch harte Euros. Nur um mehr “Macht” innerhalb des Spieles zu steuern, um ihre Chancen durch unfaire Mittel zu vermehren. Aber es ist muessig da noch weiter drueber zu reden bevor die endgueltige Entscheidung der Spielleitung vorliegt.

Das einzige was ich mir, auch wenn es dem Spiel womoeglich Spieler kostet, konsequent ist und sich diesesmal endgueltig von Spielern welche solche Mittel einsetzen trennt. Ohne die grosszuegige Chance zumindest den Hauptaccount weiter zu spielen. Oder sich einen neuen Account hoch zu ziehen waehrend der demnaechst nicht mehr verfuegbare Account noch aktiv ist. Dies fuehrte in der Vergangenheit nur dazu das die Spieler, bis auf die bislang gesammelten Erfahrungspunkte keine Nachteile zu erleiden hatten.

Der Community muss allerdings eines zugute gehalten werden: Bisher hat die Gegenseite die derzeitige Situation noch nicht versucht auszunutzen und in den derzeit geschwaechten Hain angegriffen.

Nachdem ich die Tage hoch getoent habe das die Umstellung auf Python 3 erfolgreich war, kam die Tage nun die ernuechterung. Es funktionieren mit pg8000 bei mir nur die Basisprozesse.

Aus mir nicht verstaendlichen und nachvollziehbaren Gruenden weigert sich pg8000 Updates auszufuehren. Select- und Insert-Querys stellen kein Problem dar, aber Updates… keine Chance. Hinzu kommt noch das ich die Fehlerbehandlung bei Python 3.1 / pg8000 nicht durchdrungen habe. Unter Python 2.5.2 / psycopg2 kam ich problemlos an die Fehlermeldungen heran. Das klappt hier nicht mehr. Vielleicht waere ich mit einer Fehlermeldung auch in der Lage pg8000 zu ueberreden auch Updates auszufuehren.

Konsequenz: Ich bin wieder zu Python 2.5.2 zureuck gegangen. Hier funktionieren zumidnest noch alle Bibliotheken und Module. Vielleicht schaue ich mir in einem halben Jahr noch einmal eine aktuelle Version an, wenn diese etwas gereifter ist und noch weitere Module nachgezogen haben.

Soeben habe ich die Weichen stellen koennen um meine bisherigen Python-Skripte “zukunftssicher” zu gestalten.
Bisher habe ich noch mit Python 2.5 gearbeitet, doch so langsam machte sich dann doch die Umstellungslust breit. Also die heute frisch erschienene Version 3.1 gezogen und installiert. Da kam dann gleich die erste Frage auf, “Wie schauts mit der PostGres-Anbindung aus?” Im Netz geschaut, aber von Psycopg2 gibt es keine Version fuer Python 3. Schade. Aber sehr schnell habe ich pg8000 gefunden. Erfreulicherweise kam hier kaum eine Aenderung im Quellcode meiner bisherigen Arbeiten auf mich zu. Die Import-Anweisungen habe ich ausgetauscht und danach noch die Connect-Anweisung. Der komplette Rest, Querys, Result-Verarbeitung… alles geblieben wie unter Psycopg2. Sehr fein. Wenn das auch in anderen Sprachen so einfach waere.

Ein weiterer grober Check ueber meine anderen Module.. passt alles. Auch die Datumsfunktionen arbeiten noch wie gewuenscht, also derzeit noch keine wichtigen Verluste.

Was derzeit noch nich verfuegbar ist, ist eine aktuelle Version von Django. Aber an dieser Stelle habe ich noch etwas Zeit. Bis die Insulae-Klassen alle von PHP nach Python portiert wurden werde ich sowieso noch keine Zeit haben ich wieder um die Oberflaeche zu kuemmern. Und irgendwie ist Zeit derzeit so extrem fluechtig. Und bis ich dann tatsaechlich wieder daran komme mit matplotlib zu arbeiten, das dauert.

Gerade eben bei The Corporation gelesen, Sony wird das Onlinespiel The Matrix Online abschalten.

Dabei gibt es nun zwei Punkte zu beachten. Zum einen, schade um das Spiel. Seit 2005 aktiv hat es doch irgendwie dazu gehoert. Es hat nicht so grosse Oeffentlichkeitsarbeit gehabt wie andere Spiele, aber es hatte was. Schade. Der andere Punkt ist ein rein wirtschaftlicher. Was wird Sony Online Entertainment mit den anderen, ebenfalls nicht so stark frequentierten Spielen anstellen? Werden diese ebenfalls geschlossen oder umstrukturiert? Oder hatte das Abschalten der Matrix noch andere Gruende? Wir werden es in den naechsten Monaten sehen.

Bis zum 31.Juli 2009 wird es noch moeglich sein TMO zu spielen. Danach wird es, wohl fuer immer, keine rote oder blaue Pille mehr geben.

Nachtrag: Es ist nicht der 31 Juni, sondern natuerlich der Juli.

Quelle: http://www.corpnews.com

Vor ein paar Tagen habe ich angefangen die Grundlagen fuer die individuellen Gebaeudeausbauten DB-seitig zu legen.

Was sind diese Gebaeudeausbauten eigentlich? Nun, in Insulae kann ein Gebaede ueber mehrere “AddOns” verfuegen. Diese AddOns haben Einfluss auf die maximale Produktionsmenge innerhalb eines definierten Zeitraumes. Je hoeher die Stufen eines “AddOns”, umso staerker die Produktion.

Waehrend bei allen produzierenden Gebaeuden die Fertigkeiten der Insassen, ein von der Gebaeudeart abhaengiger Koeffizient und die Landguete eine Rolle spielt, fliesst grundsaetzlich noch die Stufe der fuer jeden Gebaeudetyp unterschiedlichen Ausbauten hinzu. Bei den reinen Veredelungsgebaeuden spielt die Landguete allerdings keine Rolle.

Dabei besitzt jedes Gebaeude sein eigenes Set an Ausbauten. In einem Bauernhof ist es zum Beispiel moeglich die Felder und Staelle aufzuwerten um die Produktion von Getreide und Kuehen anzukurbeln. Felder und Staelle machen jedoch bei einer Goldmine keinen Sinn, dafuer gibt es dort Stollen welche die Goldfoerderung antreiben. Auch die zum Steigern dieser Ausbaustufe noetigen Waren sind dabei unterschiedlich und sind von dem Ausbau, nicht vom Gebaeude abhaengig.

Dies umzusetzen ist auf verschiedene Arten moeglich. Zum einen haette ich von vornerein sagen koennen das es nur n Ausbauten geben darf. Und im folgenden dann lediglich hart codieren das Ausbau 1 bei dem Bauernhof eben “Felder” heisst und bei der Goldmine “Stollen”, die benötigten Waren ebenfalls hart codiert in den Skripten hinterlegen. Das empfinde ich aber als eine unfeine Einschraenkung der Moeglichkeiten. Also blieb mir nur die Variante sowohl die einzelnen Ausbauten, aber auch deren kosten flexibel in der Datenbank zu hinterlegen. Aus folgendem Grunde. Ich moechte mir die Moeglichkeit offen halten schnell Aenderungen am System zu ermoeglichen. Aenderungen welche ggf. auch von reinen Moderatoren vorgenommen werden koennen anhand einer Onlinemaske und nicht eine Aenderung im Programmcode erfordern. Die Konsequenz, Performanceeinbußen, sind mir durchaus bewusst. Aber bei Insulae geht es ja nicht allein um Performance, sondern um eine technische Spielwiese.

Ich habe also um ein Gebaeude zu verwalten 5 Relationen in meine Datenbank. In der Relation archetyp.haus sind die Grundlegen Daten der Gebaeude abgelegt. Die Individuelle ID, der Name, Beschreibung etc. Zu einem Gebaeude sind dann in der Relation archetyp.haus_ausbau die fuer ein Gebaeude zutreffenden AddOns abgelegt, ebenfalls mit Name, Beschreibung und so weiter. Ein Gebaeude kann keines, eines oder mehrere AddOns besitzen. Dazu referenzierend gibt es noch eine Relation archetyp.haus_ausbau_ware in welcher abgelegt ist welche Waren fuer eine Steigerung der Stufe notwendig sind. Dabei wird von einer Berechnung von

Wobei

• S die aktuelle Stufe des Ausbau ist
• G die Grundwarenmenge
• und P der Phasenkoeffizient.

ausgegangen. Diese Berechnung wird fuer jeden Warentyp vorgenommen. Wie leicht zu erkennen ist, wird ein Ausbau mit jeder weiteren Stufe teurer. Der Phasenkoeffizient kann genutzt werden um die Kosten pro Phase unterschiedlich zu gestalten. In meiner primaeren Phase nutze ich hier den Wert 1.0. In einer “Speed-Runde” ist denkbar den Wert hierfuer niedriger zu halten um schneller an hoeher Ausgebaute Gebaeude zu gelangen. Aber, steuerbar ohne noch nachtraeglich in den Programmcode einzugreiffen.

Wird nun ein neues Gebaeude gebaut, wird ein neuer Eintrag in der Relation welt.haus erzeugt. Aus dieser geht eindeutig hervor wem das Gebaeude gehoert, welcher Gebaeudetyp es ist, wo es steht, zusaetzlich zu ein paar weiteren Werten. Die Insert-Query aktiviert dabei gleich einen Trigger welcher in der Relation welt.haus_ausbau die Eintraege ueber die fuer das Gebaeude vorliegenden Ausbauten vornimmt. An dieser Stelle ist bewusst ein Trigger verwendet worden um diese Logik nicht zusaetzlich im Programm abzulegen. Gleichzeitig sind in welt.haus_ausbau auch die Stufen der Ausbauten hinterlegt.

Warum nun der ganze Aufwand? Ganz einfach:

• eine Onlinemaske um ein neues Gebaeude samt Kosten, Bauland etc. zu hinterlegen anzulegen
• eine Onlinemaske um fuer einen Gebaeudearchetyp ein neues AddOn zu erstellen und mit Baukosten zu hinterlegen
• eine weitere Maske um einen Gebaeudearchetyp im Spiel zu aktivieren bzw. zu deaktiviereb.
• weiterin eine Maske um die Daten eines Ausbaus zu veraendern. Kann ja sein das ich die Kosten nachtraeglich nochmal veraendern will.

Und schon habe ich eine Verwaltung welche kaum noch Eingriffe in den Programmcode erfordert, eine Verwaltung welche auch von nicht technischem Personal erfolgen kann. Ebenso ist es ueber die Daten eines Ausbaues auch moeglich seine Produktionsformel grundlegend zu veraendern. Die Gewichtung der einzelnen Parameter welcher ueber die Produktionshoehe entscheiden ist so ebenfalls ohne Codeseitige Arbeiten moeglich. Komplex in der Realisierung und auch fuer die Produktionsauswertungen nicht das schnellste, aber was ist heutzutage schon nach viel begrenzte Rechenkapazitaet im Vergleich zu vor fuenf Jahren? :) Ganz davon abgesehen das ich hier auf einer technischen Spielwiese unterwegs bin, nicht im realen Leben.

Klar, in den Relationen stecken noch ein paar Elemente mehr, welche ich hier jedoch nicht weiter erlaeutern will. Aber wer Insulae oder Scherbenwelten kennt, der weiss das noch irgendwo die Information sein muss was in einem Gebaeude produziert wird. Generell gilt jedoch:

Wobei

• S die Fertigkeitsstufen der Insassen,
• A die Stufe des Ausbaus,
• F die Feldstaerke,
• H der fuer dieses Gebaeude spezielle Koeffizient,
• W die Modifikation gemaes des aktuellen Wetters,
• G ein Globaler Produktionsmodifikator ist und
• P ein fuer die Phase gueltiger Koeffizient ist.

Der Skill wird wahrscheinlich von mir irgendwann noch einmal differenziert in Gesamtskill, hoechster Einzelskill, geringester Einzelskill etc. Fuer den ersten Betrieb langt mir aber dieses Berechnungsmodell. Klingt erstmal kompliziert, ist es aber in keinster Weise. Und durch ein paar Filternde Tricks wird auch die Auswertungsrunde, also die Berechnungs wenn alle Gebaeude in Insulae produzieren, auch nicht umstaendlich in die Laenge gezogen.

Einen weitere Moeglichkeit hat dieses System: Ich bin in der Lage einem Gebaeude einen Ausbau zuzuordnen den dieser Gebaeudetyp fuer gewoehnlich nicht besitzt. Eine Holzhuette die auch gleich Fleisch produziert? Einfach den Ausbau dem spezifischen Gebaeude eines Spielers zuweisen und fertig. Keine statischen Gebaeude mehr, sondern eine flexible Grundlage. Lediglich an zwei Stelle habe ich begrenzend die Strukturen gebildet:

• es kann nur eine Fertigkeit fuer die Produktion eines Ausbaus herangezogen werden
• ein Ausbau kann nur eine Ware produzieren

Dieses auch noch weiter zu unterteilen wuerde dann, sogar fuer meine Verhaeltnisse, unnoetige Einbussen auf die Betriebsgeschwindigkeit besitzen.

Das sind die Grundzuege meiner Gebaeudestruktur. Datenbankseitig steht alles, Grundzuege sind auch bereits in den den Spielern zur Verfuegung stehenden Skripten enthalten. Lediglich die Onlinemasken fuer die Verwaltung stehen noch nicht. Aber die kommen noch. Und wer weiss, eventuell faellt mir ja noch bei der Implementierung der anderen Dinge etwas ein was dort beruecksichtigt werden muss.