Ergebnis 1 bis 20 von 50

Thema: Was wäre euch wichtig an dem "perfekten" Maker?

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Einfach und mächtig ist immer gut, ja.
    Ich kann z.B. nicht programmieren, ich hab nur ne theoretische Idee davon wies geht und was machbar ist.
    Einfach und mächtig heißt fürn Programmierer meist enormer Designaufwand und extremes Know-How übers Subjekt vonnöten =)

    Aber auch n paar zusätzliche Features die man einstellen kann, aber nicht muss, um das ganze dann noch interessanter für Bastler zu gestalten ist denk ich mal nicht verkehrt wenn alles soweit steht.

    Zu den Autotiles...

    ja der Maker macht viel richtig, wenns drum geht ne platte textur auf den Boden zu setzen.

    Würd gern wissen wie du bei autotiles auf 256 Variationen kommst.
    soweit ich weiß hast du ohne komplettes texturteil 4 innere Ecken, 4 äußere Ecken und 4 gerade, macht 12 tiles (14 mit positiv und negativ textur).

    Aber die Anzahl tut eh nichts zur Sache.

    Ich dacht mehr dran dass man für eine Tileart mehrere Varianten hinterlegen kann.

    Heißt quasi, wenn man ne Bodentextur hat und von dieser 5 Varianten und man wählt dieses Tile aus und setzt es auf die Map dann wird einfach per Zufallsfaktor eines der hinterlegten Tiles gesetzt.
    Perfekt wäre wenn man den Zufallsfaktor dann selber mit ner Prozentangabe einstellen könnte (und diese Einstellungen auch speichern und laden könnte)

    Zum Beispiel mappen wir Gras, wir haben 5 16x16 Variationen, einige Texturen, einige Texturdetails
    Gras V1, Gras V2, kleine Blumen V1, kleine Blumen V2, große Blumen
    dann setzen wir hier % wie das Tile gesetzt wird
    30%,30%, 15%, 15%, 10%

    Und dann ziehen wir über n 10x10 Feld diese Textur, dann sollten wir eigentlich jedes Mal mit ner sehr detaillierten Textur ändern, die jedes mal anders aussieht, da der Zufallsfaktor viel Arbeit abnimmt.
    Heißt in 10 Sekunden mappen wir etwas schönes und detailliertes für das wir sonst an die 5-10 Minuten sitzen.

    Durch Einstellungen der Variationen können wir auch ne Wiese mit wenig Blumen und ne Wiese mit vielen Blumen relativ flott darstellen, da wir lediglich eine Einstellungändern müssen.
    (Wird dann vmtl Einstellungsdateien oder sowas brauche, wo die Werte gespeichert werden)

    Wir setzen noch einen drauf und arbeiten mit n paar zusätzlichen Metatiles (32x32 texturstücke, die nur in dieser Anordnung vorkommen - größere wie 48x48 gehen natürlich auch noch, aber man kann alles ausreizen...)
    Heißt erstmal müssen wir bei einer Textur rausfinden wie viel Platz für Metatiles ist, und dann, sofern Platz ist und nach einer Eingabe für Häufigkeit werden random Metas gesetzt

    sieht dann so aus:
    Klicke auf die Grafik für eine größere Ansicht 

