- Der Anregungs-Thread für das PaC-DK -

[Schiman]

Ich hab auch noch einen Vorschlag zum PaCDK:

Ich würde es gut finden, wenn man den speech-Text, oder generell alle Textausgaben unterlegen könnte - Vielleicht mit einer einfachen Box oder sowas, in der der Text dann gezeichnet wird. (Evtl noch transparent einstellbar?) Dies würde den Text einfacher lesbar machen. Bei Hintergründen mit vielen Details finde ich die Textausgabe manchmal etwas anstrengend. Problematisch ist vor allem, das sich die Outline-Farbe nicht einstellen lässt (ist immer schwarz). So ist man quasi gezwungen für die Schrift eine helle Farbe zu verwenden. Wenn die Szenerie des Spiels dann auch eher hell ist, wirds manchmal anstrengend.

Der Vorschlag ist gut. Bist aber nicht der Erste, der das vorschlägt. Ich bezweifle, dass das jemals implementiert wird.

[Baelavay]

Ja, einen optionalen gefüllten Rahmen hinter den „showinfo()“-Zeilen, vergleichbar mit der Windows-Quickinfo, halte ich nach wie vor für notwendig damit der Text auf allen Hintergründen lesbar ist. Bei GCV Version 0.1 habe ich mir glaube ich auch mit Outlines geholfen.

*edit: ursprünglicher Vorschlag

Es gibt zwei Gründe, weshalb ich mir einen Kasten hinter der Infozeile wünsche: Erstens suche ich seit langem vergeblich in den Grundeinstellungen meines Spiels nach einem Farbton, der sich von jedem Hintergrund der Maps in meinem Projekt abhebt, gleichzeitig aber auch zum Design passt (also kein schweinchenrosa o.ä.), zweitens würde es nach meinem persönlichen Empfinden schlichtweg besser aussehen. Ich meine, jeder kennt doch die windows-typischen Quick-Infos, die erscheinen, verweilt man längere Zeit mit der Maus über einem Icon. Für mich war die "showinfo()"-Textzeile immer eine Art vereinfachte Quick-Info. Stell dir doch mal die System-Infozeile ohne den gelben Balken vor - das geht ja wohl mal gar nicht

Ich will dich natürlich zu keinem neuen Feature drängen, hast ja schon viel für mich am PaC-DK verbessert. Kannst du dir aber vorstellen, einen optionalen (!) "Kontrastkasten" hinter den Infozeilen zu integrieren - oder wäre das überhaupt machbar? Hier noch zwei kleine Pics um dich von der Notwendigkeit zu überzeugen:


Man kann sich wahrscheinlich vorstellen wir das auf dunklerem Untergrund aussehen würde (das stellt jetzt einfach mal ein Adventure-Objekt "Arbeitsplatz" dar ) - oder weiße/ graue Schrift auf hellem Untergrund...

[HeXoR]

Ich bezweifle, dass das jemals implementiert wird.

Sag niemals nie.

Es ist doch einfach eine Frage der Machbarkeit bzw. der notwendigkeit. Ob einer die Möglichkeit haben möchte oder mehrere. Ob irgend jemand oder jemand der schon längere Zeit aktiv hier und mit PacDK arbeitet dies gerne hätte, ist doch der entscheidende unterschied.

[Robin]

Es ist doch einfach eine Frage der Machbarkeit bzw. der notwendigkeit. Ob einer die Möglichkeit haben möchte oder mehrere. Ob irgend jemand oder jemand der schon längere Zeit aktiv hier und mit PacDK arbeitet dies gerne hätte, ist doch der entscheidende unterschied.

Die Machbarkeit ist eine Sache - wobei, der Text für Textszenen kann ja auch verschiedenfarbig unterlegt sein, also bin ich mal wieder als Foren-Trottel unterwegs und denke mir, es könnte doch nicht sooo schwer sein, auch Speech-Text farbig zu unterlegen?

