Es gibt 161 Antworten in diesem Thema. Der letzte Beitrag () ist von seh.
Der Schaden könnte sich ja auch automatisch langsam wieder abbauen.
Mit freundlichen Grüßen,
Thunderbolt
Achtung: Die Versionen die ich zurzeit hochlade sind bloß Tests.. Es fehlen noch GUI und andere fundamentale Komponenten eines Spiels.
Freut mich das man überhaupt Burgen bauen kann und es nicht crasht .. Glück gehabt ( =
Fadenkreuz wird mit dem GUI implementiert, bald .
Liebe Grüße und herzlichen Dank für eure Partizipation.
Und Gott alleine weiß alles am allerbesten und besser.
@Thunderbolt ich denk des braucht zuviel Leisung und noch mehr Speicher...
Lg Mokki
Smartnotr - ein intelligentes Notizprogramm
zum Thread
Hm... eine automatische Regeneration klingt nicht schlecht.
Zu RAM: Zurzeit werden für eine 15x15 große Map um die 70 MB Arbeitsspeicher beansprucht.
Maximal wird eine Sichtweite von 25 Chunks erlaubt sein ( das sind 25x25, Minecraft-Far Einstellung) und das sind dann 167 MB...
Leistung wird dadurch hoffentlich minimal beansprucht zumal die Generierung eines Chunks wenige Millisekunden benötigt.
Das merkt der Nutzer gar nicht wenn neue Daten an die Grafikkarte gesendet werden, sind einige bytes...
Also möglich ist es ... werde aber die Chunk Algorithmus etwas modifizieren.
Zurzeit ist es so, dass wenn ein Würfel aus dem Chunk entfernt wird, der ganze Chunk neu erstellt wird.
Konsequenterweise heißt das, alle BoundingBoxes und Würfel-Seiten zu löschen und neu zu erstellen.
Stattdessen werden bald _eben nur noch Veränderungen aktualisiert.
Wären 230 MB RAM denn zu viel?
Ich meine.. etwas höhere Ansprüche dürfen an moderne PC doch gestellt sein.
Ist theoretisch alles sicher.
Prüft die Version im GIT, und downloaded von GitHub die aktuelle ZIP-Repräsentation der Repositories.
SSL!
Und Gott alleine weiß alles am allerbesten und besser.
Also bei mir ist das Spiel bisher erst ein einziges Mal abgestürzt. Ich habe sehr tief gegraben, und mich runterbewegt, und stand genau an der Grenze zwischen der Grenzen zweier Blocks, setzte einen, in ziemlich genau dem Moment, indem ich die Grenze zu dem Block überschritt.
PS: Wenn das Spiel bis stabil genug ist / das Speichern der Welt möglich ist, werde ich dir eine schöne Burg bauen. Damit kannst du dann Werbung machen!
There are only 10 types of poeple in the world: Those who understand binary and those who don't.
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Galmaris P“ ()
Bei Erde macht der sichtbare Schaden für mich wenig Sinn...Vllt könntest du das speichern/reparieren von dem Blocktyp abhängig machen...Erde verliert den sichtbaren Schaden sehr schnell, Gemauertewände (aus Steinblöcken) behalten ihn. Da du eine Art Shooter vllt implementieren würdest, könnte man so auch den Geschossschaden sichtbar machen.
Würfel entfernen, ohne den Chunk in Gänze zu regenerieren, nun möglich
Das neue Update erlaubt es Würfel zu entfernen, ohne den ganzen Chunk zu aktualisieren.
So bleiben die dem entfernten Würfel anliegenden geschädigten Würfel erhalten.
Es fehlen noch folgende elementare Funktionalitäten:
Erklärt sich jemand bereit Tester zu werden?
Wer Bugs findet wird natürlich (irgendwann) in den Credits (wenn diese _ implementiert wird) erwähnt ( =
Und Gott alleine weiß alles am allerbesten und besser.
Erste Impressionen: Neue Chunk-Klasse in Kombination mit Licht:
Und Gott alleine weiß alles am allerbesten und besser.
Soll Feuchtigkeit implementiert werden?
Heißt: Wenn ein Würfel exemplarisch von einem Regentropfen benässt wird, dieser seine Farbe entsprechend wechselt:
Und Gott alleine weiß alles am allerbesten und besser.
ich würde es nur implementieren wenn es keine "harten" Grenzen gibt. Sprich Ein Blick ist nass und gibt seine feuchte an die umliegenden Blöcke teilweise mit ab, sodass die angrenzenden Blöcke eine "feucht" Textur verpasst bekommen um einen Auslauf zu haben, so ähnlich wie dein Licht verlauf
Jap, gute Idee.
Und Gott alleine weiß alles am allerbesten und besser.
Ich muss mein Lob aussprechen, ich finde es gut, wie du am Projekt arbeitest
Schön zu sehen, in deinen Posts, was du alles machst, das ist echt gut!
Weiter so!
Ihr sucht Webspace für eure Projekte? Dann sagt bescheid - kostenfrei und ohne Werbung!
Man könnte diese "Auslauf"-Idee auch auf den Schaden an den Blöcken anwenden...
There are only 10 types of poeple in the world: Those who understand binary and those who don't.
Erste Versuche: Höhlen!!
Erste Versuche Höhlensystem zu implementieren:
Wird wohl noch einen effizienten Culling implementieren müssen... @jvbsl Hast du Erfahrung mit Höhlensystemen?
Post scriptum: Soll Sand gravitative Kraft erfahren?
Und Gott alleine weiß alles am allerbesten und besser.
Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „φConst“ ()
meine einzige Erfahrung mit Höhlensystem sind gesammelte Ideen, hab noch nichts davon implementiert.
Meine aktuellste Idee war über nen Perlin Worms Algorithmus, das dürfte dann aber sehr schwer aufwendig werden, da man die Höhlen als Strukturen sehen müsste um diese Fortlaufend generieren zu können, am liebsten wäre mir natürlich ein Worms Algorithmus, welcher nur die Position haben möchte, das dürfte aber denke ich nicht so einfach sein, deshalb glaube ich, dass das beste tatsächlich das überlagern und filter anwenden auf normale noises sein dürfte.
Richtung Turbulence oder Ridged Noise: campi3d.com/External/MariExten…elp/lib/RidgedOctaves.gif neilblevins.com/cg_education/turbulence/turb_max.jpg
aber müsst ich auch noch experimentieren, aber ich werd irgendwann mal wenn ich wieder lust habe überlegen, ob man nicht nen rein Koordinatenabhängigen Worms algo machen kann.
Ich wollte auch mal ne total überflüssige Signatur:
---Leer---
Ne also für Generierung von Höhlen habe ich eigentlich konkrete Pläne.
Meinte spezifisch Perfomace und Culling.
Und Gott alleine weiß alles am allerbesten und besser.
Was genau würdest du denn Cullen?
Frustum Culling ist denke ich mal das erste, dann könnte man evtl. Occlusion Culling noch implementieren, ich frage mich, ob man das nicht evtl. sogar drastisch optimieren kann, dadurch dass man nur mit Würfeln arbeitet und man dann diese Projezieren könnte, anstelle das Objekt tatsächlich zu rendern, aber wenn das dann auf der CPU passiert ists vmtl. langsamer.
Also könnte man einfach mal versuchen normal zu implementieren
Ich wollte auch mal ne total überflüssige Signatur:
---Leer---
Die Höhlen; sind ja zusätzliche Meshes die gerendert werden, obschon sie nicht gesehen werden, das ist gemeint.
Und Gott alleine weiß alles am allerbesten und besser.
Höhlensysteme verbunden!
Algorithmus ist relativ simpel, für den der das mal implementieren will:
1.) Jeder Chunk setzt beliebig eine sogenannte Node in CaveGenerator-Klasse
2.) Diese Nodes werden bearbeitet: Alles im Bereich der Sphere mit dem Radius N wird zu Luft ( Cubes[sphereY, sphereX, sphereZ]=0) [FLOOD FILL, sehr schnell]
3.) In CaveGenerator-Klasse die Nodes verbinden
=> für unser Beispiel:
C#-Quellcode
for (int i =0; i < Nodes.Count -1; i++)
Nodes[i].ConnectedTo = Nodes[i +1];
4.) Wenn Nodes aus der Liste bearbeitet sind, einen Ray ( PROVISORISCH) von Node A zu Node B generieren, den Richtungsvektor durch seine Länge dividieren ( sodass Länge 1 ist) und
von 0 bis max_lambda ( ursprüngliche Länge des Richtungsvektors) iterieren und weitere Sub-Nodes generieren, die ihrerseits alles Bereich der Sphere X,Y,Z die ID Luft setzen.
Der Algorithmus ist relativ schnell; man kann den Zwischenschritt mit dem Ray substituieren durch eine etwas komplexere Formel ( exemplarisch verkettete sigmoide Funtkionen wegen diesem weichen Übergang) und hat dann relativ natürliche
Höhlensysteme.
Was fehlt sind die Optimierungen( höchste Priorität), und "Naturierung" der Höhlen.. diese sehen nämlich gerade folgendergestalt aus:
Will jemand eigentlich mit-entwickeln?
Liebe Grüße.
Und Gott alleine weiß alles am allerbesten und besser.
Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „φConst“ ()
Warte mal, die Hölen sind extra Meshes, warum denn das? Den Sinn dahinter seh ich nicht so ganz?
Ich wollte auch mal ne total überflüssige Signatur:
---Leer---