Archive

Author Archive

Besuch auf Burg Lohra

June 15th, 2010 Jan H. Krueger No comments

Anfang des Monats habe ich mich mal wieder zum jaehrlichen Treffen begeben. Insgesamt war es ein sehr schoenes Wochenende. Und dank meiner neuen Kamera konnte ich auch mal ein paar Bilder aufnehmen von der doch rech schoenen Burg wie ich finde.
Leider wird nur das allernoetigste an der Burg getan, fuer alles weitere scheint es kein Geld zu geben. Dabei ist insbesondere die Kapelle schoen. Schade. Aber zumindest scheinen die Holzwuermer in der Kapelle in den letzten Jahren nicht allzu aktiv gewesen zu sein.

Interessant waere natuerlich noch, Burg Lohra einmal im Winter zu sehen, so richtig mit Schnee. Dort oben bestimmt klasse. Hm, vielleicht naechtes Jahr ;)
Aber nun, die Burgbilder vom Wochenende:

Viewing images 1-20 of 37
Lohra_2010_0108.JPG Lohra_2010_0080.JPG Lohra_2010_0062.JPG Lohra_2010_0063.JPG Lohra_2010_0066.JPG Lohra_2010_0067.JPG Lohra_2010_0070.JPG Lohra_2010_0071.JPG Lohra_2010_0072.JPG Lohra_2010_0073.JPG Lohra_2010_0074.JPG Lohra_2010_0075.JPG Lohra_2010_0076.JPG Lohra_2010_0077.JPG Lohra_2010_0081.JPG Lohra_2010_0082.JPG Lohra_2010_0083.JPG Lohra_2010_0084.JPG Lohra_2010_0085.JPG Lohra_2010_0086.JPG
Viewing images 1-20 of 37
Categories: Bilder Tags: ,

Insulae – automatisiertes Veroeffentlichen in Sozialen Netzwerken

May 30th, 2010 Jan H. Krueger No comments

Um alle Interessenten stets schnell und einfach ueber Neuerungen in Insulae informieren zu koennen, habe ich ein wenig rumprobiert und nun die erste Version der Netzwerkanbindung fuer Insulae fertig gestellt.
Konkret: mittels eines neu erstellten Formulares koennen Ankuendigung und News bequem zentral erfasst werden. Daraufhin wird die Ankuendigung aktuell an fuenf Orte eingestellt:

  • News-Seite in Insulae
  • Insulae-Forum
  • dieses Blog
  • Twitter
  • Google Buzz

Als naechsten Schritt werde ich versuchen mich mit der API zu Facebook auseinander zu setzen um auch hier einen direkten Zugang per Skript zu erlangen. Infoquellen per RSS-Feeds ergeben sich aus den genannten Quellen ebenfalls.

Dabei ist die Anbindung an die eigene News-Seite und ins Forum trivial, da Eigenentwicklungen. Daher werde ich hier auch nicht weiter darauf eingehen.

Die Twitter-API ist dankenswerterweise simpel wie es nur sein kann.

#!/usr/bin/python
 
import os
import twitter
 
E = sys.exit
 
##############################
# Send message to Twitter
##############################
 
try:
    # API initialisieren
    client = twitter.Api()
 
    # Authentifizieren
    client = twitter.Api(username='twitterusername', password='twitterpassword')
 
    # Nachricht an Twitter senden
    update = client.PostUpdate(message)
except: 
    print ("Keine Anbindung an Twitter moeglich.") 
    E(8)

Schwupps, Text bei Twitter gepostet.

Fuer Google Buzz sieht es etwas schwieriger aus. Ich habe noch keine ueberzeugende API dafuer gefunden. Doch Google hat die Moeglichkeit geschaffen, auch mittels einer E-Mail an Buzz zu senden. Daher ist die Hauptaufgabe fuer Buzz eigentlich der Versand einer E-Mail.

#!/usr/bin/python
 
import smtplib
from email.MIMEMultipart import MIMEMultipart
from email.MIMEBase import MIMEBase
from email.MIMEText import MIMEText
from email import Encoders
import os, getopt, sys
 