Was die Notwendigkeit angeht: ich kann mir nicht vorstellen, das jemand in Tränen ausbricht, wenn die Möglichkeit bestehen würde, das man Textausgaben jederzeit unabhängig vor welchem farbenfrohen Hintergrund auch immer einwandfrei lesen kann. Ganz einfach aus dem Grund, weil es auch Leute gibt, die die eventuellen vorhandenen Sprachsamples nicht oder nur unvollständig verstehen (Gehörschäden) und die auf das Geschriebene angewiesen sind. Und wenn die das nicht richtig lesen können, wird's übel.
Also ich würde eine Möglichkeit zur farblichen Unterlegung der Texte begrüßen.

[Baelavay]

Ich frage mich, ab es nicht Sinn machen würde, den laufenden Spielablauf komplett pausieren zu können, etwa standardmäßig über eine F-Taste? Ich glaube schon, denn das wäre sowohl beim Spieletesten praktisch (Zeit zum Notizenmachen) als auch beim eigenen Bugfixing (soweit ich weiß läuft das Spiel bei geöffneter Konsole weiter).

[Schiman]

Ich habe auch einen Vorschlag, der mir schon seit über einem Jahr auf der Seele liegt, aber ich konnt mich nicht durchringen, weil ich das "Nein, weil Nein" an dieser Stelle einfach nicht hören will .

Und zwar geht es um die Geschwindigkeit von moveobj und fadespeed. Da sind ja Geschwindigkeitsangaben einzugeben (movobj von 0-9 und fade von 1-15).

Das hat mich schon immer bissel gestört. Ich fände es besser und sinnvoller, wenn man da einfach Zeitangaben reinstellen könnte. Etwas in er Art wie: moveobj(Objektname; x ; y; 2,3). Das würde heißen, dass das Objekt in 2,3 Sekunden am Zielort angekommen ist.
Bei fadespeed analog dazu.

Diese Option würde das Anpassen von fade und move unglaublich vereinfachen... Außerdem könnte man wirlich langsame Objektbewegungen und fadespeeds einfach realisieren.

Weiß nicht, ob das noch jemanden interessiert, aber ich fände das unglaublich vorteilhaft .

[Zimond]

eigentlich kein schlechter Vorschlag, ich könnte allerdings nicht gewährleisten das die Zeiten absolut genau stimmen würden, aber mal schauen

[Baelavay]

Super Idee, selbiges wäre auch für den "movetext()"-Befehl praktisch. Problematisch wäre es aber, alle bisher verwendeten "moveobj()"-Befehle in den Skripts rauszusuchen und zu aktualisieren.

Da möchte ich aber auch gleich anmerken was mir eben beim "movetext()"-Befehl aufgefallen ist - der Unterschied zwischen der Geschwindigkeit "8" und "9" (am langsamsten) ist zu groß, d.h. "8" sollte langsamer sein.

[Schiman]

Problematisch wäre es aber, alle bisher verwendeten "moveobj()"-Befehle in den Skripts rauszusuchen und zu aktualisieren.

Stimmt, daran habe ich auch schon gedacht... Aber sollte die Entwicklung des Tools daran hängenbleiben, weil wir keine Lust haben unsere Skripte zu aktualisieren? Also für mich wäre das ein kleines Übel im Vergleich zu dem großen Vorteil, den so eine Funktion bringen würde.

Da möchte ich aber auch gleich anmerken was mir eben beim "movetext()"-Befehl aufgefallen ist - der Unterschied zwischen der Geschwindigkeit "8" und "9" (am langsamsten) ist zu groß, d.h. "8" sollte langsamer sein.

Solche Schwierigkeiten würden natürlich mit der oben genannten Funktion Vergangenheit sein...

[Schiman]

Ich habe einen weiteren Vorschlag:

Malen im Pac-DK via Skript.

Was meine ich damit? Ich habe auch an der neuen Lightning-Funktion gesehen, dass es möglich ist im Pac-DK zu malen. Ich denke mal, dass Zimond bei der Funktion nichts anderes macht.

Wie wäre es nun eine Funktion draw zu implementieren, die es erlaubt via Skript im Spiel zu malen.
Da stelle ich mir konkret sowas vor:

setdrawcolor(R;G;B)
draw_line(Layer; Linienbreite;Start_x;Start_y;End_x;End_y)
draw_circle(Layer; Linienbreite;Mittelpunkt_x; Mittelpunkt_y; Radius in Pixel; filled)
drawclear(Layer)

