[Idee] Webbasiertes Splittertool (WebST)

[maggus]

Was ist das WebST?

Das Webbasierte Splittertool (WebST) ist im Kern ein digitaler Manager für Splittermond-Charaktere mit Generierungsregeln und formschönem, druckbarem Output eines Charakterbogens, der von allen Splittermond-Spielern online aufgerufen und einfach bedient werden kann. Das Tool läuft im Browser (evt. zusätzlich als Applikation in mobilen Endgeräten). Darüber hinaus bestehen Ideen, das Tool auch für Steigerung oder Austausch von Charakteren zu nutzen sowie weitere Features zu installieren, die Spielern und Spielleitern nützlich sind.

Dabei gelten folgende Grundsätze:

• Das WebST soll das Rollenspiel ergänzen - aber nicht das Spiel am Tisch ersetzen.
• Das WebST soll Spieler und Spielleiter mit Regelkenntnis unterstützen - aber nicht die Regelkenntnis der Spieler überflüssig machen.

Die Idee zum WebST ist aus den Diskussionen zum filebasierten Charakter-Generator auf Excel-Basis entstanden (siehe etwa ab hier). Die dort entstandene Diskussion soll hier weiter geführt werden. Der recht generische Name "Webbasiertes Splittertool" ist ein Arbeitstitel, um das Vorhaben eindeutig zu benennen ohne die (noch im Entstehen begriffenen) Funktionen durch die Namensgebung bereits vorwegzunehmen. Ich hoffe, es können sich alle mit diesem Arbeitstitel anfreunden.

Wie entsteht das WebST?

Bis eine Webanwendung tatsächlich live geht, ist es ein langer Weg. Ein altes Sprichwort (ich glaube aus China?) hat hierfür einen aufmunternden Satz parat:
Auch der längste Weg beginnt mit dem ersten Schritt



Nun, die ersten paar Schritte haben wir bereits gemacht, jetzt ist es an der Zeit, die grobe Marschrichtung zu skizzieren. Ich sehe zurzeit folgende Hauptphasen in diesem Projekt:

• IDEE & TEAM - Ideenfindung und Teambuilding (hier sind wir gerade mitten drin)
• SCOPE & PLAN - Anforderungsdefinition und Planerstellung (hier wird aus der Idee ein konkretes Vorhaben)
• KONZEPTION - Fachliche und technische Konzepte (hier wird designt)
• REALISIERUNG - Umsetzung, Contenterstellung und Usertests (hier entstehen Code, Grafik und Text in Wechselwirkung mit Beta-Testern)
• GOING LIVE - Promotion und Veröffentlichung (Zielgerade)
• SUPPORT - Laufender Betrieb (ja, auch die Zeit nach dem Going Live sollte berücksichtigt werden)

Selbstverständlich gibt es mehrere Exit-Szenarien, die dieses Projekt beenden können. Ich finde es wichtig, schon zu Beginn über mögliche Ausstiege zu sprechen, das macht's nämlich für jeden einfacher, über seine eigene Beteiligung nachzudenken. Meine Meinung jedenfalls.

• Der erste Exit ist nach der Hauptphase "1 IDEEN UND TEAM", wenn sich nämlich kein hinreichend großes Team findet. Was "hinreichend groß" genau ist, darüber macht sich das Team dann Gedanken.
• Der zweite Exit kann nach der zweiten Hauptphase "2 SCOPE UND PLAN" kommen - wenn nämlich das Team festellt, dass die Aufgaben nicht in zumutbarer Zeit schulterbar sind.
• Den dritten und letzten Exit sehe ich bei Fortschritt der Konzeption und nach begonnener Umsetzung - wenn nämlich das Team erkennen muss, dass trotz bester Absichten die Arbeit zu viel geworden ist.

Plan und Exit-Punkte in der Übersicht:



Und all das sehe ich nicht dogmatisch sondern als Vorschlag zum Vorgehen, der gerne geändert werden kann. Nur gar keinen Plan haben mag ich nicht...

[maggus]

Bisher sind folgende Ideen und Vorschläge und Ansätze entstanden (seht's mir nach, wenn ich die jeweiligen Ideengeber nicht einzeln aufgeführt habe):


FACHLICHER INPUT

Kernfunktionen

• Kernfunktion ist ein webbasierter Charakter-Generator, der schnell und einfach ist und einen ansehnlichen Charakterbogen generiert. Zum Ausdrucken natürlich, das Tool soll ja nicht Pen und Paper ablösen, sondern unterstützen.
• Features, die eine webbasierte Anwendung mit sich bringt, weil sie eben webbasiert ist: Von überall erreichbar, alles zentral gespeichert, Updates und Erweiterungen quasi automatisch, Austausch mit anderen.
• Die Übersichtlichkeit sollte natürlich ein wichtiges Kriterium sein.

Erweiterung der Kernfunktionen

• Die Ergebnisse sollen verwaltbar sein, so dass ich als Spielleiter nicht jedesmal bei Null anfangen muss.
• Im WebST soll nicht nur die Generierung sondern auch die Steigerung von Spielercharakteren (oder NSCs) möglich sein
• Die einzelnen Werte sollten unabhängig von den Generierungsregeln frei veränderbar sein, wenn man etwas kreieren möchte, dass „stärker“ oder einfach anders als der normale humanoide (N)SC ist.
• Typische Meisteraufgaben in der Vorbereitung eines eigenen Abenteuers: NSC's zusammenstellen und übersichtlich parat haben. Also z. B. Scorecards für "Schwertfutter" oder etwas detailliertere Steckbriefe für die wesentlichen Antagonisten der Spieler schnell erstellen und in einer Übersicht ausdrucken
  Als SL die Spielercharaktere vorliegen haben (für verdeckte Würfe, zur Abenteuerplanung etc.). Außerdem gibt's einfachere NSCs, komplexere Meisterpersonen und simple Gegner, die erstellt, eventuell entwickelt und verwaltet werden wollen.
• Und wenn schon webbasiert, dann können auch SC's und NSC's untereinander bereit gestellt werden. Vielleicht kann man auch die klassischen Gegner (Orks, Goblins, Räuber etc.) zentral hinterlegen, so dass man sich ohne Generierung schnell eine Übersicht zusammenklickt. Gerne auch in Stufen (Standard, geübt, Veteran).
• Benutzerverwaltung (passt ja auch zum Web-basierten vorgehen), so dass ich meine Charaktere letztlich online "lagern" kann - mit der Option, sie entsprechend auch vom Bildschirm zu spielen. Dafür wäre dann idealerweise auch eine Darstellung vorhanden, die auf mobilen Endgeräten taugt - zumindest fürs Spielen, nicht zwingend für die Erstellung und Steigerung.
• Die selbst erstellten (N)SC auch offline als pdf o. ä. abspeichern und anzeigen
• Charaktere für andere lesbar schalten, damit der SL die Charaktere der Mitspieler einsehen kann.

Zusätzliche Funktionen

• Ein Probentool wäre dann auch recht leicht zu integrieren.
• Eigene Ausrüstung, magische Gegenstände, Zauber, Meisterschaften, usw. hinzuzufügen
• Hausregeln ermöglichen
• Spielleiter-Tools: NSC-Namens-Generatoren, Wetter-Ermittler, Kräutersuche, Jagen, Zufallsbegegnungen
• Verlinkung ins Wiki.
• Verwaltungstool für die selbst kreierten Landstriche, Städte etc.
• Tickvisualisierung

TECHNISCHER INPUT

• Der Einsatz einer Datenbank ist Pflicht. Wichtig ist aber auf jeden Fall, dass wir die Datenbank sauber designen
• konsequent von Anfang an für die Darstellung auf alle Geräte optimieren
• Framework nutzen, dass die Mobildarstellung von Haus aus mitbringt
• Charakterverwaltung mit Nutzerzuordnung auf Datenbankbasis
• Bisher diskutierte Programmiersprachen (Muttersprache): Java, PHP, Ruby on Rails;
  siehe dazu flippahs gute Zusammenstellung des Dikussionstands im Splitterwiki: http://splitterwiki.de/wiki/Charaktergenerator/Webanwendung
• wahrscheinlich ist es am besten, mit der Benutzerverwaltung anzufangen, denn die braucht man später eh - und die meisten Frameworks bringen sowas ja ohnehin mit

So, ab jetzt bitte weitermachen mit den guten Ideen

[maggus]

@TECHNIK

Ich fände es wichtig, dass es einen (ich nenne ihn mal) Admin-Editor gibt, über den Werte und ggf. auch Regeln editiert werden können. Wenn alle Werte (Regeln) ausschließlich im Programmcode und/oder der Datenbank hinterlegt sind, müsste ja jede Erweiterung, jeder Bug und zu Anfang sogar "einfach alles" durch die Entwickler mit irgendwelchen Entwickler-Werkzeugen eingetragen werden (IDE, SQL-Editor etc.). Ein Admin-Editor würde es ermöglichen, dass auch Nicht-Entwickler den eigentlichen Content für das Tool hegen und pflegen können. Das entlastet - langfristig - nicht nur die Entwicklung sondern macht die Anwendung auch zukunftsfähiger, weil man keine programmiertechnischen Kenntnisse und Ahnung von der Umsetzung zu haben braucht, um das Tool am Laufen zu halten.

So ein Admin-Editor sollte über den Browser aufgerufen werden, muss kein schönes aber soll funktionales Design haben und ist in der Benutzung an die Admin-Rolle gebunden.

Apropos Rollen, ich sehe zurzeit folgende Rollen:

• Anonymer Nutzer
• Spieler (registriert)
• Spielleiter (registriert)
• Admin

Ich teile auch die Einschätzung von flippah und Belzhorash, dass die Nutzerverwaltung sehr früh im Projekt technisch zu designen ist. Das Rechte-Rollen-Konzept einer Anwendung ist dermaßen Meta, dass man es sich einfach nicht leisten kann, es erst später "ranzuflanschen".

[flippah]

Prima! Da merkt man schonmal, dass ein Mensch mit Projektleitungserfahrung am Werk ist.

Wichtig wäre aus meiner Sicht erstmal die Teamfindung. Solange wir nicht eine ausreichende Anzahl Leute haben, brauchen wir nicht ernsthaft anzufangen, dafür ist das Projekt zu groß.

Danach sollten wir sichten, welche Kenntnisse vorhanden sind. Denn die entscheiden mE sehr weitgehend darüber, in welcher Technologie wir arbeiten wollen. Dazu bietet sich wohl ein Teamtreffen an.

Anschließend würde ich vorschlagen, erstmal einen Prototypen zu erstellen - was insbesondere auch dazu dienen würde, das technologische KnowHow zu stärken.

Zum Thema Adminbackend:

Das sehe ich tatsächlich weniger problematisch. Hier würde sich mE die Nutzung von phpMyAdmin anbieten. Man kann ja einen zusätzlichen User einrichten, der eingeschränkte Schreibrechte hat, so dass hierüber die Pflege der Steuertabellen erfolgen kann. Der Aufwand, hier eine Wartungsgui zu schreiben, ist mE zu hoch im Vergleich zum Mehrwert gegenüber einer Pflege mittels phpMyAdmin.

[maggus]

@FACHLICH

Ich fänd's perfekt, wenn am Ende ein Paket herauskommt, dass mir für Splittermond den Umfang bietet, den mir bei DSA Helden-Software (Erstellen&Steigern), MeisterGeister (Verwalten&Bespielen) und DSATab (mobil) bieten. Nur bitte im  gleichen Design, in einem Bundle und deshalb dann auch gescheit kompatibel

@Wolfhunter: Die Helden-Software kenne ich ganz gut, sie entspricht ja im Großen und Ganzen der Kernfunktion "Charakter-Manager".

Aber was genau kann MeisterGeister denn so? Was ich nämlich (jedenfalls für die initiale Projektphase) ausschließen möchte, ist eine BattleMap. Da gibt es ja schon ganz gute Online-Tools (wie MapTool oder Roll20), und den Aufwand für eine mapbasierte Anwendung stelle ich mir ganz enorm vor.

Auch DSATab kenne ich noch nicht. Ist das dieses Tool?:

[flippah]

DSATab ist letztlich die App zu Helden-Software - aber halt offline.

[maggus]

Prima! Da merkt man schonmal, dass ein Mensch mit Projektleitungserfahrung am Werk ist.

  Entwickler, die die Arbeit von Projektleitern schätzen können, sind nicht gerade Standard. Schön, dass wir uns hier gefunden haben 

Wichtig wäre aus meiner Sicht erstmal die Teamfindung. Solange wir nicht eine ausreichende Anzahl Leute haben, brauchen wir nicht ernsthaft anzufangen, dafür ist das Projekt zu groß.

Danach sollten wir sichten, welche Kenntnisse vorhanden sind. Denn die entscheiden mE sehr weitgehend darüber, in welcher Technologie wir arbeiten wollen.

Ja, Teamfindung ist gerade zentral. Aber bitte auch Ideenfindung. Jedes Projekt bruacht am Anfang viel, viel kreativen Input, abmagern tut's später sowieso. Außerdem möchte ich gerade momentan möglichst alle Forenmitglieder zur Beteiligung anregen, auch wenn sie nicht im Team mitmachen wollen. Gute Ideen kann nämlich jeder haben.

Auch die Kenntnisse der Teammitglieder sind ein sehr wichtiger Faktor. Allerdings kann ich mir auch vorstellen, dass das übergeordnete technische Design losgehen kann, bevor wir uns für diese oder jene Muttersprache mit Framework X oder Y entschieden haben. Usecases oder Klassenmodelle lassen sich modellieren, egal ob später in Java, PHP, .NET oder RoR entwickelt wird (ja, auch PHP kann man objektorientiert umsetzen), und auch die Auswahl der Datenbank kann nach dem Design eines Entity-Relationship-Models erfolgen.

Dazu bietet sich wohl ein Teamtreffen an.

  Unbedingt. Wenn's ernst wird, würde ich persönliche Treffen einmal pro Quartal zur Pflicht machen, ansonsten regelmäßige Teammeets übers Netz.

Anschließend würde ich vorschlagen, erstmal einen Prototypen zu erstellen - was insbesondere auch dazu dienen würde, das technologische KnowHow zu stärken.

Hui, ich bin ja der klassische Wasserfall-Typ. Erst planen, dann umsetzen. Aber wenn Prototyping effektiver ist... lasse ich mich gerne eines Besseren belehren. Nur mit Scrum kannste mich jagen, und "agil" kann ich auch nicht mehr hören. Bei 9 von 10 Leuten meint das nämlich nichts anderes als "Arbeiten auf Zuruf".

Zum Thema Adminbackend:

Das sehe ich tatsächlich weniger problematisch. Hier würde sich mE die Nutzung von phpMyAdmin anbieten. Man kann ja einen zusätzlichen User einrichten, der eingeschränkte Schreibrechte hat, so dass hierüber die Pflege der Steuertabellen erfolgen kann. Der Aufwand, hier eine Wartungsgui zu schreiben, ist mE zu hoch im Vergleich zum Mehrwert gegenüber einer Pflege mittels phpMyAdmin.

Das sollten wir noch ausdiskutieren, wenn das ERM skizziert ist. Via SQL-Editor Daten zu pflegen klappt meiner Erfahrung nach nur, wenn das Abstraktionsniveau des Modells recht niedrig ist. Das sehe ich momentan nicht...

[flippah]

Ich sehe den Prototyp nicht als Weg zum Endprodukt, sondern wirklich als Lernhilfe für die Technologie.

Was die Anforderungsanalyse angeht, so bin ich ganz bei dir: erst muss man wissen, was man will, dann erst loslegen.
(meine Kollegen würden sich wundern, dass ich das schreibe - aber mir sind halt auf der Arbeit die Anforderungen meistens sehr schnell klar)

Und ich habe genug Zeit mit schlecht gemanagten Projekten verbracht, dass ich weiß, dass ein guter Projektleiter wirklich hilft

Im übrigen sehe ich es auch so: wir müssen erstmal wissen, was für Anforderungen es gibt. Die Frage der technischen Umsetzung kommt später.

[koppelschoof]

Hey Jungs,

Ich habe schon den alten Thread beobachtet und würde mich da liebend gerne euch anschließen!

Zu mir kann ich sagen, dass ich Software Entwickler bin und derzeit hauptsächlich auf Android entwickle wozu noch Ruby und JavaScript kommen. Datenbanken sind auch eine Welt in der ich mich sehr daheim fühle. C/C++ wäre auch noch drin aber das ist für dieses Projekt eher nicht von Nöten.

Ich habe selbst vor einiger Zeit aus Spaß ein Planspiel gemacht in dem ich die Entwicklung von einem DSA Helden Generator analysiert habe. (Helden Software ist zwar cool aber das Interaktionsdesign ist eine Katastrophe).

Ich habe echt 'ne Menge Ideen über die Zeit gesammelt die ich gerne mit euch teilen möchte! Aber Diskussionen über Eigenschaften und Möglichkeiten des Tools sind imo nicht sinnvoll bis nicht ein Kernteam steht, welches genaue Pläne ausarbeiten kann.

Oh und übrigens kann ich meinen V-Server zur Verfügung stellen.

Viele grüße,
Nico.

Gesendet von meinem GT-I9300 mit Tapatalk 2

[Eyb in the box]

Hier eine Stimme aus dem OFF:

Jungs, ich finde es super professionell wie Ihr hier die Sache angeht. Das hätten unsere SMufanten bestimmt nicht im entferntesten erwartet, was hier für eine aktive Fanbase zu diesem sehr frühen Zeitpunkt entstanden ist. Nicht das wir unsere SMufanten noch überholen...   Danke Euch allen. Hier kann echt was Großes entstehen. Und wenn das auch noch im Einklang mit unseren SMufanten geschieht, perfekt!


Ich kann Euch später gerne beim Testen helfen. Ich erkenne relativ schnell ob etwas (ich meine an dieser Stelle die Haptik + das Design des Tools) flüssig läuft, oder einfach nur umständlich zu handhaben ist. Ich selber habe jahrelange Erfahrung mit Projekten (Leitung etc.), dem Aufbau neuer Systeme im Unternehmen (Credit Management etc.), sowie dem Controlling und Reporting. Was ich aber vor allem habe: Neugierde, viele irre Ideen, ein Gefühl fürs einfache Design, sowie Beharrlichkeit Dinge so gut wie irgend möglich zu gestallten - da habe ich in der Vergangenheit schon so manchen genervt  . Aber der "Erfolg" gab mir meistens recht.

Also falls Ihr irgendwann mal jemanden braucht, der mal einen Blick auf das Tool wirft, ich bin gern dabei.

[maggus]

Hey Jungs,
Ich habe schon den alten Thread beobachtet und würde mich da liebend gerne euch anschließen!

Herzlich willkommen Als alter Beobachter weisst Du ja, dass wir noch in der Findungsphase sind und (fast) alles noch offen ist.

Zu mir kann ich sagen, dass ich Software Entwickler bin und derzeit hauptsächlich auf Android entwickle wozu noch Ruby und JavaScript kommen. Datenbanken sind auch eine Welt in der ich mich sehr daheim fühle.

Feine Sache, bisher hat sich auch noch niemand zu JavaScript gemeldet, das, richtig eingesetzt, ja ganz enorme Quantensprünge am Webfrontend auslösen kann. Sei es die Haptik von Funktionselementen, allgemein visuelle Effekt, die Nutzung einer Bibliothek bis hin zu Performance-Steigerungen durch AJAX bzw. Loading-on-demand. Verstehe mich aber bitte nicht falsch, weder ist der Einsatz der Sprachen fix noch möchte ich Dich auf eine JS-Rolle festnageln. Gutes Datenbank-Design, das haben hier schon einige verlauten lassen, ist auch ein notwendiges Erfolgskriterium (auch, wenn man die Wartbarkeit der Anwendung erreichen möchte).

Helden Software ist zwar cool aber das Interaktionsdesign ist eine Katastrophe

Ganz meine Meinung. Wobei wir bei der Frage angelangt sind, wer sich in der Lage sieht, ein UI-Design zu entwickeln (UserInterface-Design, also die Oberflächen, welche die lieben Nutzer schlussendlich zu sehen bekommen).

Ich habe echt 'ne Menge Ideen über die Zeit gesammelt die ich gerne mit euch teilen möchte!

Leg los! Noch bewegen wir uns in einem offenen Rahmen.

Aber Diskussionen über Eigenschaften und Möglichkeiten des Tools sind imo nicht sinnvoll bis nicht ein Kernteam steht, welches genaue Pläne ausarbeiten kann.

Da bin ich bedingt anderer Meinung. Konkrete Eigenschaften des Tools detalliert zu diskutieren - ja, dazu ist es zu früh. Und ja, das muss im Kernteam passieren, das anschließend auch für die Realisierung zuständig ist. Aber bevor wir da angelangt sind, halte ich es für notwendig, erst einmal alles zu sammeln, was den Leuten hier durch den Kopf schießt. Jede Idee, und sei sie noch so utopisch, ist zurzeit willkommen. Je breiter die Basis wird, desto besser lässt später ein konkreter Scope erstellen, der auch zukunftsgerichtet ist.

Oh und übrigens kann ich meinen V-Server zur Verfügung stellen.

Hosting ist noch ein unbeschriebenes Blatt. Da sollte mMn auch zwischen der Umsetzungsumgebung und der Laufzeitumgebung differenziert werden. Je nach "Muttersprache" der Anwendung werden wir zu gegebener Zeit über CVS und irgendwelche Builder sprechen, um paralleles Entwickeln und zentrales Testing gewährleisten zu können.

Ich kann Euch später gerne beim Testen helfen.

Na dann - herzlich willkommen im Team, Abteilung Qualitätssicherung

viele irre Ideen

Moment mal, die Ideen brauchen wir jetzt, nicht erst beim Testen. Also einfach loslegen, noch sind wir in der Wünsch-Dir-Was-Phase. Was es von den Ideen dann genau in den Scope schafft, ist eine traurige Pflicht, die in Phase 2 zu erledigen ist (Abmagern des Designs).

[koppelschoof]

Ok ich werde heute Abend, wenn ich mal Zeit finde etwas ausformulieren. Kann aber dann sein, dass ich mich unnötig in Details verliere.

Je nach "Muttersprache" der Anwendung werden wir zu gegebener Zeit über CVS und irgendwelche Builder sprechen, um paralleles Entwickeln und zentrales Testing gewährleisten zu können.

Aber eine große Bitte habe ich da noch. Bitte kein CVS/SVN! Git ist für so ein dezentrales Arbeiten immens besser geeignet! Meinetwegen gebe ich Allen einen Einführungskurs, aber bitte bitte bitte bitte Git!

Gesendet von meinem GT-I9300 mit Tapatalk 2

[Eyb in the box]

Ideen ... kommten bald jetzt schon mal eine Kleinigkeit. 
Nix besonders, dennoch finde ich sehr wichtig für die grundsätzliche spätere Handhabung...

Layout/Haptik/Design
Es sollte einen fixen oberen Bereich (siehe Anhang) im Tool geben. Nicht zu viele Spalten, max 3-4. Und egal ob ich scrolle oder nicht, dieser Bereich sollte immer oben stehen. Von dort aus, kann ich immer in sämtliche Menüs springen. Hat hier vielleicht jemand Erfahrung mit Apple und OS? Die machen das genau richtig. Somit kann man, egal wo auch immer man sich gerade befindet, schnell in ein anderes Menü (SC Erstellung, SC Verwaltung, SC wasweißich) springen.

Das Layout (Farben etc.) sollte sich ebenfalls an dem Offiziellen orientieren, dass ist hier im Internet gar nicht sooo verkehrt und bietet keinen unnötigen Schnick-Schnack. Vulgo, gefällt mir.



Hallo SMufanten, hi Tionne, wäre es jetzt nicht langsam an der Zeit ein weiteres Unterforum einzurichten?
Es wäre zu schade, wenn das Allgemeines-Forum weiter mit Fanwork (oder wie auch immer man das jetzt nennen möchte / Kreativsplitter, ) vermischt wird.
Ferner wäre es auch einfacher für unsere Kreativabteilung, ein festes Unterforum hier zu haben.

[flippah]

Ich denke auch, dass GIT da wohl die bessere Wahl ist. Aber ich kann auch mit SVN leben.

[maggus]

Aber eine große Bitte habe ich da noch. Bitte kein CVS/SVN! Git ist für so ein dezentrales Arbeiten immens besser geeignet! Meinetwegen gebe ich Allen einen Einführungskurs, aber bitte bitte bitte bitte Git!

Sorry, mein Fehler Ich meinte nicht CVS sondern VCS (Version Control System), also nicht eine konkrete Software sondern den Softwaretyp. Welches VCS verwendet wird, ist mir persönlich nicht wichtig, solange überhaupt ein VCS verwendet wird. Das sollte dann das Entwicklerteam auch bestimmen. Und ja, Git hat dank Deines Engagements wohl gerade einen Pluspunkt bekommen