# Hier die zu veroeffentlichende Nachricht
message = "Beispielnachricht"
 
# Google Buzz Konfiguration
gmail_user = "username@googlemail.com"
gmail_pwd  = "password"
 
# Ab hier nichts mehr veraendern
 
# Derzeit verarbeitet Google Buzz lediglich den Titel einer
# eingehenden Mail. Daher muss die Nachricht direkt in den
# Mailtitel geschrieben werden.
# so subject = message
subject = message
 
E = sys.exit
 
##############################
# Send message to Google Buzz
##############################
try:
    msg = MIMEMultipart()
    msg['From']    = gmail_user
    msg['To']      = "buzz@gmail.com"
    msg['Subject'] = subject
    msg.attach(MIMEText(message))
 
    smptServer = smtplib.SMTP("smtp.gmail.com", 587)
    smptServer.ehlo()
    smptServer.starttls()
    smptServer.ehlo()
    smptServer.login(gmail_user, gmail_pwd)
    smptServer.sendmail(gmail_user, to, msg.as_string())
    smptServer.close()
except: 
    print ("Kein Versand an Google Buzz moeglich") 
    E(8)

Grosser Dank fuer diesen Teil geht dabei an samof76 von Megam: Cloud Buzz. Dort habe ich die Basis fuer den Mailversand her.

Der Einfachheit halber habe ich hier in den Beispielen zwei separate Skripte vorgestellt. Fuer Insulae sind die entsprechenden Schritte im Portal zentral eingebettet.

Warum der Aufwand? Um schnell und einfach in verschiedenen Kanaelen Informationen ueber Insulae zu verbreiten. In meinen Augen ist es in der heutigen Zeit notwendig, die zur Verfuegung stehen Mittel auch vollstaendig zu nutzen. Je breiter die Informationsbasis, umso mehr potentielle Spieler lassen sich finden. Je mehr Informationskanaele genutzt werden, umso geringer die Wahrscheinlichkeit einen potentiellen Spieler nicht zu erreichen. Daher gilt ein meinen Augen: Der Spieler sucht sich den Informationskanal, der ihm gefaellt. Gerade Browsergames bei denen keine grosse Entwicklungsfirma im Hintergrund steht, koennen sich in meinen Augen nicht erlauben, Spielern zu diktieren welchen Kanal sie zu nutzen haben, erst recht wenn sie erst noch Spieler werden sollen. Gar nichts zu veroeffentlichen ist inakzeptabel.

Wenn wie oben bereits angesprochen auch Facebook in mein Portal integriert ist, habe ich denke ich eine gute bis sehr gute Abdeckung von Informationskanaelen die ich mit Infos bestuecke. Dabei gilt: je mehr, umso besser. Aber nur relevante Informationen! Zu wenig, und Spieler koennen den Eindruck gewinnen das ein Projekt eingeschlafen ist. Zu viele, und wichtige Infos koennen unter der Masse verloren gehen.

Daher: Spread the word!

Interessant waere es eventuell auch, Google Wave anzusprechen. Doch derzeit bin ich vom insgesamten Nutzen von Wave nicht ueberzeugt, daher steht dieses Kanal auch noch sehr weit hinten an. Ob, ausser Facebook und eventuelle Google Wave, noch andere Kanaele angebunden werden… das kann ich zum aktuellen Zeitpunkt noch nicht sagen. Ich wuensche mir allerdings, das die verbliebenen deutschen Browsergame-Portale entsprechende Schnittstellen anbieten wuerden damit auch diese in einem Schritt gefuettern werden koennen. Aber dies wird wohl niemals passieren.

Nebenbei: die Suchmaschinen werden mittels Ping-Dienste aus dem Blog bereits darauf hingewiesen das es neues futter fuer sie gibt welches sie konsumieren koennen. Also auch dieser Teil erfolgreich abgedeckt.

Google Webfonts

May 29th, 2010 Jan H. Krueger No comments