Also.. setdrawcolor dürfte klar sein. draw_line ist einfach eine Linie von dem punkt Start zum Punkt End.
draw_circle dürfte klar sein. Das filled ist einfach true oder false für einen Kreis der gefüllt ist oder eben nur aus einer kreisförmigen Linie besteht.
Die Layer sind dafür da, dass man auf verschiedenen Ebenen malen kann und dann mit drawclear ganz spezielle Ebenen wieder ausradieren kann.

Damit könnte man Beispielsweise direkt im Pac_dk Implementieren, dass der Spieler etwas malen kann. Oder einen 3d würfel, der sich dreht usw.

Denkt darüber nach .

[HeXoR]

Und das braucht man wofür?

[Frigi077]

Damit könnte man Beispielsweise direkt im Pac_dk Implementieren, dass der Spieler etwas malen kann. Oder einen 3d würfel, der sich dreht usw

Hat er doch geschrieben

[Scarabaea]

fände linien auch nicht schlecht - würde sie in minigames gut brauchen können

[Schiman]

Und das braucht man wofür?

Unzählige Anwengungsmöglichkeiten gibt es dafür ^^. Nur ein wenig Fantasie.. In meinem Projekt wüsste ich schon was . Im Kampfsystem, das ich gerade entickle. Ich werde bald ne KS-Demo rausbringen, da werdet ihr verstehen, warum Malen nicht schlecht wäre^^.

[Zimond]

sowas hab ich mir auch schon überlegt... es wären da natürlich fragen zu klären wie bleibt ein gezeichnetes Objekt solange aktiv bis es gelöscht wird oder nur für einen Frame. Auf jeden fall ist das natürlich nichts was ich demnächst angehen würde sondern das kommt auf die "Nach Alühn 2"-Liste.

[Baelavay]

Ich hatte mich schonmal damit auseinandergesetzt, wie innere Monologe am besten umzusetzen seien. Das heißt der Spieler erfährt die Gedanken des Charakters. Dazu braucht man einen Speech-Befehl, aber die Reden-Animation soll nicht abgespielt werden, weil der Charakter das ja nur denkt.

Workaround 1: Offspeech
Workaround 2: Charakter für die Zeit des inneren Monologs ersetzen (hin- und zurückbeamen) durch einen Klon, dessen Sprechanimation leer ist

Da beide Workarounds viel zu umständlich sind, wenn man bedenkt, dass es eigentlich ganz gebräuchlich ist, den Charakter laut denken zu lassen, schlage ich einen "think()"-Befehl vor. Dieser soll genauso funktionieren wie der "speech()"-Befehl, nur dass die Sprechanimation nicht abgespielt wird. ...wie schauts aus?

[Schiman]

Ich hatte mich schonmal damit auseinandergesetzt, wie innere Monologe am besten umzusetzen seien. Das heißt der Spieler erfährt die Gedanken des Charakters. Dazu braucht man einen Speech-Befehl, aber die Reden-Animation soll nicht abgespielt werden, weil der Charakter das ja nur denkt.

Workaround 1: Offspeech
Workaround 2: Charakter für die Zeit des inneren Monologs ersetzen (hin- und zurückbeamen) durch einen Klon, dessen Sprechanimation leer ist

Da beide Workarounds viel zu umständlich sind, wenn man bedenkt, dass es eigentlich ganz gebräuchlich ist, den Charakter laut denken zu lassen, schlage ich einen "think()"-Befehl vor. Dieser soll genauso funktionieren wie der "speech()"-Befehl, nur dass die Sprechanimation nicht abgespielt wird. ...wie schauts aus?

Workaround 1 verwende ich übrigens mit offspeech(100;0;...).
Dadurch wird der Offspeech ganz oben rechts in der Ecke angezeigt... Ich denke das ist Ok, obwohl ich ihn schon lieber unten in der Mitte hätte.. naja.

[Baelavay]

Der Nachteil von Workaround 1 ist, dass die Textfarbe sich dann u.U. von der des Charakters unterscheidet, da du beim Offspeech leider (!) keine Farbe einstellen kannst. Aber da bin ich schon beim nächsten Wunsch...

[Schiman]

da du beim Offspeech leider (!) keine Farbe einstellen kannst. Aber da bin ich schon beim nächsten Wunsch...

Ähm hä??

offtextcolor (Rot ; Grün ; Blau)
Setzt die Farbe für den Offtext d.h. die Farbe des Textes für den Offspeech Befehl.

[Baelavay]

Ah ja, den gabs ja auch noch.
Dann kann man Workaround 1 benutzen, wenn auch umständlich...

Code: Select all

setnum(offspeech-x;[charx:char]/25)
setnum(offspeech-y;[chary:char]/25)
setnum(offspeech-x;+1)
setnum(offspeech-y;+1)
offtextcolor(r;g;b)
offspeech([offspeech-x];[offspeech-y];text;sample)

Habs mal so reingeschrieben damit ichs zu gegebener Zeit nachschlagen kann.

Damit sollte sich "think()" glaube ich erledigt haben. Na wenigstens ist das jetzt geklärt.

[Schiman]

Aha... und das funzt? Aus irgendeinem Grund habe ich damals diese Methode verworfen... Nur welcher war das .
Ich habe nämlich auch schon daran gedacht, habe mich dann aber für die Rechts-Oben Variante entschieden... Das hatte einen gewichtigen Grund.. Leider schon über nen Jahr her und ich weiß net mehr -.-.

Edit: Thread rausgekramt und Grund gefunden^^ (http://board.adventure-creator.com/view ... =offspeech). Das wars.. und deshalb geht das mit der Offspeech-Zentrierung nicht.

(Ist übrigens überhaubt noch nicht über ein Jahr her... Ich dachte das liegt schon länger zurück... naja).

[Baelavay]

Praktisch fände ich es, den gesamten Skriptablauf pausieren zu können ("freeze"), etwa über die Devmode-Konsole. Ich hoffe, das wurde nicht schon vorgeschlagen...

[Schiman]

Praktisch fände ich es, den gesamten Skriptablauf pausieren zu können ("freeze"), etwa über die Devmode-Konsole. Ich hoffe, das wurde nicht schon vorgeschlagen...

Ist ja krass. Heute dachte ich das auch^^. War gerade im Kampftesten und da klingelt das Telefon. Da wäre son Freeze Befehl echt nicht schlecht. So musste ich den Kampf eben neu starten.

[japanhonk]

Hi,

also ich würde mir wünschen, dass der Particle Befehl um eine Variante
ergänzt wird : Ist als Richtung 360 angegeben, könnten die Partikel dann
von einem Punkt in der Mitte oder einem definiertem Bereich in der Mitte des Screens nach aussen laufen. Muss den Geradeausflug durch Sterne
noch mit einzelnen Objekten und Moveobj regeln...

und im Editor selber wäre es gut, dass man nicht alle Ordner öffnen muss, wenn man etwas verschieben will. Ist die Liste lang, kann ich das unterste Element nicht in den Obersten Ordner schieben, weil der sich stets automatisch öffnet und ich das Element NUR auf den ORDNER ziehen kann, damit es auch verschben wird...Wenn er aber geschlossen bliebe beim draufziehen, wäre es besser.

Gruss

Manni

[Schiman]

Hi,

also ich würde mir wünschen, dass der Particle Befehl um eine Variante
ergänzt wird : Ist als Richtung 360 angegeben, könnten die Partikel dann
von einem Punkt in der Mitte oder einem definiertem Bereich in der Mitte des Screens nach aussen laufen. Muss den Geradeausflug durch Sterne
noch mit einzelnen Objekten und Moveobj regeln...

und im Editor selber wäre es gut, dass man nicht alle Ordner öffnen muss, wenn man etwas verschieben will. Ist die Liste lang, kann ich das unterste Element nicht in den Obersten Ordner schieben, weil der sich stets automatisch öffnet und ich das Element NUR auf den ORDNER ziehen kann, damit es auch verschben wird...Wenn er aber geschlossen bliebe beim draufziehen, wäre es besser.

Gruss

Manni

Ich finde beide Vorschläge ziemlich gut.
Der erste wird wohl nicht machbar sein, das ist echt ne Menge Aufwand. Wenn man bissel drüber nachdenkt, merkt man wieviele neue Parameter da mit angegeben werden müssen.

Aber der zweite ist echt net schlecht. Hatte auch schon diverse nervige Minuten damit verbracht^^.