Das ist der aktuelle Stand der Karte mit Beispielobjekten. Im Unterschied zu Freelancer sind die Objekte wesentlich größer dargestellt und das Raster hat einen stärkeren visuellen Effekt - der für ein Browsergame für gute  Usability IMHO nötig ist.

Die neue Karte: Nouron Galaxy Map

Im letzten Blogeintrag zum Stand von Nouron erwähnte ich, dass ich an einer neuen Karte arbeite welche universell einsetzbar sein soll. Und weil es dich sicher brennend interessiert möchte ich dazu etwas mehr Hintergrundinfos veröffentlichen… 😉

Nochmal kurz meine Beweggründe für dieses (Teil-)-Projekt:

  • Einsatz von mehr SVG
  • Training für meine (eher durchschnittlichen) Javascript/JQuery/Ajax-Skills
  • Wiederverwertbarkeit von Teilen meines Browsergames…
  • Einstiegshürde für Entwickler die mir evtl. helfen wollen verringern
  • … und eine Referenz mehr auf GitHub 😉

Mittlerweile hat das Projekt einen brauchbaren Stand. Ich habe die Karte auch schon testweise in Nouron eingebaut und es funktioniert soweit. Es gibt noch fehlende Funktionalität für den wirklichen Gebrauch im Browsergame, aber dazu mehr weiter unten.

Wie ist die Karte konzeptionell aufgebaut?

Zunächst einmal handelt es sich um eine klassische 2D-Karte ohne viel Schnick-Schnack. Die Karte ist in 9 Felder aufgeteilt – bei einem Weltraumbrowsergame wie Nouron kann man sie als Systeme oder Sektoren bezeichnen. Die 9 Felder sind nach Himmelsrichtungen + Zentrum angeordnet. Jedes Feld ist eine SVG-Karte für sich, so dass das Nachladen von Inhalten beim Scrollen von oben/unten bzw. links/rechts sehr einfach möglich ist.

Ebenso war es mein Ziel bereits Teile des Nachbarfeldes/systems/sektors sehen zu können. Somit ist das Feld im Zentrum vollständig dargestellt – die Felder außen herum nur zum Teil. Je nach gewählter Skalierung kann man dass aber auch anders einstellen.
Die angezeigten Objekte selbst sind extra etwas größer dargestellt (momentan ca. 30px) um sie besser anklickbar zu machen. Das kann in Zukunft aber noch anders skaliert werden. Je nach Einsatzzweck für die Karte kann man die Skalierung wunschgemäß in der Konfiguration eintragen.
Außerdem werden mehrere Ebenen unterstützt. Für Nouron liegen z.B. auf der untersten Ebene die Objekte für großflächige Felder wie Asteroidenfelder und Trümmerhaufen. Darüber dann die Ebene mit Planeten und Monden. Und darüber dann die Ebene für Schiffe/Flotten.

Was habe ich bisher durch dieses Projekt gelernt?

  • ich konnte einige meiner eingestaubten SVG-Grundlagen auffrischen
  • ich habe gelernt wie man mit Javascript SVG erzeugt,
  • dass man aufgrund des in den meisten Browser umgesetzten Sicherheitskonzepts namens ‚Same Origin Policy‚ nicht mal eben eine JSON-Datei vom Dateisystem als Beispiel-Datenquelle nutzen kann,
  • dass man mit SVG keine Techniken ähnlich der CSS Sprites anwenden kann (!) und
  • wie man ein Projekt mit Bower.js – Support austattet

Bisher aufgetretene Probleme

Die erwähnte ‚Same Origin Policy‘-Problematik kann man durch Webserver-Einsatz umgehen. Entsprechenden Hinweis habe ich in der README hinzugefügt und damit ist das Problem vom Tisch. Die fehlende Möglichkeit jedoch mit SVG eine Technik ähnlich der CSS-Sprites einzusetzen hat mir schon einen gehörigen Strich durch die Rechnung gemacht. Um Requests zu sparen ist eine Sprite-Technik sehr wichtig. Leider ist das wie gesagt mit SVG nicht wie gewünscht möglich. Insofern sah ich mich gezwungen einen zweiten Modus einzubauen: den Hybrid-Modus. Dies ist wie der Name vermuten lässt eine Kombination aus HTML und SVG. Somit kann ich hier auf klassische CSS-Sprites setzen. SVG wird dabei momentan eigentlich nur noch für den Hintergrundraster verwendet.

So richtig glücklich bin ich damit nicht weil ich jetzt zwei Modi unterstützen muss und das natürlich zusätzliche Komplexität in den Quellcode des Projekts bringt. Ich bin schon stark am überlegen ob ich die SVG-Komponente doch wieder ganz entfernen werde. Wollen tue ich das aber eigentlich nicht – schließlich war es ursprünglich das Primärziel dieses Projekts.

Welche Funktionalität fehlt jetzt noch?