Bereits vor einiger Zeit hat Google begonnen für Webentwickler etwas sehr praktisches zu veröffentlichen. Die Möglichkeit mittels CSS weitere Schriftarten einzubinden. Das Ganze nennt sich Google font directory, die Bedienung ist so simpel wie es nur möglich ist:

Für jeden einzubindenden Font gibt es ein externes Style Sheet welches auf gewohnte CSS-Weise eingebunden wird:

<link rel="stylesheet" type="text/css" href="http://fonts.googleapis.com/css?family=Tangerine">

Danach kann die Schriftart mittels CSS angegeben werden:

font-family: 'Tangerine', serif;

Das war’s.

Zwar mag das aktuelle Angebot mit 19 Schriftarten noch etwas gering anmuten, doch so wie ich Google einschätze, wird dies nur eine Frage der Zeit sein bis wir hier weitere Schriftarten nutzen können.

Warum erwähne ich dies hier? Nun, mittels der von Google bereit gestellten Mittel ist es für mich als Entwickler möglich andere Schriftarten zu verwenden mit der Gewissheit das diese auf den unterschiedlichsten Clients auch korrekt angezeigt werden.
Interessant wird dies dann, wenn man wie in Insulae und Scherbenwelten in den Foren auch Bereiche eingerichtet hat in denen Rollenspiel betrieben wird. Konkret: Spieler können Texte in Schriftarten ihrer Wahl verfassen, umso ihr Rollenspiel noch weiter zu unterstreichen. Und alle anderen sehen dann den Beitrag so wie er eingestellt wurde.

Entsprechendes wurde in Scherbenwelten auch bereits vorgeschlagen. Ich wage zwar zu behaupten das ein solches, auch nachdem ich eine mögliche Lösung mittels Google-Mitteln vorschlug.
Bei einer der nächsten Überarbeitungen des Forums in Insulae werde ich das Potential von Google Webfonts mit beachten und entsprechende Wahlmöglichkeiten für die Spieler einbauen.
Denkbar ist auch, den Spieler mittels der Webfonts zu erlauben ihre Signaturen in den Rollenspiel-Foren zu personalisieren. Oder die Diplomatie-Nachrichten. Auf alle Fälle steckt auch viel Potential für Browsergames in den Webfonts.

Quellen: Google font directory, Scherbenwelten

Insulae – Umstrukturierung Boesartigkeit

May 28th, 2010 Jan H. Krueger No comments

Die Bösartigkeit, also der Wert, welcher in Insulae und auch Scherbenwelten angibt, wie viele böse Taten ein Account bereits begangen hat, war bisher ein globaler Wert welcher auf der gesamten Welt Gültigkeit besaß. Dieses wurde nun von mir geändert, die Bösartigkeit steht nicht mehr für die gesamte Welt sondern nur noch für die Insel bzw. den Kontinent auf dem die böse Tat begangen wurde. Als Nebeneffekt werden die einzelnen Regionen noch stärker hervorgehoben im Spiel, da sich eben auch Änderungen im Verhalten der Bewohner ergeben können.

Die Ablage im Datenmodell ist dabei so einfach wie möglich gehalten, anbei ein Beispiel. Kurz, knapp und auch für die Datenbank leicht zu verarbeiten.

Was hat dies für Konsequenzen? Nun, erst einmal kann es so nun passieren das ein Account in seinem Heimatland zwar ein ganz schlimmer Junge ist, am anderen Ende der Welt jedoch noch niemand etwas davon gehört hat. Der Bösartigkeitswert wird nun daher für jede Insel und jeden Spieler getrennt gespeichert. Erhöht die Datenmenge, aber ich denke dies ist es wert. Nun erfährt nicht sofort Bauer Hans auf der anderen Seite der Welt das Person A mal wieder Sklaven gesammelt hat. Wenn allerdings ein gewisser Schwellenwert überschritten wird, wird die erhaltene Bösartigkeit jedoch auch auf die umliegenden Inseln anteilig weiter gereicht. Die Geschichten über die schrecklichen Taten verbreiten sich also auch über die Landesgrenzen hinweg.

