Dynamische Tutorials

Morgen

Ich habe mir die Tage mal ein paar gedanken zum Thema Tutorial gemacht und bin bei verschiedenen möglichkeiten gelandet.

Einfaches Texttutorial -> in meinen Augen nett anzusehen aber wirklich lesen tuts eh keiner...zumindest ich hab mir noch keins wirklich durchgelesen

Audio/Video Tutorial -> in meinen Augen etwas "to much", außerdem hab ich niemanden zur Hand der das machen würde.

Interaktives Tutorial -> Ist in meinen Augen die effektivste Möglichkeit dem Spieler Wissen über das Spiel beizubringen.

Nur bei der Umsetztung happerts noch ein wenig. Meine Idee ist das ich eine Tabelle mit allen Tutorialtexten habe und zusätzlich noch bedingen ala Key -> Value, also was muss erfült um diesen Schritt zu schafen.

In der User Tabelle kommt dann einfach ne spalte rein mit dem Akutellen Tutorialschritt.

So weit so gut...

Zum Glück kennt Ruby wie andere Sprachen auch so nette Sachen wie eval oder call. Wodurch ich entsprechende Datenbankwerte Interpretieren kann.

Der Punkt wo es bei mir im mom noch hackt ist. Wie speicher ich die Bedingungen für den nächsten Schritt in der Datenbank ohne das ich nachher Datenbank generierten Code bekomme.

Bis jetzt habe ich es so gelöst das, ich den Key aus der Tabelle mit call aus den userdaten hole und dann mit value vergleiche. Aber das ist wie ich finde doch etwas sehr mager...

Hat hier jemand Idee oder schon Erfahrung mit Dynamischen Tutorials?

Mfg Nerosmeel

Schau dir einmal das Tutorial vom Postgame.de an, ob das das trifft, was du unter Dynamisches Tutorial verstehst?

Jap so in der Art würde ich das auch gerne machen

Ich habe dabei komplett auf den Server/Datenbank part verzichtet, das Tutorial läuft komplett im Client ab ohne Serverkommunikation. Hat aber ein großen nachteil, dass ich teilweise den Code der die Spielaktionen ausführt nochmal im Tutorial emulieren musste. Also z.B. damit eine Nachricht beim Spieler ankommt, musst ich halt neuen Code schreiben der eine Nachricht manuell generiert und dem Spielerobjekt zuordnet und konnte nicht auf meinen Serverpart zurückgreifen.

Das Postgame-Tutorial läuft bei mir spontan nicht, daher kann ich jetzt nicht genau wissen, was du suchst. Allerdings ist es doch relativ "einfach", ein entsprechendes "Regelwerk" eiens mir üblichen Verständnisses eines Tutorials/Expertensystem (nein, ist es nicht, aber es erinnert in der Struktur ja ein bisschen dran) aufzubauen. Ob man nun die Einheiten/Kapitel nur grob aufteilt, oder in Unterbereiche ist hierfür egal; der eigentliche Clou für die Dynamik wäre eine Relation mit n Regeln pro Aufgabe/Kapitel. Da kommt es natürlich drauf an, was man benötigt: Reicht nur Erfolg/Misserfolg (zwei Regeln? Die Regel Misserfolg könnte ja auch schleifenartig auf die gleiche Aufgabe zeigen.), oder detaillierte wie nach Antworten, nach einer Quantifizierung (8/10 von irgendwas).. geeignet strukturiert könnte man so sogar mehrere Tutorials mit teilweise überschneidenden Aufgaben erstellen.

Bei Financial-Rumors habe ich das so gemacht, dass ich an den Stellen in den Controllers, an denen eine Aufgabe erfüllt sein könnte, eine Funktion im User-Object aufrufe und diese Funktion prüft dann, ob der Spieler dieses Kapitel gerade erfüllen muste, dieses erfüllt hat, und wenn dem so ist, eine Entsprechende Nachricht generiert und den Tutorial-Kontext weiter schaltet.

 def next_tutorial_lesson lesson, company
  if !option?(:tutorial_off) && tutorial_context == TUTORIAL_LESSONS[lesson] && check_special_tutorial_trigger(lesson, company)
  next_tutorial_step company
  return true
  end
 
  false
 end

Warum möchtest Du Quellcode in der Datenbank ablegen? Ich lege den in Datei ab.

von möchten kann keine rede sein ^^

es ging mir nur darum das ich die bedienungen bei Bedarf überarbeiten kann ohne im Code zum zu bauen...

im grunde pure Faultheit...

Die Idee mit den Controllern hört sich gut an so in der richtung werd ichs wohl auch machen.

Wo ist den Deiner Meinung nach der Unterschied, ob Du den Code in der Datenbank, oder in einer Datei änderst?

in der Datenbank ist es schnelelr zu ändern ^^

Sorry, aber wieso ist das schneller zu ändern?

Da musst du mit SQL (oder phpmyadmin) rumhampeln, während du den Code bequem z.B. in VI bearbeiten kannst.

Original von Kampfhoernchen

Sorry, aber wieso ist das schneller zu ändern?

Da musst du mit SQL (oder phpmyadmin) rumhampeln, während du den Code bequem z.B. in VI bearbeiten kannst.

Man spart sich das FTP-Programm. Aber das ist alles denke ich Geschmackssache und Gewohnheit.

jop es ist geschmackssache ^^

Ich nutze Navicat und damit ist das nunmal schneller zu ändern als immer per FTP was hochzuladen oder per vi zu ändern..meine Meinung

Original von rami95

Original von Kampfhoernchen

Sorry, aber wieso ist das schneller zu ändern?

Da musst du mit SQL (oder phpmyadmin) rumhampeln, während du den Code bequem z.B. in VI bearbeiten kannst.

Man spart sich das FTP-Programm. Aber das ist alles denke ich Geschmackssache und Gewohnheit.

Dann würde ich den gesammten Quellcode des Spiels in der Datenbank ablegen. Als Datei müste dann nur noch ein kleiner "Boot"-loader vorhanden sein.

Dann würde ich den gesammten Quellcode des Spiels in der Datenbank ablegen. Als Datei müste dann nur noch ein kleiner "Boot"-loader vorhanden sein.

Das war doch jetzt (hoffentlich) pure Ironie?  

Nur, wenn das mit dem FTP auch ironisch gemeint war! Ansonsten behaare ich darauf, dass ich gerade den Stein der Weisen gefunden habe!!!11elf!

Wenn du keine Lust auf FTP hast, leg ich dir VCS ans Herz. Wir nutzen bei all unseren Projekten git.

Bei mir läuft auf dem Server ein Subversion Client. Die neue Version bekommt ein eigenes Tag und mit "svn switch" wird dann die neue Software installiert. Das nette daran ist, dass geänderte Konfigurationsdateien ihre Änderungen behalten und das auch nur die Dateien vom Subversion-Server geholt werden, die sich zwischen den beiden Versionen geändert haben.

Jetzt frage ich mich, wie man FTP mit einem VCS vergleichen kann? Wo ist die Schnittmenge? Das ist das totale Chaos, das andere ist ein Repository. :)

Samba-Server ... Webdav ... Problem gelöst.