Name:	tilesheme_metauvqe3.png 
Hits:	155 
Größe:	1,2 KB 
ID:	19358

    Die dunkelgrauen sind dann Metas, sowohl für die normalen, als auch für die Metas sind Variationen vorgesehen.

    Heißt wir kriegen noch mehr Variation rein gleichbleibendem Mappingaufwand,
    Plus metas sind noch für ne andre sache wichtig (heißt das system bräuchten wir noch) - gleich mehr dazu


    (Mach dir hie rden Anhang auf um mitzukommen)
    Nun gehen wir nen Schritt weiter und arbeiten mit ner klassischen Autotile Textur (G1)
    Für dieses Set gibt es wieder beliebig viele Variationen (G2)

    Mappingschema ist das selbe wie beim Maker
    Der Zufallsfaktor haut nur wieder zufällige Variationen rein
    (Beispiel G3)

    Nun packen wir wieder das meta Prinzip an - in diesem Falle große Ecken (G4)
    Große Ecken für Texturen haben nebst Kantenvariation und Eckenvariation den Vorteil, dass sie das Raster komplett aufbrechen
    heißt, dass der Zufallsgenerator random große Ecken verpflanzt, falls möglich und falls nicht zu viele andre große Ecken in der Nähe sind.

    Mappingaufwand wär immer noch gleich wie mit nem normalen Maker.
    Ein paar Adjustierungen in nem normalen Tilecode
    Mit der Methode brauchen wir nur mehr Grafik, aber die macht man einmal und edits sind verhältnismäßig leicht anzufertigen.
    Das Resultat sieht allerdings eher wie n großes Bild aus und nicht wie ne ständig kopierte Tileansammlung
    Je mehr Variationen man hat, desto besser wird natürlich das Ergebnis.
    Ha tman keine Variation, kann mans einstellen oder ne idente Textur einfach 5x abspeichern und iwann mal Variationen nachliefern

    Anhang 19357

    Wesentlich komplizierter wirds bei Klippen.
    Wenn man ne Standardgrafik hat wie G5, sieht man schon dass die Höhe ausschlaggebend für die Anzahl der Ecken ist (G6, G7)
    Ganz zu Schweigen von allen Verschnittvarianten von Tiles und Höhen

    Heißt für ein Klippenautotile müssten wir nem Tile unbedingt ne Z-information mitgeben (trotz 2D Map)

    Programmiert man allerdings 1x ne routine für alle Fälle für eine Höhe und geht davon aus, dass sich die dunkelgrauen Fronttiles bei ner höheren z-Höhe lediglich vermehren (Einstellung von Z) müsste das auch funktionieren.

    Heißt man müsste eigentlich mit ner einzelnen Höhe schon gut mappen können

    Als Zuckerguss:
    Wenn wir nen schritt weiter und uns die Höheninformationen (z-werte) anschauen, dann müsste man eigenlich mit der Tileinformation (Ecke, Gerade, ...) und der Differenz genau errechnen können was für eine Art von Tile auf dem Raster gezeigt werden muss.

    Heißt man könnte mit so einer Art von System in sekundenschnelle perspektivisch korrekte Klippen mappen, wenn man erst einmal ein tileset ausgearbeitet hat, dass alle Tilevarianten abdeckt.

    Und ums zu perfektionieren:
    (natürlich kann man dann auch nochmal nen Schritt weitergehen und große Klippenkanten bauen um ne perfekte Vielfalt zu haben =)

    Und wenn man Texturen und Klippen schnell mappen kann, brauchts eig. eh nur noch Details

    Die sind meist eh relativ schnell gesetzt
    Dann baut man ma richtig geile Maps in 10 minuten, für die man sonst 2-3 Stunden sitzt.v


    Wenn interessiert bist sowas für die Allgemeinheit oder grad mal testweise umzusetzen, würd ich mir vmtl sogar die Zeit nehmen und dafür Tiles fürn Testtileset bauen (oder von nem etablierten Stil z.B. Mack&Blue alle Varianten für ne Textur und ne Klippe zu editieren)


    Kommen wir nochmal zurück aufs setzen von Objekten:
    Objekte als quasi bild setzen funktioniert auch.
    Wenn man allerdings Häuser mit Türen setzt usw. (Die pixelgenau am Teleport/Tileraster ausgerichtet sein sollten) sollte man zumindest nen Button für ne Rasterfunktion haben, die diese Grafiken am Tileset ausrichtet.

    Geändert von Cyangmou (31.12.2013 um 03:00 Uhr)

  2. #2
    @Cornix
    Wenn der GUI-Code mächtig genug ist, dann ist eine höhere Programmiersprache wohl wirklich nicht nötig, aber wie würdest du den Code denn gestalten, um diese Mächtigkeit zu erreichen?

    Zitat Zitat
    Falls jemand wirklich bereit ist eine höhere Programmiersprache zu lernen, dann braucht er auch keinen Maker mehr, das ist für solch eine Person nur eine Zeitverschwendung.
    Das finde ich nicht, denn dieser jemand müsste ja Engine und Editor selbst schreiben. Dort fließt eine Menge Zeit rein, die mancher Entwickler lieber in das Spiel stecken möchte. Außerdem braucht man die Programmiersprache nicht komplett lernen. Eine "unsaubere" Lösung, bei der man die Sprache nur als Hilfsmittel benutzt, sieht für den Spieler von außen genauso wie eine "saubere" aus.

    Von den Lizenzprobleme mit MP3s hab ich auch schon gehört. OGG ist ja eigentlich bei gleicher Qualität sowieso kleiner, meine ich, nur war das nicht so, dass die Datei erst komplett in den Speicher geladen werden muss? Ich meine, dass es beim XP Lags gibt, wenn eine OGG-Datei das erste Mal gespielt wird.

  3. #3
    Mal abseits von Tilegrößen etc. ~ ich mag die Idee keine Scriptsprache zu geben, dafür umfangreichere Klickwerkzeuge.

    ich hatte in meinem 2k3 - Spiel schon vor DynRPG viele Kampfmechaniken eingebaut, die ich vorher noch in keinem Makerspiel gesehen hatte. Das ging auch, war aber umständlich, dabei gibt es zwei Konzepte.

    - DynRPG: Die Callbacks passieren oft, meine Lieblingscallbacks in jedem Frame, bzw. mehrere in jedem Frame, weil ich z.B. Helden- und Monsterfähigkeiten in ihrem Zeichenzyklus erledige, da dies der Callback ist, der genau zu ihnen gehört.
    - MakerEventcode: Die EventPages im Kampf sind sehr grobschlächtig.Zuerst einmal muss man sich eine Art Framework basteln, um überhaupt Custommechaniken einbauen zu können. Dazu gehört eine Eventseitenstruktur in jeder Monstergroup und dann entsprechender Code, um aus "Welches Ziel wurde ausgewählt?" und "Wieviel Mana wurde verbraucht?" zu schlussfolgern, was im Kampf passiert ist. Schlussfolgern, ich will nicht schätzen müssen, was die Helden in meinem Spiel gemacht haben!

    Hier mein Ansatz:
    Events wenn Dinge passieren.
    • Betrete die Map -> OnMapEntered
    • Verlasse die Map -> OnMapLeft
    • Held greift an -> OnHeroAction
    • Held ist damit fertig -> OnHeroActionDone
    • Held plötzlich tot -> OnHeroDead

    Und dann als Parameter, lokale Variable, sowas in der Art, Informationen was genau passiert ist. Wer hat angegriffen, wer wurde angegriffen und womit und hat es kritisch getroffen, hat es verfehlt?
    Auf vielen Makermaps ist das Konstrukt ParallelProcess->tu was ->erase. Was der Entwickler will ist etwas beim Betreten der Map zu tun. Die Struktur wird jedes mal neu gebaut. Event an die Map anhängen, tatarataaa.

  4. #4
    Zitat Zitat von Kelven Beitrag anzeigen
    @Cornix
    Wenn der GUI-Code mächtig genug ist, dann ist eine höhere Programmiersprache wohl wirklich nicht nötig, aber wie würdest du den Code denn gestalten, um diese Mächtigkeit zu erreichen?
    Das steht noch in Frage ob >ich< dazu in der Lage wäre.
    Ganz allgemein würde es bereits ausreichen alle Arten von Attributen mit Get- und Set-Methoden zur Verfügung zu stellen. Dazu einen Variablen-Manager mit dem man alle Arten von Objekten in Spiel referenzieren kann und dann einfache Datenstrukturen wie Arrays und Collections, vielleicht auch noch Sortierbare Listen und definitiv Hashtables die von dem Benutzer verwendet werden können.
    Das ganze in einen freundlichen und dokumentierten GUI-Code eingebaut, welcher sich darum kümmert alle illegalen Eingaben von vornherein abzufangen.


    Zitat Zitat von Kelven Beitrag anzeigen
    Das finde ich nicht, denn dieser jemand müsste ja Engine und Editor selbst schreiben. Dort fließt eine Menge Zeit rein, die mancher Entwickler lieber in das Spiel stecken möchte. Außerdem braucht man die Programmiersprache nicht komplett lernen. Eine "unsaubere" Lösung, bei der man die Sprache nur als Hilfsmittel benutzt, sieht für den Spieler von außen genauso wie eine "saubere" aus.
    Niemand ist heutzutage dazu gezwungen eine Engine zu bauen. Soetwas bekommt man inzwischen überall im Internet als Template.
    Man kann auch immer die eigentliche Spielengine hinter dem Maker direkt als Bibliothek mit ausführlicher API veröffentlichen. Dann brauch sich niemand der wirklich programmieren kann mit etwas so klumpen wie dem Maker beschäftigen.

    Zitat Zitat von Kelven Beitrag anzeigen
    Von den Lizenzprobleme mit MP3s hab ich auch schon gehört. OGG ist ja eigentlich bei gleicher Qualität sowieso kleiner, meine ich, nur war das nicht so, dass die Datei erst komplett in den Speicher geladen werden muss? Ich meine, dass es beim XP Lags gibt, wenn eine OGG-Datei das erste Mal gespielt wird.
    Wer sagt, dass man die Dateien erst laden sollte wenn man sie abspielen will? Wenn kommerzielle Spiele das tun würden wäre der Spielspaß gegen null.

  5. #5
    Meine Welt wäre alleine durch eine "Suchen" und "Ersetzen"-Funktion schon ein ganzes Stück heller.
    Aber Gerüchte besagen da ist was Großartiges in der Mache...! *Richtung Grufty schiel*

Berechtigungen

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