[MonoGame]Minecraft-Klon

    • C#
    • .NET (FX) 4.5–4.8

    Es gibt 161 Antworten in diesem Thema. Der letzte Beitrag () ist von seh.

      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 :D .. 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.

      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 schöne ist, dass die VertexBuffers eines Chunks relativ klein sind.
      Man beachte bitte folgende Methode:
      github.com/NET-D3v3l0p3r/MCMG/…Chunk/Model/Chunk.cs#L221

      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.

      Post scriptum: Hier ein Updater: github.com/NET-D3v3l0p3r/MCMGUpdater

      Ist theoretisch alles sicher.
      Prüft die Version im GIT, und downloaded von GitHub die aktuelle ZIP-Repräsentation der Repositories.
      SSL! :D

      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! :D

      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:

      - Infinite Maps
      - Würfel hinzufügen :D
      - Verbessertes Licht
      - Biome
      - et cetera

      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.

      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

      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---

      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---

      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

      1. for (int i = 0; i < Nodes.Count - 1; i++)
      2. 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“ ()

    Facebook
    Telefonspende