So, jetzt tippe ich auch mal was zu den Gedanken, die ich mir zu so einem Tool bereits gemacht habe.
Achtung: hier ist viel wirr zusammengetippt und evtl. zu sehr im Detail erklärt.
Zum einen der Fokus auf Mobile Geräte: (D.h. Smartphone und Tablets)
Den Charakter zu generieren ist eine Sache, die man natürlich gerne an einem Großen Bildschirm, aber so oft generiert man seinen Charakter auch nicht neu. Andere Sachen, wie das von Grimrokh angesprochene ausrechnen von Erfolgen, werden dagegen viel frequentierter genutzt. Daher ist ein Fokus auf Mobiles sehr wichtig. Meiner Meinung nach hat man am Spaß an einem Programm, wenn man es sinnvoll und häufig nutzen kann.
Deswegen würde ich auch Hilfsfunktionen einbauen. Selbst sachen, die Pen 'n Paper Puristen niemals nutzen würden (z.B. Würfelgenerator). Klarerweise sollte man dabei darauf achten, dass die Funktionen strukturiert angeordnet sind und sich alles Intuitiv nutzen lässt.
Dazu noch ein digitaler Charakterbogen in dem man schnell auf wichtige Werte und auch Ausrüstung zugreifen kann. Dies alles sollte auf dem Mobile prominenter präsentiert werden als die Generierungs-Optionen selbst. Klar, man sollte über einen Menüpunkt auch in der Lage sein, einen neuen Charakter zu generieren, aber der Fokus sollte auf dem Mobile eher in den Hilfsfunktionen liegen. (seht euch DsaTab für Android an - quasi genau so!)
Als Android Entwickler, der sich auch schon mit mobilen WebApps herumschlagen musste bin ich dafür, dass auch eine native Android App dafür entwickelt wird. Und keine Angst liebe iOS-Nutzer, da kann ich parallel auch dran arbeiten - nur Veröffentlichen geht nicht ohne Spenden.
Desktop-WebApp:
Diese sollte ganz klar auf Charaktergenerierung und -verwaltung ausgelegt sein. Dabei sollten Spieler auch ruhig selbst ihr Benutzerkonto besitzen und ihre Charaktere erstellen können. Das heißt jeder kann sich registrieren und ggf. als Spielleiter eine Gruppe einrichten. Andere Nutzer können nach Absprache dieser Gruppe beitreten oder der SL erstellt die SCs von nichtregistrierten Spielern selbst. Dazu käme noch das schon vorher erwähnte Erstellen und Verwalten von NSCs.
Darüberhinaus fände ich es klasse, wenn der SL auch noch Handouts usw. in dem Tool verwalten könnte.
Damit kämen wir dann zu meinem nächsten aberwitzigen
Feature-Vorschlag:
Während der Spielrunde kann der SL allen oder einzelnen Spielern Nachrichten (a la "Du spürst einen Schatten in eurem Rücken") oder Handouts, die die Spieler auf dem Gerät ihrer Wahl angezeigt bekommen. So kann dann auf einem Tablet ein Stadtplan oder ähnliches gezeigt werden. Oder jmd schließt seinen PC an einen großen Fernseher an oder oder oder
(ausführlichere Diagramme dazu kommen die nächsten Tage)
Zu dem technischen bla bla:
Als Basis der Business-Logic würde ich eine Library vorschlagen. Diese Library soll sowohl von der WebApp als auch den mobilen Apps genutzt werden können. Außerdem könnten andere interessierte Projekte unsere Library nutzen und Plugins oder eigene Apps entwickeln (Community-Gedanke und so
)
Um die Library für alle Platformen nutzbar zu machen muss man sich da zwischen Java und C einigen.
pro Java:
+ objektorientiert
+ von vielen lesbar
+ nativ nutzbar mit Android, JRuby (Ruby das auf einer JVM läuft) und
GWT pro C:
+ wilich von überall ohne Quirks und Workarounds aus aufrufbar
con Java:
- Quirks und Workarounds um es in iOS (
j2objc) oder reinem Ruby (JRuby oder Java-Ruby-Bridge) zu nutzen
con C:
- nicht objektorientiert
- schwierig zu entwickeln
Allgemein:
Wir sollten bei dem ganzen mit
WebSockets arbeiten - das gibt uns einige Möglichkeiten Daten an den User zu schicken. Sowohl auf der Browser- als auch auf Mobilseite (damit ist nicht per se eine Website gemeint!)
Web-Backend:
Um PHP mache ich gerne einen sehr großen Bogen. Java EE ist natürlich sehr performant aber ein Krampf richtig einzurichten und auch sehr resourcenhungrig. Mein Favorit hier ist Ruby und speziell JRuby, da das auf einer JVM läuft und auch echte Threads kann. Und wie oben erwähnt kann es Java Code ausführen.
Bei der Datenbank können wir getrost auf eine relational SQL DB zurückgreifen. Welche jetzt genau ist mir nicht so wichtig, wenn das Model-Design stimmt.
NoSQL-DBs sind zwar nett, aber für unseren Fall nicht wirklich von Nöten.
Außerdem brauchen wir einen Wartungsmodus in dem User automatisch abgemeldet werden und wir neue Versionen deployen können.
Um Loadbalancing braucht man sich zu beginn auch nicht unbedingt gedanken machen. Das kann man auch noch nachträglich bereitstellen.
Zum Web-Frontend:
Naja, HTML5 und JavaScript halt
Und mit dem Rails Framework für Ruby ist das halt ne ziemlich schicke Sache, weil man da auch schön mit Templates arbeiten kann und eine schöne Rest-API quasi geschenkt bekommt (ein Traum)
Interaction-Design:
Sollten wir uns an oberste Stelle schreiben! Nichts ist frustrierender als ein Interface welches unübersichtlich, unintuitiv oder unlogisch ist. Dabei müssen wir quasi für 3 Screens entwickeln: Desktop, kleiner Touchscreen & großer Touchscreen.
Grafik-Design:
Naja, als Entwickler interessiert mich das ja meist erst zum Schluss, trotzdem sollten die Designer aber mit den Entwicklern in Kontakt stehen. Gerade für die Asset-Production.
Next:
Ich wäre schwer dafür, dass wir uns demnächst mal zusammen tun und unsere nächste Schritte besprechen. Wie z.B. eine Organisationsstruktur aufbauen. Also Kontakte knüpfen usw.
Hierfür würde ich anbieten ein Forum und Video- bzw. Sprachkonferenzen einzurichten.
Viele Grüße und danke für's Lesen,
Nico.
