Projekt "EnVisNov" gestartet. Gebt mir Eure Ideen!

[Regenduft]

Endlich habe ich die Zeit gefunden mit dem lange angekündigte Projekt zu beginnen:

... EnVisNov...
Engine für Visual Novels

(Falls es jemanden interessiert, wie ich auf den komischen Namen gekommen bin: Ich habe solange "Engine", "Visal" und "Novel" durch den Mixer gedreht, bis Google keine Ergebnisse mehr ausgab. )

Nun sind eure Ideen gefragt!

Ich fände ein kleines Brainstorming (für Menschen mit deutschkenntnissen: eine Ideensammlung) vor dem losprogrammieren sehr praktisch, also:
Schreibt einfach mal bitte alles, was ihr euch von dem fertigen Programm wünschen würdet!
Es kommt dabei nicht auf Sinn oder Stimmigkeit an. Es macht auch nichts wenn eine Idee mehrfach auftaucht. Es macht auch nichts, wenn manche Ideen sich gegenseitig ausschließen! Es kommt mir mehr darauf an, zunächst "Material" zu erhalten, welches dann sortiert werden kann und worüber man abschließend um Sinn und Unsinn diskutiert kann.

Ich mache einfach mal den Anfang, damit jeder weiß, was ich meine (...mit einem unstilistischen Doppelposting...)

[Regenduft]

So! Hier mal mein "Gehürnstürm":

