Seite 4 von 4 ErsteErste 1234
Ergebnis 46 bis 49 von 49

Thema: [RL(?)] Plagiarismus als höchste Form der Wertschätzung

  1. #46
    Registrierter Benutzer Avatar von v33l3dn3M
    Registriert seit
    29.12.11
    Beiträge
    5.231

    Angriffs-UI-Komponenten, Teil 2

    Also, man könnte ihn auch genausogut als einen "Golen" interpretieren, statt "Goler". Aber immerhin dem.



    Man könnte neben dem Namen und dem vollen Namen (auch die reguläre Box mit Länge 172 statt 110 ist für reguläre genretypische Namen ja etwas arg kurz, hab das schon an ein paar Ideen getestet) den Monstern auch noch einen Kurznamen verpassen, der dann in der Box Anwendung findet, falls sie so bleibt. Also "Geduldiger Golen/Goler" -> "Geduld. Golem" oder so. Oder man verkürzt die Namen generell auf die Länge, aber... nee. :mies.

    Ein anderes Problem ist die Darstellung der Effektivität, weil momentan der Schaden vorberechnet und an die UI-Komponente übergeben wird.

    Bild
    Naja, so sähe das Ding in etwa in Gesamtheit aus, vorerst. Habe statt eines Pfeils mal das provisorische Axtthema-/schema als Darstellung für Angriffe beibehalten, wenn man schon keine große Axthäufen bauen kann. Wird vielleicht trotzdem noch nach Effektivität rot oder grün statt orange eingefärbt, aber erstmal nicht.
    Und mit verkürzem Namen, etwas unglücklich, aber in der Darstellungsform leider notwendig.


    Nun hatte die werte Referenz noch einen lustigen Stempel, wenn ein Monster beim Angriff sein Leben aushauchen würde, würde ich eigentlich gerne auch so einbauen... Die SEIB2 hat eine Größe von 192x176...

    Bild
    Nur natürlich doof, wenn es sich später herausstellt, dass die Annahme von 192x176 (hat die Platzhaltertextur dahinter, aber die wird halt gestreckt ) gar nicht stimmt, es sind selbst ohne Rand schon 224 Pixel, wie auch in der regulären Box. War auch ein ziemliches Gefrickel, den Text mit 315°-Drehung so passen zu lassen, dass man noch rechte Winkel drum kriegt. Egal, dann wird das halt zentriert, sieht sonst eh zu gestreckt aus. Gibt es auch in Englisch (da sagte es meines Wissens in der Referenz nur "Destroy", aber so ist es konsistenter ). Wobei die englische Version eine ungerade Pixelzahl zu den Ecken übrig hat, also hört es oben ein bisschen früher auf als es unten anfängt. Schriftart wieder Noto Sans, Größe 34 oder so ging am besten.
    (habe nebenbei immerhin mal die HP-Anzeigen in Ordnung gebracht, die hatten Typkonvertierungsprobleme)

    Bild
    So. Oder doch lieber um 90° rotiert?

    Bild
    Glaube, die erste Variante beißt sich da weniger mit den Symbolen, oder? Vielleicht sogar unzentriert, damit sie ggf. von einem roten Sprite wegbleibt. Oder die Marker brauchen halt noch eine Umrandung.


    Bild
    ... was dann (nun wieder zurückrotiert) so aussähe. Irgendwie schon ein bisschen zu glatt, eventuell muss das rot vielleicht noch etwas aufgelockert werden. Erinnert mich gerade irgendwie an ...Monopoly...? Emoticon: kratz
    Angehängte Grafiken Angehängte Grafiken

  2. #47
    Registrierter Benutzer Avatar von Fimi
    Registriert seit
    12.08.10
    Beiträge
    23.279
    Wenn es im fertigen Spiel keinen "Schw. Tr. d. Le.en.-W." gibt, kriegst du aber was von mir zu hören!
    "They say that talking to yourself is a sign of mental stability... that's what i tell myself."

    Zitat Zitat von Fonte Randa Beitrag anzeigen
    Manchmal kann ich Fimi verstehen...
    Zitat Zitat von Kaiserin Uschi Beitrag anzeigen
    Ja, aber das ist nur ein Grundgesetzbruch, aber kein Verfassungsbrauch. Bring das mal vors Bundesgrundgericht ;)

  3. #48
    Registrierter Benutzer Avatar von v33l3dn3M
    Registriert seit
    29.12.11
    Beiträge
    5.231

    Die Runde Null, Teil 0,5 + mal wieder ein paar belanglose Überlegungen

    Ist notiert. Emoticon: preuss2 Könnte aber für das ganz kurze Textfeld in der Form wieder zu lang sein.



    Bevor es mit irgendwas substanzielle Fortschritte gibt, mal wieder eine Überarbeitung des Z-Ebenen-Konzepts
    Zitat Zitat von v33l3dn3M Beitrag anzeigen
    0 Landtextur
    Nichts 1 Diagonalenmarkierungen, ggf. Raster
    1 2 Begehbarkeitsmarkierungen
    2 Angreifbarkeitsmarkierungen (wollte die beiden Kategorien eigentlich erst zusammenfügen, aber andererseits, besser nicht...)
    3 Entitäten
    Nichts 4 Entitätsbeschädigungseffekte (Risse je nach HP-Prozentsatz)
    4 5 Freund/Feind-Markierungen (es sei denn, jede mögliche Entität bekommt einen Freund- und einen Feind-Sprite, mit dem sie initilisiert werden kann - das Referenzspiel macht das meinem Verständnis zufolge für die Figurenmodellierung auf dem Brett tatsächlich eher so, aber... ich glaube, ich mache das lieber als eine Art Overlay)
    Nichts 6 Effektindikatoren (zB für Zauber/Buffs)
    Nichts 7 Angreif Interagierbarkeitsmarkierungen
    5 8 Passiver Cursor
    6 9 Spielercursor
    7 10 Partikel (zB Schadenseffekte)

    20 UI-Hintergrund
    21 UI-Symbole und -Texte
    ... 21 Overlaymenüs (Escape-Menü, Detailinfoübersichten, ggf. Optionsmenü, da bin ich mir bei der Szenenübergangslogik noch nicht ganz sicher, ist aber auch erstmal egal)
    [/CODE]
    Das ist schon wieder veraltet, weil...:

    • An der Stelle "Landtexturen" ist mir noch immer unklar, ob die Darstellung Feld für Feld oder mit einer vorgezeichneten größeren Karte passieren soll, und... warum nicht beides? Dann wäre es sinnvoll für den Fall von Überlagerungen, den Einzeltexturfeldern ihre eigene Z-Schicht zu verpassen. Und seien es nur Landschaftspartikel, keine vollen Texturen. Mal sehen.
    • Diagonalenmarkierungen und Raster: würde definitiv noch ein Raster miteinbringen wollen. Die Idee dazu: jedes Feld könnte eine vergrabene Textur (auf Z-Ebene 2 dann) haben, die das Raster darstellt, und, und das ist der Knackpunkt, damit könnten nicht begehbare Felder eine Sonderkennzeichnung erhalten. Ob es allerdings sinnvoll wäre, die Diagnonalenmarkierungen auf derselben Ebene zu behalten oder nicht... warum nicht?
    • Begehbarkeitsmarkierungen - zwei Änderungen dazu: 1. mit der Einführung der schwachen Begehbarkeitsmarker können die eigentlich gerne oberhalb von Entitäten erscheinen, die Reihenfolge kam glaube ich von der Idee, dass die nichtfeindliche Entität den Begehbarkeitsmarker einfach überschatten sollte und damit "schwach" machen sollte. Von daher können die eigentlich wieder direkt unter die Interagierbarkeitsmarkierungen.
      Es gibt noch einen zweiten Kontext, in dem diese Kategorie relevant ist, das ist besagte dynamische Entitätenplatzierung (wodurch ich eigentlich erst auf die Idee kam, das noch mal neu aufzurollen) - da kann man unbedenklich die selbe Z-Schicht für verwenden, es braucht halt wieder nur starke und schwache Markierungen.
    • "Entitätsbeschädigungseffekte" - ob die wirklich sinnvoll sind? dazu müsste erstmal definiert sein, welches Format die Viechersprites überhaupt erhalten. Ein bisschen vom Feld sollte schon noch durchschauen, 64x64 wird das nicht. Wäre trotzdem eher geneigt, ein Portraitformat als im Offenen stehende Sprites zu verwenden - vielleicht nicht quadratisch, sondern statt Kreisen mit vielleicht Sechs- oder Achtecken? Solange sie nicht offen stehen, sollte die Darstellung solcher Effekte nicht das Problem sein, außer bei den animierten Kristallen. Entweder müsste da jeder Frame (sind zum Glück momentan nur 4, viel mehr Kanten passten nicht in die Pixelzahl ) geupdated werden und eine Extraanimation mit Rissen eingeladen (vielleicht könnte man diese Animation sogar separat machen und für alle 8 Kristalltypen verwenden - wahrscheinlich geht das natürlich nicht. )
      Was man allerdings noch davor schieben könnte, sind entitätenspezifische passive Partikel, die eigentlich nur die Kristalle betreffen würden (Elementareffekte wie Nebel, Stürme, Sporen, Blitze, Strahlung...). Wenn beidseitig zu kompliziert ist, am ehesten sogar hinter die Kristalle. Ist nicht so wichtig und käme mit zuletzt, aber man kann ja mal Platz dafür offenhalten.
    • Freund/Feind-Markierungen - deren Platzierung ist eigentlich relativ egal, solange mindestens auf Entitätenebene aber unter Effektindikatoren landen. Kann davon auch mehr als 2 geben, man muss ja dem 1v1-Format keine Nibelungentreue schwören. Bis 8 Spieler?
    • Cursor: der braucht, egal ob er gelb bleibt und mit Sand Probleme kriegt, oder die Farbe ändert und mit anderen Dingen Probleme kriegt, noch einen Kontrastmodus. An sich nichts allzu kompliziertes. Braucht auch keine Z-Ebene, wollte ich nur mal protokolliert haben.


    Hm, tja, würde jedenfalls den Großteil des Gesamten noch mal um 2 oder 3 Felder Z verschieben, kursive sind noch nicht existent:
    [CODE]0 vorgeladene Landtextur
    1 dynamische Landtextur
    2 Raster inkl. Unbegehbarkeitsmarkierungen
    3 Diagonalenmarkierungen
    4 Kristallpartikeleffekte
    5 Entitäten
    6 Entitätsbeschädigungseffekte
    7 Spielerzugehörigkeitsmarkierungen
    8 Effektindikatoren
    9 Begehbarkeitsmarkierungen
    10 Interagierbarkeitsmarkierungen
    11 Passiver Cursor
    12 Spielercursor
    13 Partikel

    Dazu braucht es natürlich zwei neue Buttons (dafür wird wohl die Sanduhr noch eine Stutzung erhalten müssen ), und es stellt sich eine Frage für den dynamischen Entitätenplatziermodus - sollte man in diesem zwischen Karte und Auswahlmenü hin- und herwechseln können, oder nicht? Wenn ja, bräuchte das noch einen Button? Lösungsidee: Man könnte einen Teil des Overlays dafür ausblendbar machen, und einen Teil einfach statisch lassen, wie minimierte Fenster. Müsste nur Methoden, um Tastendrucke und ggf. Controllerinput in dem Moment davon auffangen zu lassen. Aber das sollte nicht so schwer sein.

    Nun aber mal zum Thema.
    Der Vorgang sollte folgendermaßen ablaufen:

    Bild
    Fällt jetzt nicht ganz so schlimm aus wie die vorherigen Flussdiagramme. Der einzige Haken ist, wählt man seine aktive Selektion erst zum Zeitpunkt der Startposiauswahl von der nicht-wirklich-Ersatz-Bank, oder im Vorfeld? Ist halt ein Spielervorteil, sofern die KIs (wie im Referenztitel) fest vorgelegte Konstellationen haben, und man einfach auf ihre Auswahl reagieren kann.
    und, beim Auswürfeln darf der Wurfgewinner wählen, ob er Position auswählen und dafür spät ziehen oder den frühesten noch verbleibenden frühen Zugreihenfolgenpunkt haben will.
    Die Positionen sollten in den Kartendaten in einem Array stehen, in dem sie falls unausgeglichen nach Vorteil sortiert sind (damit KI immer die beste vorgefüttert kriegen kann, oder bei einem geringen Rationalitätswert vielleicht auch eine schlechtere auswürfeln), und das erste Feld dieses Arrays sollte immer das Standardfeld für den Kristall sein, selbst wenn der Kristall frei platzierbar ist. Der Rest ergibt sich dann von da aus... hoffentlich.

    Also, Gerüsttechnisch... Wo nimmt man die langfristig die Besetzung her, die man noch bevor man beginnt, die Reihenfolge zu bestimmen, braucht? Man könnte das direkt mit der Karte verankern, aber das wäre natürlich unvorteilhaft, wenn man irgendwas dynamisches dabei machen möchte, zB Charaktere auf anderen Karten auftreten lassen. Ging im Referenztitel zwar nicht, da war wirklich alles statisch vordefiniert, aber der ist ja trotz aller ... Konzeptinspirationen auch nicht der Goldstandard.

    In der Kampagne sind alle Begegnungen (vermutlich) statisch vordefiniert, aber wenn man im Postgame einen freien Spielmodus freischaltet...
    Es braucht eine Kampf-Vordefinitionsklasse, in der entweder die Kampagnenszenarien festgeschrieben stehen (und simple Arrays von Vordefinitionen können dann Fortschrittsunterteilungsgebiete bilden), oder die man zu einer Szenariozusammenstellungsauswahl für einen solchen freien Modus ableiten könnte (mit ein paar Validitätschecks und Kreuzreferenzen auf bestimmte Begrenzungen der Karten oder KI-Profile)


    Wie man dabei eventuell mehrere gleichzeitig agierende menschliche Spieler verwalten könnte, erschließt sich mir noch nicht ganz, aber das Hauptproblem dabei ist noch immer selektive Visibilität, die mir sich noch nicht ganz erschließt, ansonsten kann man jede Referenz auf "den Menschen" durch eine Schleife, die durch einen Menschenarray brettert, ersetzen.

    Also, die Kampfvordefinition muss separat, dann aber Reihenfolgenbestimmung (mit dafür dedizierten UI-Elementen) und Platzierung sowieso als Teil der dicken regulären "Combat"-Klasse. Oder -Szene.


    Bild
    Langsam füllt die Szenenauswahl aber auch die gesamte Suchbox aus und wird echt unübersichtlich, und das, obwohl ich die Skripte nicht im selben Ordner abgespeichert habe. Müsste die eventuell noch mal unterteilen, je nachdem, wie das noch anwächst. Nur spezifische Dinge definierende, von generischen abgeleitete Szenen (Geisterdefinitionen (bei denen ich mir noch immer nicht des entgültigen Formats sicher bin, wegen der elenden Specials ), Karten, Charaktere) kommen natürlich hier ohnehin nicht rein.

    Bild
    Soviel braucht es eigentlich gar nicht, was das angeht, zumindest in der Grundklasse. HumanPlayers eher so als Platzhalter für den Multiplayerfall () wenn, dann sehr viel später; denn dass der aktive Spieler selbst mitspielt, ist ja klar.
    und selbst wenn AIPlayers fast immer nur ein Element haben wird in der Kampagne, macht das ja nichts.

    Was mir nicht klar ist, ist wie man, zB im Falle einer dynamischen Szenarioauswahl aber nicht mal zwingend dann, die Parameter ohne Konstruktoren an die Combat-Klasse übergeben würde. Denn wenn man ein "change_scene" macht, ist erstmal alles in anderen Szenen geladene weg. In die globalen Variablen will ich auch nicht allzu viel großes Zeug stopfen. Vielleicht kann man die Combatszene vorladen, eine Parameterübergabefunktion aufrufen, und dann erst voll zu ihr wechseln? Da muss ich noch mal Youtubetutorials durchstöbern und hoffen, dass es was dazu gibt, müsste ja eigentlich ein häufiges Problem sein.
    Angehängte Grafiken Angehängte Grafiken
    Geändert von v33l3dn3M (21. Oktober 2020 um 22:31 Uhr)

  4. #49
    Registrierter Benutzer Avatar von v33l3dn3M
    Registriert seit
    29.12.11
    Beiträge
    5.231

    Spielerreihenfolgenbestimmung, Teil 1

    War die letzten Tage etwas ausgelaugt und unmotiviert, heute wieder etwas mehr Fortschritt.
    Bild
    Zur Ermittlung der Spielerreihenfolge: Das Referenzspiel hatte hier eine Streichholzzieheinlage (in Form von aufdeckbaren Karten, aber kommt aufs Selbe hinaus), die wohl dem Zufall eine Schein-Wahl überlassen sollte. Fand ich nie besonders sinnvoll, das wird wegrationalisiert. Stattdessen wird die die Reihenfolge bestimmende Zufallszahl einem direkt als vollendete Tatsache hingestellt.

    Zweitens, die Wahl, vor der man steht: Als erster oder zweiter (bei mehr als zwei: letzter) zu ziehen. Hat erstmal wieder ein paar hässliche provisorische Icons bekommen. Im Referenzspiel war zweitere Option fast immer unvorteilhaft, da der Erstzieher die bereits platzierten Monster des Letzziehers ansehen konnte - dieser Vorteil sollte stattdessen dem Letztzieher zugute kommen, also muss in Runde 0 die Reihenfolge rückwärts durchinkrementiert werden. Früher ziehen ist (bzw war, aber das dürfte sich nicht großartig ändern) stark genug, um Positions und Präperationsvorteil beide aufzuwiegen - gerade da ersterer nicht bei allen Karten eine Rolle spielt. Folglich, Defensives zu Defensivem. Zum Glück hat die Arrayklasse sowohl eingebaute Shuffle- als auch Invert-Funktionen.

    Sollte man nun Letztwähler sein, wäre das Ergebnis ja bereits vorbestimmt, und die Auswahl quasi müßig. Das heißt, dafür müsste es eine Sonderkondition geben, nach der dann halt ein "Tja, Pech gehabt" eingeblendet wird, statt der Buttons. Oder vielleicht ändert sich ihre Textur einfach nur zu "ok ". Mal sehen.

    Wobei das Ding noch ein bisschen zu klein sein könnte, aber wie gesagt, mal sehen.

    Bild
    Das könnte dann in bestem Denglisch einfach so aussehen, nur halt mit unterschiedlichen Grafiken für die möglichen Zahlen. Habe bislang 9 Spielerfarbenmarker drin (das Einzige in der Zwischenzeit seit dem letzten Post noch gemachte ), also bis 9 momentan. Ungewöhnliche Zahl, ja. (Gedanke dahinter: alle 8 plus der Spieler - und ja, eine Teamzuweisungsmethodik fehlt noch, aber kommt wahrscheinlich mit rein)

    An der Stelle stellt sich nur die Frage, ob man eventuell entweder einem Button zwei Texturen verpassen kann (da das eine lokalisiert werden muss, das andere nicht), oder zwei Buttons dafür benötigen würde.

    Bild
    Das Ding an sich ist sogar relativ leichtgewichtig, viel mehr braucht es nicht Und die Combatklasse muss nur die Aufrufe und Ausgaben der Funktionen (außer der Button-verlinkten Pick-Funktionen) verwalten. Die LastPick-Funktion lösche ich entweder wieder raus oder schreibe sie noch um, in der ursprünglichen Form macht die erstmal keinen Sinn und ist folglich auch auskommentiert.
    (stattdessen kam dann unten referenzierte Funktion noch mit rein)

    Bild
    Und dann, irgendwie sowas, nur in fertig. Gerade spät genug, dass ich es für heute lieber mal sein und den Rohbau so stehen lasse und bis zum Wiederaufgriff noch mal überlegen kann, wie man die Einbindung der Sortierreihenfolgenentscheidungen am besten gestaltet.
    Angehängte Grafiken Angehängte Grafiken

Seite 4 von 4 ErsteErste 1234

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •