Thread: [dsaster-devel] Sammlung der spontanen Ideen
Status: Pre-Alpha
Brought to you by:
j6cubic
Menu
▾
▴
dsaster-devel
|
From: Dingsi <do...@gm...> - 2006-02-11 01:00:51
|
Einfach mal irgendwelche Dinge dir mir einfach so eingefallen sind.
Vollkommen unstrukturiert. ;)
Also...
Automatische Verwaltung von Aktionen (\01ACTION ...\01 und *...*), und
Kommentaren ([...] und {...}).
Diese sollten leicht ein- und ausblendbar sein.
Außerdem sollte es automatische Komplettierung und Bereinigung von
Zeilen wie
"{ bla bla." -> "{ bla bla. }"
"[ omg }" -> "[ omg ]"
geben.
Das ganze per Befehl/Button/Konfigurationsmenü leicht ein- und ausschaltbar,
damit man auch "normal" Chatten kann.
Sowieso sollten die Untermenüs (Charakter, Map, Infos, Chat, was-weiß-ich)
modular sein, so dass man auch alles außer zum Beispiel dem Chat ausblenden
lassen kann und nur einen ganz normalen IRC-Klienten hat.
Jeez' hatte glaube ich mal Tabs vorgeschlagen. Klingt ganz in Ordnung, imo.
Außerdem ist zu überlegen, ob man die oben erwähnten Funktionen über
irgendein
Skriptinterface macht, so dass man einfach und schnell Änderungen vornehmen
kann oder ähnliche Konvertierungen anwenden kann.
Ich schlag mal spontan Rhino und JRuby vor. Rhino ist natürlich überlegen
schnell, aber ist der Rückstand JRubys da gravierend genug, als dass man ihn
in einem IRC-Clienten merken würde?
Ansonsten sind mir die beiden eigentlich ziemlich gleich, ich mag sowohl
JS als auch Ruby sehr gern.
mq ist sicher für Jython. :B
Mmh. Oder das Bean Scripting Framework nehmen? Das klingt irgendwie sehr
heiß.
Wenn wir das nähmen, hätten wir gleich JS, Ruby, Python und viele weiter
schon
drin.
Da müsste sich irgendwer mal mit auseinandersetzen. o.o
Da MQ sich ja um die IRC-Lib kümmert und Jeez um
das GUI macht das wohl DFYX. :P (Ob ich das nicht machen kann? Neee.
Nein, wirklich. Ich hab gerade mal wieder einen massiven Motivationsschub
für meine GameDB und für die Gentoo-Installation, da will ich die nicht
gleich
wieder durch ein neues Projekt verpuffen lassen. Ich hoffe das versteht ihr.
Achja, Jeez, räum mal die Projektseite von DSAster auf. Da steht soviel
unnötiger Kram. Ich meine, Files hab wir noch keine, CVS nicht, Bugtrucker
nicht usw. usw. Unter Screenshots könntest du vielleicht schon deiner
http://jesus_666.fnord.name/Bild%209.png
Designstudie tun. =D
Äh. Ja. *ähnlich wie mq kein gutes ende finden tu* Ha, ha, das reimt sich!
|
|
From: masterquest <rpg...@we...> - 2006-02-11 01:35:37
|
> Ich schlag mal spontan Rhino und JRuby vor. Rhino ist natürlich überlegen > schnell, aber ist der Rückstand JRubys da gravierend genug, als dass man ihn > in einem IRC-Clienten merken würde? > Ansonsten sind mir die beiden eigentlich ziemlich gleich, ich mag sowohl > JS als auch Ruby sehr gern. Beides nette Sprachen, aber... > mq ist sicher für Jython. :B exakt. Wie bist du da bloß drauf gekommen? > Da müsste sich irgendwer mal mit auseinandersetzen. o.o > Da MQ sich ja um die IRC-Lib kümmert und Jeez um > das GUI macht das wohl DFYX. :P IRCLib klau ich doch von woanders (LGPL), ich werd wohl den Großteil des IRC-Krams machen. Auch die GUI davon, wenn ich's auf die Reihe kriege. |
|
From: Tim O. <in...@gm...> - 2006-02-11 02:08:44
|
Hmm, wir sollten uns mal ein Wiki einrichten, wo man die Ideen sammeln kann. Ich bin nämlich am überlegen, ob wir unsere Versionsnummer nicht erst mal an den implementierten Features festmachen - also eine Bitmaske verwenden. In der Roadmap habe ich so was ja schon angedacht, mit dem Wert 1 für die Grund-Datenstruktur, 2 für das Schreiben von Werten, 4 für die komplette Äquivalenz zur Wiege... Vielleicht sollten wir uns da was neues überlegen, dann könnte man an der Milstonenummer gleich festmachen, was implementiert ist. Nur so ein Gedanke. -- Jeez |
|
From: DFYX <df...@ly...> - 2006-02-11 02:46:43
|
Einverstanden. Wer k=FCmmert sich um ein Wiki? Und nebenbei? Hab ich nich schon mal eins aufgesetzt? |
|
From: Dingsi <do...@gm...> - 2006-02-11 12:55:40
|
> Einverstanden. Wer kümmert sich um ein Wiki? Und nebenbei? Hab ich > nich mal eins aufgesetzt? War das nicht mq? Ansonsten: Von mir aus gern ein Wiki und was die Versionsnummern angeht, da müssten wir uns erstmal klar werden welche groben Features wir denn brauchen. Also einmal natürlich den IRC-Klienten, dann die Charaktererstellung und -verwaltung (Eigene Charaktere), dann Abenteuer-Verwaltung (mit integriert Charakterverwaltung der Mitspieler ;) Zu den Abenteuern, dazu gehören dann noch viele Sachen wie ein Scrapboard, auf dem die Spieler sachen ablegen können, Karten, Rätsel, all den Kram den wir aus #free-dsa kennen. Am besten unterteilt in Dateien, die entweder Bild oder Text sein können. Und das ganze natürlich kollaborativ, so dass man dabei zur Spielzeit rumarbeiten kann. Ich merke schon, das wird komplex. x_X Mmh, zu den Bildern fällt mir dann auch gleich noch ein Problem ein. Den Text kann man ja recht einfach über das IRC-Protokoll ablaufen lassen, aber das mit den Bildern? Vielleicht DCC? Damit könnte man u.U. noch kompatibel zu normalen IRC-Clients bleiben, was ich gar nicht so schlecht fände. Uff, Chat, Charaktere, Abenteuer, was brauchen wir noch? Brauchen wir den ganzen Umfang der Wiege, vonwegen Basar, Locator, Reise, Metrik? Dieser "Kleinkram" wie Würfelskript... mh.. einfach per Skript implementieren? Noch ein Anliegen: Wollen wir uns strikt auf DSA festlegen, oder am besten Versuchen, das ganze so modular zu halten, dass man möglicherweise das ganze auch zu einem Shadow Run Client machen kann? |
|
From: masterquest <rpg...@we...> - 2006-02-11 13:28:47
|
>> Einverstanden. Wer kümmert sich um ein Wiki? Und nebenbei? Hab ich >> nich mal eins aufgesetzt? > > War das nicht mq? Ja, war ich. Aber vielleicht ist DFYX mein Zweitaccount und ich weiß nichts davon, dann kann's auch er gewesen sein. Ich hatte damals allerdings irgendwelche Probleme mit dem Wiki (an die ich mich aber nicht mehr genau erinnern kann), von daher kann DFYX das gerne nochmal neu machen. > Also einmal natürlich den IRC-Klienten, dann die Charaktererstellung und > -verwaltung (Eigene Charaktere), dann Abenteuer-Verwaltung (mit > integriert Charakterverwaltung der Mitspieler ;) Ich würde auch noch eine Kampfverwaltung auf Spielleiterseite ganz gut finden. Also im Prinzip, dass der Meister (bzw. sein Client) den Kram übernimmt, den momentan Rheia macht. > Zu den Abenteuern, dazu gehören dann noch viele Sachen wie ein > Scrapboard, auf dem die Spieler sachen ablegen können, Karten, Rätsel, > all den Kram den wir aus #free-dsa kennen. Am besten unterteilt in > Dateien, die entweder Bild oder Text sein können. Und das ganze > natürlich kollaborativ, so dass man dabei zur Spielzeit rumarbeiten > kann. Ich merke schon, das wird komplex. x_X Die Frage ist vor allem, wie wir das "kollaborativ" implementieren. Wenn 2 Spieler gleichzeitig drin rumkritzeln können sollen, wird das wirklich komplex. Alternativ könnten wir's auch einfach so machen, dass DSAster, wenn der User eine Datei aktualisiert, automatisch eine Nachricht wie "[ DSAster: newest version of $filename here ]" ausgibt und die anderen Clients dass dann verarbeiten (sprich: sie führen eine Liste der Dateien, die gerade im Umlauf sind, und merken sich, welcher Spieler gerade die aktuellste Version der Datei hat. Wenn der User jetzt auf die Datei zugreifen will, schickt DSAster 'ne entsprechende Anfrage, und der andere Spieler schickt das per DCC rüber). Dann müssten wir allerdings eine Art DSAster-Protokoll erstellen, dass eben über OOC-Klammern läuft (wie mein Beispiel). Dummerweise sind wir dann natürlich nicht mehr wirklich zu anderen Clients kompatibel. Aber das wird eh schwer zu erreichen, wenn wir irgendwelche Kollaboritäts-Features wollen. Und dann bleibt noch die Frage, ob wir alles mit DSAster selbst bearbeiten wollen (was für Kram wie Mindmapping und Text wohl geht, aber bei "richtigen" Bildern komplex wird) oder ob wir das mit externen Programmen machen. Und wenn's über externe Programme läuft, wie wir feststellen, wann die Dateien geändert werden. > Mmh, zu den Bildern fällt mir dann auch gleich noch ein Problem ein. Den > Text kann man ja recht einfach über das IRC-Protokoll ablaufen lassen, > aber das mit den Bildern? Vielleicht DCC? Damit könnte man u.U. noch > kompatibel zu normalen IRC-Clients bleiben, was ich gar nicht so > schlecht fände. Ich denke, DCC ist da die einzig vernünftige Lösung, außer, wir erweitern das IRC-Protokoll (wo ich persönlich strikt gegen bin). > Uff, Chat, Charaktere, Abenteuer, was brauchen wir noch? Brauchen wir > den ganzen Umfang der Wiege, vonwegen Basar, Locator, Reise, Metrik? > Dieser "Kleinkram" wie Würfelskript... mh.. einfach per Skript > implementieren? Würfeln würde ich einfach als Script machen, schon allein, damit man's im Notfall leichter modifizieren kann. > Noch ein Anliegen: Wollen wir uns strikt auf DSA festlegen, oder am > besten Versuchen, das ganze so modular zu halten, dass man > möglicherweise das ganze auch zu einem Shadow Run Client machen kann? Gute Frage. Ist mir eigentlich relativ egal. DSA hat natürlich die höchste Priorität, aber SR wäre schon nett. |
|
From: Tim O. <in...@gm...> - 2006-02-11 13:46:58
|
masterquest wrote:
> Ich würde auch noch eine Kampfverwaltung auf Spielleiterseite ganz gut
> finden. Also im Prinzip, dass der Meister (bzw. sein Client) den Kram
> übernimmt, den momentan Rheia macht.
Das hatte ich so geplant, daß die Spieler einfach den Spielleiter
bitten, das entsprechende Skript auszuführen; spielleiterseitig wird
dann verwaltet, wer schon angegriffen hat etc.
> Dann müssten wir allerdings eine Art DSAster-Protokoll erstellen, dass
> eben über OOC-Klammern läuft (wie mein Beispiel). Dummerweise sind wir
> dann natürlich nicht mehr wirklich zu anderen Clients kompatibel. Aber
> das wird eh schwer zu erreichen, wenn wir irgendwelche
> Kollaboritäts-Features wollen.
Ich würde sagen, wir haben einfach im Hintergrund einen "unsichtbaren"
Kanal offen, in dem die Clients miteinander reden. Da gibt der Client
dann eben eine Zeile wie "RES UPDATE MAP 5" ("Ich habe eine Ressource
geupdatet, es ist die Karte mit der Nummer 5. Bitte holt euch die neue
Version") aus, was die Spieler aber nicht sehen.
> Und dann bleibt noch die Frage, ob wir alles mit DSAster selbst
> bearbeiten wollen (was für Kram wie Mindmapping und Text wohl geht,
> aber bei "richtigen" Bildern komplex wird) oder ob wir das mit
> externen Programmen machen. Und wenn's über externe Programme läuft,
> wie wir feststellen, wann die Dateien geändert werden.
Menü -> Ressourcen -> Hinzufügen... -> Pfad eingeben -> auf "Ok" klicken
-> DSAster lädt den Kram hoch
> Ich denke, DCC ist da die einzig vernünftige Lösung, außer, wir
> erweitern das IRC-Protokoll (wo ich persönlich strikt gegen bin).
Wiue schon in der anderen Mail gesagt, DCC ist meiner Erfahrung nach
extrem unzuverlässig und sollte nicht für etwas gebraucht werden, das
irgendeine Relevanz hat. Da sollten wir allgemein nichts beutzen, das
einen offenen eingehenden Port benötigt - beispielsweise wre das
Programm sonst beispielsweise für Ineluki unbrauchbar, weil er ja übers
Uinetz reingeht und die Admins ihm sicher nicht für DSAster einen Port
forwarden werden.
-- Jeez
|
|
From: Tim O. <in...@gm...> - 2006-02-11 13:39:43
|
Dingsi wrote: >Mmh, zu den Bildern fällt mir dann auch gleich noch ein Problem ein. Den >Text kann man ja recht einfach über das IRC-Protokoll ablaufen lassen, >aber das mit den Bildern? Vielleicht DCC? Damit könnte man u.U. noch >kompatibel zu normalen IRC-Clients bleiben, was ich gar nicht so >schlecht fände. > > DCC hat den Nachteil, daß man offene Ports braucht, die viele einfach nicht haben. Es ist schon di absolute Ausnahme, mit einem normalen Client Daten transferieren zu können. DCC ist für uns eindeutig zu unzuverlässig. Über P2P können wir den Kram nicht verschieben; vielleicht wäre FTP da geeigneter. Kleinere Datenpakete (bespielsweise die Spielerpositionen auf der Karte und Metadaten zu selbiger) könnte man auch per Base64 oder Base85 über's IRC verschicken (Base85 wäre besser, da geringerer Overhead). >Uff, Chat, Charaktere, Abenteuer, was brauchen wir noch? Brauchen wir >den ganzen Umfang der Wiege, vonwegen Basar, Locator, Reise, Metrik? >Dieser "Kleinkram" wie Würfelskript... mh.. einfach per Skript >implementieren? > > - Zuerst mal brauchen wir ein Wiege-Äquivalent. - Dann brauchen wir eine erweiterte Wiege, die Dinge wie Autoerstellung von Charakteren nach Templates oder Inventarverwaltung sowie den Export in diverse andere Formate unterstützt. - Dann brauchen wir einen IRC-Client, in den wir obigen Kram einstöpseln könnnen (siehe unten). - Und der Client muß noch Zusatzfunktionalität wie Skriptfähigkeit (BSF klingt toll), Karten etc. kriegen. Die Metrik kann man nebenbei als Plugin realisieren. Der Basar wäre nett, aber ich habe nicht die nötigen Regelwerke. Das leiche gilt für Reise etc. - und ohne die brauchen wir den Locator nicht. Die Würfelskripte etc. sollte man IMO als Paket machen, das je nach geladener Umgebung geladen wird - siehe unten. >Noch ein Anliegen: Wollen wir uns strikt auf DSA festlegen, oder am >besten Versuchen, das ganze so modular zu halten, dass man >möglicherweise das ganze auch zu einem Shadow Run Client machen kann? > An sich reicht es, wenn der IRC-Client die Charakterverwaltung komplett als Plugin lädt; mit der Verwaltung sind dann Dinge wie die Würfelskripte assoziiert, die zusätzlich geladen werden. Die Verwaltung selbst sollten wir nicht modular machen, weil selbst zwischen den DSA-Versionen kaum was übrigbleiben würde, was man wiederverwenden kann. -- Jeez |
|
From: <do...@gm...> - 2006-02-13 19:47:01
|
Tim Okrongli wrote: > Dingsi wrote: > >> Mmh, zu den Bildern fällt mir dann auch gleich noch ein Problem ein. Den >> Text kann man ja recht einfach über das IRC-Protokoll ablaufen lassen, >> aber das mit den Bildern? Vielleicht DCC? Damit könnte man u.U. noch >> kompatibel zu normalen IRC-Clients bleiben, was ich gar nicht so >> schlecht fände. >> >> > DCC hat den Nachteil, daß man offene Ports braucht, die viele einfach > nicht haben. Es ist schon di absolute Ausnahme, mit einem normalen > Client Daten transferieren zu können. DCC ist für uns eindeutig zu > unzuverlässig. > Über P2P können wir den Kram nicht verschieben; vielleicht wäre FTP da > geeigneter. FTP klingt gut. >> Noch ein Anliegen: Wollen wir uns strikt auf DSA festlegen, oder am >> besten Versuchen, das ganze so modular zu halten, dass man >> möglicherweise das ganze auch zu einem Shadow Run Client machen kann? >> > An sich reicht es, wenn der IRC-Client die Charakterverwaltung komplett > als Plugin lädt; mit der Verwaltung sind dann Dinge wie die > Würfelskripte assoziiert, die zusätzlich geladen werden. Die Verwaltung > selbst sollten wir nicht modular machen, weil selbst zwischen den > DSA-Versionen kaum was übrigbleiben würde, was man wiederverwenden kann. Und sind die Plugins umgesetzt? Per $SCRIPT_ENGINE eingebundene Skripte? Oder Java-Klassen? Ich wär ja für Skripte, wär flexibler. |
|
From: Tim O. <in...@gm...> - 2006-02-13 21:56:34
|
Thorben Müller wrote: > Noch ein Anliegen: Wollen wir uns strikt auf DSA festlegen, oder am > Und sind die Plugins umgesetzt? Per $SCRIPT_ENGINE eingebundene > Skripte? Oder Java-Klassen? > Ich wär ja für Skripte, wär flexibler. Das Problem ist dann aber, daß wir mit dem Skript eine komplette Swing-GUI erstellen müssen. Ich dachte bei den Plugins an ein Paket aus Java-Klassen, die an eine Schnittstelle andocken (für den Kram wie die Charakterverwaltung etc.), Skripten (Würfelskripte etc.) und allem, was man sonst für ein Spiel braucht. -- Jeez |
|
From: DFYX <df...@ly...> - 2006-02-14 00:54:34
|
Kleiner Nachtrag: als Formate, um die GUI aufzubauen, fallen mir zwei
sinnvolle M=F6glichkeiten (und noch mindestens eine nicht ganz so sinnvol=
le)
ein. Beide mal anhand von je zwei Feldern f=FCr Zahlen von 1 bis 20 (evtl=
.
noch sch=F6n mit Pfeilen zum =E4ndern an der Seite) in einem JPanel
1. Ini
[Attribute]
Type=3DJPanel
Parent=3D_Frame
Width=3D100
Height=3D30
[Mut]
Type=3DNumber
Min=3D1
Max=3D20
Default=3D11
Parent=3DAttribute
[Intuition]
Type=3DNumber
Min=3D1
Max=3D20
Default=3D11
Parent=3DAttribute
2. XML
<!-- ... -->
<panel name=3D"Attribute" width=3D"100" height=3D"30">
<input>
<name>Mut</name>
<type>Number</type>
<min>1</min>
<max>20</max>
<default>11</default>
</input>
<input>
<name>Intuitiont</name>
<type>Number</type>
<min>1</min>
<max>20</max>
<default>11</default>
</input>
</panel>
<!-- ... -->
Das sollte beides recht leicht zu parsen und darzustellen sein. Per Skrip=
t
k=F6nnte man auf die Inputfelder dann =FCber ein assoziatives Array oder
=E4hnliches zugreifen, um Werte abzufragen oder zu ver=E4ndern.
Die nicht ganz so sinnvolle Idee w=E4re ein JEditorPane in dem einfach ei=
ne
HTML Seite dargestellt wird, wobei wir dann nicht so einfach eigene
Inputfelder (Slider, Tabellen etc.) definieren k=F6nnten. Daf=FCr w=E4re =
das recht
schnell eingebaut und w=FCrde ein sehr sch=F6nes und individuelles Design
erm=F6glichen.
|
|
From: Tim O. <in...@gm...> - 2006-02-14 10:02:10
|
DFYX wrote: >2. XML ><!-- ... --> ><panel name="Attribute" width="100" height="30"> > <input> > <name>Mut</name> > <type>Number</type> > <min>1</min> > <max>20</max> > <default>11</default> > </input> > <input> > <name>Intuitiont</name> > <type>Number</type> > <min>1</min> > <max>20</max> > <default>11</default> > </input> ></panel> ><!-- ... --> > > Dann können wir auch einfach sagen, daß das Interface als serialisierte JavaBeans vorzuliegen hat. Das könnte es dann auch einfacher machen, Dinge wie Layoutmanager einzubauen (und spätestens bei den Panels für's Hauptfenster brauchen wir die). Die einzige Frage, die sich mir stellt, ist ob bei JavaBeans die Methoden samt Code mitserialisiert werden. Ich habe nämlich eher weniger Lust, irgendeine Skriptsprache einbinden zu müssen, um auf den "Weiter"-Knopf drücken zu können. >Die nicht ganz so sinnvolle Idee wäre ein JEditorPane in dem einfach eine >HTML Seite dargestellt wird, wobei wir dann nicht so einfach eigene >Inputfelder (Slider, Tabellen etc.) definieren könnten. Dafür wäre das recht >schnell eingebaut und würde ein sehr schönes und individuelles Design >ermöglichen. > > "Schön und individuell" kann man auch "unintegriert und schwer kontrollierbar" nennen. Ich stimme dir bei "nicht ganz so sinnvoll" mal zu. ;) -- Jeez |
|
From: DFYX <df...@ly...> - 2006-02-14 02:06:58
|
Dann m=FCssen wir uns halt ne kleine Markupsprache f=FCr unsere GUIs implementieren. Einfach nur im Stil von HTML Forms mit Typ, Name und Defaultwert. Das sollte ja wohl relativ einfach machbar sein, wenns nur u= m einfache Oberfl=E4chen wie die Charakterverwaltung geht. |
|
From: DFYX <df...@ly...> - 2006-02-11 02:32:30
|
> IRC-Krams machen. Auch die GUI davon, wenn ich's auf die Reihe kriege. Dann mach hinne. Ich w=FCrd auch evtl. noch Codeelemente von DFC (Meinem = fast komplett fertigen Projekt f=FCr den Contest, das ich immer noch hier schlummern hab) beisteuern, falls Bedarf besteht. |
|
From: DFYX <df...@ly...> - 2006-02-11 02:34:52
|
Deine Ideen find ich durchweg gut. Welche Skriptsprache wir verwenden, is mir eigentlich recht egal, ich hab bisher keine von den genannten wirklic= h verwendet. Nur halt ein kleines bisschen JS f=FCr Webseiten, wenns wirkli= ch nicht anders geht. Ob ich das dann implementier, kann ich noch nich sagen= , aber ich denk schon. Wird ja im Vergleich zum Rest nich so schrecklich vi= el Arbeit sein. |
|
From: Dingsi <do...@gm...> - 2006-02-11 12:41:31
|
Wie gesagt, wir können auch versuchen das BSF ( http://jakarta.apache.org/bsf/ ) zu benutzen, dann müssten wir uns im Code eigentlich nur um eine zentralen Skriptinterpreter kümmern (dem BSFManager, dem man ggf. nur noch BSFEngines für z.B. JRuby übergeben muss) und hätten schon ganz von selbst etliche Sprachen unterstützt. >Deine Ideen find ich durchweg gut. Welche Skriptsprache wir verwenden, is >mir eigentlich recht egal, ich hab bisher keine von den genannten wirklich >verwendet. Nur halt ein kleines bisschen JS für Webseiten, wenns wirklich >nicht anders geht. Ob ich das dann implementier, kann ich noch nich sagen, >aber ich denk schon. Wird ja im Vergleich zum Rest nich so schrecklich viel >Arbeit sein. > > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 >_______________________________________________ >Dsaster-devel mailing list >Dsa...@li... >https://lists.sourceforge.net/lists/listinfo/dsaster-devel > > > |
Thanks for helping keep SourceForge clean.
X