Es muss eine Möglichkeit geben Objekte anzuklicken und deren Informationen anzuzeigen. Dies soll so universell wie möglich geschehen. Es wird also auf einen Ajax-Request auf eine individuell einstellbare Url hinauslaufen, deren Response-Daten entweder in ein zuvor definiertes DOM-Element wie z.B. ein Popup geladen werden.

Wenn ich dann noch irgendwann Lust drauf habe, baue ich vielleicht noch einen Editor, mit dem man sich Karten aus gegebenen Sets zusammenklicken kann – aber das ist momentan noch eher Wunschdenken.

Wie gehts weiter?

Von Zeit zu Zeit werde ich weiter an der Karte basteln und sie so anpassen, dass ich sie für Nouron einsetzen kann – aber auch so dass sie für andere Browsergameprojekte einsetzbar wird. Für die oben angesprochenen SVG-Problematik muss ich noch eine Lösung finden… vielleicht ein Fork ohne SVG-Support?

Wie dem auch sei: ich hoffe ich konnte mal wieder einen kleinen Einblick gewähren und würde mich über Feedback sehr freuen!

Bis zum nächsten Mal,
tector 🙂

Nouron – Stand: April 2014

Stand: November 2013
Stand: Januar 2013
Stand: März 2014
Stand: April 2014

Fast ein halbes dreiviertel Jahr ist die letzte News zu Nouron her… und noch schlimmer: ich habe mehrmals einen neuen Blogeintrag angekündigt und es dann nicht eingehalten! Das tut mir leid für die 1-2 Leute die wirklich interessiert sind und darauf gewartet haben.
Wie du an den (symbolischen) Streichungen oben im Text sehen kannst habe ich durchaus mehrfach angefangen diesen Blogpost zu schreiben aber nie richtig vollendet und veröffentlicht. Das hole ich nun hiermit nach.

Und auch wenn es so von außen aussieht als ob sich nix getan hätte, ist das Gegenteil der Fall.
In den letzten Wochen gab es auch wieder vermehrt Commits auf GitHub – Meine Aktivität ist also wieder deutlich gestiegen. Aber ich erläutere einfach mal was sich so im letzten Jahr getan hat:

Phase 1: Sommer 2013 – November 2013

Es gab zwei sehr große Baustellen in dieser Zeit

Restrukturierung der Techtree-Objekte

Teil 1 von 2 großen Umbauten in diesem Jahr. Letztendlich eine sehr technische Sache von der man im Frontend gar nichts spürt. Aber für diesen Umbau musste ich gefühlt 60-70% des bestehenden Codes umschreiben. Statt alle Technologie-Arten (Gebäude, Forschungen, Schiffe, Berater) wie bisher in einer Tabelle der DB zu speichern werden sie jetzt in jeweils einzelnen Tabellen gespeichert. Also ein Schritt weg von ‚Oh, erfinde jetzt mal was bahnbrechend Neues und lege mir dabei selbst Steine in den Weg’… Bitte nicht falsch verstehen: Das Konzept hätte aufgehen können, aber es wurde einfach zu kompliziert für einen einzelnen Entwickler den Überblick zu bewahren. Und es ist schwer verständlich für andere Entwickler die vielleicht mal in das Projekt einsteigen wollen.
Insofern jetzt der klassische Ansatz den jeder Browsergame-Programmierer versteht.
Aber es mussten ja nicht nur die Tabellen der Datenbank umgeschrieben werden sondern auch die zugehörigen Model-Klassen. Außerdem mussten fast alle bereits implementierten Funktionen (Techtree, Flottenzusammenstellung, Handelsangebote) nochmal angefasst werden. Also das war schon eine Menge Arbeit.
Ich kann noch nicht mal behaupten, dass das wirklich schon 100% abgeschlossen ist. Hier und da stoße ich noch auf Probleme die mit dieser Umstellung zusammen hängen, wobei die Lösung mittlerweil recht einfach ist, da ich genau weiß wie ich es haben möchte! (das war auch nicht immer so 😉

Beim Techtree habe ich optisch nichts verändert. Bei der Flottenzusammenstellung jedoch habe ich die Oberfläche in diesem Zusammenhang komplett überarbeitet. Es ging dabei vor allem um eine Vereinfachung und die Möglichkeit auch auf kleinen Bildschirmen (Smartphones, Tablets) gut bedienen zu können.

Einführung von Aktionspunkten

Das war der zweite ganz große Umbau in diesem Jahr. Es gab so ein Gefühl in mir das irgendetwas an dem Spiel noch nicht stimmte aber ich wusste nicht was. Irgendwo fehlte einfach etwas.
Dann machte ich zusammen mit meinem besten Freund ein Brainstorming und heraus kam die Idee der Aktionspunkte. Personal gibt Aktionspunkte pro Tick. So wird neben dem statischen Supply auch eine dynamische Ressource eingesetzt. Es fühlt sich jedenfalls richtig an. Bei rundenbasierten Brettspiele ist der Einsatz von Aktionspunkten ja auch gang und gebe. Und ich glaube hier konnte ich eine große Lücke im Spieldesign schließen. Nach der Idee der Einführung der Aktionspunkte sprudelten die Ideen was man damit anfangen könnte nur so über. Ich bin jedenfalls schwer begeistert und denke dass da in Zukunft noch einiges kommen wird was ich dann genauer erklären kann.

Sonstiges

Neben diesen großen Umbauten gab es noch kleinere Baustellen und Experimente

  • Migration vom Frontend-Framework Bootstrap 2 zu Bootstrap 3
  • Update der verwendeten JQuery-Version
  • Behaviour Tests mit Behat [experimentell]
  • Kontaktaufnahme mit einem Texter der vielversprechend war, aber leider ist der Kontakt wieder ohne Ergebnisse abgebrochen

Phase 2: Dezember 2013 – Anfang Januar

Hier passierte nichts! Nicht weil ich nicht wollte, sondern weil daran gehindert wurde:
Zum einen hatte ich über einen Zeitraum von mehr als 2 Wochen kein Inet und zum anderen gab meine Festplatte den Geist auf und musste ersetzt werden. Ich hatte also eine neue Platte ohne die Tools die ich zum programmieren brauchte und kein Inet um mir die Tools zu besorgen aber ich hatte ganz viel Zeit die ich sonst nicht habe …
Scheiß Kombination >:-/

Phase 3:

Im Januar konnte ich dann wieder anfangen und habe erstmal die Umstellung auf Bootstrap 3 und JQuery-Update fertig gemacht. Dann war erstmal alles auf einen guten Stand und ich wollte mich daran machen die Aktionspunkte auch bei Flottenbewegungen zu implementieren. Nach längerem Überlegen bin ich zu dem Schluss gekommen, dass die momentane Karte nicht gut ist: alles viel zu klein und fummelig – außerdem nicht ansatzweise auf mobilen Geräten tauglich. Also Flottenbewegungen erstmal nach hinten verschoben. Jetzt muss erstmal eine neue Karte her…

Phase 4:

… und weils sonst langweilig wird, ist daraus ein eigenes Projekt entstanden. Naja es gab gute Gründe dafür:

  • ich will mehr SVG einsetzen und mit den aktuellen Browsern ist das nicht mehr so ein Krampf wie früher
  • ich will meine Javascript/JQuery/Ajax-Skills trainieren
  • ich will Teile meines Browsergames wiederverwertbar machen… so eine Karte kann man auch leicht in andere Browsergames einbauen
  • ich will damit die Einstiegshürde für Entwickler die mir evtl. helfen wollen verringern, da bei diesem Projekt keine Einarbeitungszeit in das komplexe Zend Framework 2 nötig ist
  • und nicht zuletzt: eine Referenz mehr auf GitHub 😉

Das Projekt heißt momentan ‚Nouron Galaxy Map‘ (Name kann und wird sich wohl noch ändern) und ist unter https://github.com/tector/ngm erreichbar.
Ich würde es auf dem aktuellen Stand noch niemandem empfehlen produktiv einzusetzen! Aber ich werde weiter dran arbeiten, dass das irgendwann mal der Fall ist.

Jedenfalls bin ich seit ein paar Wochen wieder deutlich aktiver und öfter am programmieren. Vielen Dank auch an @xBlackScorpx für die zusätzlich Motivation 🙂

BlackScorp hat mich auch auf das Tool Scrutinizer.com gestoßen, mit dem man leicht die CodeQualität seines Projekts überprüfen kann – was auch sehr motiviert diese zu verbessern. Tja, da ist mir erstmal aufgefallen an wievielen Stellen im Code man deutlich erkennen kann, dass ich meine Arbeit mittendrin aufgrund von Zeitmangel eingestellt habe und dann vergessen habe.. Solche Probleme versuche ich derzeit zu fixen. Und in diesem Zusammenhang schreibe ich nun auch wieder vermehrt Unittests. In der alten Version mit ZF1 hatte ich schon einiges an Unittests zusammengetragen und eine Code Coverage von ca. 75%. Das ist jetzt nicht mehr der Fall.. ich würde gerne wieder da hin kommen… momentan sind es aber gerademal 20%.

So das war doch jetzt mal ein sehr ausführlicher Blogpost 😉 Entschuldigt evtl. Rechtschreib/Grammatikfehler.. ich werde sie nachträglich beseitigen sollten mir welche auffallen aber jetzt wollte ich den Post endlich mal fertig stellen und nicht weiter verzögern. Deshalb leider auch NUR Text und keine Bilder… ich bin leider kein guter Blogger 😦

Abschließend möchte ich noch betonen, dass ich mich wie immer über jede Form von Feedback freue!
Folgt Nouron auch auf Twitter, Facebook und Google+
Vielen Dank und bis zum nächsten Mal! Have Fun!

Nouron – Stand: Juli 2013

Hallo verehrter Blogbesucher und alle Interessierten! Ich habe diesen Post fürs Wochenende versprochen und.. nunja.. es ist ja noch nicht ganz vorbei 😉 Es ist schon wieder zu lange her, dass ich etwas zum aktuellen Stand von Nouron geschrieben habe. Das möchte ich hiermit nachholen: Was hat sich bei Nouron getan?

Aktionspunkte
Das ist wirklich ein großes Thema! Aktionspunkte (kurz: AP) kamen im Rahmen einer ‚Brainstorming-Session‘ mit meinem Kumpel ins Gespräch und lassen mich seitdem nicht mehr in Ruhe! Wie ich bereits einmal twitterte schießen mir ständig tolle Ideen vor allem im Zusammenhang mit Aktionspunkten in den Kopf. Ich habe das Gefühl, dass man mit Aktionspunkten das ganze Spiel vielseitiger und interessanter machen kann. Vor allem vermeide ich damit auch etwas Leerlauf gerade für Neueinsteiger, weil es etwas mehr Klicks benötigt und man dann nicht so stark das Gefühl bekommt am Anfang wenig machen zu können. Andererseits muss ich aber aufpassen damit nicht gegen das Grundkonzept ‚wenig Klickaufwand‘ zu verstoßen – aber solange man nicht jeden Aktionspunkt einzeln klicken muss werde ich das schon in Einklang bringen können.

Ich wundere mich selbst, dass ich bei einem quasi rundenbasierten Spiel – wo Aktionspunkte ja nichts unübliches sind – nicht von vornherein die Möglichkeit von Aktionspunkten bedacht habe. Man kann damit viel flexibler agieren z.B. beim Bau von Gebäuden indem man den Bau auch unterbrechen oder die Fertigstellung verschiedener Gebäude allein durch die richtige Verteilung von AP synchronisieren kann. Aber wie soll das Ganze überhaupt funktionieren?
Zunächst einmal ergänzen sich das Versorgungssystem (=Supply) und die Aktionspunkte wunderbar! Denn nun kommt zu den statisch investierten Versorgungspunkten (konstant verbraucht pro Tick) die dynamisch einsetzbaren AP (stehen pro Tick erneut zur Verfügung). Hier kommen dann auch die Berater bzw. Personal ins Spiel: um Personal zu bekommen investiert man Versorgungspunkte (=VP bzw. Supply) und bekommt dafür AP. Je nachdem in welches Personal man VP investiert bekommt man unterschiedliche Arten von AP (BauAP, ForschungsAP, HandelsAP, FlottenAP, DiplomatieAP). Diese wiederum braucht man um Gebäude oder Forschungen fertigzustellen (neben den benötigten Ressourcen), Verträge zu schließen oder Gesetze zu entwerfen. Und so weiter, und so fort… Ich hoffe ich kann ansatzweise verdeutlichen wieviel Potential da drin steckt. Hoffe es wird nicht zu kompliziert… die nächste Brainstorming-Session ist bereits geplant 😉

Unittests

Ein heikles Thema aus der technischen Ecke! Info für alle Nichtprogrammierer: Es geht darum den geschriebenen Code mit automatisierten Tests abzudecken um die Codequalität und -zuverlässigkeit zu erhöhen und die Wartbarkeit zu erleichtern. Vor der Umstellung auf das Zend Framework 2 hatte ich mit der alten Version eine recht gut Testabdeckung des Quellcodes von über 70%. Mit dem ZF2 habe ich lange gebraucht überhaupt die Testfunktionalität zur verfügbar zu machen. Dies ist mir nun aber gelungen und ich werde langsam aber sicher mehr und mehr Tests hinzufügen.

Flottenmanagment
Nachdem ich mit der Art und Weise wie die Flotten zusammengestellt werden irgendwie nicht zufrieden war, habe ich diesen Teil nochmal komplett überarbeitet und radikal vereinfacht. Das ging eigentlich ziemlich gut und ich bin ganz zufrieden damit. Jetzt sollte das auch auf mobilen Geräten ganz gut funktionieren – habe es aber noch nicht getestet.

Handel (insbesondere Gebote einstellen)
Die Handelskomponente ist jetzt erstmal die letzte dringende Kernkomponente die ich von der alten Version auf die neue portieren muss. Dann wären Techtree, Galaxie, Flotten und Handel grob fertig – und fast ein spielbarer Status erreicht (naja ‚fast‘). Am Anfang ging das mit dem Handel auch ganz gut: Suchform, Angebotsform, Tabellarische Übersicht, Seitennavigation.. Aber irgendwas hindert mich daran die Funktion zum ’neues Angebot erstellen‘ fertigzustellen. Es ist ziemlich komplex, da hier sowohl (Zend) Formularkomponente, Validierung, Formatierung/Fehlerausgabe, Datenbank (zum abspeichern) und dieser ganze Ajax-Mist mit reinspielen. Das ist schon heftig für eine eigentlich doch so simple Funktion… Aber ich bleibe dran und das wird schon noch werden! 🙂

neuer Texter
Ich habe jemanden kennengelernt, der als begeisterter Rollenspieler sehr viel Lust hat in Zukunft für Nouron die Story, Beschreibungen, Charaktere etc. zu entwerfen. Bin gespannt was die Zukunft bringt… Mehr dazu bald.

Was steht als nächstes auf dem Plan?
Ich muss jetzt erstmal weiter an den neuen Aktionspunkten arbeiten – was hier und da leider wieder Umbauten erfordert. Bin aber trotzdem ganz zuversichtlich, dass das relativ problemlos laufen wird. Weiterhin versuche ich demnächst die Ajax-Funktionen in den Griff zu kriegen und einheitlich zu gestalten… (z.B. beim Gebäude bauen oder Handelsgebot einstellen).
Javascript und vor allem Ajax sind wirklich nicht mein Ding – aber es muss ja leider sein in der heutigen Zeit… Desweiteren werde ich parallel mehr und mehr Unittests schreiben um den bestehenden Code abzudecken. Mehr möchte ich erstmal nicht vorausplanen. Wenn ich das Entwicklungtempo der Vergangenheit als Schätzungsgrundlage nehme werden diese Dinge wohl wieder einige Monate in Anspruch nehmen (da ich meist nur am Wochenende Zeit für Nouron habe). Bis dahin gibt es dann natürlich wieder Updates per Twitter, Facebook, Google+ und natürlich hier im Blog. Bitte unterstützt das Projekt indem ihr folgt, kommentiert, teilt und/oder liked… Vielen Dank und bis bald!

Flottenmanagement in Nouron

Ich habe hier im Blog schon über die Flottenbewegungen geschrieben, aber noch nicht über die Flotten selbst. Ich möchte hier nun etwas auf das Flottenmanagement in Nouron eingehen. Aber zunächst möchte ich noch einmal auf eine technische Besonderheit aufmerksam machen:

Im Techtree von Nouron gibt es vier Kategorien: Gebäude, Forschungen, Schiffe und Berater. Diese Objekte laufen alle unter dem Namen ‚Technologie‘ – ja, auch Berater sind aus technischer Sicht Technologien 🙂 Jede Technologie hat neben der Kategorie (Typ) auch einen Zweck, wie z.B. Zivil, Wirtschaft, Militär etc. (evtl. wird es pro Technologie auch mehr als ein Zweck geben). Zudem haben Technologien ein Attribut welches sie als handelbar auszeichnet oder eben nicht. Ich spiele durchaus mit dem Gedanken auch Gebäude handelbar zu machen – aber da ist ebenso noch nichts in Stein gemeißelt.

Was ist nun eine Flotte?

Eine Flotte ist ein Verbund von Raumschiffen, also Technologien der Kategorie ‚Schiff‘. Weiterhin benötigt eine Flotte Crew-Mitglieder, also Technologien der Kategorie ‚Berater‘. (‚Berater‘ ist vielleicht nicht das optimale Wort, das wird evtl. noch geändert) Optional kann eine Flotte Fracht in Form von Passagieren (=Berater), Technologien (Gebäude, Forschungen, evtl. kleine Schiffe/Satelliten/Drohnen) und Ressourcen zugewiesen bekommen. Man muss sich also nicht pro Schiff um die Einzelheiten kümmern, sondern um die Flotte als Ganzes.
Ein einzelnes Schiff ist technisch gesehen zwangsläufig eine eigene Flotte.

Was wird es nicht geben?

Es wird keine individuellen, aus Modulen bestehenden Raumschiffe geben. Ich weiß, dass das ein tolles Feature wäre was viele vermissen werden. Aber ich werde darauf verzichten um das Spiel nicht zu komplex in diesem Bereich werden zu lassen. Der Schwerpunkt von Nouron liegt ja woanders. Andererseits ist diese Entscheidung nicht fest in Stein gemeißelt und ich werde sobald das Spiel mal einen stabilen, spielbaren Status hat nochmal über diese Möglichkeit nachdenken.

Welche Schiffstypen gibt es?

Ich unterscheide in zivile und militärische Schiffe. Momentan sind bei den zivilen Schiffen kleine, mittlere und große sowie Personen- Transporter geplant – und ach ja: das Kolonieschiff. Bei den militärischen Schiffe sind es Jäger, Fregatten und Kreuzer. Ja, das sind nicht so viele Typen bisher aber wie schon erwähnt: Schwerpunkt und so. Dennoch gibt es gewisse Schiffstypen die ich evtl. noch gerne einbauen würden. Z.B. ein Spionageschiff das über Tarnung verfügt, ein Forschungsschiff (ermöglicht Handel mit Forschungen) oder ein Konstruktionsschiff (Handel von Gebäuden).
Aber das sind alles Dinge die später eingebaut werden können wenn mal das Grundgerüst steht.
Jeder Schiffstyp hat unterschiedliche Ausprägungen von Schiffsattributen, u.a. Geschwindigkeit (verfügbare Aktionspunkte pro Tick), Frachtraum

Flottenbefehle

Flottenbefehle die in der ersten spielbaren Version möglich sein sollen sind ‚erstellen‘, ‚auflösen‘, ‚bewegen‘ und ‚angreifen‘. Später sollen dann Befehle wie ‚joinen‘, ’stationieren‘ und ‚eskortieren‘ möglich sein.

Was ist momentan noch problematisch?

Es ist noch ungeklärt wie der Zustand der Flotte bzw. der einzelnen Schiffe technisch umgesetzt wird. Technologien altern prinzipiell was den Zustand senkt. Bei Gebäuden äußert sich das in dem der Level sinken kann wenn man den Zustand durch Reparatur nicht verbessert. Wenn Schiffe einer Flotte zugewiesen sind (und nicht der Kolonie) funktioniert das momentan noch nicht. Hierbei wird zwangsläufig auch der Zustand unterschiedlich werden. Das ist problematisch und bedarf noch einer Lösung.

So das war es zu dem Thema erstmal. Hoffe ich habs nix vergessen. Wenn ihr noch Fragen oder Feedback/Anregungen habt nutzt bitte die Kommentarfunktion! Bis dann, have fun!

Nouron – Stand: Januar 2013

Hey Hey Hey!
Mit Nouron gehts voran! Ich weiß: ich bin mal wieder einen längeren Post schuldig… Hier eine Kurzübersicht zum aktuellen Stand:

Ich hab mich soweit in ZF2 eingearbeitet und bin nun dabei den alten ZF1-Code auf ZF2 zu portieren und ggf. zu verbessern. Techtree ist grob fertig und ich arbeite grad an der Galaxie- und Systemansicht. Es ist alles sehr aufwendig und die meisten bereits vorhandenen Funktionen der alten Version müssen überarbeitet werden – aber es wird sich lohnen! Das Datenbank-Schema wird zum Teil gleich mit überarbeitet – war zwar nicht geplant, ist aber ein guter Zeitpunkt und macht jetzt nicht den großen Unterschied,  vom Aufwand her (goodbye ‚ungarische Notation‚!)

Die Portalseite habe ich komplett überarbeitet: sie ist weiterhin per Kurz-Url über http://www.nouron.de.vu erreichbar sie ist unter der Domain http://www.nouron.de erreichbar. Ich empfehle aber den Aufruf der direkten Url: http://nouron.github.io/nouron (ja die Portalseite nutzt GitHub-Pages).

Apropos GitHub: Nouron kann man jetzt auf GitHub finden, folgen und clonen: https://github.com/nouron/nouron. Es steht jetzt unter OpenSource zur Verfügung!

Ich experimentiere in den letzten Wochen und Monaten auch viel mit Social Media (wie man vielleicht auch schon hier im Blog erkennen kann). Es gibt bereits eine Page für Nouron auf Facebook und auch Google+, allerdings sind sie noch nicht freigeschaltet (Updates dazu folgen wenn es soweit ist).

Freigeschaltet ist aber der Twitter-Account: Ihr könnt Nouron nun auf Twitter unter dem Account @_nouron finden und folgen! (Ihr könnt auch meinem privaten Twitter-Account @_tector folgen wenn ihr wollt 😀 )

Auf Twitter werde ich sehr viel öfter Updates posten als hier im Blog, versprochen!

Also nochmal kurz die Möglichkeiten aufgelistet wie ihr Nouron unterstützen könnt und immer auf dem aktuellsten Stand bleibt:

Nouron: Mai 2012 (2) – Ein Achievementsystem für Nouron

… auch wenn sie schon lange nix neues mehr sind: Meiner Meinung nach sind Achievements toll! Sie bereichern Spiele um eine weitere Komponente zum kompetitiven Vergleich zwischen Spielern.. Sonst gibt es ja nur diverse Highscorelisten.

Das tolle an Achievements ist, dass die Motivation vieler Spieler dadurch erhöht werden kann. Ich sprech da etwas aus Erfahrung.. so ist es durchaus schon vorgekommen, dass ich Spiele nur nochmal wegen bestimmter Achievements angespielt habe. Es gibt natürlich auch Spieler denen Achievements scheißegal sind. Trotzdem ist diese Art der „Belohnung“ im Allgemeinen natürlich spieltriebfördernd.

Aus Programmierersicht sind Achievements auch toll: Sie sind – wenn die Basis stimmt – mit relativ wenig Aufwand erstellbar und können jederzeit erweitert werden.

Der Einbau eines Achievementsystem in Nouron (und damit verbunden ein grundlegendes Eventsytem) brennt mir schon länger unter den Fingernägeln. Weiterlesen

Nouron: Mai 2012 (1)

Lange, lange ist es her, dass ich in diesem Blog über mein Browsergame Nouron geschrieben habe und der Verdacht liegt nahe, dass das Projekt eingeschlafen ist. Nun.. so ganz stimmt das nicht.

Auch wenn im letzten Jahr wirklich wenig passiert ist in Sachen Nouron – von Zeit zu Zeit habe ich doch etwas dran gearbeitet. Es gab einen groben Fehler im Game-Design der behoben werden musste – und das war nicht so unproblematisch:

Bislang gab es nur Ressourcen pro Kolonie aber keine Ressourcen für Spieler. Dies war insbesondere schlechtes Design, da die Ressourcen Supply und vor allem Credits natürlich auf den Spieler bezogene Ressourcen sind.

Ich habe dieses Problem lange Zeit unterschätzt und auch etwas ignoriert, weil ich fälschlich annahm es sei kein großes Problem. Aber die Behebung des Problems erwies sich als äußerst kompliziert weil es schon zu tief im Code verwurzelt war. Zum Glück ist das nun aber erledigt. Es gibt nun eine saubere Trennung zwischen Spielerresourcen und Kolonieressourcen.

Außerdem habe ich mich mit der Implementation von Achievements beschäftigt, aber dazu folgt in Kürze ein eigener ausführlicher Blog-Eintrag.

Stand Dezember 2010: Flottenbewegungen

Bevor ich es vor Weihnachten doch noch komplett vergesse hier der versprochene Post ^^.

Wie bereits geschrieben habe ich vor kurzem wieder verstärkt an Nouron gearbeitet. Vor allem noch am neuen Galaxiesystem und den Flottenbewegungen.

Ich habe dabei ein paar Entscheidungen getroffen: um in etwas schneller voran zu kommen habe ich ein paar geplante Features in beiden Systemen erstmal auf Eis gelegt. Es handelt sich dabei um die Handelsrouten und Sternstraßen sowie der damit verbundenen komplizierten Wegberechnung bei Flottenbewegungen. Diese Features werden also vorerst nicht implementiert – ich behalte sie jedoch im Hinterkopf und werde sie noch in Angriff nehmen, sobald eine halbwegs ausgereifte, spielbare Spielversion fertiggestellt ist. Weiterlesen

Browsergame-Design: The Dos and Don’ts #3 Klickaufwand

In dieser kleinen Serie geht es um kleine und große Unannehmlichkeiten von Browsergames. Fehler im Design oder der Umsetzung. Absichtlich oder unabsichtlich. Wie man User abschreckt oder bindet. In Teil 3 geht es um die oft zu hohe Anzahl benötigter Mausklicks…

Klickaufwand

In einem Browsergame muss der Entwickler darauf achten auf der einen Seite nicht zu viele Klicks vom Spieler zu verlangen, andererseits aber auch nicht zu wenig (sonst hat der Spieler nichts zu tun – oder zumindest das Gefühl). Zum Beispiel ist eine Bestätigungsseite für eine Aktion wie z.B. „Flottenbewegung wurde gestartet“ auf der man einfach nur auf Ok/Weiter klickt überflüssig und kann auf Dauer extrem nerven. Das ist z.B. beim BG Revorix ein großes (bekanntes) Problem um das sich aber auch seit Jahren nicht wirklich gekümmert wird (bin zwar nicht auf dem neuesten Stand, glaube aber nicht dass es sich geändert hat.)

Beispiel Streetcrime:
Bei Streetcrime muss man sehr oft andere Spieler angreifen. Dazu klickt man auf die „Spieler online“ Liste und klickt jeden einzelnen verfügbaren Spieler an um dann auf der nächsten Seite erst zu sehen ob man ihn wirklich angreifen kann oder nicht. Dann erst kommt der Klick auf Angriff und dann kommt die Bestätigungsseite die man wegklickt. Der geübte Spieler nutzt deshalb schon die rechte Maustaste -> „In neuem Tab öffnen“-Funktion um nicht ständig hin und herwechseln zu müssen zwischen Liste und Spieler. Die geöffneten Tabs muss man dann aber auch wieder schließen – was wieder Klicks sind.  Das ist ständig die selbe Mechanik die einem auf Dauer echt auf den Keks gehen kann…

Ein weiteres Beispiel – Wewaii:
Am linken Bildschirmrand ist eine Liste mit allen Gebäuden und deren Zustand zu sehen. Klickt man eines an kommt am unteren Bildschirmrand eine Box wo man auf „Reparieren“ klicken kann. Das Problem: Meist will man mehrere Gebäude reparieren, also wiederholt sich folgendes Schema:

  • Linksklick auf Gebäude am linken Rand,
  • Mausbewegung nach unten,
  • Klick auf Reparieren,
  • Maus nach links Mitte,
  • Klick auf Gebäude,
  • Maus nach unten,
  • Klick auf reparieren,
  • Maus nach links Mitte,
  • … usw.

Viele Spieler scheinen diese Tortur hinzunehmen, aber irgendwann wird es auch sie langweilen immer die gleichen Schemata durchzuführen. Der Weg mit der Maus vom Bildschirmrand links nach unten ist auf Dauer echt nervig. Warum gibt es kein „Reparieren“-Icon für jeden Eintrag direkt in der Liste?

So ich denke das waren genug Beispiele.
Wichtig ist vor allem, dass man keine unnötigen Bestätigungseiten oder Popups zum Wegklicken einbaut: also kein „Flottenbewegung wurde gestartet – Ok“-Dialog oder ähnliches.

Browsergame-Design: The Dos and Don’ts #1 Login

In dieser kleinen Serie geht es um kleine und große Unannehmlichkeiten von Browsergames. Fehler im Design oder der Umsetzung. Absichtlich oder unabsichtlich. Wie man User abschreckt oder bindet. Teil 1 beschäftigt sich mit dem Login-Formular.

Das Login-Formular

Der Login in ein Browsergame ist essentiell! Es ist die Aktion die vom Spieler oft mehrmals täglich ausgeführt werden muss, von der er aber eigentlich im Spiel selbst nichts hat. Insofern möchte der Spieler die lästige Pflicht möglichst schnell hinter sich bringen: Username und Passwort sollten (sofern man dies wünscht) automatisch ausgefüllt werden und man braucht nur noch auf Login zu klicken oder Enter drücken. Wenn man den Opera-Browser benutzt kann man hierfür auch die überaus nützliche Mausgestenfunktion benutzen – wenn, ja wenn, der Login damit klarkommt… (Anm.: Ich gehe nur auf Firefox- und Opera-Browser ein. Ich benutze kein IE oder Chrome. Erfahrungen mit diesen Browsern könnt ihr gerne in den Kommentaren kundtun.)

– Beispiel Ikariam:
Beim Login muss neben Username und Passwort auch die Spielwelt per Select-Box ausgewählt werden. Operas Mausgeste kann erst nach Auswählen der Spielwelt für den Login benutzt werden. (mindestens drei Klicks sind nötig: Selectbox anklicken, Welt auswählen, Login-Klick oder Mausgeste oder Enter)
Auch der Firefox kann es nicht besser: Username und Passwort-Feld werden zwar vorausgefüllt – die Welt muss aber manuell ausgewählt werden. Also auch drei Klicks.

– Beispiel Xhodon:
Unter Opera geht der Login nicht mit dem Passwortmanager (Strg+Enter). Die Mausgeste funktioniert nicht. Mühevolles eintippen von Username und Passwort ist nötig. Beim Firefox gehts mit einem Klick. Xhodon hat ein anderes Problem: Nach dem Logout kommt man nicht auf die gleiche Login-Seite zurück. Der Passwortmanager des Browsers erkennt die Loginseite also nicht.
Was Xhodon gut macht: Wenn man nur in einer Welt angemeldet ist muss man die Welt nicht extra auswählen beim Login – sie wird automatisch erkannt! Lobenswert!

– Beispiel Streetcrime:
Beim Login gibt es ein Häkchen „Merken“. Username und Passwort-Feld werden beim nächsten Login dann vorgefüllt. Passwortmanager geht in Opera und Firefox problemlos. Operas Mausgeste geht auch. Bleibt abzuwarten wie evtl. später mehrere Welten gemanaged werden…

– Beispiel Wewaii:
Da Wewaii weitgehend auf Flash setzt muss zumindest das Passwort beim Login immer per Hand eingegeben werden. Passwortmanager und Mausgesten helfen einem hier nicht weiter – Schade 😦
Von der Wewaii-Startseite muss man erstmal die Spielwelt auswählen bevor es zum Login geht. Es gibt für jede Spielwelt eine eigene Subdomain. Wenn man sich die Url abspeichert kommt man auch direkt auf die Login-Seite der Login-Screen (langsam) geladen wird.

Lösungsmöglichkeiten:

Cookies könnten eingesetzt werden um die zuletzt ausgewählte Spielwelt zu speichern. Ich weiß nicht warum das in der Regel nicht gemacht wird; liegt vielleicht daran dass Cookies nicht so beliebt sind und es etwas unseriös wirken könnte diese bereits vor dem eigentlich Login zu benutzen.
Kürzlich habe ich so genannte „Greasemonkey“-Scripts entdeckt. Eigentlich ist Greasemonkey ein Addon für Firefox, dass es dem User ermöglicht eigene Javascript-Dateien zu benutzen um Webseiten bei der Anzeige im eigenen Browser zu verändern. Die Javascripte funktionieren aber oft auch mit dem Opera-Browser (nativ, ohne Plugin). Mit solchen Scripten kann man zum Beispiel den Login automatisieren. ABER Vorsicht! Es gibt Scripts die laut Spielregeln in BGs verboten sind und können bei Verwendung zur Sperrung des Accounts führen. Ein Login-Script sollte meiner Meinung nach jedoch ok sein – wenn schon die Betreiber keine einfache Möglichkeit anbieten…

So das war Teil 1. Würde mich sehr über Kommentare und Kritiken freuen. Evtl. habt ihr auch Anregungen/Ergänzungen die ich noch mit aufnehmen kann.

MfG tector