• Hintergrundbilder
• Charakterbilder
• Musik
• Sprachausgabe
• Klangeffekte
• OS-unabhängig (1. Windows; 2. Linux; 3. MacOS)
• diverse Grafikformate (BMP, JPEG, JPEG2000, PNG, TGA, TIFF)
• diverse Audioformate (Wave, FLAC, OGG Vorbis und zusätzlich Codec-gestützt)
• Musik auch als Tracker-Modules (ProTracker, FastTracker, ImpulseTracker...)
• Videosequenzen (Codec-gestützt; Vollbild oder z.B. auf den Bildschirm eines Fernsehers im Hintergrundbild gelegt)
• Charakter optional als "Anziehpuppen" (Körperhaltungen, Gesichtsausdrücke, Klamotten usw. als EINZELNE Grafiken, die dann kombiniert werden können)
• Variablen (für Punktestände, Merker, Inventar oder sonstige "Besonderheiten")
• Bildschirmformat-unabhängig (4:3, 16:9 usw.)
• Auflösungsungs-unabhängig (640×480, 800×600, 1024×768 usw.)
• Wiederholungsraten-unabhängig (60Hz, 70Hz, 100Hz usw.)
• Ingame-Menüs (Objekte wie Buttons, Schieberegler, Häkchenfelder usw.)
• Spielstände (optional mit festen Speicherpunkten)
• Benutzerprofile
• Ausblendfunktion für Steuerelemente
• Passwortgeschützte Cheats (für die Fehlersuche)
• optionale Onlinefähigkeit (benötigte Sounds, Grafiken usw. werden bei Bedarf oder kontinuierlich im Hintergrund heruntergeladen -> d.h. das Spiel kann gestartet werden BEVOR es komplett installiert wurde, es sind regelmäßig erscheinende Episoden möglich u.ä.)
• Automatischer Abspielmodus mit Geschwindigkeitsregler
• Optionales eigenes Containerformat mit optionalem Packer (JCalG1-Algorhythmus) und optionaler Verschlüsselung (AES-Algorhithmus im CBC- oder EBC-Modus), um (wenn so gewollt) "massive" Szenenpakete zu erstellen und das nachträgliche Verändern und das "Herausklauen" von Dateien durch dritte zu erschweren.
• Skriptsprache zum erstellen der Szenen
• Eine Grafische Entwicklungsumgebung
• Eine Spielplattform (sozusagen ein kostenlosen Steam für Visual Novels... *träum*)
• Ein Ingame-Storyboard (damit man beim wiederholten Spielen sagen kann: "Ah! Das letzte mal habe ich so reagiert, darum mache ich jetzt etwas anderes, mal sehen wie sich die Geschichte dann entwickelt.")
• "Vorrausschauendes Laden" (d.h. Grafiken, Sounds und Co. werden bereits "kurz" bevor sie benötigt werden parallel im Hintergrund geladen oder heruntergeladen.)
• Mini-Games (Tik-Tak-Toe, Wimmelbilder o.ä.)
• Beleuchtungs- und Grafikeffekte (z.B. alle Grafiken vergrauen und ein Charakter wird mit einem Spotlight hervorgehoben u.ä.)
• Dynamische Grafiken (z.B. ein fließender Wasserfall im Hintergrund)
• Wetter- oder Partikel-Effekte (z.B. rieselnder Schnee oder Regenfall im Hintergrund)
• "Vollbild-Effekte" (z.B. ein Charakter erhält eine Ohrfeige, warauf hin das gesamte Bild kurz wackelt)
• Ein-, Aus- und Überblendungen von Grafiken und Sounds
• Optionale Steuerung (Maus, Keyboard, Joystick, Gamepad... gibt's noch was?)
• Mehrsprachig (Entwicklungsumgebung und zu erstellende Spiele)
• Unicode- statt ASCII-Texte (z.B. werden dann Umlaute IMMER korrekt angezeigt und es sind auch japanische Schriftzeichen möglich usw., allerdings benötigt dann ein Buchstabe im Arbeitsspeicher 2 anstatt 1 Byte.)
• getrennte Lautstärkeregelung (Gesamt, Sprache, Klangeffekte, Musik)
• Kindersicherung (oder "Elternsperre" oder soetwas in der Art)
• ...genug erstmal... Jetzt seid Ihr dran! ... Kann, aber muss auch nicht so eine lange Liste werden. Einfach frei losschreiben, ohne zu beachten, was jemand anderes bereits geschrieben hat!

[Der Tor]

Heu... du hast ja schon ziemlich hohe Ansprüche an dein eigenes Produkt (-:

Ich bin da eher bescheiden (-:

Was ich mir von einer neuen VN-Engine wünschen würde sind natürlich in erster Linie Sachen die bei den Bisherigen VN-Engines noch nicht vorhanden sind. Die größte Schwachstelle der bisherigen VN-Engines ist natürlich das sie (mit Ausnahme von Ren'Py) fast alle auf japanisch sind. (was sie für die meisten von uns bereits gänzlich untauglich macht - weil selbst wenn man japanisch kann, so laufen diese Programme und die damit erstellten Spiele nur mit erheblichen Problemen oder enormen Aufwand auf deutschen Rechnern).

Ich glaube Ren'Py ist bisher die einzige VN-Engine mit einer deutschen Version, also zähl ich einfach die schwächen von Ren'Py auf, was dann natürlich auch genau die Sachen sind die ich mir von einer neuen VN- Engine wünschen würde.

Nachteile von Ren'Py:

1. Es gibt zwar eine deutsche Version, aber es ist keine ofizielle deustche version und es ist nur eine sehr grobe unvollständige Übersetzung mit vielen Fehlern. Fakt ist um wirklich im praktischen Leben mit Ren'Py Spiele erstellen zu können muss man immer noch zwingend und ziemlich gut englisch beherrschen sonst geht fast gar nix. Was ich mir also von einer neuen Engine wünschen würde ist die Möglichkeit auch ohne englischkenntnisse mit ihr in der Lage sein zu können Spiele zu erstellen.

2. Ren'Py basiert natürlch auf Python. Das heißt man kommt nicht drumm rum einige Grundlagen von Programmiersprachen wie Phyton können zu müssen, sonst lässt sich damit so gut wie gar nix anfangen. Was ich mir also von einer neuen VN-Engine wünschen würde ist das sie nicht auf Phyton basiert, bzw. man wenigstens nicht selbst Befehle in Python schreiben muss um sie verwenden zu können.

3. Es gibt bisher keine VN-Engine bei der es offiziellen deutschen Support gibt (weil die Programmierer bisher eben alles keine Deutschen waren). Was ich mir also von einer neuen VN-Engine wünschen würde ist das es deutschen Support bei Fragen gibt.

[Misato]

Ren'Py ist nicht die einzige englischsprachige Visual Novel Engine. Es gibt auch noch Blade: http://www.bladeengine.com

Der Unterschied ist das Blade einfacher zu bedienen, aber auch simpler ist als Ren'Py. Für Blade braucht man keine Python Befehle zu können, aber dafür hat Blade auch kaum irgendwelche Features und unterstützt noch nicht einmal Umlaute.

[Regenduft]

Heu... du hast ja schon ziemlich hohe Ansprüche an dein eigenes Produkt (-:

Darum habe ich "Brainstorming" gesagt: Ich habe einfach mal "drauflosgesponnen". Was umsetzbar oder überhaupt sinnvoll ist sortiere ich später aus.

(...) Die größte Schwachstelle der bisherigen VN-Engines ist natürlich das sie (mit Ausnahme von Ren'Py) fast alle auf japanisch sind. (...) so laufen diese Programme und die damit erstellten Spiele nur mit erheblichen Problemen oder enormen Aufwand auf deutschen Rechnern. (...) Was ich mir also von einer neuen Engine wünschen würde ist die Möglichkeit auch ohne englischkenntnisse mit ihr in der Lage sein zu können Spiele zu erstellen. (...) Was ich mir also von einer neuen VN-Engine wünschen würde ist das es deutschen Support bei Fragen gibt.

(...) Blade (...) unterstützt noch nicht einmal Umlaute.

OK, eine gute Lokalisierung steht nun ganz oben auf meiner Prioritätenliste: Entwicklungsumbebung (inkl. Doku) und erstellte Spiele sollten immer "richtig komplett" übersetzt/übersetzbar sein. Sonderzeichen wie z.B. Umlaute sollten problemlos möglich sein, ebenso wie andere (nicht lateinische) Schriften inkl. Rechts-nach-links-Schreibung. (Da war ich mit dem Punkt "Unicode- statt ASCII-Texte" wohl goldrichtig gelegen ).
Deutscher Support ist bei einem deutschen Programmierer natürlich gegeben! Englisch ist auch kein Problem, auch wenn mich Amis immer wegen meiner britischen Rechtsschreibung für 'nen Franzosen halten (z.B. "colour", "metre" oder "centre").

(...) Was ich mir also von einer neuen VN-Engine wünschen würde ist das sie nicht auf Phyton basiert, bzw. man wenigstens nicht selbst Befehle in Python schreiben muss um sie verwenden zu können. (...)

(...) Blade einfacher zu bedienen, aber auch simpler ist als Ren'Py. Für Blade braucht man keine Python Befehle zu können, aber dafür hat Blade auch kaum irgendwelche Features (...) .

Hmmm... das klingt nach einer Gratwanderung...
Einerseits: Eine einfache und intuitive Bedienung ist wünschenswert, bei der man (zumindest fast) keine Ahnung vom Programmieren haben muss.
Andererseits: Genau so wünschenswert ist es auf viele tolle Features zugreifen zu können und möglichst frei und flexibel in der Gestaltung zu sein, ohne auf ein "Das-geht-so-nicht" zu stoßen oder irgendwelche "workarounds" erfinden zu müssen.

Hier hätte ich mal ein paar Grundansätze (der Übersicht zu liebe getrennt dargestellt, praktisch aber "vermischbar"):

1. Symbolische Skriptsprache
2. Flussdiagramm statt Skriptspache
3. Multilinguale Skriptsprache

Zu a. Symbolische Skriptsprache:
Beschreibung: Funktionen werden als Piktogramme dargestellt. Grüne Diskette = laden; Lautsprecher = Sound; Mund = Sprache; ...
Pro: Non-verbal (Übersetzung wird gespart); intuitiv; übersichtlich kompakt
Contra: Quelltexte können nicht einfach (z.B.) in ein Forum geposted werden sondern es müssen Screenshots gemacht werden; wenn die Piktogramme per Maus gesetzt werden, muss immer zwischen Tastatur und Maus gewechselt werden, was den Arbeitsfluss behindert; wenn die Piktogramme per Tastatur (z.B. F-Tasten) gesetzt werden, ist die Intuivität wieder gering; Piktogramme können bei ungünstiger Gestaltung wiedersprüchlich oder falsch augenommen werden (z.B. Mund = geschriebene oder akkustische Sprachausgabe?)

Zu b. Flussdiagramm statt Skriptspache:
Beschreibung: Ich lass mal Wikipedia beschreiben . Hier 2 Beispiele: Programmablaufplan oder Nassi-Schneiderman
Pro: übersichtlich, flexibel
Contra: mögen viele einfach nicht; ungewohnt; nicht immer eindeutig

Zu c. Multilinguale Skriptsprache:
Beschreibung: Für eine Funktion existieren mehrere Ausdücke
Pro: Jeder kann seinen "eigenen Stil" ausleben
Contra: unübersichtlich; erschwert Austauschbarkeit; sehr schwer zu erstellen und zu pflegen (also für mich, nicht für den Nutzer )

Ich hätte eigentlich noch ein paar andere Fragen/Anregungen, komme langsam aber unter Zeitdruck und eigentlich ist ja oft weniger mehr, daher die Abschließende Frage: "Was meint Ihr dazu?"

PS: Danke für die Anregungen!

[Der Tor]

Ich persönlich würde ja zu Option a. oder b. tendieren. Ganz einfach weil das bisher noch nicht da war und es das ganze für die meisten Anwender wirklich vereinfachen würde. Natürlich wenn ich an mich selber und rein egoistisch denken würde, wäre ich natürlich von Option c. total angetan. Weil ich hab mir früher in meiner Schulzeit Basic und Visual Basic beigebracht und dann von der Schule aus musste ich dann aber auch noch C++ lernen und jetzt in letzter Zeit hab ich ein bisschen Python mitgenommen was dazu führt das ich ständig alles durcheinander werfe

Nein, aber jetzt ernsthaft a. oder b. ist das sinnvollste und für den Benutzer am einfachsten und würde es im Vergleich mit den bisherigen Programmen wirklich abheben und für den Anwender deutlich einfacher machen.

Ich freue mich natürlich das es überhaupt jemanden gibt der sowas machen will und ich finde das toll, weil es könnte wirklich dazu führen die Anzahl der deutschen Visual Novels zu erhöhen und es jedem nahe bringen selbst eine Visual Novel zu machen. Aber letzten Endes musst du es wissen und vor allem du musst auch deine Möglichkeiten und Zeit abschätzen. Wenn du sagst das du es schaffen kannst würden sich bestimmt viele Leute darüber freuen. Du musst aber bedenken das der Dank der Leute erst wirklich kommt NACHDEM du etwas fertig gemacht hast und bis dahin ist es evtl. eine schwere Zeit und es ist allzu leicht ein Projekt anzufangen und es dann aber auf halbem Weg aufzugeben (glaub mir das weiß ich aus Erfahrung - ich hätte längst mehr von Koenchu Yonogi Seiyu weiterübersetzen sollen - ich schau das ich heute dazu komme ).

[Regenduft]

Ich persönlich würde ja zu Option a. oder b. tendieren. (...) Natürlich wenn ich an mich selber und rein egoistisch denken würde, wäre ich natürlich von Option c. total angetan.

Gleich 3 Wünsche auf einmal!? Das geht jetzt aber wirklich nicht...Doch! Mit EnVisNov-Überraschung!
Ich hab' mir das ganze so gedacht: Die Projekte werden als getrennte Skripte gespeichert (Charakterdefinitionen, Sczenen...) und die IDE (= Entwicklungsumgebung) visualisiert das entsprechend. Also der Szenenablauf als Flußdiagramme, die einzelnen Szenen dann als symbolische und/oder multilinguale Skripte.
Der Große Vorteil: Am Anfang kann ich erstmal ohne IDE loslegen.

(...) Basic und Visual Basic (...) dann auch noch C++ lernen und (...) ein bisschen Python mitgenommen was dazu führt das ich ständig alles durcheinander werfe.

Kenn ich... bei mir war's (chronologisch) C64-Basic, QBasic, Amiga-Basic, GFA, Amos, Blitz, Visual Basic, C (ohne +)... jetzt bin ich seit ein paar Jahren bei PureBasic und liebe es! Zwei Entwickler (ein Franzose und ein Deutscher), super Community und man spart sich einen haufen Schreibarbeit, da es viele komplexe Funktionen gibt, 'ne einfache Syntax und nicht irgenwelche Bibliotheken einbinden muss, da einfach diejenigen eingebunden werden, die man beim Proggen verwendet hat UND man muss nur einen einzigen Code schreiben, den man dann auf Windows und Linux (jeweils 32- und 64-Bit), MacOS (Intel und PowerPC) und (eingeschränkt) sogar für AmigaOS (68k) kompilieren kann, ohne irgendetwas anpassen zu müssen, außer man nutzt irgendwelche OS-APIs, was man dann aber mit einem "CompileIf OS = xxy" auch schön strukturieren kann... *hüst* Sorry... bin etwas ins Schwärmen geraten...

Ich freue mich natürlich das es überhaupt jemanden gibt der sowas machen will und ich finde das toll, weil es könnte wirklich dazu führen die Anzahl der deutschen Visual Novels zu erhöhen und es jedem nahe bringen selbst eine Visual Novel zu machen.

Danke für die Blumen aber dass ich der "Firestarter" der deutschen VN-Szene werde bezweifel ich doch sehr.

Du musst aber bedenken das der Dank der Leute erst wirklich kommt NACHDEM du etwas fertig gemacht hast und bis dahin ist es evtl. eine schwere Zeit und es ist allzu leicht ein Projekt anzufangen und es dann aber auf halbem Weg aufzugeben (glaub mir das weiß ich aus Erfahrung - ich hätte längst mehr von Koenchu Yonogi Seiyu weiterübersetzen sollen - ich schau das ich heute dazu komme ).

Da hast Du recht, aber ich Progge das Ding hauptsächlich erstmal für mein eigenes Vergnügen (ja, ich bin so ein "Ich zerbreche mir gerne stundenlange zum Vergnügen den Kopf"-Mensch). Übersetzen find ich da zermürbender... habe da auch ein wenig Erfahrung... am Anfang läuft's ruck-zuck, aber wenn dann eine "kritische" Stelle kommt, wo es ein "so oder so?" gibt wird's blöd. Vor allem wen man später in der Übersetzung merkt, dass man sich doch für das schlechtere "so" entschieden hat und irgendwann den Überblick verliert.

Aber zurück zu EnVisNov: Ich schätze in einem Monat hab ich 'ne kleine Grundversion (hab schon angefangen). Bis dahin heißt es jetzt wohl weiter "ranklotzen".
(Hihihi! Der Smilie is' so geil!)

Danke für Kritik und Anregungen! (kann man nicht oft genug sagen)

[Akures]

Zur Gradwanderung zwischen Einfacher Bediehnung und Komplexitaet faellt mir der RPG Maker 3D ein, dort gab es einfache Scriptmasken, aber auch die Moeglichkeit direkt im Code rumzufuschen.

Klangeffekte
Wetter- oder Partikel-Effekte (z.B. rieselnder Schnee oder Regenfall im Hintergrund)

Hier kann man sicher eine Menge machen.
Was mir an vielen VNs bisher gefehlt hat waren anstaendige Hintergrundgeraeusche.
Mit allen mir bekannten VN Engines kann man auch nur einfach eine eine Sounddatei abspielen oder nicht, und bestenfalls noch die Lautstaerke regulieren.
Wovon ich aber schon immer traeume sind dynamisch erzeugte Soundkulissen, insbesondere fuer Wettereffekte.
Leider habe ich nichtmal ansatzweise eine Idee wie man so etwas erzeugen koennte.
Einfacher waehre es da vielleicht feste Soundeffekte in der Tonhoehe, also Abspielgeschwindigkeit, zu manipulieren, und die Moeglichkeit sie in einem 3D Raum zu positionieren. So das man mit nur wenigen Sounds eine dynamische Klangkulisse erzeugen kann, schaetze ich...

Bei Grafikeffekten faende ich es interessant wenn man auch mit Beleuchtungsmasken arbeiten koennte, also farbige Masken die auf bestimmte Grafikebenen hinzuaddiert werden. Am besten natuerlich noch dynamisch erzeugt.
Man koennte geometrische Formen definieren mit einer festen Beleuchtung die dann gleichmaessig, natuerlich auch nach festgelegtem Faktor, abnimmt.

Ich denke damit kann man schoene Algorythmen schreiben um so ziemlich alle Wetter Effekte zu erzeugen, sowie Beleuchtung dynamisch zu simulieren.

[Regenduft]

Hey-hey-hey! Ein paar echt gute Punkte!

Zur Gradwanderung zwischen Einfacher Bediehnung und Komplexitaet faellt mir der RPG Maker 3D ein, dort gab es einfache Scriptmasken, aber auch die Moeglichkeit direkt im Code rumzufuschen.

Im Endeffekt wollte ich das so realisiere, dass der Nutzer im Normalfall überhauptnicht mit der Skriptebene in Kontakt kommt, sonder das ganze "visuell zusammelwürfelt". Nur im Sonderfall kann man dann sozusagen "lowlevel" im Skipt rumpfuschen. Den RPG Maker 3D kenne ich leider nicht.

Wovon ich aber schon immer traeume sind dynamisch erzeugte Soundkulissen, insbesondere fuer Wettereffekte. (...) Einfacher waehre es da vielleicht feste Soundeffekte in der Tonhoehe, also Abspielgeschwindigkeit, zu manipulieren, und die Moeglichkeit sie in einem 3D Raum zu positionieren. So das man mit nur wenigen Sounds eine dynamische Klangkulisse erzeugen kann, schaetze ich...

So etwas hatte ich in einem früheren Projekt mal versucht (hat auch prinzipell funktioniert), wenn ich richtig verstehe, was Du meinst.

Beispiel "dynamische Wetterfunktion"
Windstärke-Parameter: Nullpunkt (0=windstill; negativ=links; positiv=rechts), Abweichungsfrequenz & -amplitude, Zufallstolenranzen
Regen-Parameter: Nullpunkt-Dichte, Abweichungsfrequenz & -amplitude, Fallgeschwindigkeit, Zufallstolenranzen (Dichte, Frequenz & Amplitude)
Gewitter-Parameter: minimales/maximales Blitzintervall, minimale/maximale Donnerverzögerung (sozusagen Gewitterentfernung)
Partikel-Parameter: entweder dynamisch erzeugte Partikel (Regen, Schnee, Funken, Ruß, Hagel...) oder benutzerdefinierte Partiken (Partielgrafiken verwenden)
Sound-Parameter: Regenplätschern, Hagelklimpern, Windbrausen... die Sound halt! Einfache "Zischlautsche" könnte man theoretisch auch dynamisch erzeugen, allerdings glaube ich das vorgerenderte oder digitalisierte Soundschleifen besser klingen.

Die Werte betreffen dann immer Sound UND Grafik. Z.B. würde die aktuelle Windstärke die Tonhöhe und -lautstärke des Windsounds sowie Richtung und Stärke, in welche die Regen-Partikel geblasen werden, beinflussen.
Hast Du Dir soetwas darunter vorgestellt? An der genauen "Parameter-aufstellung" müsste man halt noch arbeiten.
Für die Bequemlichkeit: Standardwerte für nicht verwendete Parameter.
Für die Komplexität: Möglichst viele Parameter zur genauen Wunschdefinition.
Für Bequemlichkeit UND Komplexität: vordefinierte und benutzerdefinierte (wiederverwendbare) "Umgebungssets" (Nieselwetter, Sturmgewitter, milder Scheefall...)
Falls jemand Lust auf 'ne Ideensammlung für Parametersets hat: Einfach losposten! Muss nicht unbedingt perfekt sein, sondern kann auch einfach 'ne Inspiration sein!
Die Steuerung könnte man auch schön visuell umsetzen: (Hauptsächlich) einfach ein paar Schieberegler!

Zum Thema 3D-Sound und Echtzeit-Soundeffekte: Einfachste Echtzeiteffekte wie Echo, Hall und Phaser traue ich mir problemlos zu. Pitching sowieso. Pitchshifting, Timestreching u.ä. (inkl. Overlapping etc.) würden mich überfordern (nicht in der Anwendung, aber in der Programmierung ). Es gibt zwar schöne 3D-Sound Funktionen in PureBasic, allerdings sind diese für die direkte verwendung mit der 3D-Grafik Engine gedacht (OGRE), also ungeeignet. Kleine "Pseudo-3D" Effekte könnte ich mir evtl. vorstellen, aber die liegen wirklich schon ganz am Ende meiner Vorstellungsgraft... Ausser eine Stereo-Signalverzögerung fällt mir da nix ein... EAX oder sowas entzieht sich komplett meiner Kenntnis! Ich könnte höchtens mal in den PureBasic-Foren suchen, ob sich jemand damit auskennt, aber das ist (zumindest für den Anfang) zu aufwendig (man muss bedenken: Einmannprojekt! ). Es gibt zwar auch gute frei verwendbare Audio-DLLs von Drittanbietern (z.B. IrrKlang), aber auch dies wäre mir im Moment zu anstrengend, vor allem, weil ich Null Erfahrung damit habe und mich komplett einarbeiten müsste.

Bei Grafikeffekten faende ich es interessant wenn man auch mit Beleuchtungsmasken arbeiten koennte, also farbige Masken die auf bestimmte Grafikebenen hinzuaddiert werden. Am besten natuerlich noch dynamisch erzeugt.
Man koennte geometrische Formen definieren mit einer festen Beleuchtung die dann gleichmaessig, natuerlich auch nach festgelegtem Faktor, abnimmt.

Sehr geile Idee!!! Einfach (z.B.) einen Gradient (Frabverlauf) von weiß nach schwarz (oder "farbig" nach schwarz) in Dreiecksform dynamisch erzeugen und dann "überblenden", fertig ist das Spotlight aus der Seitenansicht! Purebasic liefert da geniale Zeichenfuntionen um einfach Farbverläufe zu erzeugen (wie gesagt: Einmannprojekt! ). Oder ein paar bunte ausgefüllte Kreise als Fabfilter über die Szene sausen lasen (Bewegung z.B. per einfachen Winkelfunktionen) und fertig ist die Diskoneleuchtung!
Einziges Problem: Ich blick's noch nicht ganz mit den DirectX-Blendingfunktionen (bzw. OpenGL für Linux)... Ich kann Sie zwar alle Problemlos verwenden, verstehe aber nicht ganz das Prinzip mit dem Quell- und Zielmodus. Ich kenne gängige Kombinationen um gewünschte Effekte zu erzielen, aber es ist ein schlechter Stil "den Taschenrechner zu verwenden bevor man das Ein-mal-Eins im Kopf hat".
Falls sich jemand dafür interessiert, einfach in Google "DirektX" und ein oder zwei der folgenden Konstanten suchen: D3DBLEND_ZERO, D3DBLEND_ONE, D3DBLEND_SRCCOLOR, D3DBLEND_INVSRCCOLOR, D3DBLEND_SRCALPHA, D3DBLEND_INVSRCALPHA, D3DBLEND_DESTALPHA, D3DBLEND_INVDESTALPHA, D3DBLEND_DESTCOLOR, D3DBLEND_INVDESTCOLOR, D3DBLEND_SRCALPHASAT, D3DBLEND_BOTHSRCALPHA, D3DBLEND_BOTHINVSRCALPHA

BTW: Vollbildfarbfilter und Spritefarbfilter sind absolut kein Problem!

Danke für die wirklich sehr gute Inspiration! (Ich hoffe der Satz lutscht sich nicht ab, denn ich meine es ernst!)

EDIT: Sitzt Du eigentlich (klischeegerecht) an 'ner japanischen Tastatur oder warum fehlen Dir die Umlaute?

[Akures]

Die Werte betreffen dann immer Sound UND Grafik. Z.B. würde die aktuelle Windstärke die Tonhöhe und -lautstärke des Windsounds sowie Richtung und Stärke, in welche die Regen-Partikel geblasen werden, beinflussen.
Hast Du Dir soetwas darunter vorgestellt? An der genauen "Parameter-aufstellung" müsste man halt noch arbeiten.

Joa, in etwa so habe ich mir das Vorgestellt.
Dazu noch Umgebungspresets (natuerlich mit freier Anpassungsmoeglichkeit) zB.:
Wald - Blaetterrauschen und Zeige-/Aesteknacken abhaengig vom Wind, Regen auf Blaetter Sounds
Hoehle - tiefere, 'roehrende' Windeffekte, vielleicht auch inklusive Wassertropfen
Urban - Regen auf Asphalt bzw befesstigten Untergrund sowie auf Wasser (schnellere Pfuetzenbildung)
Inneraum, wahlweise mit und ohne Fenster - Regen der (bei starkem Wind) gegen die Scheibe peitscht, und eine allgemeine Daempfung der Wettersounds

Also auch die Moegelichkeit des Kopelns von verschiedenen Soundeffekten, wenn sie (hauptsaechlich) von den gleichen Parametern abhaengen.

Und noch eine Sache zu den graphischen Wetter Effekten. Sie sollten auf keinen Fall nur auf einen Layer beschraenkt sein. In der VN Snow wurde mir wunderbar demonstriert wie athmosphaerisch es wirken kann, wenn ein Layer mit wenigen grossen Schneeflocken vor dem Characterlayern, und eine Anzahl von Layern mit vielen und kleineren Flocken dahinter plaziert wird.

EDIT: Sitzt Du eigentlich (klischeegerecht) an 'ner japanischen Tastatur oder warum fehlen Dir die Umlaute?

(Leider) nein, bin nur zu bequem und verwoehnt um auf das deutsche Tastatur Layout zu wechseln.
Bin inzwischen viel zu sehr an das japanische Layout gewoehnt(welches im Standardmodus fast wie das englische ist). Und fuers programmieren ist es auch noch megapraktisch (im Gegensatz zum Deutschen).