Pen & Paper - Rollenspiel > Pen & Paper - Rollenspiel- & Weltenbau

Kartengröße (für Weltgenerator)

<< < (2/5) > >>

Sanguaire:
Du hast recht, das eine Welt schon viele Pixel hat. Aber man muß nicht die ganze Welt in maximal Auflösung nicht im Arbeitsspeicher halten. Man lagert normalerweise die unsichtbaren Bereiche/Details der Welt in einen Puffer aus. Hierdurch erhält man eine höhere Performance des Programms.

Ich denke Dark-Star sollte am Programmdesign noch etwas feilen. Auch bei den heutigen Arbeitsspeicherausbauten ist eine Pufferung ab einer gewissen Datenmenge nötig.

Grimnir:
Zunächst einmal: Das Projekt finde ich super. Ich habe mich auch schon sehr über Fraktale Weltgeneratoren geärgert, aus den gleichen Gründen, die Du anführst: Gewaltige Gebirgsmassive oder Hochebenen in der Mitte des Kontinents und so gut wie nie Küstenketten. Daher  :d

Was die Größe anbelangt, bin bin eigentlich für eine ganze Welt in Erdgröße. Selbst wenn ich mir später nur eine Region zum Bespielen aussuche, habe ich für mich gerne eine Verortung der mythisch-magischen Orte, die in der bespielten Region nur als Sagen auftauchen, z.B. sowas wie "Uluk hinter den Stürmen" oder "die Leviathane des gräsernen Meeres".

Außerdem ist durch die Generierung einer ganzen Welt diese auch gut für eine SF-Entdecker-Kampagne à la Traveller gut zu gebrauchen.

Tudor the Traveller:
Da (je nach Spielstil) die SC nicht immer in der gewählten Region bleiben, ist es zumindest grundsätzlich wünschenswert, das insgesamt erreichbare Gebiet wenigstens grob abgedeckt zu haben. Das ist natürlich je nach verwendetem System bzw. Genre auch wieder verschieden. Insofern sollte man wohl oder übel grundsätzlich von der ganzen "Welt", d.h. i.d.R. vom gesamten Planeten ausgehen.

Für die Größe des bespielten Gebiets hängt es davon ab, welche Klimazonen (natürlicherweise) vertreten sein sollen. Wenn ich sowohl Ewiges Eis als auch tropischen Regenwald drin haben will, sollte der Ausschnitt schon entsprechend groß sein. Dabei ist die Erde für Distanzen als gewohnter Bezugsrahmen immer ein solider Ausgangspunkt, finde ich.

Dark-Star:
Erstmal danke an euch  :D

Die Implementierung von Städten war für den Anfang nicht geplant, kann ja für Version 2 noch gemacht werden am Anfang sollte es nur die Möglichkeit geben das man Städtesymbole setzen kann, evtl auch ein automatischer Algorythmus den der Benutzer drüberlaufen lassen kann wenn er ein Gebiet generisch besiedeln lassen will.

Das Programm wird allein für die Plattentektonik schon den gesamten Planeten generieren. In diesem Rahmen wird das noch grob geschehen. Was Speicherbedarf und Rechenzeit angeht habe ich erstmal an einem Programm getestet das Punkte gleichmäßig auf einer Kugel verteil. Man muss ja wissen wie hardwarefressend ein Prozess in der Größenordnung überhaupt sein wird.
Grade schreibe ich an einer Methode wie man die einzelnen Bereiche in Abhängigkeit der Detailstufe ansteuert. (Hab mir schon meine Gedanken gemacht)
Für mich war hauptsächlich die Frage wie groß die feinstrukturierten Bereiche ausfallen werden damit ich es vermeiden kann, das man wenn nicht der Bedarf besteht alle Feinstrukturen überall generiert und gespeichert werden müssen. Sondern nur die in den Größenordnungen in denen Nutzer ihre Zoomkarte erzeugen wollen.
Aber das was Boba über die "Pixelzahl" sagt trifft schon teils recht gut. Wenn man sich auf Google Earth mal anguckt welche Strukturen man auf vollem Zoom out noch sieht bekommt man einen nett erschreckenden Detailgrad. Auf guter globaler Auflösung bräuchte man Punkte mit einem Abstand von grob 8km. Mit Abstrichen könnte man auch auf grob 18 oder 36km gehen.
Die darunterliegende Feinstruktur muss dann mindestens in 1km abstand ihre Punkte haben. Besser wäre noch ein 250m Abstand aber das kommt in Angriff wenn Speicher und Performance das noch zulassen.

An dem Sanguaire angesprochenen Auslagerungssystem arbeite ich grade ;) Auch wenn ich nach Möglichkeiten suche so wenig Speicher wie möglich zu verbrauchen. Aber mir ist auch klar das ich nicht 1,5 GB(aus der Luft gegriffene Zahl) mal völlig egomanisch an Stackspeicher anfordern kann.

Aber so wie viele von euch meinten das man grobe Züge generiert und nur auf Bedarf beim Zoom in oder auf Befehl interessante Bereiche verfeinert(am besten einstellbar) war schon so geplant.
Also das man auch sagen kann die SC´s wollen mal den anderen Kontinent besuchen fahren weil der interessant aussieht und man dann nach Reisezeit bzw Reinzoomen in den entsprechenden Bereich gleich dort weiter machen kann.

Aus diesem Grund versuche ich ja grad anhand eurer Angaben, für die Gebietsgrößen die ihr detailiert braucht, das Optimum für die Aufteilung und Größen der Feinstrukturbereiche auszuloten.

Sanguaire:
Mit welcher Programmiersprache arbeitest Du. Manchmal kann man sich durch die Wahl der Programmiersprache manche Optimierungen sparen.

Ich hoffe wirklich, das Du nicht soviel Stackspeicher reservierst  >;D. Dynamisch angelegter Speicher landet auf dem Heap  ;).

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete