Das ist natürlich richtig, ich wüsste jetzt aber kein Spiel, bei dem man unbedingt 10 Küsse für eine Quest erhalten muss? Es ging in dem Beispiel ja explizit um eine Spiele App – und nicht um eine Systemquest. Fakt ist allerdings, dass eine Quest die nicht alleine zu bewerkstelligen ist für Unzufriedenheit in der Userschaft führt. Daher wäre es meiner Meinung nach schon sinnvoll, wenn man bei neuen Quests auch einfach auf die Qualität und Zufriedenheit der User achtet. Dies soll nun nicht unschlagbar schwere Hürden für die Entwickler darstellen, nur macht das aus meiner Sicht einfach mehr Sinn.
Quest Kussmonster:
(Ich wollts nur mal erwähnt haben ;))
Selbst die "Giese Blumen anderer Nutzer"-Quest sind ebenfalls eine Spielerei und dennoch auch eine Quest, die man nicht alleine abschließen kann.
Man kann auch andere Dinge mit Erfolgen versehen. Es ist herausfordernder, aber durchaus möglich.
Das Beste um es dem Entwickler leicht zu machen, ist eine einfache Anforderung an zwei oder drei Parameter, die bei der jeweiligen App dann abgefragt werden können, so wie "mayJoinChannel" dies bereits handhabt.
Da wird auch eine Rückmeldung der App berücksichtigt ob etwas "erlaubt/geschafft/erreicht" wird was vorausgesetzt wird.
Mein Vorschlag ist es eher einfache Funktionen bereitstellen für das Questsystem:
- In wie vielen Schritten kann die Quest abgeschlossen werden einfache Zahl von 1-100 (für die Prozentanzeige im QuestSystem)
- Eine fixe Funktion in die in der App vorausgesetzt wird um den Queststatus zu aktualisieren um als gültige Quest für das gesamte System anerkannt zu werden, bei Aufruf sollte sie den Wert des Nutzers einfach um 1 erhöhen bis hin zum Erfolg.
- Die Konfigurationsparamter in der app.config die ich vorher erwähnt hatte.
- +Questbeschreibung und Titel der Quest sowie eine Liste der Punkte im Plaintext welche benötigt werden
Genauso kann man im System an sich prüfen, ob eine Quest oft getauscht wurde, falls ja, fällt die App nunmal in der Nutzerbewertung.
Und wenn eine Quest unter einen gewissen Wert bei diesem Rating fällt, erst dann sollte geprüft werden wieso dies passiert. Vorher sollte man da dem Entwickler freie Hand lassen. Ich kann viele der Einschränkungen ja nachvollziehen, aber manche sind ... naja. :)
So bräuchte man in der Konfigurationsdatei der jeweiligen App also nur ein paar Parameter und lediglich eine Funktion die den Apps bereitgestellt wird, welche den Status dann aktualisiert.
Was eben passiert, wenn man mit der Standalone App oder über den HTML-Chat online ist und diese Quest zugeteilt bekommt und anschließend via Android online ist – bekommt man ja nicht automatisch neue Quests zugeteilt. In der Regel prüft das System zumindest so, dass man keine Quest bekommt, die man nicht absolvieren kann. Sprich es merkt sich „aha, der war mal mit Android online – also könnte er diese Quest erledigen.“
Und genau das war auch mein Gedanke, das System hat diese Informationen bereit, warum also in der App dies nicht einfach hinterlegen, dass es z. B. nur damit Möglich wäre.
Wenn ein Nutzer nie (oder nur selten, es wird ja sicherlich in der Sitzung mit gespeichert, welcher Client verwendet wurde) mit dem Applet oder HTML Chat online war, ist er nunmal ein "Mobile"-User und kann vom Questsystem auch so eingestuft werden.
Im System könnte also die Prüfung so geändernt werden, mit welchem Clienttypen der Nutzer am häufigsten online ist und dann nur Quests aus dieser Kategorie zuweisen.
vorheriges Thema
Index