Andererseits ergeben sich für einen Account der stets nur auf derselben Insel verbleibt keine Änderungen, für diesen gibt es (scheinbar) nur einen abgespeicherten Wert.

Dies bedeutet allerdings auch, dass ein schlimmer Finger auf der anderen Seite der Welt erst einmal eine weiße Weste hat. Der Neuanfang in einem fremden, weit entfernten Land wird damit unterstützt.

Beispiel wie die Bösartigkeitstabelle mit Inhalten aussieht:

Mit dieser Änderung einhergehend, wird auch der Abfall der Bösartigkeit angepasst. Für jede Region wird die Bösartigkeit getrennt herabgesetzt. Grundsätzlich gilt auch weiterhin: Je höher der Wert, umso länger dauert es bis dieser abgebaut worden ist.

Reduzierung der Ladezeiten

May 27th, 2010 Jan H. Krueger No comments

Nach einiger Tüftelei und vor allem einer geänderten Herangehensweise konnte ich die Ladezeiten in Insulae bedeutend verbessern. Der Gruppenschirm, ein zentraler Bestandteil von Insulae, stellt er schließlich die Welt für den Spieler dar und bietet somit Interaktionsmöglichkeiten, war stets etwas “zäh”.

Gegen Ende, nachdem so einige Dinge eingebaut waren wie ich es wollte, betrug die durchschnittliche Ladezeit 1121 Millisekunden. Definitiv nichts was irgendjemanden vom Hocker hauen kann, geschweige denn etwas was für einen Massenbetrieb geeignet ist.

Also habe ich ein wenig getüftelt, gedreht und überlegt was verändert werden kann. Ich denke ich kann sagen, die Arbeit von 4 Tagen war ein voller Erfolg. Von den eben erwähnten 1121 Millisekunden sind nun nur noch 16 Millisekunden über geblieben. Ja, richtig gelesen, 16. Der Seitenaufbau fluppt nun sozusagen.

Um dieses zu erreichen, habe ich als erstes die Protokollierung der Datenbank hoch geschraubt. PostGreSQL loggte nun haarklein, welche Querys ausgeführt werden, der Zeitverbrauch eben dieser und ob sie erfolgreich waren. Bei der Analyse eben dieser Protokolle viel eines zuerst auf: Es wurden mehrere, zum Teil zeitintensive Querys unnötigerweise ausgeführt. Um dem nachzugehen wurden die Klassen für die Spieler, die Karte sowie der Quellcode des Gruppenschirmes genauestens überprüft. Und siehe da, es fanden sich ein paar Logikfehler. Diese wurden ausgebaut, das zähe Verhalten fing an sich zu lösen. Dennoch war es noch nicht ideal. Den wirklichen Durchbruch habe ich erzielt, indem ich die Abfragelogik der 49 dargestellten Felder grundlegend umwarf.

So wurde bisher jedes Feld für sich von der Datenbank angefordert. Wenn man bedenkt das nicht nur das Feld, sondern auch eventuelle Gebäude, Städte, Spieler- und Monstergruppen, Straßen, Schilder, Karawanen, Trigger etc. auf Existenz an der betreffenden Koordinate geprüft wurden, kamen da schon recht viele Querys zusammen. Von der Einzelfeldabfrage bin ich nun weg und lese alle Felder des Kartenbereiches aus. Die Datenbank wird damit entlastet, die weitere Logik geschieht bequem innerhalb von Python. Ich mag die Dictioneries ;)

Im Anschluss gab es noch ein paar kleinere Umstellungen des Datenmodells, einige  der großen Tabellen wurden aufgeteilt um nur relevante Daten durchsuchen zu müssen.

Nun, letzten Endes hat sich gezeigt dass es, auch bei einem bestehenden, funktionierenden System sich lohnen kann Zeit zu investieren um Optimieren vorzunehmen. Damit ist Insulae wieder einen Schritt näher produktiv zu gehen.